阿里雲活動產品價格表（雲場景實踐研究第12期）

2023-05-01 01:55:59

隨著整體業務的高速發展、流量的爆發式增長，有貨對系統進行了大面積的重構。首先，數據中心從傳統的單一IDC演化成為「公有雲 IDC」混合模式，同時應用系統也從原來的單體全站應用演變到以微服務為核心的架構模式，並且從多級緩存、服務的降級等多維度、全方面地提升了系統的可用性。 有貨藉助阿里雲的能力降低了整體的硬體、運維成本，並且將系統前臺應用相關計算、緩存節點全部遷移到阿里雲上，能夠幫助系統更加有效地應對諸如雙11這樣的場景下的流量峰值衝擊。

「對於網際網路的業務而言，企業必須做到快速響應業務需求，同時網際網路業務需求是靈活多變的，傳統IDC模式很難保證在短時間內上線一款新的應用。對於像阿里雲這樣的公有雲來說，其具有的彈性伸縮能力，能應對頻繁業務活動；同時像雙十一之類的對於流量突發增長活動，公有雲可以採取峰值應對，彌補傳統IDC的不足。」

——李健

有貨CTO

採用的阿里雲產品

需要在前端使用阿里雲CDN來加速圖片、JS等靜態資源，提升用戶的體驗。

有貨基於「IDC 阿里雲」的系統架構

如圖所示的是有貨抽象化的混合雲系統架構的整個層次結構。中間是整個服務註冊中心，主要分為六層。客戶端採用多種高可用策略，在客戶端完成降級、緩存、Http DNS等操作；客戶端下側的入口層主要涉及智能DNS、高防DDOS、SLB、Nginx等；從入口層再往下是網關層，在網關層內完成安全、流控、降級等操作；核心業務服務層完成所有的核心業務邏輯，包括服務註冊、服務發現、服務調用等等；從服務層再往下就是緩存層，在緩存層內一是對熱點數據進行加速，同時也需要考慮緩存數據的更新時效等問題；最下面一層是數據層，主要的數據存儲在MySQL中，同時進行數據雙活操作，保證數據的一致性。圖中六層結構的左側是垂直運維平臺，平臺在每一層都有相關的運維監控工作，右邊是基於大數據平臺的數據分析系統。

2) 客戶端

在客戶端：

通過使用HttpDNS，解決LocalDNS的潛在問題。在移動端採取Http直連的模式，防止DNS劫持問題，通過HttpDNS Server獲取後端服務的IP列表，避免LocalDNS緩存問題，避免域名解析慢或者解析失敗，能快速應對故障處理。同時在高可用方面，混合雲的模式下，如果其中一個數據中心出現問題時，可以通過HttpDNS快速進行流量切換；

在前端使用阿里雲的CDN加速圖片、JS等靜態資源，極大的提升了用戶體驗；

App客戶端通過Cache-Control HTTP頭來定義自己的緩存策略，通過預加載和客戶端緩存，實現離線化，大幅度提升性能；

服務降級，客戶端根據降級策略可在特定條件下對非關鍵業務進行降級，以保證核心關鍵業務的高可用；

對網絡質量監測，根據用戶在2G/3G/4G/Wi-Fi等不同網絡環境下設置不同的超時參數，以及網絡服務的並發數量。同時根據不同的網絡質量設計不同的產品體驗；

業務異常監測，在客戶端監測用戶使用過程中的異常情況、快照信息，實時上報異常數據，實時定位分析問題；

如果App出現大面積故障，可快速切換至Web App模式，保障了系統的高可用。

3) 入口層

入口層使用智能DNS分發流量至混合雲的雙數據中心，將應用做成無狀態模式，在兩個應用中心做對等的部署，突破運營商地域限制，按照地域切分流量，比如將南方的數據流量切入到阿里雲上，將北方的流量切換到自建的IDC中。安全方面，使用阿里雲高防DDOS產品防護DDoS攻擊。使用阿里雲SLB作為應用層負載均衡，實現集群內水平伸縮，同時結合阿里雲的ECS，很好地應對流量高峰時、高峰過後的複雜情況。此外，接口層還使用自建Nginx Lua做反向代理、分流限流、AB測試、灰度發布、故障切換、服務降級等處理措施。

