混合雲自動化運維平臺

https://as.h5con.cn/product/819?_spam=cnblog

爲何選擇混合雲架構？

 

 

圖一 爲什麼選擇混合雲架構？

 

爲何選擇混合雲架構這個問題能夠拆成兩個問題，一是爲何使用公共雲？另外一個問題就是爲何不徹底使用公共雲，爲何還保留原來的IDC？採用這種混合雲的架構是基於如下幾個痛點考慮的：

1. 業務痛點：對於互聯網的業務而言，企業必須作到快速響應業務需求，同時互聯網業務需求是靈活多變的，傳統IDC模式很難保證在短期內上線一款新的應用。對於公共雲來講，其具備的彈性伸縮能力，能應對頻繁業務活動；同時像雙十一之類的對於流量突發增加活動，公共雲能夠採起峯值應對，彌補傳統IDC的不足；
2. 運維痛點：對於傳統的IDC，要完成一次具體的擴容，必需要從服務器的採購申請，再到服務器的上架，再去安裝操做系統，再去部署應用等等一系列操做，十分複雜。同時在擴容過程當中，不只流程過去繁瑣，還有可能遇到一系列的問題，好比由於服務器環境差別致使系統故障等問題。這些問題不只增長了運維過程當中的難度，還使得整個系統的可用性大大下降；
3. 成本控制：一方面使用公共雲能夠下降總體的硬件、運維成本；另外一方面從傳統的IDC遷移到公共雲上的遷移成本，包括遷移過程當中對系統進行改造和遷移時間的成本。因此基於二者考慮，最後選擇了混合雲的模式；
4. 安全控制：從安全角度出發，採用混合雲模式：將前臺應用相關計算、緩存節點所有遷移到阿里雲上。核心組數據依然保留在IDC中，保障核心數據的安全。

 

基於混合雲的系統架構

 

圖二 基於混合雲的系統架構

 

上圖是有貨抽象化的混合雲系統架構的整個層次結構。中間是整個服務註冊中心，主要分爲六層。客戶端採用多種高可用策略，在客戶端完成降級、緩存、Http DNS等操做；客戶端下側的入口層主要涉及智能DNS、高防DDOS、負載均衡、Nginx等；從入口層再往下是網關層，在網關層內完成安全、流控、降級等操做；核心業務服務層完成全部的核心業務邏輯，包括服務註冊、服務發現、服務調用等等；從服務層再往下就是緩存層，在緩存層內一是對熱點數據進行加速，同時也須要考慮緩存數據的更新時效等問題；最下面一層是數據層，主要的數據存儲在MySQL中，同時進行數據雙活操做，保證數據的一致性。

六層結構的左側是垂直運維平臺，平臺在每一層都有相關的運維監控工做，右邊是基於大數據平臺的數據分析系統。

 

圖三 客戶端

 

下面來具體對每一層架構進行分析。在客戶端：

1. 經過使用HttpDNS，解決LocalDNS的潛在問題。在移動端採起Http直連的模式，防止DNS劫持問題，經過HttpDNS Server獲取後端服務的IP列表，避免LocalDNS緩存問題，避免域名解析慢或者解析失敗，能快速應對故障處理。同時在高可用方面，混合雲的模式下，若是其中一個數據中心出現問題時，能夠經過HttpDNS快速進行流量切換；
2. 在前端使用阿里雲的CDN加速圖片、Js等靜態資源，極大的提高了用戶體驗；
3. App客戶端經過Cache-Control HTTP頭來定義本身的緩存策略，經過預加載和客戶端緩存，實現離線化，大幅度提高性能；
4. 服務降級，客戶端根據降級策略可在特定條件下對非關鍵業務進行降級，以保證核心關鍵業務的高可用；
5. 對網絡質量監測，根據用戶在2G/3G/4G/Wi-Fi等不一樣網絡環境下設置不一樣的超時參數，以及網絡服務的併發數量。同時根據不一樣的網絡質量設計不一樣的產品體驗；
6. 業務異常監測，在客戶端監測用戶使用過程當中的異常狀況、快照信息，實時上報異常數據，實時定位分析問題；
7. 若是App出現大面積故障，可快速切換至Web App模式，保障了系統的高可用。

