一、為什么要采用混合云的架構(gòu)

在過去很長的時間內(nèi)，大部分稍大些的互聯(lián)網(wǎng)系統(tǒng)包括微博都是基于私有體系的架構(gòu)，可以在某種程度理解成私有云系統(tǒng)。混合云，顧名思義就是指業(yè)務(wù)同時部署在私有云和公有云，并且支持在云之間切換。實際上“為什么要采用混合云”這個問題，就等于“為什么要上公有云”。我們的考慮點主要有四個方面

業(yè)務(wù)場景

隨著微博活躍度的提升，以及push常規(guī)化等運(yùn)營刺激，業(yè)務(wù)應(yīng)對短時極端峰值挑戰(zhàn)，主要體現(xiàn)在兩個方面：

• 時間短，業(yè)務(wù)需要應(yīng)對分鐘級或者小時級。
• 高峰值，例如話題經(jīng)常出現(xiàn)10到20倍流量增長。

成本優(yōu)勢

對于短期峰值應(yīng)對，常規(guī)部署，離線計算幾個場景，我們根據(jù)往年經(jīng)驗進(jìn)行成本對比發(fā)現(xiàn)公有云優(yōu)勢非常明顯

效率優(yōu)勢

公有云可以實現(xiàn)5分鐘千級別節(jié)點的彈性調(diào)度能力，對比我們目前的私有云5分鐘百級別節(jié)點的調(diào)度能力，也具有明顯優(yōu)勢。

業(yè)界趨勢

“Amazon首次公布AWS業(yè)績：2014年收入51.6億美元，2015年1季度AWS收入15.7億美元，年增速超40%。”“阿里巴巴旗下云計算業(yè)務(wù)阿里云營收6.49億元，比去年同期增長128%，超越亞馬遜和微軟的云計算業(yè)務(wù)增速，成為全球增速最快的云計算服務(wù)商。”

我們預(yù)計未來產(chǎn)品技術(shù)架構(gòu)都會面臨上云的問題，只是時間早晚問題。

安全性

基于數(shù)據(jù)安全的考慮，我們現(xiàn)階段只會把計算和緩存節(jié)點上云，核心數(shù)據(jù)還放在私有云;另外考慮到公有云的技術(shù)成熟度，需要支持在多個云服務(wù)直接進(jìn)行業(yè)務(wù)靈活遷移。

基于上述幾點考慮，我們今年嘗試了以私有云為主，公有云為輔的混合云架構(gòu)。核心業(yè)務(wù)的峰值壓力，會在公有云上實現(xiàn)，業(yè)務(wù)部署形態(tài)可參考下圖

下面介紹介紹技術(shù)實現(xiàn)。整體技術(shù)上采用的是Docker Machine + Swarm + Consul的框架。系統(tǒng)分層如下圖

二、跨云的資源管理與調(diào)度

跨云的資源管理與調(diào)度(即上圖中的pluto部分)的作用是隔離云服務(wù)差異，對上游交付統(tǒng)一的Docker運(yùn)行環(huán)境，支持快速彈性擴(kuò)縮容及跨云調(diào)度。功能上主要包括：

• 系統(tǒng)初始化
• 元數(shù)據(jù)管理
• 鏡像服務(wù)
• 網(wǎng)絡(luò)
• 云服務(wù)選型
• 命令行工具
• 其他

系統(tǒng)界面如下圖：

系統(tǒng)初始化

最初技術(shù)選型時認(rèn)為Machine比較理想，僅需要SSH通道，不依賴任何預(yù)裝的Agent。我們也幾乎與阿里云官方同時向Docker Machine社區(qū)提交了Driver的PR，然后就掉進(jìn)了大坑中不能自拔。

例舉幾個坑：

• 無法擴(kuò)展，Machine的golang函數(shù)幾乎都是小寫，即內(nèi)部實現(xiàn)，無法調(diào)用其API進(jìn)行功能擴(kuò)展。
• 不支持并發(fā)，并發(fā)創(chuàng)建只能通過啟動多個Machine進(jìn)程的方式，數(shù)量多了無法承載。
• 不支持自定義，Machine啟動Docker Daemon是在代碼中寫死的，要定義Daemon的參數(shù)就非常ugly。

