使用容器的正确方式，Docker在雪球的技术实践

【编者的话】雪球目前拥有一千多个容器，项目数量大概有一百多个，规模并不是很大。但是得益于容器技术，雪球部署的效率非常高，雪球的开发人员只有几十个，但是每个月的发布次数高达两千多次。

雪球是一个投资者交流的社区，用户可以在上面买卖股票，代销基金等各种金融衍生业务，同时也可以通过雪盈证券来进行沪、深、港、美股的交易。

为什么要引入 Docker

随着业务的发展，不同的社区业务之间所受到影响的概率正在逐渐升高，因此我们希望各个业务之间既能够不被打扰，又能在资源上、机器间、甚至网络上根据监管的要求予以不同层面的隔离。

早在 2014 年时，我们就发现容器技术具有本身镜像小、灵活、启动速度快等特点，而且在性能上比较适合于我们当时物理机不多的规模环境。

相比而言，传统的虚拟化技术不但实现成本高，而且性能损耗也超过 10%。因此，基于对镜像大小、启动速度、性能损耗、和隔离需求的综合考虑，我们选用了两种容器引擎：LXC 和 Docker。

我们把 MySQL 之类有状态的服务放在 LXC 里；而将线上业务之类无状态的服务放在 Docker 中。

容器使用方法

众所周知，Docker 是以类似于单机的软件形态问世的，最初它的宣传口号是：Build/Ship/Run。

因此它早期的 Workflow（流程）是：

• 在一台 Host 主机上先运行 Docker Build。
• 然后运用 Docker Pull，从镜像仓库里把镜像拉下来。
• 最后使用 Docker Run，就有了一个运行的 Container。

需要解决的问题

上述的流程方案伴随着如下有待解决的问题：

• 网络连通性，由于是单机软件，Docker 最初默认使用的是 Bridge 模式，不同宿主机之间的网络并不相通。因此，早期大家交流最多的就是如何解决网络连通性的问题。
• 多节点的服务部署与更新，在上马该容器方案之后，我们发现由于本身性能损耗比较小，其节点的数量会出现爆炸式增长。
  因此，往往会出现一台物理机上能够运行几十个节点的状况。容器节点的绝对数量会比物理节点的数量大一个数量级，甚至更多。那么这么多节点的服务部署与更新，直接导致了工作量的倍数增加。
• 监控，同时，我们需要为这么多节点的运行状态采用合适的监控方案。

Docker 在雪球的技术实践

网络模式

首先给大家介绍一下我们早期的网络解决方案：在上图的左边，我们默认采用的是 Docker 的 Bridge 模式。

大家知道，默认情况下 Docker 会在物理机上创建一个名为 docker0 的网桥。

每当一个新的 Container 被创建时，它就会相应地创建出一个 veth，然后将其连到容器的 eth0 上。

同时，每一个 veth 都会被分配到一个子网的 IP 地址，以保持与相同主机里各个容器的互通。

由于在生产环境中不只一张网卡，因此我们对它进行了改造。我们产生了一个“网卡绑定”，即生成了 bond0 网卡。我们通过创建一个 br0 网桥，来替换原来的 docker0 网桥。

在该 br0 网桥中，我们所配置的网段和物理机所处的网段是相同的。由于容器和物理机同处一个网段，因此核心上联的交换机能够看到该容器和不同宿主机的 MAC 地址。这就是一个网络二层互通的解决方案。

该网络模式具有优劣两面性：

• 优点：由于在网络二层上实现了连接互通，而且仅用到了内核转发，因此整体性能非常好，与物理机真实网卡的效率差距不大。
• 缺点：管理较为复杂，需要我们自己手动的去管理容器的 IP 和 MAC 地址。
  由于整体处于网络大二层，一旦系统达到了一定规模，网络中的 ARP 包会产生网络广播风暴，甚至会偶发出现 PPS（Package Per Second）过高，网络间歇性不通等奇怪的现象。
  由于处于底层网络连接，在实现网络隔离时也较为复杂。

服务部署

对于服务的部署而言，我们最初沿用虚拟机的做法，将容器启动起来后就不再停下了，因此：

• 如果节点需要新增，我们就通过 Salt 来管理机器的配置。
• 如果节点需要更新，我们就通过 Capistrano 进行服务的分发，和多个节点的部署操作，变更容器中的业务程序。

其中，优势为：

• 与原来的基础设施相比，迁移的成本非常低。由于我们通过复用原来的基础设施，直接将各种服务部署在原先的物理机上进行，因此我们很容易地迁移到了容器之中。而对于开发人员来说，他们看不到容器这一层，也就如同在使用原来的物理机一样，毫无“违和感”。
• 与虚拟机相比，启动比较快，运行时没有虚拟化的损耗。
• 最重要的是一定程度上满足了我们对于隔离的需求。

