容器到来之前
在容器平台实施之前，美团点评的所有业务都是运行在美团私有云提供的虚拟机之上。美团点评大部分的线上业务都是面向消费者和商家的，业务类型多样，弹性的时间、频度也不尽相同，这对弹性服务提出了很高的要求。
在这一点上，虚拟机已经难以满足需求，主要体现以下两点：
1.虚拟机弹性能力较弱，部署效率低，认为干预较多，可靠性差。
2.IT 成本高。由于虚拟机弹性能力较弱，业务部门为了应对流量高峰和突发流量，普遍采用预留大量机器和服务实例的做法。资源没有得到充分使用产生浪费。
容器时代
架构设计
美团点评将容器管理平台视作一种云计算模式，因此云计算的架构同样适用于容器。
如前所述，容器平台的架构依托于美团私有云现有架构，其中私有云的大部分组件可以直接复用或者经过少量扩展开发，如图所示。
图 1. 美团点评容器管理平台架构
整体架构上与云计算架构是一致的，自上而下分为业务层、PaaS 层、IaaS 控制层及宿主机资源层。
1.业务层：代表美团点评使用容器的业务线，他们是容器平台的最终用户。
2.PaaS 层：使用容器平台的 HTTP API，完成容器的编排、部署、弹性伸缩，监控、服务治理等功能，对上面的业务层通过
HTTP API 或者 Web 的方式提供服务
3.IaaS 控制层：提供容器平台的 API 处理、调度、网络、用户鉴权、镜像仓库等管理功能，对
PaaS 提供 HTTP API 接口
4.宿主机资源层：Docker 宿主机集群，由多个机房，数百个节点组成。每个节点部署
HostServer，Docker、监控数据采集模块，Volume 管理模块，OVS 网络管理模块，Cgroup
管理模块等。容器平台中的绝大部分组件是基于美团私有云已有组件扩展开发的，例如镜像仓库、平台控制器、HostServer、网络管理模块。容器平台的技术栈，核心组件，包括平台控制器，网络服务，调度器等都是自研开发的。Docker
镜像仓库基于 Openstack 的 Glance 扩展开发，监控系统有使用 Falcon，CAT；服务治理、服务发现、服务负载均衡是使用的美团自研系统。开发语言主要是
Python 和 Golang。
容器网络
高性能、高弹性的架构设计
容器平台在网络方面复用了美团云网络基础架构和组件，逻辑架构设计如图所示。
图 2. 美团点评容器平台网络架构
在数据平面，我们采用万兆网卡，结合 OVS-DPDK 方案，并进一步优化单流的转发性能，将几个 CPU
核绑定给 OVS-DPDK 转发使用，需要少量的计算资源即可提供万兆的数据转发能力。OVS-DPDK
和容器所使用的 CPU 完全隔离，因此也不影响用户的计算资源。控制平面我们使用 OVS 方案。所谓
OVS 方案是在每个宿主机上部署一个软件的 Controller，动态接收网络服务下发的网络规则，并将规则进一步下发至
OVS 流表，决定是否对某网络流放行。
自研配置模式 MosBridge
在 MosBridge 之前，我们配置容器网络使用的是 None 模式。在实践中，我们发现 None
模式存在一些不足：
1.容器刚启动时是无网络的，一些业务在启动前会检查网络，导致业务启动失败；
2.网络配置与 Docker 脱离，容器重启后网络配置丢失；
3.网络配置由 Host-SRV 控制，对于以后网络功能的升级和扩展带来很多不便，例如对容器增加虚拟网卡，或者支持
VPC。
为了解决这些问题，我们基于 Libnetwork，开发了 MosBridge – 适配美团云网络架构的
Docker 网络驱动。在创建容器时，需要指定容器创建参数—net=mosbridge，并将 ip
地址，网关，OVS Bridge 等参数传给 Docker，由 MosBridge 完成网络的配置过程。有了
MosBridge，容器创建启动后便有了网络可以使用。容器的网络配置也持久化在 MosBridge
中，容器重启后网络配置也不会丢失。
容器存储隔离性
为了解决本地磁盘数据卷限容能力弱的问题，我们开发了 LVM Volume 方案。该方案在宿主机上创建一个
LVM VG 作为 Volume 的存储后端。创建容器时，从 VG 中创建一个 LV 当作一块磁盘，挂载到容器里。这样
Volume 的容量便由 LVM 的 LV 加以强限制，得益于 LVM 机强大的管理能力，我们可以做到对
Volume 更精细、更高效的管理。例如，我们可以很方便地调用 LVM 命令查看 Volume 使用量，通过打标签的方式实现
Volume 伪删除和回收站功能，还可以使用 LVM 命令对 Volume 做在线扩容。
图 3. LVM-Volume 方案
容器状态采集
在设计实现容器监控之前，美团点评内部已经有了许多监控服务，例如 zabbix，falcon 和 CAT。我们不需要设计实现一套完整的监控服务，而更多地是如何高效地采集容器运行信息，根据运行环境的配置上报到相应的监控服务上。
图 4：监控数据采集方案
针对业务和运维的监控需求，我们基于 libcontainer 开发了 mos-docker-agent
监控模块。该模块从宿主机 proc、cgroup 等接口采集容器数据，经过加工换算，再通过不同的监控系统
driver 上报数据。该模块使用 go 语言编写，既可以高效率，又可以直接使用 libcontainer。而且监控不经过
Docker Daemon，不加重 Daemon 的负担。
美团自研容器分支：MosDocker
基本介绍
我们从 Docker 1.11 版本开始，自研维护一个分支，我们称之为 MosDocker。除了一些
Bugfix 之外，MosDocker 还有一些自研的特性。
1.MosBridge：支持美团云网络架构的网络驱动。
2.Cgroup 持久化：扩展 Docker Update 接口，可以使更多的
cgroup 配置持久化在容器中，保证容器重启后 cgroup 配置不丢失。
3.支持子镜像的 Docker Save，可以大幅度提高 Docker
镜像的上传、下载速度。
MosDocker 的大部分特性是解决美团点评业务场景的需求问题，不适合开源。对于社区的 bugfix，我们会定期
review 并 backport 到我们的 MosDocker 版本里。
原理探究：服务治理与容器编排
图 5：美团点评服务治理平台
组件：
1.MNS：命名服务
2.SG_agent: 服务治理代理
3.HLB：弹性负载均衡器
功能：
1.服务命名、注册、发现
2.负载均衡
3.容错
4.灰度发布
5.服务调用数据可视化
图 6：set 容器组设计
设计特性
1.松耦合
2.容器组作为一个整体调度、管理
3.容器之间 CPU、IO 资源隔离
4.网络栈，Volume 共享
参考 Kubernetes 的 Pod 设计，针对我们的容器平台设计实现了 set 容器组。容器组对外呈现一个
IP，内置一个 busybox 作为 infra-container，它不提供任何业务功能，set
的网络、volume 都配置在 busybox 上，所有其他的容器都和 busybox 共享。
在实际业务中的推广应用
通过引入 Docker 技术，为业务部门带来诸多好处，典型的好处有几点：
1.快速部署，快速应对业务突发流量由于使用 Docker，业务的机器申请、部署、业务发布一步完成，业务扩容从原来的小时级缩减为秒级，极大地提高了业务的弹性能力。
2.节省 IT 硬件和运维成本Docker 在计算上效率更高，加之高弹性使得业务部门不必预留大量的资源，节省大量的硬件投资。
以某业务为例，之前为了应对流量波动和突发流量，预留了 32 台 8 核 8G 的虚拟机。使用容器弹性方案，即
3 台容器 + 弹性扩容的方案取代固定 32 台虚拟机，平均单机 QPS 提升 85%， 平均资源占用率降低
44-56%。
图 7. 某业务虚拟机和容器平均单机
QPS
图 8 某业务虚拟机和容器资源使用量
Docker 在线扩容能力，保障服务不中断
总结
在容器化过程中，我们发现 Docker 或者容器技术本身存在许多问题和不足，例如，Docker 存在
IO 隔离性不强的问题，无法对 Buffered IO 做限制；偶尔 Docker Daemon 会卡死，无反应的问题；容器内存
OOM 导致容器被删除，开启 OOM_kill_disabled 后可能导致宿主机内核崩溃等等问题。因此
Docker 或者容器技术，在我们看来应该和虚拟机是互补的关系，不能指望在所有场景中 Docker
都可以替代虚拟机，因此只有将 Docker 和虚拟机并重，才能满足用户的各种场景对云计算的需求。
|
