DockOne微信分享(五十):太保DCOS平台——微信项目实践 – Docker.Ren

摘要

[db:摘要]

【编者的话】本次分享从三方面展开:为什么要引入Docker、Docker在太保的落地、太保Docker未来之路的思考。@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网、华为等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。背景2016除夕,相信很多朋友都非常关注支付宝的“咻一咻”和微信的“摇一摇”。通过这两个产品,我们不难发现,手机红包“仅在短短三年时间”里,就成为互联网金融的现象级产品。然而传统金融行业如何利用自己的优势,加速互联网入口布局,成为了我们的一个重要课题。今年春节我司希望借此良辰佳节,运用互联网的技术方式,展开“太保‘友’你,太保有礼”的除夕微信红包活动与初五迎财神抽奖活动,用千万“猴”礼,回馈新老客户。活动之前,腾讯就评估本次微信活动参与人次可能会达到1.5亿人次,高峰并发请求量达到每秒400万次。面对如此之大的用户量与交易量,不禁让我们思考,是否传统架构可以承受并支持业务活动的顺利开展?是否有比传统架构更好的方式或技术来支持?传统架构分析针对上述的三个问题,我们首先针对业务活动情况,在传统架构基础上做了部署规划方案及承载能力数据统计。但是从数据结果上看,使用传统架构来实现业务支持是不可能的。不仅资源准备周期长,同时部署过程繁琐,无法如期满足业务活动需要。即便连夜赶工完成,可能也要面临部分节点故障导致的应用服务问题。同时在传统架构上,我们也发现了另外一个严重问题。由于我司大部分应用是在虚拟机上使用Weblogic和Websphere来部署,每个节点的资源利用率上,很不平均,部分应用服务可能在本次活动中,并不会存在大并发量或者产生很多业务数据,却要占用相当一部分的资源。如果压缩资源,又担心是否会存在不稳定的情况? 不仅如此,相应的应用维护压力也会出现,如何保障应用服务稳定,也是一个难题。需求分析面对传统架构部署可能带来的这些问题,我们重新对业务活动及本身的我司微信应用做了全面的分析及解决方案的规划:需要更高效的虚拟化技术。由于我司业务特性,本次活动需要同时部署十多个类型的应用。对于不同的应用,传统方式需要不同的软硬件部署方案。为减少软硬件部署周期,需要提出更高效的虚拟化方案和技术。需要更快的部署和交付。由于准备时间周期短(1个月),如何更快的部署开发、测试、生产环境,并且交付保质保量的环境,需要更快和高质量的应用部署方案。更轻松的迁移和扩展。面对三个环境的部署,且各环境对并发量需求存在不同。需要迁移的应用迁移及能适应环境需求的扩展方案。更简单的管理。面对大量的应用服务,需要有效和简易的应用服务管理方案,来实现自动恢复及异常容错能力。新技术选型带着这些问题,我们结合行业内优秀技术方案和经验,决定使用容器化技术(Docker)来支持我们的业务活动。首先,我们针对原有微信项目架构进行回顾:面对原有以应用为单位的部署方案上,需提高资源利用率,降低虚拟机资源和中间件部署的耗费。为了解决这个问题,我们以Mesos、Marathon为核心,实现容器资源的分布式调度与协调。同时服务引流方面,鉴于原有Apache方案和应用本身特性上,采用了HAProxy来实现。其次,部分应用存在有状态Session或者热点数据,这个方面上与我们实施的方案存在冲突。为了解决这个问题,并且规避实时数据丢失,我们采用了Redis将Session数据集中存储,并使用容器挂在共享nas的方式来集中存储文件(例如影像等)。第三,为实现准确的应用监控及应用健康状态检查方案,我们针对每一个应用镜像都植入了“APM探针”,实时获取应用服务信息,如:线程数、交易响应时间等,并将数据实时记录。同时通过这些监控指标信息,来具体分析应用能力,实现应用服务自动伸缩。最后,在此基础上增加日志分析平台、自动化运维平台、端到端监控的APM平台等用于资源的统一管理、监控及问题分析,继而形成一套完整的DCOS架构。过程回顾虽然本次活动顺利收官,但是过程中遇到了一些问题:比如在压测过程中,跨网段的服务器,因网络问题致使mesos-slave与mesos-master失联,导致mesos-slave容器自动销毁。此时master无法再获取到资源节点上的容器信息,导致大量容器服务不能被发现。当时面临这个问题,第一时间还以为是资源节点服务器宕机,但是登录问题节点后才发现是slave容器不存在。在尝试重启slave后,发现容器依然自动停止。通过日志查询才发现是无法与master进行通讯。对此我们添加了docker_kill_orphans、recovery_timeout配置文件,避免在网络异常情况下,出现slave容器停止情况。由于部分应用使用资源上需要大于1c,但是测试环境资源有限,出现资源争用现象,压测数值一直不理想。在压测过程中,以上两个问题,导致项目几经波折,几乎要面临回归传统架构的方式。最后经过反复尝试,采用了限制容器CPU的参数配置方式,从而避免了由于资源互相争用而导致的服务能力不稳定。另外,容器平台的使用对传统的运维方式也带来了巨大的挑战,传统的应用监控、日志采集分析方法由于容器平台的动态扩展特性,效果都不理想。通过采用APM及日志分析平台与容器镜像的集成,解决了容器平台的使用给生产运维带来的困扰。太保Docker未来之路的思考经过本次项目后,借助Docker的一次创建,到处运行的特性搭建了我司的DCOS平台,不仅为开发人员提供了便利,也保证了开发环境、测试环境和生产环境的一致性。但是从居安思危的角度考虑,我们还是在很多方面需要完善,比如镜像版本过多后,我们该如何管理?如何将DCOS平台部署的部署方案细化?还有就是最近大家都在关心的容器安全问题,是否有要求和有标准的选择共有仓库中的镜像?为了做好这个功课,也是为了更好的推广DCOS平台,我们制定了包含镜像版本管理规则、软件版本升级规则在内,含盖开发、环境管理、生产运维领域的一系列容器相关规范、流程及技术方案。后续我们还将持续对DCOS平台在稳定性、安全性及可维护性方面进行优化。并大力推进容器技术在新项目及原有系统中的使用。Q&AQ:想问下嘉宾,资源调度层为啥选用了Mesos而不是Kubernetes?Mesos使用的是开源版本?从项目预研到落地投入的人力是多少(含开发、测试、运维)-方便透露的话?A:Kubernetes提供的集成功能较多,可以提供整体的解决方案,但我们有很多内部的应用间调用,最后选定了HAProxy+Mesos的方式,而且从前期的评测来看Mesos与Marathon集成更为稳定。Q:容器运行WebLogic的时候有没有遇到什么坑可以分享一下吗?A:容器运行WebLogic本身没有问题,但如果程序包过大,容器的自动恢复时间会较长,所以建议控制每一程序包的大小。Q:研究新的软件如Mesos这么重量级的产品也是需要很大的时间成本和人力成本的!如何权衡的?A:主要还是看面对的问题,在微信红包这样的应用场景中传统技术已遇到瓶颈,必须要引入新技术。不过我们很多新技术的研发是前期即进行,进行前期的技术储备。Q:我们发现,在Mesos中,如果主进程先退出,而子进程还在的话,会导致task直接返回,而我们的实际应用中有比较复杂的父子进程关系,除了重新梳理一下外,还有什么别的好的做法?A:应用之间的依赖关系,我们正在着手在Marathon调度之前,如B应用与A应用有依赖关系,则先判断A是否启动,A如果没启动则启动A再启动B,同时,需判断A应用启动后是否满足应用服务能力,比如一个容器是否能承受压力。Q:请问下Docker地址如何分配和管理跨主机通讯?A:地址是有容器平台动态分配,跨主机通讯通过HAProxy进行应用间调用。Q:你们如何做监控的?就是红包活动的时候如何监控当前的服务器性能或者是接口的访问量之类的?Q:聊一聊为什么使用传统方法+APM监控而不使用cAdvisor 、Prometheus、Docker API来实现?A:两个问题我一并回答,因为我们APM并不是仅使用在容器平台,目前在传统平台也使用,正好上容器平台发现传统监控遇到问题,当时我们做APM的poc有一段时间,发现APM正好可以解决此问题,所以就采用了这种方式。 容器平台本身是有性能和可用性监控工具。用APM是更好的进行应用的端到端监控。Q:传统行业转容器一般没那么容易,你们有什么过度方案吗?A:我们针对无状态的应用、传统应用的容器化都制定了对应的技术方案,帮助研发团队进行应用的容器化迁移。以上内容根据2016年3月22日晚微信群分享内容整理。分享人沈大斌,太平洋保险信息技术中心高级经理,目前主要负责Docker容器技术在太保集团的落地、推广及优化工作。18年保险行业IT从业经验,专注于应用运维领域。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

docker

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: