[[141366]]

每隔幾年，就會(huì)出現(xiàn)一種革命性的新技術(shù)來(lái)改變IT世界的工作方式。十年之前，虛擬化技術(shù)的出現(xiàn)鋪平了通往云服務(wù)和云計(jì)算的道路?，F(xiàn)在，容器及其創(chuàng)造出的充滿活力的生態(tài)系統(tǒng)勁頭正猛。本文將向你展示三星如何基于Mesos和Docker管理和運(yùn)行物聯(lián)網(wǎng)規(guī)模的計(jì)算基礎(chǔ)設(shè)施的。

容器革命很大程度上要?dú)w因于DevOps的進(jìn)步，更要?dú)w因于Docker的成功。容器是對(duì)流行的『微服務(wù)架構(gòu)』的***補(bǔ)充，正因如此，這也使得將軟件應(yīng)用設(shè)計(jì)為獨(dú)立部署的服務(wù)成為可能。在三星，我們已經(jīng)完全接受了這種新趨勢(shì)。

SAMI是個(gè)非常復(fù)雜的平臺(tái)，很多部分都是可替換和移動(dòng)的。在撰寫本文時(shí)，我們已有40多項(xiàng)內(nèi)部服務(wù)（增加中），以及目前***的一些后端技術(shù)，其中包括NoSQL數(shù)據(jù)存儲(chǔ)、消息代理、服務(wù)注冊(cè)表、配置存儲(chǔ)、圖形數(shù)據(jù)庫(kù)、HDFS、大數(shù)據(jù)處理器、內(nèi)存緩存和傳統(tǒng)SQL數(shù)據(jù)庫(kù)。這個(gè)平臺(tái)仍在不斷發(fā)展，我們會(huì)不斷引進(jìn)新技術(shù)和應(yīng)用來(lái)應(yīng)對(duì)物聯(lián)網(wǎng)所需的大數(shù)據(jù)處理過(guò)程中出現(xiàn)的問(wèn)題和挑戰(zhàn)。我們負(fù)責(zé)設(shè)計(jì)和管理支持其工作負(fù)載的基礎(chǔ)設(shè)施，確?？蓴U(kuò)展性、安全性和一致性，同時(shí)還要保持敏捷！

大約在一個(gè)月之前，我們把SAMI平臺(tái)搬到Mesos和Docker上運(yùn)行?？梢园袽esos看做數(shù)據(jù)中心的內(nèi)核，它抽象了所有的底層硬件和虛擬機(jī)，讓你把數(shù)據(jù)中心當(dāng)成一個(gè)超級(jí)大電腦來(lái)編程。同時(shí)，Docker作為容器化技術(shù)，簡(jiǎn)化了打包和搬運(yùn)應(yīng)用的方式。

這真正改變了我們對(duì)應(yīng)用打包、部署、協(xié)調(diào)和監(jiān)督的思考方式。這要求我們對(duì)自動(dòng)化流水線進(jìn)行徹底的重新設(shè)計(jì)，引進(jìn)令人振奮的新技術(shù)的同時(shí)，也要淘汰許多老工具。

向容器技術(shù)推進(jìn)

在容器成為家喻戶曉的熱門話題之前，我們?cè)幸粋€(gè)相當(dāng)不錯(cuò)的全面自動(dòng)化流水線，其核心是我們的配置管理（CM）系統(tǒng)。從配置到符合應(yīng)用程序的部署，一切都通過(guò)我們的配置管理工具實(shí)現(xiàn)自動(dòng)化。

但隨著我們平臺(tái)的增長(zhǎng)，這些工具的缺點(diǎn)開始逐漸暴露出來(lái)。為了支持和衡量如SAMI般日益復(fù)雜的系統(tǒng)，一些新功能被迅速推出，我們意識(shí)到，我們急切需要一種新方法來(lái)部署和管理日益增多的微服務(wù)。

下面是一些需要解決的限制問(wèn)題（注：這些都是CM工具中常有的陷阱，而未必是執(zhí)行時(shí)常見的）：

1. 節(jié)點(diǎn)/機(jī)器專屬角度（Node/Machine-specific perspective）
2. 聲明：Run ‘this’ on ‘that’ VM
3. 靜態(tài)分區(qū)
4. 多租戶需要手動(dòng)配置
5. 資源浪費(fèi)
6. 無(wú)資源隔離
7. 配置和部署時(shí)間長(zhǎng)
8. 沒(méi)有依賴/工作流管理：可以不執(zhí)行“僅當(dāng)部署Service-A之后且通過(guò)健康檢查再部署Service-B”
9. 無(wú)自愈功能：機(jī)器宕機(jī)，操作員需手動(dòng)更換死亡節(jié)點(diǎn)
10. 異構(gòu)基礎(chǔ)框架困難：幾乎所有的cookbook/module/playbook都不能跨越兩個(gè)發(fā)行版本
11. 陡峭的學(xué)習(xí)曲線

