摘要：一個(gè)容器起來(lái)，能夠?qū)ν夥?wù)，這時(shí)就看下一步的負(fù)載均衡服務(wù)發(fā)現(xiàn)以及編排。它們有不同的應(yīng)用場(chǎng)景，比如傾向于四層的負(fù)載均衡。不單是負(fù)載均衡，它同時(shí)解決了服務(wù)發(fā)現(xiàn)和負(fù)載均衡兩個(gè)點(diǎn)。

今天是數(shù)人云容器三國(guó)演義Meetup嘉賓演講實(shí)錄第二彈。數(shù)人云工程師春明為大家奉送了一盤(pán)干貨的大餐，讓我們讀讀源碼，深入了解一下SwarmKit的世界吧！
小數(shù)前方預(yù)警：有大量代碼出現(xiàn)！

今天與大家分享一下數(shù)人云對(duì)于SwarmKit的嘗試和探索。Swarm早在2014年就出來(lái)了，和Docker Compose幾乎是同一時(shí)期。Docker解決的是單機(jī)上容器的問(wèn)題，但如何在一個(gè)集群一組的硬件資源上去調(diào)度容器？Swarm可以解決。SwarmKit是在Swarm的基礎(chǔ)上研發(fā)出來(lái)的，只不過(guò)Docker公司對(duì)SwarmKit聯(lián)系得更緊密。SwarmKit的主要代碼提交在2016年4、5月份， Docker1.12出來(lái)以后正式把它release出來(lái)。

我個(gè)人比較看好SwarmKit的原因在于它很簡(jiǎn)單。在生產(chǎn)環(huán)境部署Mesos或者Kubernetes，需要安裝的組件非常多。Mesos為例，首先要裝Zookeeper，然后裝master、 slave，它們之間配置、連線(xiàn)都很復(fù)雜，更不用說(shuō)每條連線(xiàn)后面大量的工作，最終cluster才能跑起來(lái)，并且有很復(fù)雜的API。相比而言，SwarmKit非常簡(jiǎn)單，一個(gè)Binary解決所有問(wèn)題。

今天分享的第一部分會(huì)和大家說(shuō)一下什么是SwarmKit，第二部分聊聊ServiceScheduler，從一個(gè)程序員的角度思考如何構(gòu)造一個(gè)調(diào)度器。這個(gè)調(diào)度器， Service Scheduler，類(lèi)似于SwarmKit、Kubernetes、Mesos加Marathon。第三部分通過(guò)幾段代碼片段了解SwarmKit的關(guān)鍵點(diǎn)。

SwarmKit、Swarm、Swarm Mode這三個(gè)詞，對(duì)剛開(kāi)始接觸的人來(lái)說(shuō)可能有很多困惑。SwarmKit是Swarm這個(gè)項(xiàng)目的升級(jí)版。Swarm和SwarmKit最主要的區(qū)別在于Swarm是多帶帶運(yùn)行的，它需要一個(gè)第三方的分布式存儲(chǔ)，它支持三種存儲(chǔ)方式，即主流的三種分布式存儲(chǔ)——Zookeeper、ETCD和Counsul。

SwarmKit在Swarm的基礎(chǔ)上精進(jìn)了一步，不再需要有第三方存儲(chǔ)，也不需要做Leader選舉。它的發(fā)布方式，一種是獨(dú)立的，另一種是直接和DockerEnginet混搭放在一起。所以大家安裝新Docker1.12版本之后，實(shí)際上也擁有了SwarmKit。你有多臺(tái)機(jī)器安裝了Docker1.12版本，就已經(jīng)擁有了一個(gè)Swarm的cluster，在上面就可以把任務(wù)負(fù)載到不同的機(jī)器上，不需要再去安裝一堆組件。另外一個(gè)詞叫Swarm Mode，如果你開(kāi)啟了Swarm模式的Docker Engine，用Docker的集群功能的時(shí)候 ，它實(shí)際上就是進(jìn)入了Swarm Mode。

