圖十 業(yè)務(wù)混合云部署形態(tài)
上圖是2016年春晚上典型的業(yè)務(wù)混合云部署形態(tài)。內(nèi)部是典型的后端互聯(lián)網(wǎng)服務(wù)技術(shù)站，通過四層的負載，通過Nginx實現(xiàn)七層負載，再往后是一些WEB層的計算和RPC服務(wù)，最下面是緩存層的資源、數(shù)據(jù)庫。由于數(shù)據(jù)庫的請求量和數(shù)據(jù)安全要求比較高，因此暫時沒有將DB層放到公有云上。架構(gòu)的最右側(cè)是采用了負載均衡服務(wù)、之下的RPC、WEB、Nginx都是部署在 云服務(wù)器 上的。
圖十一 彈性調(diào)度機制
在具體的彈性調(diào)度框架上采用了開源的解決方案，例如Swarm、Mesos等。在它們的基礎(chǔ)上封裝了統(tǒng)一調(diào)度的API，將原來專有云內(nèi)分散的各個應(yīng)用平臺統(tǒng)一到一起，大大節(jié)省在基礎(chǔ)運維上的時間成本。
圖十二容量評估
通過在線容量評估，決策某一個服務(wù)是否需要在公有云上擴容。通過選取服務(wù)的多個業(yè)務(wù)上的指標(biāo)來綜合評價某一個業(yè)務(wù)是否存在流量突增或者性能的瓶頸。比如采集平均響應(yīng)時間和QPS、內(nèi)部計算資源線程池，最終計算出總體資源池的冗余百分比，用于決策是否需要動態(tài)擴容。
編排與容器發(fā)現(xiàn)
業(yè)務(wù)部署到阿里云之后，需要快速地將業(yè)務(wù)提供方與調(diào)用方快速地銜接起來，就需要編排和容器發(fā)現(xiàn)的機制。
圖十三 業(yè)務(wù)容器編排
在實現(xiàn)DCP系統(tǒng)環(huán)節(jié)內(nèi)部可能存在微博內(nèi)部其他的系統(tǒng)，比如原有的運維系統(tǒng)、發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)等等。這些原有的系統(tǒng)內(nèi)部需要打通，這也是業(yè)務(wù)編排的核心任務(wù)。另外一個問題就是實現(xiàn)自動化，擴容一臺完整的微博后端業(yè)務(wù)大概需要上百步的操作，通過自動化操作避免了數(shù)據(jù)不一致問題的出現(xiàn)。還有一些服務(wù)發(fā)現(xiàn)的機制，原來通過管理員配置的服務(wù)發(fā)現(xiàn)機制對上千規(guī)模的彈性業(yè)務(wù)節(jié)點管理起來成本較高。
圖十四 自動擴縮容
上面這張圖是微博自動擴容的具體流程。首先預(yù)測流量到來時，向DCP系統(tǒng)發(fā)出指令進行擴容。DCP平臺首先向共享池或公有云申請資源，進行資源配額模塊后，在經(jīng)過初始化，進入調(diào)度中心。在調(diào)度中心中根據(jù)服務(wù)之間的依賴關(guān)系，在公有云上啟動該服務(wù)，比如需要先啟動緩存的服務(wù)，才能再啟動RPC服務(wù)，再啟動WEB前端的服務(wù)，最后再啟動應(yīng)用的PHP服務(wù)。服務(wù)啟動后需要向Consul集群進行服務(wù)注冊和服務(wù)健康的檢查。
圖十五 服務(wù)發(fā)現(xiàn)
對于服務(wù)發(fā)現(xiàn)，業(yè)界通用服務(wù)發(fā)現(xiàn)機制是基于Nginx Reload本地文件來實現(xiàn)服務(wù)發(fā)現(xiàn)。這種服務(wù)發(fā)現(xiàn)實現(xiàn)管理成本高，并且不支持并發(fā)注冊，會帶來性能損耗。目前微博采用基于Consul配置中心實現(xiàn)自動發(fā)現(xiàn)服務(wù)，解決了Reload的性能問題。
圖十六 資源的自動發(fā)現(xiàn)
對于資源的動態(tài)發(fā)現(xiàn)，原有的方式是將后端緩存、Redis等資源的配置放在配置框架中進行，在增加阿里云RDC時會導(dǎo)致配置文件快速膨脹?，F(xiàn)在，微博采用將配置同步到Consul集群的方式，通過域名動態(tài)解析阿里云上資源IP變更，無需變更業(yè)務(wù)代碼，對整體的彈性伸縮帶來了很大的便利。