看浙江移动如何将 CRM 系统成功接入 DCOS 平台

DCOS(云操作系统)即是 Mesos 的“核心”与其周边的服务及功能组件所组成的一个生态系统,可以运行在任意的 linux 环境,公有或私有云,虚拟机甚至是裸机环境,逐渐被大家认可。

之前一篇文章《关于 Mesos,你知道多少》详细的介绍了 Mesos 的概念以及使用场景 ,Mesos 目前不仅用于国外的 Twitter,PayPal,eBay 等公司的分布式实践,也受到国内的爱奇艺,去哪儿,小米,乐视等多家公司的青睐。

近期浙江移动将 CRM 系统成功接入 DCOS 平台的实践,足以说明 Mesos 以它的轻量级,提高分布式集群的资源利用率等特点被越来越多的公司接受并用于实践。

数人云是基于 Mesos 的云操作系统(DCOS),在得到浙江移动的转载授权后决定将这一实践分享给大家,Mesos 的实践和未来需要我们大家一起努力。

CRM 系统成功接入 DCOS 平台

2015 年 12 月10 日晚,杭州西湖科技园中国移动浙江公司三墩枢纽楼灯火通明,在湖州分公司的通力合作下,CRM 系统正式接入 DCOS 平台,同时湖州分公司作为第一个试点地市进行了 DCOS 新环境的割接上线。经过一周的实际操作验证和观察,系统运行稳定、情况良好,标志着CRM系统接入 DCOS 平台成功!

三墩 IT 人通过不断努力,前期已顺利完成 DCOS(DataCenter Operating System,数据中心操作系统)平台的建设,并于今年双11活动期间,平稳支撑了浙江公司手机营业厅各类促销秒杀活动,在实际业务场景下充分验证了平台的可靠性和稳定性。基于平台优异的表现,三墩 IT 人制定了更高的目标,决定将运营商最核心的 CRM 系统接入 DCOS 平台。CRM 系统接入 DCOS 平台后,做到了“四化”,即服务标准化、架构透明化、开发敏捷化、发布便捷化,实现了 CRM 系统 WE B端、以及 WEB-APP 端的在线发布,上线发布的同时对前台业务操作几无感知;系统架构和高可用更加稳健,并且大幅提升后台硬件资源使用效率。

项目组精诚团结,克服了“时间短、难度大、风险高”三大难题:从目标制定(2015 年 11 月16 日)到预计上线(2015 年 12 月12 日),只有 27 个日夜,648 个小时,为了实现既定目标,项目组必须分秒必争;其次是必须面对负载设备无法适应 WEB 层应用服务自动扩缩容、用户会话数据无法满足 Docker 的无状态要求、APP 自动扩缩后带来的服务发现和负载均衡等技术难题;最后就是传统运营商系统架构力求稳定,通常采用商业应用解决方案,一直未有运营商敢于将核心系统尝试运行于 DCOS 的 Docker 环境下,本次项目可能遇到前所未有的巨大风险。

经过近一个月的不懈努力,项目组对现有系统存在的各类问题进行了逐一解决,取得了一系列重大创新和突破,为后续应用迁移到 DCOS 平台积累了可借鉴的实战经验,为未来解决生产发布等问题奠定了坚实的基础。

铿锵三人行

“DCOS 激情三人组”隆重登场!!!

“DCOS 激情三人组”为 CRM 系统接入 DCOS 平台做出了重大贡献,功不可没!

好了,言归正传!下面为大家分享三墩IT人在此次 CRM 系统接入过程中的经验总结!

纯干货!不要走开 :)

应用改造经验总结

CRM 系统经过多年建设,不断优化,形成如下的典型架构:

用户请求通过负载均衡设备进行连接分发到相应的 Web 应用上。Web 集群和 Web App 集群一一对应,Web App 主要处理业务路由、服务调用组合等。Web App 通过 ESB(Enterprise Service Bus)企业级服务总线调用EJB业务服务。最终由EJB服务落地相应业务逻辑和数据存储。通过在 Web 层 JVM 中缓存用户前台的一些临时数据。负载均衡设备进行会话保持。Web 到 Web App 层是通过集群一对一部署的,Web 层通过启动时读取配置文件来确定连接到哪个 Web App 服务上。