圖四 入口層

 

入口層使用智能DNS分發流量至混合雲的雙數據中心，將應用作成無狀態模式，在兩個應用中心作對等的部署，突破運營商地域限制，按照地域切分流量，好比將南方的數據流量切入到阿里雲上，將北方的流量切換到自建的IDC中。

安全方面，使用阿里雲高防DDOS產品防禦DDoS攻擊。使用阿里雲負載均衡做爲應用層負載均衡，實現集羣內水平伸縮，同時結合阿里雲的雲服務器，很好地應對流量高峯時、高峯事後的複雜狀況。此外，接口層還使用自建Nginx+Lua作反向代理、分流限流、AB測試、灰度發佈、故障切換、服務降級等處理措施。

 

圖五 網關層

 

入口層之下的網關層內也作了不少措施來保障系統高可用性。安全控制方面，在網關層統一完成客戶端請求的身份認證，統一完成數據的加密解密；分流與限流方面，將流量按業務切分，路由至後端不一樣業務線的服務中心，以實現後端服務的實時動態水平擴展。當流量超過預約閥值，系統出現瓶頸的時候自動限制流量進入後端服務，以防止雪崩效應。服務降級方面，在系統出現瓶頸是，自動降級非關鍵業務，以保證核心業務的正常運轉。

熔斷機制方面，根據後端服務的健康情況，自動熔斷對服務的調用，以防止雪崩效應。異步化方面，網關異步化調用後端服務，避免長期佔用請求線程，快速響應處理結果，快速釋放線程資源。

在網關層，一級緩存用於加速熱點數據；二級緩存用戶容災。請求進入網絡層後首先調用一級緩存，若是一級緩存命中，直接將結果返回給客戶端；若是沒有命中，網關層會調用後端服務，從服務中返回數據，在這個過程當中若是服務出現故障沒法訪問時，網關會訪問二級緩存，由於二級緩存是用於容災處理，因此二級緩存的時間很是長，數據保存24小時。

 

圖六 服務層

服務層主要用於服務化的改造，將在以後的服務化章節詳解講解。

圖七 緩存層-用戶數據持久化場景

 

在不一樣的場景下，採用不一樣的緩存策略。在用戶數據（收藏夾、瀏覽記錄）持久化場景中，採用混合雲雙數據中心徹底對等的部署方式、作雙寫雙活。每一個數據中心微服務將數據寫入緩存時，均是將數據發送到當前數據中心的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集羣中存的數據可能不一致。

 

圖十 數據層

 

數據層做爲六層架構中的最底層，主要的應用仍是基於MySQL的主從模式。下面提到的特色是在非核心業務上的一些嘗試，並無大面積應用：

1. 同城雙活，即由業務層來控制數據的實時性和最終一致性，而不是經過數據同步來保證明時性和一致性。
2. 業務層雙寫，數據異步分發至兩個數據中心，任意機房寫入的數據經過異步消息的方式分發到另外一個機房，以此來保證兩個機房數據的最終一致性。
3. 業務層經過二級查詢保證數據的實時一致性，因爲業務層雙寫只能保證數據的最終一致性，沒法保證明時一致性，所以，針對具備實時一致性要求的業務場景，咱們經過業務層的二級查詢來保證。 
4. 重複寫入應對單機房故障，當任意機房出現故障時，若是寫入的數據尚未分發至另外一個機房，則由業務層在可用機房重複寫入數據，經過算法來生成相同的ID。
5. 經過failover庫爲高可用提供雙重保險，針對流水型業務數據，在數據庫故障時，須要進行主從切換，此時經過業務層將全部數據的讀寫切換至failover庫，主庫恢復之後再將流量切回主庫。
6. 垂直拆分與水平拆分結合使用。

 

服務化

 

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

 

 

圖十一 服務系統框架

 

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

 

 

圖十二 服務註冊、發現、調用

 

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

 

圖十三 服務化負載均衡

 

服務化還有一個很重要的要求就是服務化負載均衡，通常是有兩種方案：

