摘要：一個容器起來，能夠對外服務，這時就看下一步的負載均衡服務發現以及編排。它們有不同的應用場景，比如傾向于四層的負載均衡。不單是負載均衡，它同時解決了服務發現和負載均衡兩個點。

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

今天與大家分享一下數人云對于SwarmKit的嘗試和探索。Swarm早在2014年就出來了，和Docker Compose幾乎是同一時期。Docker解決的是單機上容器的問題，但如何在一個集群一組的硬件資源上去調度容器？Swarm可以解決。SwarmKit是在Swarm的基礎上研發出來的，只不過Docker公司對SwarmKit聯系得更緊密。SwarmKit的主要代碼提交在2016年4、5月份， Docker1.12出來以后正式把它release出來。

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

今天分享的第一部分會和大家說一下什么是SwarmKit，第二部分聊聊ServiceScheduler，從一個程序員的角度思考如何構造一個調度器。這個調度器， Service Scheduler，類似于SwarmKit、Kubernetes、Mesos加Marathon。第三部分通過幾段代碼片段了解SwarmKit的關鍵點。

SwarmKit、Swarm、Swarm Mode這三個詞，對剛開始接觸的人來說可能有很多困惑。SwarmKit是Swarm這個項目的升級版。Swarm和SwarmKit最主要的區別在于Swarm是多帶帶運行的，它需要一個第三方的分布式存儲，它支持三種存儲方式，即主流的三種分布式存儲——Zookeeper、ETCD和Counsul。

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

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

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

以前我們用Docker Daemon，那現在如何判斷一個服務是不是健康的？在DockerEgine加入了健康檢測之前，我們主要看它的容器是否起來。一個容器起來，能夠對外服務，這時就看下一步的負載均衡、服務發現以及編排。服務之間其實有一個依賴，服務A在依賴服務B的情況下，只有服務B起來，服務A才能起。所以這一步很重要，對應用具體的實例抽象，這里面其實是一個狀態機，專門做了狀態的切換。

第三部分，在做一個服務編排的時候，應該有一定的策略、算法去做服務的分發以及服務的編排。某些服務可能對特定資源有一些特別的需要，比如對網絡的需要比較強，對存儲、對運算能力可能有一些特別的需求；兩個服務之間有一定的親緣性，比如希望web服務跑在離開我更近的緩存上面；服務有幾種分類，舉例來說，Web的應用和數據庫類型的應用其實有一些區別，數據庫類型的應用對彈性的需求沒有那么高，而Web服務對彈性的需求比較高。所以第三件事情應該是做好這一層面策略以及分發。

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

對于服務發現，DNS、SRV、 IPVS都是非常好的解決方案。它們有不同的應用場景，比如IPVS傾向于四層的負載均衡。DNS不單是負載均衡，它同時解決了服務發現和負載均衡兩個點。

我們的場景非常需要Proxy層，對它有很多期望：比如流量分發、限制、統計以及灰度發布等。最近我做的一件事情是在所有的應用前面加一層Proxy，大家可以理解為一層Nginx或者是一層HA，但實現HA這種性能其實是很難做到的。

如何做好一個Service Scheduler，除了上述幾點，接下來幾個方面也很重要。第一，HA的需求，即客戶對ServiceScheduler的高可用性的要求，數人云有很多金融方面的客戶，他們對HA要求更高，比如提到的“兩地三中心”，歸根結底是HA的需求。

第二個，安全方面， SwarmKit支持分布在不同的地方，那么解決安全的問題就非常重要。Docker的安全問題很嚴重，因為實際上Docker給外部的人有權限去執行任何程序。

解決HA問題無非是要布多個，布單個可能有單點的問題。SwarmKit從中借鑒了很多，它把Mesos的幾個部分合在一起，這就引出一個問題，比如它要記錄狀態，那么如何在一個分布式的環境下去記錄這個狀態，分布式的存儲。

這是開啟一個SwarmKit的管理節點的一行命令，相當于安裝一個Mesosmaster和一個Zookeeper。第二個命令是把當前Docker agent加入到一個Swarm集群里面，相當于裝了一個slave的節點。剛才這兩條命令其實就構建了一個兩節點的Swarm集群。

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

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

接下來展示SwarmKit的代碼結構，來了解它們各自的工作。第一個是agent，即剛才說的Worker，它做的事情是SwarmKit節點作為agent的時候要做的事情，代碼寫在agent這個地方。第二個是API，API不是通過HTTP REST Service或者通過命令行跟它交互，API實際上是Manager和Worker之間交互的那些命令，它用gRPC協議，通過protobuf協議來交互。第三個目錄叫CA，CA解決安全問題。SwarmKit號稱安全做得很好，它的公鑰和私鑰可以ratate，即它的公鑰和私鑰有一個過期時間，然后再不同的循環，所以私鑰被compromise的時候不會影響整個系統的安全性，因為會rotate它。CLI和CMD是操作一個SwarmKit時的入口。design是設計文檔。integration是集成。

下面是比較重要的兩個文件夾，第一個是Manager，和上面的agent對應，一個Swarm node在充當一個Manager的時候，它的邏輯就在這里，即它分發、健康檢查及其他代碼都在Manager上面。另一個是node的節點，Docker Swarm init的時候就是創建一個node邏輯的概念，其主要的代碼在node的下面。

這張截圖是打開agent的文件夾，介紹一下每個文件分別做什么。第一個是文件夾，這里的核心邏輯，exec文件夾下核心文件是一個Docker client。大家如果用GoDocker client會發現里面就是這些——如何維護、連一個Docker的agent去update、create、destroy Docker的代碼。但它使用的是docker engine-api的庫，而不是Godocker client，因為engine-api那個項目是Docker公司的，agent的核心代碼都在里面。