目前我們采用的是Puppet的方案，采用去Master的結(jié)構(gòu)。配置在GitLab上管理，變更會通過CI推送到pluto系統(tǒng)，然后再推送到各實例進(jìn)行升級。在基礎(chǔ)資源層面，我們目前正在進(jìn)行大范圍基礎(chǔ)環(huán)境從CentOS 6.5升級到CentOS 7的工作。做這個升級的主要原因是由于上層基于調(diào)度系統(tǒng)依賴Docker新版本，而新版本在CentOS 6.5上會引發(fā)cgroup的bug，導(dǎo)致Kernel Panic問題。

元數(shù)據(jù)的管理

調(diào)度算法需要根據(jù)每個實例的情況進(jìn)行資源篩選，這部分信息目前是通過Docker Daemon的Label實現(xiàn)的，這樣做的好處是資源和調(diào)度可以Docker Daemon解耦。例如我們會在Daemon上記錄這個實例的歸屬信息：

• —label idc=$provider #記錄云服務(wù)提供商
• —label ip=$eth0 #記錄ip信息
• —label srv=$srv #記錄所屬業(yè)務(wù)
• —label role=ci/test/production…
• …

目前Docker Daemon最大的硬傷是任何元數(shù)據(jù)的改變都需要重啟。所以我們計劃把元數(shù)據(jù)從Daemon遷移到我們的系統(tǒng)中，同時嘗試向社區(qū)反饋這個問題，比如動態(tài)修改Docker Daemon Label的接口(PR被拒，官方雖然也看到了問題，但是比較糾結(jié)是否要支持API方式)，動態(tài)修改registry(PR被拒，安全因素)，動態(tài)修改 Docker Container Expose Port(開發(fā)中)。

鏡像服務(wù)

為了提升基礎(chǔ)資源擴(kuò)縮容的效率，我們正在構(gòu)建虛機(jī)鏡像服務(wù)。參考Dockerfile的思路，通過描述文件定義定義虛機(jī)的配置，支持繼承關(guān)系，和簡單的初始化指令。通過預(yù)先創(chuàng)建好的鏡像進(jìn)行擴(kuò)縮容，可以節(jié)省大約50%的初始化時間。

描述文件示意如下：

centos 7.0:

– dns: 8.8.8.8

– docker:

– version: 1.6

– net: host

meta:

– service: $SRV

puppet:

– git: git.intra.weibo.com/docker/puppet/tags/$VERSION

entrypoint:

– init.sh

不過虛機(jī)鏡像也有一些坑，例如一些云服務(wù)會在啟動后自行修改一部分配置，例如router, dns, ntp, yum等配置。這就是上面entrypoint的由來，部分配置工作需要在實例運(yùn)行后進(jìn)行。

網(wǎng)絡(luò)

網(wǎng)絡(luò)的互聯(lián)互通對業(yè)務(wù)來說非常關(guān)鍵，通常來說有三種方案：公網(wǎng)，VPC+VPN，VPC+專線。公網(wǎng)因為性能完全不可控，而且云服務(wù)通常是按照出帶寬收費(fèi)，所以比較適合相互通信較少的業(yè)務(wù)場景。VPC+VPN實際鏈路也是通過公網(wǎng)，區(qū)別是安全性更好，而且可以按照私有云的IP段進(jìn)行網(wǎng)絡(luò)規(guī)劃。專線性能最好，但是價錢也比較好，且受運(yùn)營商政策影響的風(fēng)險較大。

網(wǎng)絡(luò)上需要注意的是包轉(zhuǎn)發(fā)能力，即每秒可以收發(fā)多少個數(shù)據(jù)包。一些云服務(wù)實測只能達(dá)到10萬的量級，而且與CPU核數(shù)、內(nèi)存無 關(guān)。也就是說你花再多的錢，轉(zhuǎn)發(fā)能力也上不去。猜測是云廠商出于安全考慮在虛機(jī)層面做了硬性限制。我們在這上面也中過槍，比如像Redis主從不同步的問題等等。建議對于QPS壓力比較重的實例進(jìn)行拆分。

云服務(wù)選型

我們主要使用的是虛機(jī)和軟負(fù)載兩種云服務(wù)。因為微博對緩存服務(wù)已經(jīng)構(gòu)建一套高可用架構(gòu)，所以我們沒有使用公有云的緩存服務(wù)，而是在虛機(jī)中直接部署緩存容器。

虛機(jī)的選型我們重點關(guān)注CPU核數(shù)，內(nèi)存，磁盤幾個方面。CPU調(diào)度能力，我們測試總結(jié)公有云是私有云的1.2倍，即假設(shè)業(yè)務(wù)在私有云上需要6個核，在公有云上則需要8個。