项目组对现有系统存在的问题一一给出了解决方案。

WEB层应用改造

Web 实例的 JVM 中缓存用户登录信息、部分号码的业务信息。通过引入 Redis 缓存进行会话集中管理,解决用户浏览的临时数据存放问题。

为了能实现 Web 层实例的自动扩缩容,但是负载均衡设备无法通过应用自动更改应用实例映射端口,所以在负载均衡设备后增加了 HAProxy 软负载,解决Web实例新增后自动扩展负载端口的问题。

改造完成后用户的缓存数据使用方式:

  1. 用户访问 WEB 实例1,登录后生成用户信息。
  2. WEB 实例1以 sessionId 为唯一标示,将用户信息存放于 REDIS 缓存中,并指定用户信息的过期时间。
  3. 前端 WEB 层由于在 Array 后面加了 HAProxy,暂时无法保证会话保持,同一用户的请求可能会分发到 WEB 实例 2。
  4. WEB 实例 2 通过在 cookie 中查询到的 sessionId 向 REDIS 中查询用户信息,若有则认为用户为登录状态。
  5. 若操作员进行组织切换或变更操作的手机号码时,会变更了操作员的信息,若操作员进行登出时,则会触发清除操作员信息的指令。
  6. 变更、清除 REDIS 中的用户信息。

改造后,用户的临时数据通过 REDIS 存放,不在存储于 JVM 中,HAproxy 采用随机连接的方式分发连接到不同的 Web 实例上。在 Web 实例新增和删除时,通过 DCOS 平台在实时通知 HAproxy,实现 Web 实例的动态扩展。

在这种结构下会带来 REDIS 缓存单点问题,无法满足高可用要求,为此我们对 REDIS 进行分组配置,每组 REDIS 配置主从模式,通过 keepalived 实现主从切换:

在 Web 层的应用改造过程中也非一帆风顺,中间也遇到到一些问题,这里分享两点:

  1. 一开始项目团队选择的 HAproxy 为 1.5 版本,但是在应用改造完成部署到测试环境的时候,测试的人员在验证时发现,只要用户请求的连接参数中带有中文等宽字符,在 HAproxy 转发时就会报错,导致连接请求会丢失,到不了 Web 服务。经过项目团队几天的努力,找了各种网上的帖子,不断尝试,最终确定是因为 1.5 版本 HAproxy 不认在IE浏览器对中文字符的编码。通过降低 HAproxy 的版本到 1.4 得以解决。

  2. 在改造完成的应用中,通过 REDIS 进行缓存集成存放,但是在我们上了生成以后发现运行一段时间之后,Web 层的服务内存暴长,导致服务会自动重新启动。前端用户感知非常慢。经过对代码进行分析,发现在把会话方式统一到 EDIS 时,并没有把原来进行 JVM 缓存的代码下掉,导致用户在访问时不断增长。删除不需要的逻辑代码得以解决。

APP 层应用改造

APP 层要支持动态的伸缩,除了 APP 层实现无状态化外,取决于 WE B到 APP 的R PC调用方式:

HTTP 协议:同 WEB 层一样使用负载均衡方案 HAProxy+Confd+Etcd;

服务化框架:使用服务化框架服务的发现和注册功能,注意需要将容器外的 IP 和端口上报给配置中心;

未实现服务发现的 RPC 调用:对于没有服务发现和注册功能的传统应用则需进行改造。我们以移动的 CRM 系统为例,CRM 系统使用 EJB 技术实现,APP 层没有服务注册的能力,改造后的架构图如下所示:

Zookeeper 保存 APP 实例的实时分布数据,Marathon 负责监控 APP 实例的运行状态,并在状态发生变化时通知给 Zookeeper 进行修改 APP 实例分布数据,WEB 层根据分组策略获取一组的 APP 实例分布信息,根据该信息轮训调用组内的 APP 实例。

  • 分组

