中国移动一级业务支撑系统网状网 PaaS 之路

1. 背景

中国移动一级业务支撑系统做为中国移动的管理中心和全网业务的核心系统，有内容计费，网状网，BBOSS，统一电渠，一级营销，一级客服等系统，业务模式涵盖了交易、计费、服务等各种移动核心业务模式，系统功能各异复杂度高。

(点击放大图像)

这些系统都是做为独立项目单独建设的。然而，近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。

企业在IT 平台的建设、开发和维护的过程中，经常会被以下问题所困扰：开发环境管理复杂，开发、测试、生产环境无法进行有效隔离，无法实现自动化的安装部署和应用维护，业务的环境和配置依赖问题常常会给系统迁移带来很大的麻烦；X86 化加大了系统的运维压力，日常升级部署工作繁杂巨大，开发/ 测试/ 运维人员之间相互抱怨。

特别是随着移动X86 化推进，资源数量急速膨胀。怎样实现资源集中有效管理，资源动态灵活调配，提高对资源的可监控可管理能力对现有系统构架提出了挑战。

另一方面，随着移动融合业务发展，尤其是互联网业务的发展，对系统水平弹性动态扩展、业务连续性保障、故障迅速恢复提出高要求。因此，企业迫切需要引入新的技术和管理方式来应对云计算时代所带来的变革，旧有的平台技术架构亟待升级，开发管理流程亟待优化。

做为一级业务支撑中心，怎么实现所有系统的统一资源分配和调度，怎么实现原有烟囱系统的资源共享，怎么实现开发/ 测试/ 生产部署的有效分离，怎么实现整个X86 集群的统一监控是支撑中心亟待解决的问题。针对以上问题，中国移动业务支撑系统部业务支撑中心（以下简称业务支撑中心）在2015 年开始了PAAS 平台的摸索，希望通过试点积累PAAS 平台的建设和运维经验，为未来建设一级系统PAAS 平台打下基础。

2. 试点系统选择

(点击放大图像)

网状网做为整个一级业务支撑系统的核心系统，是中国移动内外部信息传输交换、服务管控、数据处理、业务支撑、运营开放为一体的综合信息交换枢纽，是连接中国移动集团、31 个省公司、各一级业务平台、服务公司、合作伙伴等内外部各应用系统，并对外提供服务的桥梁，是中国移动的企业数字神经网络。目前承载 200 多个平台的接入，支撑业务达到 2000 多个，包含金融，客服，业务订购，互联网等各类的业务。峰值业务量目前达到 10 亿笔 / 每天，每月结算金额在 60 多亿。

系统承载业务具有容量大，实时性强，波动剧烈，增长迅速，重要性强，客户影响大，无状态业务居多等特点。非常适合做 PAAS 平台的试点。

业务支撑中心和网状网项目技术团队经过大量的研讨，创新的提出了 APU（Application Process Unit）的概念，把资源和应用有效的结合在一起，解决未来的系统的发展和管理瓶颈，并申请了专利。而且通过深入的技术研究和实践探索，在 Docker 基础上通过增强接口和管理功能，实现了 APU 概念的落地。结合 Kunbernet 做为集群管理平台，搭建了能够承载网状网系统的 PAAS 平台试点。实现了整个平台的容器化改造和集群的部署，管理和监控。

• 2015 年 3 月，搭建 Kubernetes+Docker 集群，选取部分业务进行 POC。
• 2015 年 5 月，开始逐步大规模进行业务的开发改造。
• 2015 年 7 月，基于 Kubernetes+Docker 的网状网 PAAS 平台上线，第一步迁移了移动商城业务。
• 2015 年 9 月，建立生产 + 容灾两个集群，共 120 个节点，迁移 60% 的业务。
• 2015 年 12 月，开始逐步迁移全部的业务到 PAAS.

3. PAAS 技术选型

目前适用于容器集群管理和大规模部署的，并且得到大规模生产验证的开源产品有：Kubernetes、Apache Mesos。这两个平台各有特点：

3.1. Kubernetes

2015 年，谷歌公布多年以来的容器集群方面的秘密：Google 早些年构建了一个管理系统，它可以用来管理集群、容器、网络以及命名系统。第一个版本被称为 Brog，后续版本称为 Omega。目前每秒会启动大约 7000 个容器，每周可能会超过 20 亿个容器。利用在容器技术上的实践经验和技术积累， Google 构建了 Kubernetes(简写 K8s)。

Kubernetes 是一个全新的基于容器技术的分布式架构的集群管理解决方案，Kubernetes 具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。