3) 網關層

入口層之下的網關層內也做了很多措施來保障系統高可用性。安全控制方面，在網關層統一完成客戶端請求的身份認證，統一完成數據的加密解密；分流與限流方面，將流量按業務切分，路由至後端不同業務線的服務中心，以實現後端服務的實時動態水平擴展。當流量超過預定閥值，系統出現瓶頸的時候自動限制流量進入後端服務，以防止雪崩效應。服務降級方面，在系統出現瓶頸是，自動降級非關鍵業務，以保證核心業務的正常運轉。熔斷機制方面，根據後端服務的健康狀況，自動熔斷對服務的調用，以防止雪崩效應。異步化方面，網關異步化調用後端服務，避免長期佔用請求線程，快速響應處理結果，快速釋放線程資源。在網關層，一級緩存用於加速熱點數據；二級緩存用戶容災。請求進入網絡層後首先調用一級緩存，如果一級緩存命中，直接將結果返回給客戶端；如果沒有命中，網關層會調用後端服務，從服務中返回數據，在這個過程中如果服務出現故障無法訪問時，網關會訪問二級緩存，因為二級緩存是用於容災處理，所以二級緩存的時間非常長，數據保存24小時。

4) 服務層

5) 緩存層

在不同的場景下，採用不同的緩存策略。在用戶數據（收藏夾、瀏覽記錄）持久化場景中，採用混合雲雙數據中心完全對等的部署方式、做雙寫雙活。每個數據中心微服務將數據寫入緩存時，均是將數據發送到當前數據中心的MQ中，讀取數據是直接從當前數據中心的Redis集群讀取。Redis集群同時訂閱兩個數據中心的MQ的數據，確保兩個數據中心部署的Redis集群完全對等，同時Redis集群中的數據也是全量數據，當一個數據中心出現問題時，可以將流量切換到另一個數據中心。

在共享數據加速，保持數據（如訂單數據）一致性的場景下，採用單主多從的緩存模式，在兩個數據中心更新緩存時，是先寫到一個Redis Master集群中，然後從一個Redis Master集群同步到兩個數據中心的Redis Slave集群中，整個請求的邏輯就是：請求進入其中一個機房的微服務中，微服務首先會讀取微服務本地的一級緩存，如果沒有命中，再去本數據中心的Redis Slave集群進行查詢，如果還是沒有命中，再回源到本數據中心的資料庫中進行查詢，將讀取後的數據寫入到Redis Master集群，同時更新本地的一級緩存和Redis Slave集群，當然Redis Master集群也會將數據同步更新到另一個數據中心的Redis Slave集群中。這種單寫多讀的緩存模式實現數據加速以及保證數據一致性的要求。目前這種跨機房的主從同步延時並不明顯，延遲在一兩毫秒左右。

在共享數據加速但不考慮數據（商品）一致性的場景下，也是採用多活的理念，即在兩個數據中心部署完全對等的緩存集群。在上圖的機房一中，當有數據請求時，首先從本地一級緩存進行查詢，如果沒有命中，再去查本地的Redis集群，依舊沒有命中時，回源到本地的資料庫進行查詢，同時將查詢到的數據更新到本數據中心的Redis集群。雖然兩個數據中心的緩存集群部署一致，但是在Redis集群中存的數據可能不一致。

6) 數據層

數據層作為六層架構中的最底層，主要的應用還是基於MySQL的主從模式。下面提到的特點是在非核心業務上的一些嘗試，並沒有大面積應用：

同城雙活，即由業務層來控制數據的實時性和最終一致性，而不是通過數據同步來保證實時性和一致性。

業務層雙寫，數據異步分發至兩個數據中心，任意機房寫入的數據通過異步消息的方式分發到另一個機房，以此來保證兩個機房數據的最終一致性。

業務層通過二級查詢保證數據的實時一致性，由於業務層雙寫只能保證數據的最終一致性，無法保證實時一致性，因此，針對具有實時一致性要求的業務場景，我們通過業務層的二級查詢來保證。

