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

原创
开发 架构 大数据
2016年4月14-15日,由51CTO传媒主办的WOT2016互联网运维与开发者大会在北京珠三角JW万豪酒店召开。秉承专注技术、服务技术 人员的理念,自2012年以来,WOT品牌大会已经成功举办九届,积累了大量的技术专家资源,获得了广大IT从业者和技术爱好者的一致认可,成为了业界重要的技术分享交流平台以及人脉拓展平台。

来到移动互联网时代,广告技术发生了质的改变。不再像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这种方式,比如一些对于可靠性要求非常高的业务,会提高项目整体迭代能力和可靠性。

 

 

 

责任编辑:Ophira 来源: 51CTO.com
相关推荐

2013-04-24 10:31:44

公有云云安全

2023-07-07 08:16:53

Redis持久化

2023-10-27 07:36:16

存储系统数据防丢

2022-03-07 08:13:06

MQ消息可靠性异步通讯

2018-09-27 14:13:27

云服务可靠故障

2010-12-28 19:50:21

可靠性产品可靠性

2013-12-06 15:31:49

TechEd2013

2021-09-03 09:00:00

SREIT运营

2010-09-15 17:12:28

UPS寿命

2013-02-01 14:13:41

服务器内存可靠性可用性

2014-02-13 10:30:13

云计算迪普科技DPX19000

2019-07-26 08:00:00

微服务架构

2017-09-13 12:18:29

2023-06-27 17:50:22

2022-07-29 15:46:19

测试混沌工程

2019-08-30 12:10:05

磁盘数据可靠性RAID

2022-08-05 12:59:50

物联网IoT

2020-12-06 14:51:23

物联网可靠性IOT

2010-12-28 19:55:20

软件架构可靠性

2010-12-28 20:04:10

网络的可靠性网络解决方案可靠性
点赞
收藏

51CTO技术栈公众号