目录
[显示]

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能帮我们做什么。