微博红包：大规模 Docker 集群实践经验分享

编者按

每年除夕看春晚，今年除夕抢红包。在整个羊年的春节假期里，大家都在忙着抢各种各样的电子红包，互联网用红包的方式革新了我们的拜年方式。为此，InfoQ 策划了“春节红包”系列文章，以期为读者剖析各大平台的红包活动背后的技术细节。本文为微博篇。

羊年春晚 Docker 集群成功的为 1.02 亿小伙伴刷微博、抢红包提供了可靠的服务。本文将为大家揭开微博平台 Docker 集群的神秘面纱，包括集群规模，技术架构等方面情况。不过在分享前，先问两个问题，不知道大家是否正为这两个问题而纠结：

1. Docker 技术能够解决什么问题？
2. Docker 技术是否足够成熟，是否可以在生产环境上大规模应用？

一个月前，微博平台也在这两个问题中纠结一段时间，事实胜于雄辩，先来看一下微博平台 Docker 集群的规模情况：

• Docker 集群规模达到 1000+ 节点
• QPS 峰值达到 800K/s
• 4 个 9 的服务 SLA 达到 150ms
• 共覆盖 23 个核心服务
• 春晚共调度近 300 节点完成动态扩容

在引入任何新技术之前，在架构决策上必须回答：我们现在有什么问题，它能够解决吗。否则就变成了唯技术论，造成不必要的资源浪费。促使平台做出决定的一个主要因素就是春晚的红包飞活动。现在大家都知道，微博春晚红包飞共计抽取了 3.5 亿次，马云的支付宝红包以及任性土豪的 1234567 元跨年红包，在 3 分钟内被抢光，带动用户用活跃度提升 46%，达到 1.02 亿用户。同时广大用户还活跃在各种粉丝群中，为了抢到一个分组红包手机屏幕都快点碎了。面对这种到处开花的流量峰值，传统按照业务峰值部署集群的方式，设备成本将无法接受。所以平台需要一种能够在集群间快速调度业务的技术方案。

Docker 是目前能够实现这一目的的最佳方案。为什么原有的集群管理方式，无法实现快速业务切换呢，关键问题是环境的差异性。程序猿都知道在代码运行的世界里，拆东墙补西墙是一件不靠谱的事情，弄不好会塌方的。虚拟化可以实现隔离软件运行环境差异性，目前虚拟化技术有以 OpenStack 为代表传统 VM 技术，和以 Docker 为代表的 Container 技术两大类。如何在二者中进行选择，平台从下面几个维度进行了评估，供大家参考：

Docker

OpenStack

结论

启动速度

秒级

分钟级

面对流量峰值，速度就是一切

复杂度

基于内核的 namespace 技术，对现有基础设施的侵入较少

部署复杂度较高，并且很多基础设施不兼容

因为平台是对已有的线上生产系统进行改造，必须选择侵入性较小的容器化技术

执行性能

在内核中实现，所以性能几乎与原生一致

对比内核级实现，性能较差

微博核心业务对服务 SLA 要求非常苛刻

可控性

依赖简单，与进程无本质区别

依赖复杂，并且存在跨部门问题

生产系统集群可控性是核心竞争力能力

体积

与业务代码发布版本大小相当，MB 级别

GB 级别

当集群大规模部署时，体积小就代表更大的并发调度量

下面先介绍目前微博平台 Docker 集群的技术栈：

• 宿主机：CentOS 6.5
• Docker：1.3.2
• Registry：docker-registry 0.9.1 版本
• 组网：host 模式
• 监控：cAdvisor + Elasticsearch + Kibana + Graphite
• 文件系统：devicemapper
• 镜像发布：Jenkins Container
• 容器：容器即服务，服务即容器
• 日志：volume 挂载
• 生命周期管理：自研，类似 Compose
• 服务发现：自研，类似 Kubernetes 的 Pods 和 Service

那么从无到有部署一个超过 1000 节点，风险和挑战是非常大的。必须有一套方法能够确保在改造过程中业务的稳定性，平台也想了很多办法，但其实宗旨就一个：可控。把这些方法可以总结为几条原则：

• 规模化
• Stupid But Works
• 无缝对接

先来谈一谈规模化。乍一看，规模化与可控是对矛盾体。程序员都知道，如果一种新技术不在大规模环境下验证通过，是无法证明其可靠性。从业务角度，一旦引入新技术，就要承担出问题的风险，所以业务都希望引入的新技术是通过大规模环境验证过的。对于这种情况，一般做法有两种，一种是先在一个业（bei）务（cui）试点，成功后再进行推广。但是这种方式主要问题是反复概率较大，引用一句台词就是：“我吃了没事，不代表你吃了就没事”，结果就会出现到处打补丁的局面，不利于架构标准化。所以平台采用的是“大锅饭”的方式，就是所有业务同时上马，逐步增加规模。这种方式好处显而易见，差异性可以在第一时间得到解决，最终只有一套标准化架构。但这种方式需要非常强的项目管理能力，保证各业务组目标一致，分工明确，里程碑清晰，同时还需要项目组成员有强烈的使命感，时间意识，团队意识。

搞定团队之后，首要任务就是要使工作保持方向，那么什么是正确方向呢：Stupid But Works。新技术落地项目失败有很多因素，其中主要一个诱因就是：完美主义，或者叫偷换目标。典型症状如下：目前架构不够优雅，需要 XXX。例如 Docker 的组网能力饱受诟病，此时不应该纠结一个完美的组网方案，否则就可能项目不保。因为技术突破都依赖很多先决条件，可能是受限于基础网络环境，受限于内核能力，所以此时最佳的策略是跟上趋势，积累经验，伺机突破。再比如 Docker 对日志数据管理方式奇多，但最完美的并不一定适合你，如果此时决定对现有的日志管理进行改造，就合原本的目标背道而驰了。最佳的策略是选择认知成本最小的方案，而不是最完美的方案。

对已有集群进行 Docker 化改造，最大的一个阻力就是新老结合问题，所以 Docker 集群必须能与原有运维、研发系统无缝对接，才能够使项目顺利进行。例如容器化，是否改造代码。平台当时遇到的一个问题是不同宿主机的容器分配的 ip 有可能是一样的，原本获取本地 ip 的代码就会取到相同的值，直接导致分布式系统跟踪系统失效。所以要在 Docker 层面解决这个差异性，而尽量不修改原系统设计。

对于 Docker 未来部署规模达到万级别后，还有很多技术难题有待解决，平台也会在下面几个方面继续探索，希望能够把经验回馈给社区：

• 网络瓶颈，万级别的容器部署，势必会挑战现有的网络基础设施，交换机的转发表项会遇到瓶颈。网络隔离可以保证服务间互不影响，但是又限制了灵活调度，SDN 是大趋势。
• 弹性调度，目前还处于“社会主义初级阶段”，一切都还要靠“中央”下达指令。Kubernetes、Mesos、Swarm 等技术提供在万级别集群规模下自动化弹性调度的可能性，但整体解决方案我们也还在摸索。

微博平台期待你的加入，共同开始打造大规模 Docker 集群。

感谢郭蕾对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。