內(nèi)存寫入速度和帶寬都不是問題，我們測試發(fā)現(xiàn)甚至還好于私有云，MEMCPY的帶寬是私有云的1.2倍，MCBLOCK是1.7倍。所以內(nèi)存主要考慮的是價錢問題。

磁盤的性能也表現(xiàn)較好，順序讀寫帶寬公有云是私有云的1.4倍，隨機(jī)寫是1.6倍。唯一要注意的是對于Redis這種業(yè)務(wù)，需要使用I/O優(yōu)化型的虛機(jī)。

以上數(shù)據(jù)僅供參考，畢竟各家情況不一樣，我們使用的性能測試工具：sysbench, mbw, fio，可自行測試。

CLI客戶端(命令行工具)

為了伺候好工程師們，我們實現(xiàn)了簡單的命令行客戶端。主要功能是支持創(chuàng)建Docker容器(公有云或私有云)，支持類SSH登陸。因為我們要求容器本身都不提供SSH(安全考慮)，所以我們是用Ruby通過模擬docker client的exec命令實現(xiàn)的，效果如下圖：

其他方面

跨域的資源管理和調(diào)度還有很多技術(shù)環(huán)節(jié)需要處理，比如安全，基礎(chǔ)設(shè)施(DNS、YUM等)，成本核算，權(quán)限認(rèn)證，由于這部分通用性不強(qiáng)，這里就不展開了。

#p#

三、容器的編排與服務(wù)發(fā)現(xiàn)

提到調(diào)度就離不開發(fā)現(xiàn)，Swarm是基于Consul來做節(jié)點發(fā)現(xiàn)的。Consul采用raft協(xié)議來保證server之間的數(shù)據(jù)一致性，采用 gossip協(xié)議管理成員和傳播消息，支持多數(shù)據(jù)中心。Consul集群中的所有請求都會重定向到server，對于非leader的server會將寫請求轉(zhuǎn)發(fā)給leader處理。

Consul對于讀請求支持3種一致性模式：

default ：給leader一個time window，在這個時間內(nèi)可能出現(xiàn)兩個leader(split-brain情況下)，舊的leader仍然支持讀的請求，會出現(xiàn)不一致的情況。

consistent ：完全一致，在處理讀請求之前必須經(jīng)過大多數(shù)的follower確認(rèn)leader的合法性，因此會多一次round trip。

stale ：允許所有的server支持讀請求，不管它是否是leader。

我們采用的是default模式。

除了Swarm是基于Consul來做發(fā)現(xiàn)，業(yè)務(wù)直接也是通過Consul來做發(fā)現(xiàn)。我們服務(wù)采用Nginx來做負(fù)載均衡，開源社區(qū)的方案例如 Consul Template，都需要進(jìn)行reload操作，而reload過程中會造成大量的失敗請求。我們現(xiàn)在基于Consul實現(xiàn)了一個nginx- upsync-module。

Nginx僅需在upstream配置中聲明Consul集群即可完成后端服務(wù)的動態(tài)發(fā)現(xiàn)

upstream test { 
# fake server otherwise ngx_http_upstream will report error when startup 
server 127.0.0.1:11111; 
# all backend server will pull from consul when startup and will delete fake server 
consul 127.0.0.1:8500/v1/kv/upstreams/test update_timeout=6m update_interval=500ms strong_dependency=off; 
upstream_conf_path /usr/local/nginx/conf/upstreams/upstream_test.conf; 
} 

這個模塊是用C語言實現(xiàn)的，效率已經(jīng)經(jīng)過線上驗證，目前驗證在20W QPS壓力沒有問題。而且這個模塊代碼已經(jīng)開源在Github上，也歡迎大家提Issue：https://github.com/weibocom/nginx-upsync-module。

下圖是我們做的幾種方案的性能對比：

當(dāng)然我們的RPC框架motan也會支持Consul，實現(xiàn)機(jī)制同樣也是利用Consul的long polling機(jī)制，等待直到監(jiān)聽的X-Consul-Index位置發(fā)生變化，這個功能已經(jīng)在我們內(nèi)網(wǎng)驗證通過，不過由于依賴整個motan框架，所以目前還沒有開源。

Consul的監(jiān)控

由于Consul處于系統(tǒng)核心位置，一旦出現(xiàn)問題會導(dǎo)致整體所有集群失聯(lián)，所以我們對Consul做了一系列保障措施，其中所有Consul Server節(jié)點監(jiān)控指標(biāo)如下

