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

轻轻的

编者按
　　每年除夕看春晚，今年除夕抢红包。在整个羊年的春节假期里，大家都在忙着抢各种各样的电子红包，互联网用红包的方式革新了我们的拜年方式。为此，InfoQ策划了“春节红包”系列文章，以期为读者剖析各大平台的红包活动背后的技术细节。本文为微博篇。
　　羊年春晚Docker集群成功的为1.02亿小伙伴刷微博、抢红包提供了可靠的服务。本文将为大家揭开微博平台Docker集群的神秘面纱，包括集群规模，技术架构等方面情况。不过在分享前，先问两个问题，不知道大家是否正为这两个问题而纠结：

• 　　Docker技术能够解决什么问题？
  
• 　　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）关注我们，并与我们的编辑和其他读者朋友交流。

• 　　领域
  
• 　　运维 & 基础架构
  
• 　　架构 & 设计
  
• 　　语言 & 开发
  
• 　　专栏
  
• 　　微博
  
• 　　架构
  
• 　　Docker
  
• 　　春节红包
  
• 　　转载:http://www.infoq.com/cn/articles/large-scale-docker-cluster-practise-experience-share