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