Leader節(jié)點監(jiān)控指標(biāo)如下圖

Consul的坑

除了使用不當(dāng)導(dǎo)致的問題之外，Consul Server節(jié)點通信通道UDP協(xié)議，偶發(fā)會出現(xiàn)server不停被摘除的現(xiàn)象，這個問題官方已在跟進(jìn)，計劃會增加TCP的通道保證消息的可靠性。

容器調(diào)度

容器調(diào)度基于Swarm實現(xiàn)，依賴Consul來做節(jié)點發(fā)現(xiàn)(話說Swarm才剛剛宣布Production Ready)。容器調(diào)度分為三級，應(yīng)用-應(yīng)用池-應(yīng)用實例，一個應(yīng)用下有多個應(yīng)用池，應(yīng)用池可以按機(jī)房和用途等來劃分。一個應(yīng)用池下有多個Docker容器形式的應(yīng)用實例。

我們利用Swarm的Filter機(jī)制，實現(xiàn)了適應(yīng)業(yè)務(wù)的調(diào)度算法。整個調(diào)度過程分為兩步：主機(jī)過濾：指定機(jī)房、內(nèi)存、CPU、端口等條件，篩選出符合條件的主機(jī)集合;策略選擇：對符合條件的主機(jī)集合進(jìn)行打分，選擇出最合適的主機(jī)，在其上創(chuàng)建容器以部署應(yīng)用。調(diào)度子系統(tǒng)Roam實現(xiàn)了批量的容器調(diào)度與編排。

業(yè)務(wù)調(diào)度

容器調(diào)度是于業(yè)務(wù)無關(guān)，具體串聯(lián)起資源管理，容器調(diào)度，發(fā)現(xiàn)等系統(tǒng)，完成業(yè)務(wù)容器最終跨云部署的是我們的JPool系統(tǒng)。JPool除了完成日常的業(yè)務(wù)容器上線發(fā)布之外，最重要的是完成動態(tài)擴(kuò)縮容功能，使業(yè)務(wù)實現(xiàn)一鍵擴(kuò)容、一鍵縮容，降低快速擴(kuò)容成本。一次擴(kuò)容操示意圖如下

圍繞這調(diào)度和發(fā)現(xiàn)，需要很多工具的支撐：

例如為了使業(yè)務(wù)接入更加方便，我們提供了自動打包工具，它包括代碼打包、鏡像打包的解決方案，支持svn、gitlab等代碼倉庫，業(yè)務(wù)僅需要在工程中定義pom.xml和Dockerfile即可實現(xiàn)一鍵打包代碼，一鍵打包鏡像，過程可控，接入簡單。

我們還對Docker的Registry，我們進(jìn)行了一些優(yōu)化，主要是針對混合云跨機(jī)房場景，提供跨機(jī)房加速功能，整個服務(wù)架構(gòu)如下：

#p#

四、混合云監(jiān)控體系

微博體系在經(jīng)歷了多年的IT建設(shè)過程后，已經(jīng)初步建立了一套完整的信息化管理流程，極大地提升了微博業(yè)務(wù)能力。同時微博開展了大量的IT基礎(chǔ)設(shè)施建設(shè)(包括網(wǎng)絡(luò)、機(jī)房、服務(wù)器、存儲設(shè)置、數(shù)據(jù)庫、中間件及各業(yè)務(wù)應(yīng)用系統(tǒng)等)。

針對于混合云體系，我們提供了一套完整的監(jiān)控告警解決方案，實現(xiàn)對于云上IT基礎(chǔ)架構(gòu)的整體監(jiān)控與預(yù)警機(jī)制，最大程度地保證了微博體系能夠穩(wěn)定地運(yùn)行在混合云體系上，不間斷地為用戶提供優(yōu)質(zhì)的服務(wù)。監(jiān)控告警解決方案實現(xiàn)了四個級別上的監(jiān)控與預(yù)警：

• 系統(tǒng)級監(jiān)控
• 業(yè)務(wù)級監(jiān)控
• 資源級監(jiān)控
• 專線網(wǎng)絡(luò)監(jiān)控
• 系統(tǒng)級監(jiān)控

混合云體系支持的系統(tǒng)級監(jiān)控(與新浪sinawatch系統(tǒng)的對接)包括：CPU，磁盤，網(wǎng)卡，IOPS，Load，內(nèi)存

