1. 背景
中国移动一级业务支撑系统做为中国移动的管理中心和全网业务的核心系统，有内容计费，网状网，BBOSS，统一电渠，一级营销，一级客服等系统，业务模式涵盖了交易、计费、服务等各种移动核心业务模式，系统功能各异复杂度高。
这些系统都是做为独立项目单独建设的。然而，近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。
企业在IT平台的建设、开发和维护的过程中，经常会被以下问题所困扰：开发环境管理复杂，开发、测试、生产环境无法进行有效隔离，无法实现自动化的安装部署和应用维护，业务的环境和配置依赖问题常常会给系统迁移带来很大的麻烦；X86化加大了系统的运维压力，日常升级部署工作繁杂巨大，开发/测试/运维人员之间相互抱怨。
特别是随着移动X86化推进，资源数量急速膨胀。怎样实现资源集中有效管理，资源动态灵活调配，提高对资源的可监控可管理能力对现有系统构架提出了挑战。
另一方面，随着移动融合业务发展，尤其是互联网业务的发展，对系统水平弹性动态扩展、业务连续性保障、故障迅速恢复提出高要求。因此，企业迫切需要引入新的技术和管理方式来应对云计算时代所带来的变革，旧有的平台技术架构亟待升级，开发管理流程亟待优化。
做为一级业务支撑中心，怎么实现所有系统的统一资源分配和调度，怎么实现原有烟囱系统的资源共享，怎么实现开发/测试/生产部署的有效分离，怎么实现整个X86集群的统一监控是支撑中心亟待解决的问题。针对以上问题，中国移动业务支撑系统部业务支撑中心（以下简称业务支撑中心）在2015年开始了PAAS平台的摸索，希望通过试点积累PAAS平台的建设和运维经验，为未来建设一级系统PAAS平台打下基础。
2. 试点系统选择
网状网做为整个一级业务支撑系统的核心系统，是中国移动内外部信息传输交换、服务管控、数据处理、业务支撑、运营开放为一体的综合信息交换枢纽，是连接中国移动集团、3 1个省公司、各一级业务平台、服务公司、合作伙伴等内外部各应用系统，并对外提供服务的桥梁，是中国移动的企业数字神经网络。目前承载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 |
|
|
定位 |
|
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%以上的网络性能损耗，在高吞吐量的应用中不可接受。因此对标准方案做了如下的改造提升系统性能：：
- 增加硬负载均衡器，替代service，提升负载均衡能力和稳定性。
- 实现集群节点状态变化实时与负载均衡器同步，保证集群扩张和节点状态变化实时反应到负载均衡器的策略上。
- 采用直接路由降低跨node间的pod访问网络损耗。
- 跳过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平台做好准备。
