1.摘要

前一阵微博风风火火的用大规模docker集群扛过了春节峰值。最近跟不少人聊起接下来要做什么，总是有一种能做的很多，但是能做的又很少的感觉。想了一下原因，感觉还是对docker、docker的生态系统、应用和集群没有划清楚的界限，docker并不是很多问题的最终解决方案，只是解决方案中的一环而已。

2.容器化与轻量

一谈起docker总是会在各种地方看到轻量这个词，甚至会有一种通过docker启动一个服务会节省很多资源的错觉。

但是docker总归不是一个资源优化技术，所谓“轻”也只是相对于传统虚拟机而已。

相对于传统的虚拟技术，docker提供的容器化方案优势在于：

1. 虚拟化额外的资源占用更少了
2. 部署、启动和销毁的时间更短了
3. 部署、启动和销毁的工作量更少了

但相对于不使用容器化方案来说：

1. 占用的资源更多了（可以忽略）
2. 启动、销毁的时间增加了（可以忽略）
3. 部署的时间和工作量变少了

也就是说，相对于不使用容器化的方案，docker在效率方面主要的贡献是可以在不增加性能消耗的情况下，降低部署服务的工作量，提高部署效率。

3.虚拟化与隔离

这里先抛掉神乎其神的docker，考虑一下传统的虚拟化技术。传统的虚拟化技术在牺牲了性能之后换来了什么？最大收益大概是更好的隔离性。

隔离了什么？用到最多的有四类：

• cpu：不同虚拟机的计算资源不混用
• 内存：不同虚拟机的内存不共享
• 网络：每个虚拟机有自己的网络栈
• 文件系统：每个虚拟机独享自己的文件系统

传统的虚拟化消耗了一些系统资源，换来了对cpu、内存、网络和文件系统的隔离。换句话说，一个服务不会影响另一个服务的资源。

于是自然的会想到，一个服务的依赖可以做成一套随着服务一起发布的文件系统，用时加载、停时弃置；也可以把需要不同资源的服务可以部署在一起以节约成本，等等，隔离给了虚拟化真正的价值。

4.微服务与弹性调度

接下来的问题是，怎么更大限度的提高资源的利用率。

又是显而易见的，要提高资源利用率，就得降低资源的浪费，而浪费来源于两方面：服务自身和依赖环境对资源的浪费、服务没有利用到的空闲资源。

一般来说，一个服务内聚越高，对资源的浪费就越少（全人类脑后插管连到母体大概是最省资源的吧……），但现实情况下资源被拆分成一台台计算机，服务也要跟着拆分。当服务的拆分不能保证和资源拆分相同的粒度时，空闲资源就产生了。

服务拆分的粒度越粗，与资源不匹配的矛盾会越激烈；拆分粒度越细，带来的资源浪费也就越多。另一方面，服务内聚提高会带来更高的更高的耦合度和风险，反之会带来更高的部署和维护成本，等等。

所以服务拆到多细这件事本身没有定论，docker能做到的只是降低其中一两个砝码的权重而已。

5.集群管理与服务发现

在一个资源上启动了服务之后，接下来的问题是：启动了这个服务有什么用？因为在启动服务之后，服务只是“可用”的，并没有提高资源的利用率。

于是需要有一种机制，让可用的服务变成被使用的服务，有很多方法可以实现，比如通过配置文件指定访问的ip和端口，大部分场景下，手工配置的方式已经足够了。

但是伴随着系统越来越复杂，配置也越来越复杂，渐渐的手工配置已经有些吃力了。

而伴随着虚拟化和容器化，配置的修改也越来越频繁和复杂，甚至已经超过了启动服务本身的难度。单纯启动一个服务没有意义，需要通过一个足够可靠和高效的机制把“可用”的服务变成“被用”的服务，服务发现担当了这个任务。

6.docker与生态系统

那么，总结一下docker本身带来了什么：

• 更高效的服务部署、启动方式。
• 对cpu、内存、网络和文件系统的简单隔离。

由于docker本身带来了这两点好处，通过docker和相关的生态系统，可以更简单的实现：

• 系统监控和管理对象由“机器”改为抽象的“资源”
• 基于对资源的抽象，提供更灵活的服务部署、调度机制

而docker能做也仅仅是调整天平中众多砝码中的几个而已。更高效的集群管理、更高的资源利用率是目的，docker的生态系统、服务发现和微服务等都是手段，与其纠结于我们要用docker做什么，不如拆分成两个问题：我们要做什么，docker能帮我们做什么。