接下來(lái)聊一聊從一個(gè)程序員寫(xiě)代碼的角度理解如何去構(gòu)造一個(gè)Service Scheduler，服務(wù)調(diào)度。程序員其實(shí)不太關(guān)心底層的硬件資源或者Saas層是怎么來(lái)的，更多是考慮如何實(shí)現(xiàn)一個(gè)任務(wù)或者一組任務(wù)去分發(fā)、放在不同的一組機(jī)器上。如果想做好這個(gè)事情，無(wú)論是公有云、私有云或者虛擬機(jī)，首先要做的應(yīng)該是把所有的資源進(jìn)行抽象。如果是Mesos Framework，第一件事情是去Mesos申請(qǐng)一塊資源，不用關(guān)心資源到底來(lái)自于哪里，你申請(qǐng)一個(gè)offer、要兩塊CPU或者200M的內(nèi)存， Mesos如果滿(mǎn)足你就會(huì)反饋OK，如果滿(mǎn)足不了你就告訴你等一下。首先把一組資源抽象，比如池子有多少個(gè)CPU、有多少內(nèi)存，把它抽象。第二步分配，如果有一個(gè)請(qǐng)求過(guò)來(lái)，就從池子里面分配資源，然后release。

服務(wù)可能分很多個(gè)進(jìn)程，最終負(fù)載在不同的機(jī)器上。第二部分，是對(duì)服務(wù)這個(gè)概念上有一個(gè)抽象，服務(wù)應(yīng)該有它的生命周期、健康檢測(cè)。服務(wù)下面應(yīng)該有不同的進(jìn)程，這在不同的Service Scheduler有不同的叫法，比如Marathon把它叫做instance， Mesos中叫task，SwarmKit也叫task，實(shí)際上它是一個(gè)運(yùn)行中的實(shí)例，包含了剛才從資源池里申請(qǐng)的一塊資源，并且有自己的生命周期。其中最重要的應(yīng)該是健康檢查，不同人對(duì)一個(gè)服務(wù)的健康狀態(tài)有著不同的定義。

以前我們用Docker Daemon，那現(xiàn)在如何判斷一個(gè)服務(wù)是不是健康的？在DockerEgine加入了健康檢測(cè)之前，我們主要看它的容器是否起來(lái)。一個(gè)容器起來(lái)，能夠?qū)ν夥?wù)，這時(shí)就看下一步的負(fù)載均衡、服務(wù)發(fā)現(xiàn)以及編排。服務(wù)之間其實(shí)有一個(gè)依賴(lài)，服務(wù)A在依賴(lài)服務(wù)B的情況下，只有服務(wù)B起來(lái)，服務(wù)A才能起。所以這一步很重要，對(duì)應(yīng)用具體的實(shí)例抽象，這里面其實(shí)是一個(gè)狀態(tài)機(jī)，專(zhuān)門(mén)做了狀態(tài)的切換。

第三部分，在做一個(gè)服務(wù)編排的時(shí)候，應(yīng)該有一定的策略、算法去做服務(wù)的分發(fā)以及服務(wù)的編排。某些服務(wù)可能對(duì)特定資源有一些特別的需要，比如對(duì)網(wǎng)絡(luò)的需要比較強(qiáng)，對(duì)存儲(chǔ)、對(duì)運(yùn)算能力可能有一些特別的需求；兩個(gè)服務(wù)之間有一定的親緣性，比如希望web服務(wù)跑在離開(kāi)我更近的緩存上面；服務(wù)有幾種分類(lèi)，舉例來(lái)說(shuō)，Web的應(yīng)用和數(shù)據(jù)庫(kù)類(lèi)型的應(yīng)用其實(shí)有一些區(qū)別，數(shù)據(jù)庫(kù)類(lèi)型的應(yīng)用對(duì)彈性的需求沒(méi)有那么高，而Web服務(wù)對(duì)彈性的需求比較高。所以第三件事情應(yīng)該是做好這一層面策略以及分發(fā)。

第四部分，把一堆服務(wù)都分到下面不同的機(jī)器上，有不同的分發(fā)策略以及不同的網(wǎng)絡(luò)模型后，如何讓服務(wù)真正的對(duì)外服務(wù)？即如何解決服務(wù)發(fā)現(xiàn)、負(fù)載均衡還有Proxy這層的問(wèn)題。市面上服務(wù)發(fā)現(xiàn)的方案非常多。比如SwarmKit通過(guò)DNS實(shí)現(xiàn)，IPVS也是它的一種。新浪微博提出的NginxModule以及更早期的一個(gè)開(kāi)源項(xiàng)目叫Bamboo，一個(gè)刷HA的工具，如果容器的狀態(tài)有變化，它會(huì)通過(guò)Bamboo去刷HA的配置，最終把HA重啟。還有Registratorr、confd、 Counsul Template等一些項(xiàng)目，其實(shí)都是著力解決服務(wù)發(fā)現(xiàn)、LoadBalance以及Proxy。

