聚效广告张烨：基于Docker和Mesos的服务可靠性保障实践

来到移动互联网时代，广告技术发生了质的改变。不再像PC时代广告的展示空间、广告样式那样丰富和自由；广告的商业化特殊特征，也使其技术平台接受着高并发、极低延时和大数据量的挑战。面对移动时代越来越苛刻的用户体验需求，广告业务对于系统可靠性的要求也变得越来也高。

在WOT2016互联网运维与开发者大会现场，51CTO记者专访到聚效广告SRE工程团队总监张烨，探寻聚效工程团队是如何利用Docker 和 Mesos来保障服务可靠性的。

嘉宾简介

张烨（Michael）目前就职于聚效广告平台工程师团队，主要负责SRE和大数据平台。十多年互联网行业的DevOps实践经历，也是OCP在国内的少数先行者之一。同时也是中国反垃圾邮件联盟的联合创始人和Linux中国小区的初创专家。

为什么是Docker

移动互联网时代的广告创意和营销，必须要找到精准与用户体验之间的平衡点。张烨介绍说，为了应对挑战，聚效广告除了依托数据和精准营销的技术之外，还针对移动端的一些新特性和场景，设计In APP广告、HTML5广告等一些特有应用，基于原有的基础平台尝试不同的产品化实现。这些广告产品业务的复杂性及商业化的特殊性，使聚效广告系统需要表现出更高的可靠性，来应对高并发、极低延时和大数据量的挑战。

张烨认为对于可靠性的定义，应该基于整体业务平台之上来衡量，包括公司系统的经济损失、商业品牌塑造、媒体影响力等等，而不应该局限于系统的某些模块或服务可用性。可靠性指标是一个目的，为了达到这个目的，企业还需要要解决哪些问题，系统架构、开发和运维工具等方面还需要做哪些事情，根据业务的实际情况是应该将目标定为3个九、4个九或是更高，等等。为了达到目的，企业需要从技术和可靠性等方面做综合的考量。

为了保障服务的可靠性，以及提高系统的灵活伸缩性能，聚效工程团队在Docker容器化和Mesos资源调度框架方面进行了较为深入的探索。2014年底，聚效SRE团队开始接触Docker，2015年中旬开始正式将Docker投入到生产环节来使用。张烨说之所以选择Docker,是为了解决公司业务对于服务可调度化的需求。他们发现将服务Docker化可以解决这个诉求，于是开始将Docker集成到公司原有的的CICD（持续集成与持续交付）的开发流程中，并驱动团队开发和保证这些监控工具和运维工具的可用性。“我们不是为了Docker而使用Docker，Docker只是一个轮子，是驱动我们提高软件和系统品质的工具”，张烨这样告诉记者。

为什么是Mesos

随着在生产环境下部署Docker集群的需求越来越多，Mesos、Kubernetes等资源管理和调度软件也渐渐走进大家的视线。经过不断的选型和尝试，聚效广告系统目前采用的是Mesos来实现Docker集群的管理和资源调度

最初聚效广告系统选择的是Kubernetes来管理Docker集群。“Kubernetes是很好的整体解决方案，因为它是一个大而全的工具，既能解决容器化、又能解决资源调度，又能解决服务发现等等的问题”，张烨是这样评价Kubernetes的。那是什么原因让他们放弃Kubernetes，转而使用Mesos的呢？张烨向记者解释说，这是因为Kubernetes的网络模型比较复杂，在高并发情况下的性能是很大的问题，但这正是广告系统非常关键的需求，因此只能无奈放弃。

Mesos是Apache下的开源分布式资源管理框架，起源于Google的数据中心资源管理系统Borg，被称为是分布式系统的内核。Mesos实现了双层调度机制，使它可以管理多种类型的应用程序。第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成，包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管。这些Framework可以减少个业重造轮子的代价，像Mesos本身不处理网络问题，但利用Marathon我们可以选择Docker本身提供的Host模式和Bridge模式。Mesos的开源特性与基于Framework的调度机制，是聚效广告系统选择它的重要原因。

服务Docker容器化的典型问题

经过不断的摸索和实践，聚效SRE团队在服务Docker容器化方面积极了很多经验，张烨也享了几个比较典型的问题。

• 不要在Docker中加入SSH

很多人都喜欢用SSH，也会认为在Container里安装一个SSH Server 就可以直接连接Container并且进入它的内部，这样就可以很容易地检查日志，做备份，或者重启进程，调整配置等。但其实只有SSH Sever是不够的，还需要加入进程管理软件，Monit 或 Supervisor等监控软件，而且由于Docker只能管理单进程，如果应用停止了，我们只能通过进程管理软件那里获得信息，这样就把简单的Docker复杂化了，并且还会有一些访问安全上的隐患。在使用Docker的时候，一定要跳出把它当成小“vps”的误区，寻找其它解决方案来处理需要SSH的问题

• 存储持久化

Docker 有一个Plugin的机制，可以让一个容器为其他容器提供存储。这个容器是可以Ceph, Gluster或者任何其他的存储集群的一员，并挂载在另一个容器上，来解决存储持久化的问题。

• Docker网络性能

张烨讲到，他们跳过了Docker本身网络性能问题。对于网络性能需求高的服务，他们选择了它的host模式来兼容；对于网络性能不高的服务，则是采用Docker本身自带的网络解决方案，从而避免了我们重新去做SDN的研发，或者说重新造轮子的代价，而是选择用适合于自身业务的产品绕过去。

留给每位工程师的DevOps问题

Docker是一个对开发者非常友好的东西：简单的实现不同机器上的环境标准化，可以轻松拿来拿去，而且在不同的云平台上都支持。但把Docker用起来对运维而言则是很大的挑战。

张烨告诉记者，在聚效，DevOps是每个工程师都必须要做的事情，所有开发规范和工作方式都是围绕DevOps的方式去做，所以对每位工程师的能力要求非常高。因为每位工程师不仅仅是在开发产品的Feature，还要在DevOps理念的指导下，考虑开发出来产品的可运维性、可监控性、可交付性等等，并且日常的Ops的这些On call工作，也是由Dev-team轮流完成。

张烨的建议是，不要强求每个团队都要用DevOps这种方式工作。我们可以在特定的团队和特定的项目里采用DevOps这种方式，比如一些对于可靠性要求非常高的业务，会提高项目整体迭代能力和可靠性。