为保证 APP 负载的均衡我们采用分组策略,我们将所有 Zookeeper 内的 APP 实例根据 Hash 算法进行分组,每个组内保持着一定数量的 APP 实例,每个 WEB 请求按照路由策略均衡分发到组内 APP 实例上。

  • 扩缩容调度

垂直调度:因为每次弹性扩缩都会对 WEB 访问 APP 的路由表进行更新,当频繁更新时有可能会造成服务访问的短时异常,为避免该问题我们采用垂直调度机制,每个 APP 组根据弹性调度算法进行垂直扩缩操作,不影响其他组的运行。

水平调度: 对 APP 层整体服务能力进行评估,当能力变化值大于一个组的服务能力时,需要进行水平扩缩操作,以组为单位进行水平扩缩。

DCOS 建设经验总结

技术选型

数据中心操作系统(DCOS)是为整个数据中心提供分布式调度与协调功能,实现数据中心级弹性伸缩能力的软件堆栈,它将所有数据中心的资源当做一台计算机来调度。

大规模应用的数据中心操作系统有:Google Borg/Omega 系统和 Twitter、Apple、Netflix 等公司基于 Mesos 构建的系统。

可以用于数据中心操作系统构建的开源解决方案有:

  • Mesos:Mesos 最早由美国加州大学伯克利分校 AMPLab 实验室开发,后在 Twitter、Apple、Netflix等互联网企业广泛使用,成熟度高。其中,Mesosphere 公司 DCOS产品,就是以 Mesos 为核心,支持多领域的分布式集群调度框架,包括 Docker 容器集群调度框架 Marathon、分布式 Cron(周期性执行任务)集群调度框架 Chronos 和大数据的主流平台 Hadoop 和 Spark 的集群调度框架等,实现系统的资源弹性调度。

  • Apache Hadoop YARN:Apache Hadoop YARN一种新的 Hadoop 资源管理器,它是一个通用资源管理系统,可为上层应用提供统一的资源管理和调度。

  • Kubernetes:Kubernetes 是 Google 多年大规模容器管理技术的开源版本,面世以来就受到各大巨头及初创公司的青睐,社区活跃。

  • Docker Machine + Compose + Swarm:Docker 公司的容器编排管理工具。

  • 此外,CloudFoundry/OpenShift 等PaaS产品也可以作为 DCOS 的解决方案。

相关技术在调度级别、生态活跃、适用场景等方面的比较如下表所示:

(注:按照公开文档和使用经验做简单比较,未做详细验证)

根据对适合构建 DCOS 的各种技术架构的评估,我们选择以 Mesos 为基础的方案。其优点是成熟度高、使用两级调度框架、适合多种应用场景、支持混合部署、应用与平台耦合度低。

DCOS 技术方案

技术架构

中国移动浙江公司 DCOS 方案采用了以容器为基础封装各类应用和运行环境,以 Mesos、Marathon 为核心实现容器资源的分布式调度与协调,以 Haproxy、Confd、Etcd 实现服务注册和业务的引流。架构如下:

功能框架

以开源技术 Mesos 、Marathon 、Docker、HAProxy 为引擎,在其上开发了 DCOS 控制台、资源管理模块、鉴权模块、统一日志中心、弹性扩缩容调度模块、监控管理模块、持续集成平台。DCOS 的功能框架如下:

  1. DCOS Dashboard

  2. 资源管理模块:服务目录管理、规则管理、CMDB 信息;

  3. 监控管理模块:监控数据采集、日志管理、告警管理和事件管理;

  4. 弹性扩缩容调度模块:基于 CPU 使用率、内存使用率、服务并发数、响应时间等容量数据,通过定制的调度算法实现服务的自动弹性扩缩容;

  5. 统一日志中心:采用 Elasticsearch、Logstash、Graylog 构建,实现对容器日志的统一存储及检索;

  6. 鉴权模块:用户管理、用户组管理、权限策略管理和统一认证接口;

  7. 持续集成平台:镜像构建、集成测试、流程管理和上线管理。