對(duì)于服務(wù)發(fā)現(xiàn)，DNS、SRV、 IPVS都是非常好的解決方案。它們有不同的應(yīng)用場(chǎng)景，比如IPVS傾向于四層的負(fù)載均衡。DNS不單是負(fù)載均衡，它同時(shí)解決了服務(wù)發(fā)現(xiàn)和負(fù)載均衡兩個(gè)點(diǎn)。

我們的場(chǎng)景非常需要Proxy層，對(duì)它有很多期望：比如流量分發(fā)、限制、統(tǒng)計(jì)以及灰度發(fā)布等。最近我做的一件事情是在所有的應(yīng)用前面加一層Proxy，大家可以理解為一層Nginx或者是一層HA，但實(shí)現(xiàn)HA這種性能其實(shí)是很難做到的。

如何做好一個(gè)Service Scheduler，除了上述幾點(diǎn)，接下來(lái)幾個(gè)方面也很重要。第一，HA的需求，即客戶(hù)對(duì)ServiceScheduler的高可用性的要求，數(shù)人云有很多金融方面的客戶(hù)，他們對(duì)HA要求更高，比如提到的“兩地三中心”，歸根結(jié)底是HA的需求。

第二個(gè)，安全方面， SwarmKit支持分布在不同的地方，那么解決安全的問(wèn)題就非常重要。Docker的安全問(wèn)題很?chē)?yán)重，因?yàn)閷?shí)際上Docker給外部的人有權(quán)限去執(zhí)行任何程序。

解決HA問(wèn)題無(wú)非是要布多個(gè)，布單個(gè)可能有單點(diǎn)的問(wèn)題。SwarmKit從中借鑒了很多，它把Mesos的幾個(gè)部分合在一起，這就引出一個(gè)問(wèn)題，比如它要記錄狀態(tài)，那么如何在一個(gè)分布式的環(huán)境下去記錄這個(gè)狀態(tài)，分布式的存儲(chǔ)。

這是開(kāi)啟一個(gè)SwarmKit的管理節(jié)點(diǎn)的一行命令，相當(dāng)于安裝一個(gè)Mesosmaster和一個(gè)Zookeeper。第二個(gè)命令是把當(dāng)前Docker agent加入到一個(gè)Swarm集群里面，相當(dāng)于裝了一個(gè)slave的節(jié)點(diǎn)。剛才這兩條命令其實(shí)就構(gòu)建了一個(gè)兩節(jié)點(diǎn)的Swarm集群。

這張圖描述了Swarm的工作模式。有三層，這是一個(gè)二進(jìn)制，它們充當(dāng)不同的角色。這些線(xiàn)彼此連接，可以看到Manager和Manager之間是可以交互的，Manager和Worker之間也可以交互。Manager和Manager節(jié)點(diǎn)之間交互是raft協(xié)議在做Leader的選舉，和Worker之間的這條線(xiàn)表示把一個(gè)任務(wù)分發(fā)到不同的Worker上。在SwarmKit里面，Worker換了一個(gè)名字叫叫agent。Worker聽(tīng)起來(lái)像純粹干活的東西，agent則還能做一些其它事情，比如做健康檢測(cè)、做主機(jī)、主機(jī)資源的收集。

在圖上大家會(huì)看到每一個(gè)Worker和三個(gè)Manager同時(shí)通信的，但事實(shí)上不是這樣， SwarmKit在同一時(shí)間只和raft選舉出的一個(gè)leader去交互。