有了 Kubernetes，你可以告诉系统，你的应用程序需要一个数据库、三个服务器、X 量的存储等等。Kubernetes 主要关注的是对服务级别的控制而并非仅仅对容器级别的控制，Kubernetes 提供了一种“机智”的管理方式，它将服务看成一个整体。在 Kubernetes 的解决方案中，一个服务甚至可以自我扩展，自我诊断，并且容易升级。在 Kubernetes 的设计理念中，第一次将 Service 的高度提升到超过 Machine，第一次将服务自动化提升到平台高度（监控、部署、扩容）。

目前 Kubernetes 生态环境热度很高，发展很快。

3.2. Mesos

Mesos 最早由美国加州大学伯克利分校 AMPLab 实验室开发，Mesos 是分布式系统内核，它可以将不同的机器整合在一个逻辑计算机上面。当你拥有很多的物理资源并想构建一个巨大的静态的计算集群的时候，Mesos 就派上用场了。有很多的现代化可扩展性的数据处理应用都可以在 Mesos 上运行，包括 Hadoop、Kafka、Spark 等，同时你可以通过容器技术将所有的数据处理应都运行在一个基础的资源池中。

如果你拥有已经存在的多个工作任务（Hadoop、Spark、Kafka 等），那 Mesos 提供了一个将不同工作任务相互交错的框架。

Mesos 目前做为 DCOS（Data Center Operation System）理念的实现者，也得到了很多企业的关注。但是 Mesos 如果做为容器集群的管理者，需要通过 Marathon 框架支撑，另外还需要另外增加很多 Kubernetes 内置的一些功能，如 proxy，service DNS，以及集群的动态伸缩要求的和 proxy 负载策略的数据同步，应用的监控等等。因为，如果企业只是想实现容器集群实现 PAAS 平台搭建的话，Mesos 过于复杂，但是如果企业想实现 DCOS 平台的话，Mesos 是个不错的选择。另外，一个针对 Mesos+kubernetes 的框架正在开发中，来替换 Marathon，提供最理想的方式以构建基于微服务架构的应用程序实现对容器集群的更有效的管理。总的趋势是两者不断的借鉴和融合。

3.3. 产品对比

相关技术在核心特点、量级、复杂性、稳定性、扩展性，二次开发工作量等方面的比较如下表所示：

Kubernetes

Apache Mesos

定位

• 专注于容器 Docker 的集群管理
• 以 service 的角度定义容器的应用，产生微服务
• 整个框架考虑了很多生产中需要的功能，比如 proxy， service DNS， liveness Probe 等，基本不用二次开发就能应用到生产

Mesos 是一个分布式系统内核，编织不同类型的主机放在一起当一台逻辑计算电脑。它专注资源的管理和任务调度，并不是针对容器管理的。Mesos 上所有的应用部署都需要有专门的框架支撑，如支撑 Docker 必须安装 Marathon。安装 spark 和 hadoop 都需要不同的框架。

对容器支撑

天生就是针对的容器，和应用的云化，通过微服务的理念对容器的进行服务化包装

支撑 Docker 必须安装 Marathon 框架。Mesos 只关注应用层资源的管理。其余由框架完成。

对资源的控制

Kubernets 本身具备资源管控能力，可以控制容器对资源的调用

Mesos 对所有的主机虚拟成一个大的 CPU，内存池，可以定义资源分配，也可以动态调配

是否可以分区

Kubernetes 能通过 namespace 和 node 进行集群分区，能控制到主机，CPU 和内存

可以，可以定义到 cpu，内存，磁盘等

开发成本

原生集成了 service proxy，service DNS，集群动态扩展对 proxy 的实时更新。基本没有二次开发成本。而且便于多集群的集成

要实现生产应用需要增加很多功能，如 HA PROXY，SERVICE DNS 等，需要自己实现集群扩展和 proxy 的集成，二次开发成本高。需要专业的实施团队

非 docker 应用的集成

对于不能实现 docker 化的应用，通过外部 service 方式集成进集群

必须自行开发 framework 来集成到 mesos 里面

通过对以上技术体系的研究和评估，我们认为

• 如果企业只是搭建基于容器的 PAAS 平台的话，Kubernetes 是比较好的选择
• 如果是要搭建数据中心 DCOS 的话 Mesos+Kubernetes 是最优的选择。

