一、雲通訊部署架構面臨的挑戰：宕機、黑天鵝事件
數據統計顯示：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的主題分享：《雲通訊行業背景下的穩定性架構演進》。
演講者｜陳濤Qcon2017技術專場分享