接下來(lái)展示SwarmKit的代碼結(jié)構(gòu)，來(lái)了解它們各自的工作。第一個(gè)是agent，即剛才說(shuō)的Worker，它做的事情是SwarmKit節(jié)點(diǎn)作為agent的時(shí)候要做的事情，代碼寫(xiě)在agent這個(gè)地方。第二個(gè)是API，API不是通過(guò)HTTP REST Service或者通過(guò)命令行跟它交互，API實(shí)際上是Manager和Worker之間交互的那些命令，它用gRPC協(xié)議，通過(guò)protobuf協(xié)議來(lái)交互。第三個(gè)目錄叫CA，CA解決安全問(wèn)題。SwarmKit號(hào)稱(chēng)安全做得很好，它的公鑰和私鑰可以ratate，即它的公鑰和私鑰有一個(gè)過(guò)期時(shí)間，然后再不同的循環(huán)，所以私鑰被compromise的時(shí)候不會(huì)影響整個(gè)系統(tǒng)的安全性，因?yàn)闀?huì)rotate它。CLI和CMD是操作一個(gè)SwarmKit時(shí)的入口。design是設(shè)計(jì)文檔。integration是集成。

下面是比較重要的兩個(gè)文件夾，第一個(gè)是Manager，和上面的agent對(duì)應(yīng)，一個(gè)Swarm node在充當(dāng)一個(gè)Manager的時(shí)候，它的邏輯就在這里，即它分發(fā)、健康檢查及其他代碼都在Manager上面。另一個(gè)是node的節(jié)點(diǎn)，Docker Swarm init的時(shí)候就是創(chuàng)建一個(gè)node邏輯的概念，其主要的代碼在node的下面。

這張截圖是打開(kāi)agent的文件夾，介紹一下每個(gè)文件分別做什么。第一個(gè)是文件夾，這里的核心邏輯，exec文件夾下核心文件是一個(gè)Docker client。大家如果用GoDocker client會(huì)發(fā)現(xiàn)里面就是這些——如何維護(hù)、連一個(gè)Docker的agent去update、create、destroy Docker的代碼。但它使用的是docker engine-api的庫(kù)，而不是Godocker client，因?yàn)閑ngine-api那個(gè)項(xiàng)目是Docker公司的，agent的核心代碼都在里面。

接下來(lái)比較重要的就是Task、Worker和Session這三個(gè)文件，Task是任務(wù)的一個(gè)抽象。agent下面的數(shù)據(jù)結(jié)構(gòu)里面會(huì)包含一個(gè)Worker，它是task真正干活的東西，之后我們會(huì)詳細(xì)的說(shuō)一說(shuō)Worker。剛才圖中看到Worker和Manager之間那條線(xiàn)用的就是Session的抽象。

另一個(gè)比較重要的文件夾是Manager。它的文件夾很多，第一個(gè)allocator主要是說(shuō)資源，要申請(qǐng)哪些資源。它里面對(duì)網(wǎng)絡(luò)有一些抽象，從申請(qǐng)上看對(duì)CPU和Manager沒(méi)有提到，它只是對(duì)申請(qǐng)allocator有一個(gè)網(wǎng)段。constraint是有哪些限制，大家如果用過(guò)Mesos都會(huì)知道對(duì)任務(wù)的開(kāi)發(fā)需要一些label滿(mǎn)足SSD、memory等，就是由constraint來(lái)做。controlapi是alloctator和外面交互的一個(gè)API層。下面的dispatcher和orchestrator和scheduler這三個(gè)詞很難說(shuō)它們本質(zhì)有什么區(qū)別，只是多少會(huì)有一點(diǎn)。orchestrator更傾向于Swarm的任務(wù)，它分兩大類(lèi)， replicate和global的任務(wù)，global的任務(wù)在每個(gè)node上只部署一個(gè)節(jié)點(diǎn)。replicate是傳一個(gè)數(shù)量，然后部署這個(gè)數(shù)量。

看了整個(gè)代碼，我總結(jié)出了幾點(diǎn)核心概念。第一個(gè)是Node的節(jié)點(diǎn)，更確切的說(shuō)是對(duì)Dockeragent的一個(gè)抽象。然后Manager節(jié)點(diǎn)。Manager和Node agent是一個(gè)Node，它既可以作為Manager又可以作為agent，或者同時(shí)兼有兩個(gè)。第四個(gè)是Task和Service，Service是我們更高一層對(duì)應(yīng)用的抽象；Task是一個(gè)進(jìn)程，更確切地說(shuō)應(yīng)該是一個(gè)容器。SwarmKit的Task和Service都有自己生命周期的定義。

