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

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

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

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

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

1、不同類型簡訊間的相互影響

不同類型的簡訊特點不一樣，比如驗證碼簡訊實時性要求非常高，能多快就多快、營銷簡訊雖然實時性要求沒那麼高，但數量巨大，峰值QPS可能會過萬。

2、運營商情況複雜，穩定性問題突出

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

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

△產品快速迭代功能不一

雲片的產品一直在進行快速迭代，像報表、統計等功能，基本每周要發兩個版本，在快速迭代過程中如何保證產品核心流程的穩定也是系統架構設計中的挑戰。

基於以上挑戰，雲片設計了「非同步解耦」的分散式系統架構。

上圖是演化後的雲片系統架構，非同步解耦是核心，非同步帶來的好處是每個模塊可以獨立演進。首先，寫記錄的模塊，因為它不是影響簡訊能否到用戶手機上的核心流程，所以雲片把它非同步化了。另外是產品相關的模塊，也通過非同步日誌的形式，盡量保證主流程比較穩定，並且是盡量少依賴的狀態。

△雲片系統管理模塊

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

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

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

雲片系統架構演進中有幾點經驗可以分享給大家。

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

其次Procedure預路由，在Procedure端，不知道發的是哪個topic，比如雲片啟動時，突然進來了比較高的請求，會在獲取topic路由這裡有個鎖，整個過程就很慢，於是雲片就做了預路由，實現提前去獲取topic的路由。

最後雲片也做了topic均衡，因為默認自動創建的topic只會在一台broker，不然在broker重啟的時候就會變得不可用。

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

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

由於Android系統不夠穩定，如果簡訊只發到一台機器上出現問題，就覺得它有bug，並且切掉的話，很可能這是一個誤報。此外雲片還考慮到，假如整個杭州地區出現問題，而且監控機器也全部在杭州，是否也會出現問題，如果出現問題是否都要切掉，這樣會導致整個服務都不可用。基於這兩方面的因素，雲片監控機器是多區域分布的，通過這種方式一方面可以達到系統的智能性，另一方面可以儘可能地保障高可用性。

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

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