接下來比較重要的就是Task、Worker和Session這三個文件，Task是任務的一個抽象。agent下面的數據結構里面會包含一個Worker，它是task真正干活的東西，之后我們會詳細的說一說Worker。剛才圖中看到Worker和Manager之間那條線用的就是Session的抽象。

另一個比較重要的文件夾是Manager。它的文件夾很多，第一個allocator主要是說資源，要申請哪些資源。它里面對網絡有一些抽象，從申請上看對CPU和Manager沒有提到，它只是對申請allocator有一個網段。constraint是有哪些限制，大家如果用過Mesos都會知道對任務的開發需要一些label滿足SSD、memory等，就是由constraint來做。controlapi是alloctator和外面交互的一個API層。下面的dispatcher和orchestrator和scheduler這三個詞很難說它們本質有什么區別，只是多少會有一點。orchestrator更傾向于Swarm的任務，它分兩大類， replicate和global的任務，global的任務在每個node上只部署一個節點。replicate是傳一個數量，然后部署這個數量。

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

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

這是Node節點的new。Node的節點最核心的是初始化了一些channel，在上面創建了文件夾，這基本是Node節點的new，但是它的run做了很多事情。run的函數很長，里面主要做了一些文件夾初始化，以及SwarmKit用了一個在golang社區比較流行的DB叫bolt DB，這里主要初始化文件夾和bolt DB的初始化。run另外一個比較重要的是 Node的節點，Node的節點可以創造Manager的role。Node既可以充當Manager的role，又可以變為Worker的role，這兩個角色可以在運行時動態變化。它們在每次變化的時候，比如變成Manager，那作為Manager身份的一些功能就開啟，由Manager變成agent這些功能可能就被disable掉。

第二個關于Node的概念是Manager，這是Manager的數據結構。比較有意思的是中間這一部分它作為一個CAserver，作為一個dispatcher，作為一個replicatedOrchestrator，或者是作為一個global Orchestrator。這些是作為Manager功能的數據結構。

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

這是Manager new的第二個slave，是Manager真正干活的時候，也比較簡單，主要是兩件事情，第一件事情是作為一個Manager節點，監聽了raft的協議一些change的變化，第二是注冊了一些API，這些API是Manager節點和agent的節點進行交互的一些API。

注意一下handleLeadershipEvents， Manager實際上是一個小的區別于Node的節點，這幾個Manager節點參與raft的選取過程。Manager節點最終干活的只有一個，就是raft協議選出的那個leader。在這個raft協議leader變化的時候，作為Manager節點干的活就不一樣了。

在LeadershipEvents發生的時候，當前的Manager就看一下自己是leader還是follower，然后根據不同的角色轉換去做不同的事情。

第三個重點是agent。之前提到做一個Node的agent角色的時候，作為agent的角色它需要做哪些事情——負責Task的分發和執行。Worker這邊，它作為一個interface，在agent里則作為agent。它作為interface給大家一個可能性，即SwarmKit這本身可以不只依賴于Docker Engine。我見到開源項目有人叫SwarmKit on Mesos，只要有不同的worker實現，通過Swarm底層是可以運行Mesos的。SwarmKit本身對資源和任務的抽象抽象是固定的。

作為agent，其實多了一個Start， Start的時候支撐了run的函數。核心在于讓agent下面由Worker開始干活，以及維護和Manager之間的session—— agent和Worker之間，比如leader的變化、session的變化，有error都會通過session來通知agent做一些相應的事情。比如assign一個task到某個agent或者session處理一些error，大家都可以看到。

還有一個executer。executer內部是一個Docker client，操作Docker，實體化一個Docker，以及刪除一個Docker。

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

這部分代碼是TaskSpec的一個描述，并不是真正運行時Task的表達方式。因為Spec其實相當于一個模板， Task第一個field是ContainerSpec，從這里可以看出Task實際上是對container的包裝。下面的Resource requirements是需要什么樣的資源。第三個是RestartPolicy， Task restart的時候都有哪些策略。Placement對應Manager constraint那一部分，把這個Task負載到一個什么類型的Worker上面。這是Task和Spec運行前的描述。

這是Task的一個結構，它有一個引用是到Taskspec上，上面是一些運行信息，比如Task最終在哪一個Node的ID上，Task最終屬于哪一個Service，以及Task slot。我在Google Borg也見到這個slot的概念，它是一個邏輯概念，相當于對資源是一個預留。如果一個Task在slot上失敗了，你會發現slot還在，這個Task歷史也會在那兒， Task不斷的在slot上重啟、重啟、重啟，它實際上是對資源的一個reserve。

這是前面提到的Task life circle，Task有這么多狀態，這些狀態其實是對一個Task的抽象。作為Dockercontainer，大家會發現狀態沒有那么多，無非是running和非running。但作為一個Task，它抽象的狀態就非常多，可想而知這些狀態都是一個狀態機，它們之間可能有各種互相的遷移，情況比較復雜。

這是一個Service，很多個stack構成Service。Service mode會分Replicated Service和Global Service，Manager下發一個Service的時候分這兩種模式。下面一個字段叫EndpointSpec，是Service對外服務的時候選擇哪一種服務發現的方式，目前有兩個選項， DNS和VIP。DNS相當于為每一個運行時的Task生成一個DNS SRV結構；VIP的表現形式是Task，因為Docker inspect Task的時候，Task會有一個自己Task的IP，然后Task IP每次請求都打到這個Task IP上，通過IPVS負載到后面每個容器上。這是運行時Service的概念。

SwarmKit目前代碼較少，是一個上升的社區，值得關注。今天的分享就到這里，謝謝大家！