目前在容器编排领域，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级别抽象和自带的负载均衡，它从容器级别的调度器进化到了服务级别的调度器。