而劣势则有：

• 迁移和扩容非常繁琐。例如：当某个服务需要扩容时，我们就需要有人登录到该物理机上，生成并启动一个空的容器，再把服务部署进去。此举较为低效。
• 缺乏统一的平台进行各种历史版本的管理与维护。我们需要通过文档来记录整个机房的容器数量，和各个容器的 IP/MAC 地址，因此出错的可能性极高。
• 缺少流程和权限的控制。我们基本上采用的是原始的管控方式。

自研容器管理平台

面对上述缺点，我们需要自行研发一个容器管理平台，去管理各种物理机、容器、IP 与 MAC 地址、以及进行流程控制。

因此我们变更的整套发布流程为：

• 由开发人员将代码提交到代码仓库（如 Github）之中。
• 触发一个 Hook 去构建镜像，在构建的同时做一些 CI（持续集成），包括静态代码扫描和单测等。
• 将报告附加到镜像的信息里，并存入镜像仓库中。
• 部署测试环境。
• 小流量上线，上线之后，做一些自动化的 API Diff 测试，以判断是否可用。
• 继续全量上线。

镜像构建

有了容器管理平台，就会涉及到镜像的自动构建。和业界其他公司的做法类似，我们也使用的是基于通用操作系统的镜像。

然后向镜像中添加那些我们公司内部会特别用到的包，得到一个通用的 base 镜像，再通过分别加入不同语言的依赖，得到不同的镜像。

每次业务版本发布，将代码放入相应语言的镜像即可得到一个业务的镜像。构建镜像的时候需要注意尽量避免无用的层级和内容，这有助于提升存储和传输效率。

系统依赖

我们的这一整套解决方案涉及到了如下周边的开源项目与技术：

负载均衡

由于会频繁发生节点的增减，我们该如何通过流量的调度和服务的发现，来实现自动加入负载均衡呢？对于那些非 Http 协议的 RPC，又该如何自动安全地摘掉某个节点呢？

我们在此使用了 Nginx+Lua（即 OpenResty），去实现逻辑并动态更改 Upstream。

当有节点启动时，我们就能够将它自动注册与加入；而当有节点被销毁时，也能及时将其摘掉。

同时，我们在内部使用了 Finagle 作为 RPC 的框架，并通过 ZooKeeper 实现了服务的发现。

日志收集

由于节点众多，我们需要进行各种日志的收集。在此，我们大致分为两类收集方式：

• 一类是 Nginx 这种不易侵入代码的，我们并没有设法去改变日志的流向，而是让它直接“打”到物理机的硬盘上，然后使用 Flume 进行收集，传输到 Kafka 中。
• 另一类是我们自己的业务。我们实现了一个 Log4 Appender，把日志直接写到 Kafka，再从 Kafka 转写到 ElasticSearch 里面。

网络模式

在该场景下，我们采用的是上述提到的改进后的 Bridge+Host 模式。

监控系统

监控系统由上图所示的几个组件所构成。它将收集（Collector）到的不同监控指标数据，传输到 Graphite 上，而 Grafana 可读取 Graphite 的信息，并用图形予以展示。

同时，我们也根据内部业务的适配需要，对报警组件 Cabot 进行了改造和定制。

此时我们的平台已经与虚拟机的用法有了较大的区别。如上图所示，主要的不同之处体现在编译、环境、分发、节点变更，流程控制、以及权限控制之上。我们的用法更具自动化。

由于是自行研发的容器管理平台，这给我们带来的直接好处包括：

• 流程与权限的控制。
• 代码版本与环境的固化，多个版本的发布，镜像的管理。
• 部署与扩容效率的大幅提升。

但是其自身也有着一定的缺点，包括：

• 在流程控制逻辑，机器与网络管理，以及本身的耦合程度上都存在着缺陷。因此它并不算是一个非常好的架构，也没能真正实现“高内聚低耦合”。
• 由于是自研的产品，其功能上并不完善，没能实现自愈，无法根据新增节点去自动选择物理机、并自动分配与管理 IP 地址。

引入 Swarm

2015 年，我们开始着手改造该容器管理平台。由于该平台之前都是基于 DockerAPI 构建的。

而 Swarm 恰好能对 Docker 的原生 API 提供非常好的支持，因此我们觉得如果引入 Swarm 的话，对于以前代码的改造成本将会降到最低。

