雲通信行業背景下雲片高可用架構演進之道

1、雲通信部署架構面臨的挑戰：宕機、黑天鵝事件

數據統計顯示：2016年Google Cloud的宕機時間總計爲47分鐘，微軟Azure服務宕機時間爲270分鐘，亞馬遜AWS宕機時間爲108分鐘。

做爲構建在IaaS之上的PaaS服務，雲片爲了防止雲服務廠商的故障形成影響，設計了多可用區的同城雙活架構，最大限度保證部署架構層面的高可用。

2、雲通信系統架構面臨三大挑戰

在系統架構上，雲通信系統主要面臨三大挑戰：

一、不一樣類型短信間的相互影響

不一樣類型的短信特色不同，好比驗證碼短信實時性要求很是高，能多快就多快、營銷短信雖然實時性要求沒那麼高，但數量巨大，峯值QPS可能會過萬。

二、運營商狀況複雜，穩定性問題突出

△運營商狀況複雜，帶來諸多問題

運營商的狀況比較複雜，這其中會遇到各類各樣的問題。首先是突發事件，好比在杭州G20期間有些通道就沒法正常運轉。其次有些代理商服務穩定性不高，RT會須要2-3s。另外也有些代理商會限制短信類型，好比只能髮帶驗證碼的短信。最後還有速率限制，有些通道最高2000/s，有些200/s通道間容量不一致。

三、產品頻繁迭代的過程當中如何保障系統穩定性

△產品快速迭代功能不一

雲片的產品一直在進行快速迭代，像報表、統計等功能，基本每週要發兩個版本，在快速迭代過程當中如何保證產品核心流程的穩定也是系統架構設計中的挑戰。
基於以上挑戰，雲片設計了「異步解耦」的分佈式系統架構。

△雲片系統架構

上圖是演化後的雲片系統架構，異步解耦是核心，異步帶來的好處是每一個模塊能夠獨立演進。首先，寫記錄的模塊，由於它不是影響短信可否到用戶手機上的核心流程，因此雲片把它異步化了。另外是產品相關的模塊，也經過異步日誌的形式，儘可能保證主流程比較穩定，而且是儘可能少依賴的狀態。

△雲片系統管理模塊

上圖是雲片系統管控模塊，它很好的解決了前面所提到的問題。好比有些通道只能發包含某個關鍵字的短信，雲片系統加了一個模塊之後，經過不一樣的隊列，不一樣的通道，對不一樣的地域發送不一樣的短信。另外有些通道可能卡住了，可經過監控模塊監測到而後進行實時的切換。還有資源的隔離，前面提到有些通道的數據容量不同，不一樣的速率對不一樣的資源，經過這種模式也達到了一個隔離。包括不一樣的業務類型進來之後，也會進入不一樣的通道。

△雲片系統架構

雲片系統架構消息中間件採用的是RocketMQ，它的全部角色節點都是無狀態的，能夠很是方便地實現橫向擴容，另外也可以與雲片系統多可用區部署的方案結合。

四、高可用系統架構設計經驗分享

雲片系統架構演進中有幾點經驗能夠分享給你們。

首先關於消息隊列的使用，須要有堆積的監控告警，好比出現問題時消息很容易堆積，監控報警就要作好。

其次Procedure預路由，在Procedure端，不知道發的是哪一個topic，好比雲片啓動時，忽然進來了比較高的請求，會在獲取topic路由這裏有個鎖，整個過程就很慢，因而云片就作了預路由，實現提早去獲取topic的路由。

最後雲片也作了topic均衡，由於默認自動建立的topic只會在一臺broker，否則在broker重啓的時候就會變得不可用。

3、智能監控：保障系統穩定性的關鍵因素

△雲片智能監控系統

上圖是雲片智能監控系統架構。完善的監控系統是穩定性的關鍵，雲片有一個監控中心，它跟普通的用戶請求是同樣的，這些短信會到雲片的監控機上面，而後雲片開發了一個Android的App，在上面獲取到短信，把這個信息彙報給監控對象。若是一段時間沒收到彙報，基本能夠判斷某條短信的通道存在問題。此外，管控模塊提供通道切換的功能，發現某個通道有問題就能夠切掉，經過這種方式雲片實現了智能化的通道監管和切換。

因爲Android系統不夠穩定，若是短信只發到一臺機器上出現問題，就以爲它有bug，而且切掉的話，極可能這是一個誤報。此外雲片還考慮到，假如整個杭州地區出現問題，並且監控機器也所有在杭州，是否也會出現問題，若是出現問題是否都要切掉，這樣會致使整個服務都不可用。基於這兩方面的因素，雲片監控機器是多區域分佈的，經過這種方式一方面能夠達到系統的智能性，另外一方面能夠儘量地保障高可用性。

總的來講，雲片系統架構的演進：基於系統面臨的諸多挑戰進行系統架構的部署，並有智能監控系統確保流程的穩定性。在系統架構設計過程當中，雲片網資深架構師陳濤分享了一條重要的經驗，把「簡單的事情」作到極致，不斷進行產品迭代。

以上內容來自2017年4月16日，雲片網資深架構師陳濤在QCon的主題分享：《雲通信行業背景下的穩定性架構演進》。

演講者｜陳濤Qcon2017技術專場分享