在技术选型中我们最终选择以 Kubernetes+Docker 为基础的搭建 PAAS 平台方案。其优点是已经过 Google 十多年的生产验证，成熟度高，支持裸机、VM 等混合部署，适合多种应用场景，Kubernetes 可以用最快的、最简单的、最轻量级的方式来解决目前存在的问题，并帮助进行面向集群的开发。而且很多厂商已经开始支持 Kubernetes，例如微软、IBM、Red Hat、CoreOS、MesoSphere、VMWare 等。社区的热度很高，功能也在快速的增强中。

在 PAAS 平台稳定之后，逐步开始考虑一级业务支撑系统的 DCOS 平台的建设，整合 Mesos 和 Kubernetes，构建一个稳定性强，支持复杂业务场景，强大弹性扩展能力的电信行业 DCOS+Paas 平台，为未来的业务快速发展打下坚实的基础。

4. 承载网状网的 PAAS 平台技术方案

4.1. 总体架构规划

本方案规划以网状网为先行实践范例，尽可能考虑其通用性和普适性，根据业务特点，对业务类型和架构模型进行抽象，归类出典型的应用场景和架构模型进行方案设计，为其他系统的快速迁移提供参考和最佳实践。

PAAS 平台建议架构视图如下图所示：

(点击放大图像)

4.2. 技术架构

承载网状网系统的 PAAS 平台总体技术架构如下：

(点击放大图像)

Ku8Manager 可视化管理平台负责安装，部署，监控，运维，分析。

Kubernetes 集群由两类节点组成，Master 和 Node。Master 上运行 etcd、API Server、Controller Manager 和 Scheduler 四个组件，后三个组件构成了 Kubernetes 的总控中心，负责对集群中所有资源进行管控和调度。Node 上运行 Kubelet、Proxy 和 Docker Daemon 三个组件，负责对本节点上的 Pod 的生命周期进行管理。

4.3. 功能框架

以开源技术 Docker、Kubernetes 为核心引擎，在其基础上自主开发了 Ku8 Manager 可视化管理控制台，Ku8 Manager 可视化管理平台提供简便的一键式自动化安装、部署配置、基于容器、应用、服务、资源等不同视角的综合监控、系统管理和安全管理。PAAS 的功能框架如下图所示：

(点击放大图像)

4.4. 技术方案亮点

针对电信行业的特点，我们对 Kubernetes 做了很多的功能改造和增强，以适用于大规模的生产部署和管理。

【1】 高可用多数据中心之间的服务动态扩展

(点击放大图像)

场景一：多集群的统一服务部署：由Kubernetes 管理平台自动化部署模块统一对各数据中心进行服务自动化安装部署。可以定义同一个服务在不同数据中心的Kubernetes 集群统一部署，并且可以定义在每个cluster 部署服务的容器实例的比例。比如按6:4 的比例在cluster A 和Cluster B 上部署服务。

场景二：灰度升级：由Kubernetes 管理平台自动化部署模块统一对各数据中心自动化进行服务升级。可以实现先在一部分集群部署新版本，稳定之后再平滑升级全部的节点。

场景三：动态集群间业务调整：业务高峰期当一个数据中心容量不足时，由Kubernetes 管理平台自动进行服务动态扩展，启动容灾数据中心的部分服务来支撑业务。

场景四：业务高可用：当主数据中心发生故障（如网络故障）时， 由Kubernetes 管理平台自动进行容灾切换，由容灾数据中心自动接管所有业务服务。实现高可用的数据中心。

【2】 集群的Master 节点高可用

缺省的Kubernetes 集群只有一个master 节点，当Master 节点崩溃的时候将会造成整个集群无法管理，因此在生产中我们实现了三节点的高可用master 集群，保证了整个集群的高可用：

(点击放大图像)

【3】 网络方案的改造

标准 Kubernetes + Docker 的组网方案是通过软负载均衡 +flannel。该类型方案会带来 30% 以上的网络性能损耗，在高吞吐量的应用中不可接受。因此对标准方案做了如下的改造提升系统性能：：

1. 增加硬负载均衡器，替代 service，提升负载均衡能力和稳定性。
2. 实现集群节点状态变化实时与负载均衡器同步，保证集群扩张和节点状态变化实时反应到负载均衡器的策略上。
3. 采用直接路由降低跨 node 间的 pod 访问网络损耗。
4. 跳过 Iptables NAT 转发提升网络传输效率。

(点击放大图像)

【4】 先进的Docker IMAGE 全生命周期管理

对Docker IMAGE 进行统一管理，提供Docker IMAGE 的参考模型和流程指导，Docker IMAGE 模板规划、设计、生成及Pod 生成的管理流程如下图所示：

(点击放大图像)

【5】 先进的持续集成和灰度发布全过程管理