那么我们该如何对原先的网络二层方案进行改造呢？如前所述，我们一直实现的是让容器的 IP 地址与物理机的 IP 地址相对等。

因此并不存在网络不通的情况。同时，我们的 Redis 是直接部署在物理机上的。

所以依据上图中各个列表的对比，我们觉得 Calico 方案更适合我们的业务场景。

因此，我们在上层使用 Rolling 来进行各种流程的操作，中下层则用 Swarm+Calico 来予以容器和网络的管理。

Calico 使用的是 DownwardDefault 模式，该模式通过运用 BGP 协议，来实现对于不同机器之间路由信息的分发。

在默认情况下，Calico 是 Node 与 Node 之间的 Mesh 方式，即：任意两个 Node 之间都有着 BGP 连接。

当我们在一台物理机上启动了某个容器之后，它就会添加一条包含着从容器 IP 地址到物理机的路由信息。

由于多台物理机同处一个 Mesh，那么每一台机器都会学习到该路由信息。而随着我们系统规模的逐渐增大，每一台物理机上的路由表也会相应地增多，这就会影响到网络的整体性能。

因此我们需要采用这种 Downward Default 部署模式，使得不必让每台物理机都拥有全量的路由表，而仅让交换机持有便可。

众所周知，BGP 会给每一台物理机分配一个 AS（自治域是 BGP 中的一个概念）号，那么我们就可以给各台物理机都分配相同的 AS 号。

而给它们的上联交换机分配另一个 AS 号，同时也给核心交换机再分配第三种 AS 号。

通过此法，每一台物理机只会和自己上联的交换机做路由分发，那么当有一个新的节点启动之后，我们便可以将这条路由信息插入到该节点自己的路由表中，然后再告知与其相连的上联交换机。

上联交换机在学习到了这条路由之后，再进一步推给核心交换机。

总结起来，该模式的特点是：

• 单个节点不必知道其他物理机的相关信息，它只需将数据包发往网关便可。因此单台物理机上的路由表也会大幅减少，其数量可保持在“单机上的容器数量 +一个常数（自行配置的路由）”的水平上。
• 每个上联交换机只需掌握自己机架上所有物理机的路由表信息。
• 核心交换机则需要持有所有的路由表。而这恰是其自身性能与功能的体现。

当然，该模式也带来了一些不便之处，即：对于每一个数据流量而言，即使目标 IP 在整个网络中并不存在，它们也需要一步一步地向上查询直到核心交换机处，最后再判断是否真的需要丢弃该数据包。

后续演进

在此之后，我们也将 DevOps 的思想和模式逐步引入了当前的平台。具体包括如下三个方面：

• 通过更加自助化的流程，来解放运维。让开发人员自助式地创建、添加、监控他们自己的项目，我们只需了解各个项目在平台中所占用的资源情况便可，从而能够使得自己的精力更加专注于平台的开发与完善。
• 如今，由于 Kubernetes 基本上已成为了业界的标准，因此我们逐步替换了之前所用到的 Swarm，并通过 Kubernetes 来实现更好的调度方案。
• 支持多机房和多云环境，以达到更高的容灾等级，满足业务的发展需求，并完善集群的管理。

上图展示了一种嵌套式的关系：在我们的每一个 Project 中，都可以有多个 IDC。

而每个 IDC 里又有着不同的 Kubernetes 集群。同时在每一个集群里，我们为每一个项目都分配了一个 Namespace。

根据不同的环境，这些项目的 Namespace 会拥有不同的 Deployment。例如想要做到部署与发布的分离，我们就相应地做了多个 Deployment，不同的 Deployment 标示不同的环境。

默认将流量引入第一个 Deployment，等到第二个 Deployment 被部署好以后，需要发布的时候，我们再直接把流量“切”过去。

同时，鉴于我们的平台上原来就已经具有了诸如日志、负载均衡、监控之类的解决方案。

而 Kubernetes 本身又是一个较为全面的解决方案，因此我们以降低成本为原则，谨慎地向 Kubernetes 进行过渡，尽量保持平台的兼容性，不至让开发人员产生“违和感”。

如今，我们的容器只有一千多个，项目数量大概有一百多个。但是我们在部署效率方面的提升还是非常显著的，我们的几十个开发人员每个月所发布的次数就能达到两千多次，每个交易日的日志量大概有 1.5T。

原文链接： https://mp.weixin.qq.com/s/0JAhx0uFu7rcYjor3Dx9dw

作者：董明鑫，雪球网运维开发架构师，曾就职百度，2014 年加入雪球，目前主要负责保障雪球稳定性、提升资源利用率及提高开发效率等方面。关注容器生态圈的技术发展。