目前在容器編排領域，Kubernetes、Mesos以及Swarm呈現“三分天下”的格局，各自都有著不同的應用場景。短期內，華沙機房主機 荷蘭主機，很難看到“一統天下”的局面，本文，來自阿里云高級專家陳萌輝將帶你了解阿里內部在推行容器化過程中的一些著力點，同時，他將深刻剖析Swarm的進化史以及在阿里云的大規模應用，最后，他給出三個案例，供大家參考。
阿里從前年開始就已經在集團內部大規模地推行容器化和運用Swarm來做應用的發布、集群管理等事情。特別值得注意的是去年，阿里云跟Docker達成了一項深度合作的協議，從中我們不難窺探阿里的容器戰略。本文將從三個方面闡述“Swarm的進化和大規模應用”，第一， Swarm架構；第二，Swarm Mode的編排；第三是Swarm在阿里的應用。
Swarm架構
圖1 Swarm架構
我們先看一下Swarm是什么？Swarm，是Docker官方推出的，它的特點就是跟Docker本身有很好的集成，另外，它也是一個非常簡單易用的工具，所以目前吸引了很多開發者在用。
Swarm是Docker公司繼Docker Engine之后推出的很重要的集群管理系統和容器編排與調度系統。架構底層是集群的機器資源，可以是一些物理機也可以是一些虛擬機，上面經過Swarm這一層把容器調度和部署到這些機器上去，它對外提供跟Docker類似的API。
具體來看，Swarm的框架分成三塊，第一塊是Engine，第二是Manager，第三是KV store。它有幾個特點，第一依賴外部存儲來完成節點發現并保證一致性；第二，Manager只跟Daemon通信，不跟Agent通信；第三，Manager可以有多副本,這是為高可用設計的，采用一主多熱備模式，所有manager都同時連接所有Daemon，備轉發請求至主，另外，它依賴外部KV選主。
API
Swarm提供的API，主要是有這么幾類：
1.集群類：info events
2.容器類：get/list、create、start/stop等
3.鏡像類：get/list、push、pull、tag等
4.數據卷類：get/list、create、delete
5.網絡類：get/list、create、delete等
調度
資源維度層面有三個： CPU 、Memory、 端口，CPU / Memory支持超賣；調度策略有兩種：spread / binpack，另外，它不支持優先級、搶占。
它比較有特點的一些功能有兩個，一個是叫節點約束，約束可以有兩種類型，比如說你可以約束我這個節點是哪一個，你可以給節點去一個名字或者打一個標簽什么的，另外一個可以通過打標簽去選擇一種機器，你在部署的時候，可以指定這些容器部署到哪些機器上去。
節點約束：
1.節點名：constraint:node==XXX
2.標簽：constraint:key==value
親和性也有兩種，一種是image，一種是service，比如我有一個應用鏡像很大，我不希望它在集群各個地方去部署，我希望他部署下來已經下載鏡像的地方，這樣的話可以減少一些啟動的時間和下載的過程，你可以說我這個服務不是跟某個鏡像做親和，也可以跟某個服務做親和。
親和性：
1.鏡像：affinity:image==foo
2.服務：affinity:service==foo
總結一下Swarm這個產品，Swarm整體來說有幾個特點，第一個是部署簡捷，只有三個模塊，外部的依賴只有KV Store和Docker Daemon這兩個，所有組件都容器化。第二高效友好的用戶交互，高度兼容Docker Engine API，可直接使用Docker Client。第三是靈活的約束與親和性描述，可以在一定程度上彌補調度策略的不足。
同時，我們也看到它有一些不足的地方，首先一個不足的地方就是它是容器級別的API，所有的API都是針對單個容器的，抽象層次較低。其次，響應式設計，不方便執行常駐后臺的操作，它在內存中不保存任何的狀態，所有的狀態都是從Docker上統計過來的。有一個好處，它一旦掛掉了，能夠很方便地恢復狀態，但也有一些壞處，比如你要跑一個離線的任務，就不太好做。除此之外，它依賴定期同步跟Docker Engine保持一致狀態。
Swarm Mode
針對Swarm這個產品的一些不足，從1.12版本開始，Docker就提供了Swarm Mode的功能，這個功能是將Swarm的集群管理、容器調度功能集成進Docker Engine，并且提供Service級別抽象和自帶的負載均衡，它從容器級別的調度器進化到了服務級別的調度器。
架構
圖2 Swarm Mode架構
它的架構比Swarm更簡單一些，首先就是它沒有任何的外部依賴，只要你裝 Docker Engine，它就可以構成一個容器集群，DockerDaemon本身會兼Engine、Manager、Agent三職。Managers之間通過RAFT協議組成分布式強一致性KV Store，Manager與Worker的Daemon不通信。
