大规模Docker集群助力微博迎接春晚峰值挑战

羊年的春晚与往年的春晚一样，却又不太一样。一样的是服务器君仍要应对全民“DDOS攻击”，不一样的是今年无法通过简单的扩容抵御峰值。今年不但主信息流日常用户活跃度已经达到了去年春晚的峰值，同时渣浪的产品拿出了多个杀手级产品，像红包飞，明星粉丝群，这些产品带来的QPS压力同样惨绝人寰。所以今年仍然按业务峰值扩容部署，信息流、红包飞、通讯、对象库、RPC等多个服务需要的扩容成本显然已经到了无法接受程度。

怎么办？利用各服务的错峰特点，通过容器化弹性调度，解决抗峰值容量问题。平台通过对线上业务进行容器化改造，整体集群完成50%规模的容器化部署，容器节点数达到上千个以上。借助服务发现、弹性调度等基础设施，5分钟内可以完成上百规模节点调度，可即刻提供10W QPS的承载能力，应对任一服务的峰值。

达成这一目标的挑战可以概括为三个方面：时间紧，风险大，范围广。要在一个月的时间内，部署基本属于国内最大的容器化集群，并且提供一样甚至更好的服务SLA，核心接口成功率达到99.99%，平均耗时小于40ms，同时需要覆盖全业务，5分钟内完成服务间资源调配。

下面与大家分享一下平台的一些实践经验和踩过的坑。

分享平台为什么选择Docker

程序猿都知道在代码运行的世界里，拆东墙补西墙是一件不靠谱的事情，弄不好会塌方的。Docker能够完美解决环境差异化问题，通过Image定义依赖的环境因素，宿主机仅提供操作系统内核功能，所以任何一个镜像可以部署到任一Docker化的宿主机上。

当然很多人会有疑问，为什么不采用传统VM？这就是第二个关键问题，就是要快！Docker容器相比传统VM最大优势是可以实现秒级启动，更关键的是可以秒级停止。平台采用“瘦容器”的使用方式，容器与服务同生命周期。服务一旦摘除，容器就会立刻释放资源，新容器可以立刻就地启动，这样能够极大的缩短扩容所需时间。

部署一个大规模容器集群，Docker仅提供核心的容器化技术，为了确保集群的可控性需要一套完整的解决方案。平台的解决方案总体上可概括为：部署架构、服务监控、研发流程、扩容预案等几个方面。

部署

架构平台采用的是简化的结构，有几个建议很大家分享一下：

1. 一个容器仅有一个进程；
2. 采用host网络模式，除非你知道NAT，Bridge有什么坑；
3. 最小化镜像大小，规划好层次结构，并且尽量复用；
4. 日志采用volumn挂载方式；
5. 一切皆容器，例如镜像构建环境也要容器化。

容器化部署最重要也是最复杂的，就是服务发现问题。平台参考Kubernates，Mesos，etcd等开源项目的经验，结合自身的业务特点以及现有基础设施，实现了一套基于ConfigService中心和调度系统服务发现机制。服务调度粒度从原来仅能针对整个服务池，细化到任一一节点，实现了7层nginx，服务节点，RPC节点三者之间的动态联动。这里运维的开发工作量是最大的，必须为运维的小伙伴们点个赞。

Docker部署被诟病最多就是网络，平台目前采用的是host模式，为什么没有采用NAT或者Bridge呢？由于涉及的技术细节比较繁冗，这里仅分享一些踩过的坑。例如NAT使用iptables底层流量转发依靠内核netfilter模块，其默认仅保持65536个链接，在服务有大量链接的场景下，会出现大量拒绝链接的现象。再如Bridge的MAC地址默认是选择其子接口中最先的一个，这样就会导致一个宿主机下多个容器启停时出现网络瞬断。还有很多问题不一一列举，平台未来计划采用vlanif的方案来解决容器网络部署难题，请关注后续微博平台的分享。

服务监控平台

采用的是cadvisor开源方案，但由于cadvisor本身仅提供性能数据不完整，并且仅支持influxdb，所以平台在其基础上进行了二次开发，支持CPU使用率、存活个数、内存占用、Swap占用、磁盘占用等性能指标，并且提供了对ElasticSearch的支持，争取能够回馈给社区。

研发流程要尽量透明，容器应该融入到现有的流程，而不是改变现有流程。例如不要侵入代码，如请使用XXX环境变量等。不要影响原有的测试、发布、降级等流程，如测试预览环境应该容器化，而不应该增加针对容器环境的测试。

扩容预案要确定好规则，避免流量增长时乱扩容，平台通过核心接口QPS，总体QPS，平均耗时三个指标来定义扩容触发条件；扩容比例按流量增长计算，建议以10%规模递增；扩容来源于整体QPS低、冗余Buffer大于50%的服务池。另外有很多细节需要注意，例如机房流量均衡问题、流量突增问题。

回顾

整个项目临近春节，时间紧任务急，小伙伴们也是蛮拼的，在小黑屋不知度过了多少日夜。特别要感谢各位领导的支持和信任，让我们在困难面前没有畏首畏尾。当然这才是刚刚起步，希望更多牛人能够加入到平台大家庭，共同打造容器化平台。