持续集成可以让团队在持续集成的基础上收到反馈并加以改进，不必等到开发的后期才寻找和修复缺陷。 通过持续集成工具Jenkins，持续、自动地构建/ 测试软件项目，监控定时执行的任务。实现持续集成和灰度发布的全过程管理，核心工作流程如下：

(点击放大图像)

【6】 Ku8 Manager 可视化管理平台提供一键式自动化安装、部署和配置功能

集群自动化安装主界面如下图所示，可以几分钟完成几十台机器的集群安装：

(点击放大图像)

【7】 应用视角的服务部署发布

在Kubernetes 集群中，以Service、Pod、容器的分级视图进行综合管理。新Node 加入非常简单，通过相应的参数调整，即可在秒级实现容量的动态调整，如下图所示：

(点击放大图像)

【8】 基于基于服务的的立体化综合监控

传统的网管系统，因为一台机器上部署很多应用和实例，所以很难把资源的占用和业务有效匹配起来。但是实现容器化改造之后，每个业务的容器占用的资源能一目了然的看出来，有效的解决了对业务-》资源占用的有效监控。

分两种视图：

1）主机视图：从设备的角度，查看总体上主机 CPU、内存的占用情况，保证每台主机是可用的：

(点击放大图像)

2）服务视图：从业务的角度，查看每个业务的 Docker 容器对 CPU、内存关键性能指标，从而能很轻松的看出每个业务对总体资源的占用情况。监控指标如下图所示：

(点击放大图像)

5. PAAS 应用效果

5.1. 集群规模

中国移动一级业务支撑系统 PAAS 平台所承载的网状网系统 应用集群包括移动总部和 31 省公司，网状网四期之后由 1200 台 X86 服务器组成的多个集群，分布在全国。中国移动网状网应用集群架构如下图所示：

(点击放大图像)

5.2. 应用效果

• 采用 Kubernetes+Docker 承载网状网的 PAAS 平台，在 2015 年底的业务高峰中有力支持中国移动统一认证平台及移动商城等电子渠道业务，同时支撑 1 亿多活跃用户，交易额日均达 10 亿人民币，且系统运行稳定。 (点击放大图像)

  

• 实现业务的灰度发布管理，如：为移动商城平台应用建立两个集群组 ummp1 和 ummp2，两个组的业务中断互不影响，当集群组 ummp1 业务升级时，由 ummp2 支撑业务；Ummp1 完成业务升级后转为生产支撑业务，再对 ummp2 进行业务升级。通过轮换的迭代发布，实现快速的灰度发布和应用上线，实现系统上线业务不中断。

• 通过该 PAAS 平台，极大提高了大规模应用快速部署的灵活性和系统快捷的水平扩展能力。如针对 2015 年 12 月 1 日业务高峰的剧烈波动，实现了对移动商城和统一支付业务节点的动态负载均衡和容器的弹性伸缩，在秒级快速增加了 50 个容器实例支撑峰值业务量，很好地支撑了业务的波动。

• 同时通过 PAAS 平台也可构建高可用多数据中心，并实现服务的动态扩展，业务高峰期当主数据中心容量不足或发生故障时，由 Ku8 Manager 可视化管理平台自动进行服务动态扩展和自动进行容灾切换，实现高可用的数据中心。

• 通过采用 Kubernetes + Docker 的 PAAS 平台，实现了开发、测试、生产环境的有效隔离和应用的一次构建、随处运行，有效提升了开发和运维管理的效率。

• 通过采用相应的持续集成工具，在开发过程中实现持续 / 自动地构建项目，自动化测试软件代码，并监控定时执行的任务，实现了持续集成的全过程管理。

6. 下一步计划

• 继续优化承载网状网系统的 PAAS 平台，扩展规模，满足 2016 年业务 50 亿笔 / 天的需求。
• 摸索构建统一化的服务组件，如数据库即服务、中间件即服务、消息服务、流程服务、搜索引擎服务、移动化服务、安全服务等。逐步实现对中国移动总部一级业务支撑系统的资源和服务进行统一的监控和管理。。
• 形成云平台标准化技术规范，建立一套符合管理思路、适应性强、易于应用、易于推广的云平台标准化框架、模型和规范，为一级业务支撑系统的云化奠定技术基础。
• 推动其他一级业务支撑系统依据上述平台标准进行系统重构，加强应用系统业务无关性及业务能力化改造，加快业务支撑中心系统由烟囱烟囱型向平台型转变。
• 在此基础上探索 Mesos 和 Kubernetes 平台的集成，为下一步建设一级系统 DCOS 平台做好准备。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群（已满），InfoQ 读者交流群（#2））。