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

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

業(yè)務(wù)場(chǎng)景

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

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

成本優(yōu)勢(shì)

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

效率優(yōu)勢(shì)

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

業(yè)界趨勢(shì)

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

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

安全性

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

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

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

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

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

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

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

系統(tǒng)初始化

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

例舉幾個(gè)坑：

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

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

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

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

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

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

鏡像服務(wù)

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

描述文件示意如下：

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ù)會(huì)在啟動(dòng)后自行修改一部分配置，例如router, dns, ntp, yum等配置。這就是上面entrypoint的由來，部分配置工作需要在實(shí)例運(yùn)行后進(jìn)行。

網(wǎng)絡(luò)

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

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

云服務(wù)選型

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

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

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

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

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

CLI客戶端(命令行工具)

為了伺候好工程師們，我們實(shí)現(xiàn)了簡(jiǎn)單的命令行客戶端。主要功能是支持創(chuàng)建Docker容器(公有云或私有云)，支持類SSH登陸。因?yàn)槲覀円笕萜鞅旧矶疾惶峁㏒SH(安全考慮)，所以我們是用Ruby通過模擬docker client的exec命令實(shí)現(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é)點(diǎn)發(fā)現(xiàn)的。Consul采用raft協(xié)議來保證server之間的數(shù)據(jù)一致性，采用 gossip協(xié)議管理成員和傳播消息，支持多數(shù)據(jù)中心。Consul集群中的所有請(qǐng)求都會(huì)重定向到server，對(duì)于非leader的server會(huì)將寫請(qǐng)求轉(zhuǎn)發(fā)給leader處理。

Consul對(duì)于讀請(qǐng)求支持3種一致性模式：

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

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

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

我們采用的是default模式。

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

Nginx僅需在upstream配置中聲明Consul集群即可完成后端服務(wù)的動(dòng)態(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; 
} 

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

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

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

Consul的監(jiān)控

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

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

Consul的坑

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

容器調(diào)度

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

我們利用Swarm的Filter機(jī)制，實(shí)現(xiàn)了適應(yīng)業(yè)務(wù)的調(diào)度算法。整個(gè)調(diào)度過程分為兩步：主機(jī)過濾：指定機(jī)房、內(nèi)存、CPU、端口等條件，篩選出符合條件的主機(jī)集合;策略選擇：對(duì)符合條件的主機(jī)集合進(jìn)行打分，選擇出最合適的主機(jī)，在其上創(chuàng)建容器以部署應(yīng)用。調(diào)度子系統(tǒng)Roam實(shí)現(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ā)布之外，最重要的是完成動(dòng)態(tài)擴(kuò)縮容功能，使業(yè)務(wù)實(shí)現(xiàn)一鍵擴(kuò)容、一鍵縮容，降低快速擴(kuò)容成本。一次擴(kuò)容操示意圖如下

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

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

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

#p#

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

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

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

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

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

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

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

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

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

資源監(jiān)控

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

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

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

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

Q&A

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

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

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

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

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

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

Q4 : Consul temple reload nginx時(shí)為什么會(huì)造成大量請(qǐng)求失敗呢，不是graceful的嗎?

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

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

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

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

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

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

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

關(guān)于作者

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

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