要在物聯(lián)網(wǎng)規(guī)模下運(yùn)行一個(gè)現(xiàn)代平臺(tái)，這些限制是我們不可接受的。

#p#

用Mesos和Docker過(guò)渡解決問(wèn)題

• 開始，我們決定建立一個(gè)自動(dòng)化的流水線，這將使以下成為可能：
• 構(gòu)建有容錯(cuò)、自愈功能的基礎(chǔ)設(shè)施。
• 使用現(xiàn)代集群管理/分布式初始化系統(tǒng)，確保應(yīng)用程序定義副本始終都在運(yùn)行。
• 使用Git作為唯一來(lái)源：所有工作配置都存放在Git中，這能降低建立一個(gè)修改管理/審計(jì)系統(tǒng)的難度。
• 把應(yīng)用軟件打包成Docker鏡像，便于快速部署。
• 建立一個(gè)快速反應(yīng)的協(xié)調(diào)系統(tǒng)。
• 把現(xiàn)有的基礎(chǔ)設(shè)施接入流水線。
• ***，組建一個(gè)持續(xù)交付平臺(tái)。它能快速?gòu)?qiáng)大地完成工程（包括QA）進(jìn)行生產(chǎn)部署。這是我們的使命所在，它能把我們從日常運(yùn)營(yíng)的開銷和冗雜中解放出來(lái)，把時(shí)間精力集中在發(fā)展新的服務(wù)和改善流程上，這樣，才能為組織貢獻(xiàn)更多價(jià)值。

為了實(shí)現(xiàn)以上目標(biāo)，我們提出了以下設(shè)計(jì)：

• 高可用性（HA）Mesos集群將提供數(shù)據(jù)中心（DC）級(jí)別的抽象，正如典型操作系統(tǒng)提供工作站級(jí)別的抽象一樣。DC是一個(gè)新型因素。
• Mesos將作為一個(gè)DC-wide資源管理器。
• 構(gòu)建系統(tǒng)將會(huì)把應(yīng)用程序打包成Docker鏡像。之后這些鏡像將會(huì)被push到Docker內(nèi)部私有庫(kù)。
• Marathon將作為DC-wide 初始系統(tǒng)/進(jìn)程管理器。所有的長(zhǎng)時(shí)運(yùn)行作業(yè)會(huì)通過(guò)Marathon進(jìn)行部署和管理。
• Chronos將作為DC-wide cron系統(tǒng)。所有的短時(shí)/批處理作業(yè)會(huì)通過(guò)Chronos進(jìn)行調(diào)度管理。
• 所有Marathon和Chronos的作業(yè)配置都將被check到Git?；A(chǔ)設(shè)施中的任何改動(dòng)都會(huì)被追查到。
• Git2Consul將用于同步Git倉(cāng)庫(kù)到Consul的KV存儲(chǔ)，同時(shí)Consul的handler會(huì)監(jiān)視KV的改動(dòng)并通過(guò)REST API報(bào)告給Marathon和Chronos。
• Consul將繼續(xù)作為服務(wù)注冊(cè)表。用Registrator監(jiān)聽Docker事件和私有庫(kù)的改動(dòng)并報(bào)告給Consul。這些最終將被Mesos-DNS所取代。

我們現(xiàn)在的工作流程大致如下幾步：

1. 當(dāng)開發(fā)者提交時(shí)，Git Post-Receive Hook 會(huì)開啟Jenkins build。

2. Jenkins接著使用maven-dockr插件進(jìn)行創(chuàng)建、標(biāo)記和push Docker鏡像到Docker私有庫(kù)中。它也會(huì)在Consul的KV中更新鏡像標(biāo)記。

3. Consul Handler監(jiān)視KV的更改并更新包含Marathon作業(yè)配置的Git repo。

4. Git2Consul獲取這些更改并將repo同步到Consul的另一個(gè)KV。

5. 另一個(gè)Handler監(jiān)視這個(gè)KV，將作業(yè)配置發(fā)送給Marathon。如果該服務(wù)尚未注冊(cè)，創(chuàng)建新服務(wù)。否則更新該服務(wù)。

6. Marathon作為集群管理者和分布式初始化系統(tǒng)。它用API調(diào)用Docker daemon來(lái)啟動(dòng)容器。