平台能力

DCOS 平台采用93个主机节点,其中平台部分由5个节点构成 Mesos Master Cluster,8个节点构成 HAproxy Cluster,计算节点由80个 Mesos Slave 节点组成,平台和计算节点均跨机房部署,该平台可在1分钟内轻松扩展到1000个以上 Docker 容器。

问题和经验总结

经验

  • Marathon 自动弹性扩缩容调度

Marathon 的扩缩容默认只能根据用户需要进行手动调整,我们结合多年的系统运维经验,实现基于并发数、响应时间、CPU 和内存使用率等容量指标进行自动弹性扩缩容调度的算法。

  • Marathon Etcd 联动实现服务注册发现

Etcd 只是个独立的服务注册发现组件,只能通过在宿主机上部署 Etcd 发现组件,通过其发现宿主机的容器变化来发现,属于被动的发现,往往会出现发现延迟时间较长的问题,我们通过修改Etcd组件的发现接口,实现与 Marathon的Event 事件接口进行对接,达到Marathon 的任何变动都会及时同步给Etcd组件,提高了系统的发现速度,并且避免在每个宿主机上部署 Etcd 发现组件。

  • DCOS 平台组件容器化改造

为提高 DCOS 平台的可维护性,我们将 DCOS 平台的相关组件全部进行 Docker 化,相关组件运行环境和配置信息都打包到 Docker 镜像中,实现快速部署、迁移和升级。

问题

  • Marathon Exit 容器清理

弹性扩缩容会导致宿主机上产生大量的 Exit 状态的 Docker 容器,清除时较消耗资源,影响系统稳定性。默认 Mesos 只有基于时长的清除策略,比如几小时,几天后清除,没有基于指定时间的清除策略,比如在系统闲时清除,也无法针对每个服务定制清除策略。

解决方案:修改 Marathon 的源码程序,添加 Docker 容器垃圾清理接口,可以对不同服务按指定策略将Exit状态的Docker容器进行清理。

  • Docker DeviceMapper dm-thin 问题

在 CentOS6.5 上,我们发现 Docker 在使用 DeviceMappe r时会不定时出现 Linux Kernel Crash 的情况。

解决方案:通过修改 dm-thin.c 内核源码修复。

效果总结

提高资源利用率

DCOS 相较于虚拟机有着基于 CPU、内存的更细粒度的资源调度,多个计算框架或应用程序可共享资源和数据,提高了资源利用率。

高效的跨数据中心的资源调度

DCOS 平台展现了其在线性动态扩展、异地资源调度等方面的优异性能,1分钟内快速扩展到 1000+ 的容器(如果应用更轻量启动速度还可以更快),平台和计算节点完全跨机房分布式调度。

自动弹性扩缩容量

彻底解决应用的扩缩容问题,容量管理从“给多少用多少”向“用多少给多少”转变,被动变主动。应用的扩缩容时间从传统集成方式的 2-3 天缩短到秒级分钟级,可以根据业务负载自动弹性扩缩容。

敏捷开发、快速部署

容器和 DCOS 技术的结合通过将应用和它的依赖进行封装,隐藏了数据中心硬件和软件运行环境的复杂性,让开发、测试、生产的运行环境保持一致,降低应用的开发、发布难度。传统的部署模式“安装->配置->运行”转变为“复制->运行”,实现一键部署。

高可用性、容灾

DCOS 平台所有组件采用分布式架构,应用跨机房分布式调度。自动为宕机服务器上运行的节点重新分配资源并调度,保障业务不掉线,做到故障自愈。

后续计划

通过将公司两大核心系统迁移到 DCOS,对于使用 Mesos 和Docker 来构建企业私有云的弹性计算平台得到了充分的验证,后续将继续完善弹性调度功能、复杂应用编排、持续集成等能力。同时对 Kubernetes、Swarm 与 Mesos 的集成方案进行跟踪、测试和比较,构建高效稳定的 DCOS 平台能力。