讀SwarmKit的代碼比較好的一點(diǎn)是它入口非常簡(jiǎn)單，每一個(gè)核心的概念里面，一個(gè)new、一個(gè)run。new是初始化的數(shù)據(jù)結(jié)構(gòu)，run是真正的干活。大家如果想快速的了解代碼，去每一個(gè)概念里面了解這兩個(gè)函數(shù)基本上就知道它們做了什么。

這是Node節(jié)點(diǎn)的new。Node的節(jié)點(diǎn)最核心的是初始化了一些channel，在上面創(chuàng)建了文件夾，這基本是Node節(jié)點(diǎn)的new，但是它的run做了很多事情。run的函數(shù)很長(zhǎng)，里面主要做了一些文件夾初始化，以及SwarmKit用了一個(gè)在golang社區(qū)比較流行的DB叫bolt DB，這里主要初始化文件夾和bolt DB的初始化。run另外一個(gè)比較重要的是 Node的節(jié)點(diǎn)，Node的節(jié)點(diǎn)可以創(chuàng)造Manager的role。Node既可以充當(dāng)Manager的role，又可以變?yōu)閃orker的role，這兩個(gè)角色可以在運(yùn)行時(shí)動(dòng)態(tài)變化。它們?cè)诿看巫兓臅r(shí)候，比如變成Manager，那作為Manager身份的一些功能就開(kāi)啟，由Manager變成agent這些功能可能就被disable掉。

第二個(gè)關(guān)于Node的概念是Manager，這是Manager的數(shù)據(jù)結(jié)構(gòu)。比較有意思的是中間這一部分它作為一個(gè)CAserver，作為一個(gè)dispatcher，作為一個(gè)replicatedOrchestrator，或者是作為一個(gè)global Orchestrator。這些是作為Manager功能的數(shù)據(jù)結(jié)構(gòu)。

此圖是Manager的new，這一屏核心是監(jiān)聽(tīng)了一個(gè)端口，它和Docker Engine非常像，監(jiān)聽(tīng)一個(gè)TCP的端口，或者監(jiān)聽(tīng)一個(gè)unixsock的端口，都是可以的。只監(jiān)聽(tīng)一個(gè)TCP其已經(jīng)滿(mǎn)足大部分場(chǎng)景，那么Docker、agent為什么監(jiān)聽(tīng)一個(gè)unixsock的端口？大家關(guān)注過(guò)Docker Engine就會(huì)知道，有一個(gè)Docker in Docker非常適合Docker測(cè)試。如何做到Docker in Docker呢？就是把unixsock傳到Docker里，相當(dāng)于在一個(gè)Docker容器里控制外面的那個(gè)Docker。

這是Manager new的第二個(gè)slave，是Manager真正干活的時(shí)候，也比較簡(jiǎn)單，主要是兩件事情，第一件事情是作為一個(gè)Manager節(jié)點(diǎn)，監(jiān)聽(tīng)了raft的協(xié)議一些change的變化，第二是注冊(cè)了一些API，這些API是Manager節(jié)點(diǎn)和agent的節(jié)點(diǎn)進(jìn)行交互的一些API。

注意一下handleLeadershipEvents， Manager實(shí)際上是一個(gè)小的區(qū)別于Node的節(jié)點(diǎn)，這幾個(gè)Manager節(jié)點(diǎn)參與raft的選取過(guò)程。Manager節(jié)點(diǎn)最終干活的只有一個(gè)，就是raft協(xié)議選出的那個(gè)leader。在這個(gè)raft協(xié)議leader變化的時(shí)候，作為Manager節(jié)點(diǎn)干的活就不一樣了。

在LeadershipEvents發(fā)生的時(shí)候，當(dāng)前的Manager就看一下自己是leader還是follower，然后根據(jù)不同的角色轉(zhuǎn)換去做不同的事情。

第三個(gè)重點(diǎn)是agent。之前提到做一個(gè)Node的agent角色的時(shí)候，作為agent的角色它需要做哪些事情——負(fù)責(zé)Task的分發(fā)和執(zhí)行。Worker這邊，它作為一個(gè)interface，在agent里則作為agent。它作為interface給大家一個(gè)可能性，即SwarmKit這本身可以不只依賴(lài)于Docker Engine。我見(jiàn)到開(kāi)源項(xiàng)目有人叫SwarmKit on Mesos，只要有不同的worker實(shí)現(xiàn)，通過(guò)Swarm底層是可以運(yùn)行Mesos的。SwarmKit本身對(duì)資源和任務(wù)的抽象抽象是固定的。