重複寫入應對單機房故障，當任意機房出現故障時，如果寫入的數據還沒有分發至另一個機房，則由業務層在可用機房重複寫入數據，通過算法來生成相同的ID。

通過failover庫為高可用提供雙重保險，針對流水型業務數據，在資料庫故障時，需要進行主從切換，此時通過業務層將所有數據的讀寫切換至failover庫，主庫恢復以後再將流量切回主庫。

垂直拆分與水平拆分結合使用。

有貨系統架構的服務化設計

有貨的架構設計之所以需要服務化，是因為在做服務化之前系統高度耦合，牽一髮而動全身，直接影響到系統可用性；同時業務相互影響，系統很難維護；系統邏輯過於耦合，很難進行水平擴展；也無法通過流控、降級等手段保障系統的可用性；此外由於系統的高度耦合，極易產生雪崩效應。因此基於上述原因，服務化改造勢在必行。

上圖是有貨服務化系統的架構，最上面一層是客戶端，客戶端下面就是服務網關層，再往下就是具體的業務服務中心，目前對電商而言三大核心就是商品、會員、訂單中心。圍繞服務中心的是一些服務治理策略，如流控/降級、負載均衡等。系統的最低層是服務註冊中心。

對於服務化而言，最核心的就是服務的發現、註冊、調用。目前有貨採用的是Spring Register Zookeeper搭建的最簡單的服務框架，通過Zookeeper完成的服務註冊和發現，通過Register完成服務的調用。

服務化還有一個很重要的要求就是服務化負載均衡，一般是有兩種方案：集中式的LoadBalance，在服務消費者和提供者之間通過阿里雲的SLB或者F5搭建獨立的LoadBalance，通過集中式的負載均衡設備完成對服務調用的負載均衡；在進程內做負載均衡，即軟負載的方式，將負載均衡策略滲入到服務框架裡面，服務消費者作為負載均衡的客戶端，請求只需要從服務註冊中心獲取最新的服務列表，利用服務框架自身攜帶的負載均衡策略，完成負載均衡的調用。

在服務降級方面，通過使用開源的Hystrix配置服務超時時間，當服務調用超時時，直接返回或執行Fallback邏輯。另外基於Hystrix提供的熔斷器組件，可以自動運行或手動調用對當前服務進行暫停後再重新調用服務。流量控制方面，通過計數器服務限定單位時間內當前服務的最大調用次數（比如600次/分鐘），如果超過則拒絕，以保證系統的可用性；同時為每個服務提供一個小的線程池，如果線程池已滿，調用將被立即拒絕，默認不採用排隊，加速失敗判定時間。

服務化中，對於服務的監控、性能優化以及調用鏈的分析也尤為重要。通過Hystrix提供的服務化監控工具實時觀察在線服務的運行狀態，有了監控之後可以進行相應的性能優化。對於調用鏈分析，當請求從網關層進入時，追加一個Trace ID，Trace ID會在整個調用過程中保留，最後通過分析Trace ID將整個請求的調用鏈串聯起來。

自動化運維平臺

目前採用的混合雲雙數據中心模式，如果依舊採用傳統的手工部署應用，做文件拷貝、同步等工作，很容易出現版本不一致、文件更新異常等問題。因此在混合雲模式下構建自動化運維平臺需要考慮以下核心問題：

首先在運維平臺上要能完成對雙雲的一鍵式的自動化部署發布，以及部署失敗後的一鍵快速回滾；

在運維平臺中需要完成對流量的管理控制，可以完成對整個應用系統的容量規劃；

最核心的部分是運維平臺實現監控和報警，包括對業務層級監控、應用系統的監控、以及系統層級的IO、磁碟、網絡的監控。

在運維平臺中，需要做到應對故障快速恢復的預案，分析系統可能出現的故障點，在出現故障時，通過自動化的腳本對故障進行恢復。

雲棲社區場景研究小組成員：賈子甲、仲浩

本文為雲棲社區原創內容，未經允許不得轉載。