1. 集中式的LoadBalance，在服務消費者和提供者之間經過阿里雲的負載均衡或者F5搭建獨立的LoadBalance，經過集中式的負載均衡設備完成對服務調用的負載均衡；
2. 在進程內作負載均衡，即軟負載的方式，將負載均衡策略滲入到服務框架裏面，服務消費者做爲負載均衡的客戶端，請求只須要從服務註冊中心獲取最新的服務列表，利用服務框架自身攜帶的負載均衡策略，完成負載均衡的調用。

 

圖十四 服務降級和流量控制

 

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

 

圖十五 服務化的監控、優化、調用鏈分析

 

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

 

 

自動化運維平臺

 

 

圖十六 自動化運維

 

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

1. 首先在運維平臺上要能完成對雙雲的一鍵式的自動化部署發佈，以及部署失敗後的一鍵快速回滾；
2. 在運維平臺中須要完成對流量的管理控制，能夠完成對整個應用系統的容量規劃；
3. 最核心的部分是運維平臺實現監控和報警，包括對業務層級監控、應用系統的監控、以及系統層級的IO、磁盤、網絡的監控。
4. 在運維平臺中，須要作到應對故障快速恢復的預案，分析系統可能出現的故障點，在出現故障時，經過自動化的腳本對故障進行恢復。

QA環節:

 

一、有貨歷史架構的演變歷程，達到什麼樣的規模時才選用混合雲模式？

答：企業到了必定階段，須要去考慮效率和成本時，以及系統的穩定性，天然會選擇混合雲的方式，目前是將須要彈性伸縮、流量突發的業務遷移到公共雲上，後臺運營等相對穩定的業務保留在傳統的IDC。當流量訪問併發達到500-1000時，經過IDC中增長物理機支撐帶來維護和成本上的問題時，去考慮選擇混合雲模式。

 

二、如何完成多中心的自動化部署？

答：有貨在這一方面作的比較簡單，經過簡單的腳本方式，使用Shell腳本打通版本管理、編譯打包、目標服務器，將它們串聯起來，在此基礎之上，再簡單的封裝一個圖形化的界面，方便操做和權限控制，底層就是調用這一套腳原本完成的。

 

三、爲何要進行異地的雙寫，這樣作成本是否是比較高？

答：異地的雙寫是針對不一樣的應用場景，對一些實時性和一致性要求非常很高的場景，整個應用容許必定的延遲，能夠選擇異地雙寫。異地雙寫的成本是很是高的，目前有貨是同城雙寫，IDC和公共雲之間經過專線鏈接，有效下降了時間延遲。

 

四、前臺後臺進了系統解耦，如何作到二者互不影響？

答：剛開始整個應用系統都在一個數據中心部署，前臺和後臺都採用同一套數據庫，後臺的批量操做有可能影響到前臺的運行。首先須要作數據庫的解耦，即前臺和後臺不共用數據庫，目前經過MQ的方式作先後臺的數據交互。

 

五、如何進行合理的服務拆分？

答：目前服務拆分是針對不一樣的業務線進行的，對於電商來說，會分爲商品、訂單、會員等幾個大的業務線，業務線對應着各類業務中心，服務中心下面還分佈着不一樣的服務集羣，目前採用的是面向領域的模式進行拆分。例如商品服務，將商品的價格、庫存等銷售屬性和非銷售屬性分別拆成不一樣的模型，針對不一樣的模型，進行提供服務。

 

六、保證系統高可用的核心理念？

答：核心理念不是讓系統很穩健，不出故障。而是偏偏相反，任何系統的節點，軟件或者硬件出現故障時，整個系統依舊可用，即某一點的故障不使得整個系統癱瘓。

 

關於分享者：

 

李健 有貨CTO

 

有貨旨打造中國潮流生態圈，其核心業務包括有貨App、YOHO、Mars應用。有貨也積極舉辦線下活動，例如舉辦潮流嘉年華等活動。YOHO!將在2016年5月在艾尚開3000平方米的旗艦店，將集理髮、拍照、咖啡、讀書等爲一體。該店將採用徹底的電子貨架，也是全球惟一一個徹底的電子貨架模式。