作為agent，其實(shí)多了一個(gè)Start， Start的時(shí)候支撐了run的函數(shù)。核心在于讓agent下面由Worker開(kāi)始干活，以及維護(hù)和Manager之間的session—— agent和Worker之間，比如leader的變化、session的變化，有error都會(huì)通過(guò)session來(lái)通知agent做一些相應(yīng)的事情。比如assign一個(gè)task到某個(gè)agent或者session處理一些error，大家都可以看到。

還有一個(gè)executer。executer內(nèi)部是一個(gè)Docker client，操作Docker，實(shí)體化一個(gè)Docker，以及刪除一個(gè)Docker。

session是agent和Worker之間線(xiàn)的抽象。底層是一個(gè)gRPC的的client connection，上面有一些Mesos傳遞方式，有一些channel。初始化一個(gè)session，核心在于gRPC去diy一個(gè)Manager節(jié)點(diǎn)和建立物理上的連接。

這部分代碼是TaskSpec的一個(gè)描述，并不是真正運(yùn)行時(shí)Task的表達(dá)方式。因?yàn)镾pec其實(shí)相當(dāng)于一個(gè)模板， Task第一個(gè)field是ContainerSpec，從這里可以看出Task實(shí)際上是對(duì)container的包裝。下面的Resource requirements是需要什么樣的資源。第三個(gè)是RestartPolicy， Task restart的時(shí)候都有哪些策略。Placement對(duì)應(yīng)Manager constraint那一部分，把這個(gè)Task負(fù)載到一個(gè)什么類(lèi)型的Worker上面。這是Task和Spec運(yùn)行前的描述。

這是Task的一個(gè)結(jié)構(gòu)，它有一個(gè)引用是到Taskspec上，上面是一些運(yùn)行信息，比如Task最終在哪一個(gè)Node的ID上，Task最終屬于哪一個(gè)Service，以及Task slot。我在Google Borg也見(jiàn)到這個(gè)slot的概念，它是一個(gè)邏輯概念，相當(dāng)于對(duì)資源是一個(gè)預(yù)留。如果一個(gè)Task在slot上失敗了，你會(huì)發(fā)現(xiàn)slot還在，這個(gè)Task歷史也會(huì)在那兒， Task不斷的在slot上重啟、重啟、重啟，它實(shí)際上是對(duì)資源的一個(gè)reserve。

這是前面提到的Task life circle，Task有這么多狀態(tài)，這些狀態(tài)其實(shí)是對(duì)一個(gè)Task的抽象。作為Dockercontainer，大家會(huì)發(fā)現(xiàn)狀態(tài)沒(méi)有那么多，無(wú)非是running和非running。但作為一個(gè)Task，它抽象的狀態(tài)就非常多，可想而知這些狀態(tài)都是一個(gè)狀態(tài)機(jī)，它們之間可能有各種互相的遷移，情況比較復(fù)雜。

這是一個(gè)Service，很多個(gè)stack構(gòu)成Service。Service mode會(huì)分Replicated Service和Global Service，Manager下發(fā)一個(gè)Service的時(shí)候分這兩種模式。下面一個(gè)字段叫EndpointSpec，是Service對(duì)外服務(wù)的時(shí)候選擇哪一種服務(wù)發(fā)現(xiàn)的方式，目前有兩個(gè)選項(xiàng)， DNS和VIP。DNS相當(dāng)于為每一個(gè)運(yùn)行時(shí)的Task生成一個(gè)DNS SRV結(jié)構(gòu)；VIP的表現(xiàn)形式是Task，因?yàn)镈ocker inspect Task的時(shí)候，Task會(huì)有一個(gè)自己Task的IP，然后Task IP每次請(qǐng)求都打到這個(gè)Task IP上，通過(guò)IPVS負(fù)載到后面每個(gè)容器上。這是運(yùn)行時(shí)Service的概念。

SwarmKit目前代碼較少，是一個(gè)上升的社區(qū)，值得關(guān)注。今天的分享就到這里，謝謝大家！