業(yè)務(wù)監(jiān)控

混合云體系集成了目前微博業(yè)務(wù)監(jiān)控平臺Graphite，自動提供了業(yè)務(wù)級別(SLA)的實時監(jiān)控與告警。所有的配置與操作都是系統(tǒng)自動完成的，不需要用戶進(jìn)行額外的配置操作。

業(yè)務(wù)級別的監(jiān)控包括：

• JVM監(jiān)控: 實時監(jiān)控堆、棧使用信息、統(tǒng)計gc收集時間、檢查JVM瓶頸等。
• 吞吐量監(jiān)控： 實時監(jiān)控業(yè)務(wù)系統(tǒng)吞吐量(QPS或TPS)。
• 平均耗時監(jiān)控: 實時監(jiān)控業(yè)務(wù)系統(tǒng)接口的平均耗時時間。
• 單機(jī)性能監(jiān)控: 實時監(jiān)控單臺服務(wù)器的各種業(yè)務(wù)指標(biāo)。
• Slow監(jiān)控: 監(jiān)控服務(wù)器集群，實時顯示當(dāng)前業(yè)務(wù)系統(tǒng)中最慢的性能瓶頸。

資源監(jiān)控

混合云體系集成了目前微博資源監(jiān)控平臺sinadsp，自動提供了對各種底層資源的實時監(jiān)控與告警。所有的配置與操作都是系統(tǒng)自動完成的，不需要用戶進(jìn)行額外的配置操作。

具體的監(jiān)控指標(biāo)包括：命中率，QPS/TPS，連接數(shù)，上行/下行帶寬，CPU，內(nèi)存。

五、前進(jìn)路上遇到的那些坑

需要注意的坑，實際在各部分中都有提及。今天分享的主要內(nèi)容就是這些了，當(dāng)然業(yè)務(wù)上云，除了上面這些工作之外，還存在很多技術(shù)挑戰(zhàn)要解決。比如跨云的消息總線，緩存數(shù)據(jù)同步，容量評估，流量調(diào)度，RPC框架，微服務(wù)化等。

Q&A

Q1 : 為什么選Consul?看中有對比Zookeeper、etcd，尤其是etcd?

我們有對比etcd和consul，主要還是看重了consul基于K-V之外額外功能，比如支持DNS，支持ACL。另外etcd不對get request做超時處理，Consul對blocking query有超時機(jī)制。

Q2 : 上面提到的方案主要是Java體系， 對于其他語言(php, nodejs, golang)體系系統(tǒng)的是否有很好的支持(開發(fā)、測試、發(fā)布部署、監(jiān)控等)?

已經(jīng)在開始php的支持。其實容器化之后，所有語言都是適用的。

Q3 : Docker registry底層存儲用的是什么，怎么保障高可用的?

底層使用的Ceph，前端無狀態(tài)，通過DNS做跨云智能解析，加速下載。

Q4 : Consul temple reload nginx時為什么會造成大量請求失敗呢，不是graceful的嗎?

是graceful的，在QPS壓力較大的情況下，由于需要進(jìn)行大量重連，過程中會產(chǎn)生較多失敗請求。

Q5 : 剛才提到的調(diào)度系統(tǒng)是自己開發(fā)的?還是基于開源改的?

是基于Swarm二次開發(fā)的。

Q6 : 容器跨主機(jī)通信是host網(wǎng)絡(luò)嗎?

對，目前線上采用的是host網(wǎng)絡(luò)。

Q7 : Ceph IO情況怎么?高IO的是不是不太適合用Ceph?

針對Registry場景Ceph IO是可以勝任的。不過Ceph暫時還沒有宣布Production Ready，所以對于極端業(yè)務(wù)場景，請謹(jǐn)慎。

關(guān)于作者

微博研發(fā)中心技術(shù)經(jīng)理及高級技術(shù)專家。2008年畢業(yè)于北京郵電大學(xué)，碩士學(xué)位。畢業(yè)后就職華為北研。2012年加入新浪微博，負(fù)責(zé)微博Feed、用戶關(guān) 系和微博容器化相關(guān)項目，致力于Docker技術(shù)在生產(chǎn)環(huán)境中的規(guī)模化應(yīng)用。2015年3月，曾在QClub北京Docker專場分享《大規(guī)模 Docker集群助力微博迎接春晚峰值挑戰(zhàn)》。

【內(nèi)容來源：高可用架構(gòu)公眾號ArchNotes】