7. Registrator（一個(gè)小型服務(wù)）監(jiān)聽Docker事件，更新Consul的服務(wù)目錄。

8. 服務(wù)注冊(cè)表的任何改動(dòng)都能被Consul-Template捕捉到，這將刷新所有配置（主要是HAProxy）并重新加載相關(guān)服務(wù)。

如上所述，無(wú)需人工干預(yù)，應(yīng)用程序會(huì)自動(dòng)創(chuàng)建、打包和部署到各種環(huán)境中。如果你認(rèn)真理一遍就會(huì)發(fā)現(xiàn)整個(gè)審計(jì)線是這樣的：每一步都被記錄在了Git上。這點(diǎn)非常重要，特別是你的團(tuán)隊(duì)規(guī)模很大、堆棧復(fù)雜且有許多活動(dòng)部分的時(shí)候。另外，如果每天進(jìn)行各種版本服務(wù)的工程中的每個(gè)人都能做到這一點(diǎn)，你就能懂得為何部署中每一步的記錄是如此重要了。

通知（通過(guò)郵件、聊天室等）會(huì)及時(shí)的發(fā)送給團(tuán)隊(duì)，告訴他們，他們的作業(yè)是成功還是失敗。在快速反饋回路中，這些結(jié)果能完全消除來(lái)自方程的Ops！

有了Mesos，我們就能更高效地運(yùn)行基礎(chǔ)設(shè)施，控制云計(jì)算支出在預(yù)算范圍內(nèi)。我們能夠?qū)崿F(xiàn)更高效的資源利用率，而且由于資源隔離，我們能夠?qū)⒍喾N服務(wù)（在Docker容器中運(yùn)行）裝在同一臺(tái)主機(jī)上，建立真正意義上的多租戶部署，借助Cassandra and Kafka之類后端，其中的應(yīng)用程序可以實(shí)現(xiàn)共存。

#p#

回望我們已經(jīng)實(shí)現(xiàn)的

塵埃落定，從成立到實(shí)現(xiàn)生產(chǎn)，我們總共才花了三個(gè)月的時(shí)間。沒(méi)錯(cuò)，我們動(dòng)作就是快！但不論從管理還是技術(shù)角度上來(lái)說(shuō)，前進(jìn)的道路上必將迎來(lái)新的挑戰(zhàn)和阻礙。

新用戶需要了解很多Mesos/Docker世界的很多新概念和細(xì)微差別。而擺脫對(duì)應(yīng)用、主機(jī)和數(shù)據(jù)中心的傳統(tǒng)思維方式不是件容易的事情。這需要一些內(nèi)驅(qū)力來(lái)使不同的群體接受新概念。

從技術(shù)角度來(lái)說(shuō)，盡管已有巨大的工作量，容器的生態(tài)環(huán)境仍不成熟。因此，我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)要考慮這個(gè)因素，保證流水線的組織部分可以更改。更重要的是，你要將基礎(chǔ)設(shè)施設(shè)計(jì)成模塊化的，這樣你才能更加方便地根據(jù)需求進(jìn)行工具和技術(shù)的更換。

結(jié)論

有了上文中我提到的新流水線，我們可以更快的提交代碼，更易于擴(kuò)展，實(shí)現(xiàn)多租戶，確保***的資源利用率。我們能在一些預(yù)生產(chǎn)堆棧里的繁重工作負(fù)載中實(shí)現(xiàn)將近80%的資源利用率。真難以置信，因?yàn)樾袠I(yè)標(biāo)準(zhǔn)中的數(shù)據(jù)中心資源利用率只有8%左右！

舉個(gè)例子，這里是高工作負(fù)載下我們預(yù)生產(chǎn)堆棧中的一個(gè)Mesos集群資源利用率情況：

curl http://10.20.0.201:5050/metrics/snapshot 
{ 
.. 
"master\/cpus_total":247,"master\/cpus_used":192, 
"master\/mem_total":583573,"master\/mem_used":415378, 
.. 
} 

總之，SAMI團(tuán)隊(duì)對(duì)新模式的轉(zhuǎn)變感到非常振奮。但它涉及到大量的研究、學(xué)習(xí)和努力的工作，才把我們帶到這個(gè)層次。如果你們之中有人想要深入研究，一定要記住，新系統(tǒng)需要的改變與你之前做過(guò)的東西相差很大。到目前為止，我們對(duì)結(jié)果已經(jīng)感到非常開心了，而且我們相信這些變化能把我們指引到對(duì)的方向！