云计算之PaaS经典案例30

梅峰谷大数据资料整理小组云计算之PaaS经典案例汇总-中篇版本号V1.0日期2017-10-15来源梅峰谷大数据本文档版权由梅峰谷大数据所有。未经书面许可，任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部，并以任何形式传播。梅峰谷大数据资料整理小组2017年10月目录TOC\o"1-3"\h\u15545梅峰谷大数据资料整理小组 127148目录 23105第一章中国移动网状网PaaS之路 9251911.建设说明 9148431.1建设背景 9133711.2.试点系统选择 11209812.PaaS技术选型 12258692.1.Kubernetes 12291552.2.Mesos 1361982.3.产品对比 1384903.PAAS平台解决方案 15110593.1.技术架构 1552113.2.功能框架 1685243.3技术方案亮点 16180894.PAAS应用效果 22168184.1.集群规模 22246174.2.应用效果 2290235.下一步计划 2322268第二章中国公有云计算产品线 24316101.愿景 24273432.洞察 25293352.1产品竞争 25218462.2运营竞争 2532032.3客户竞争 2681113.云商 26305243.1阿里云 27194113.2腾讯云 28207433.3百度开放云 30149633.4华为云 31197803.5网易云 33145923.6新浪云 3453593.7乐视云 35165563.8360云 36266343.9京东云 37303663.10美团云 39285553.11金山云 4016057第三章中联通CU-DC/OS 41275201.研究背景 41321632.CU-DCOS发展 4219253.CU-DCOS技术创新 43194353.1创新的独立式技术架构 43122303.2资源的统一管理 44111383.3创新的大数据服务 44212723.4持续集成/持续交付能力 4466313.5统一服务网关 4489553.6多实例持久化存储 45278204.落地应用 45103654.1公共创新大数据能力开放平台 4549394.2联通PaaS平台的基础架构 45320834.3联通牛人部落实验室的基础架构 4528759第四章开源PaaS初探 46129661PaaS平台概述 46198602.主流的开源PaaS平台 47315932.1CloudFoundry 47188142.2Cloudify 4877272.3Docker 49210552.4小结 5048233开源PaaS发展趋势 5184893.1轻量化 5147543.2服务外化 518143.3大数据分析 51217654.结束语 5324046第五章传统企业PaaS上云思考（荐） 53193541.背景说明 5377582.传统架构与应用分类 54297582.1经典架构 54257842.2OLAP与OLTP 55263943.云化需求与分析 5693353.1OLTP类应用云化的要求 5679453.2OLAP型应用云化的需求 58222154.基于容器的PaaS平台架构构建 61150705.PaaS平台问题及上云注意点 64101315.1资源调度问题 6496545.2多租户的问题 64289206.问答环节 6818146第六章Pivotal云原生应用和PaaS 69174111.Pivotal的探索 6977351.1pivotal介绍 70287431.2pivotal大牛 7160822.云原生架构与应用 73187502.1云原生架构 73312812.2云原生应用特征 7480823.PaaS的业务驱动力

75116344.PaaS的架构模型与业务价值

76219475.微服务监控链—SpringZipkin 7817235第七章基于k8s的PaaS平台设计和思考 80293441.PaaS平台的意义 80148952.为什么选择Kubernetes 81271542.1主流容器框架 81291592.2容器设计理念 82210893.PaaS平台上的微服务架构应用 82198934.PaaS平台架构设计 83141744.1平台建设原则 8345184.2平台关键能力说明 84323754.3PaaS平台功能组件 8516563第八章容器驱动的PaaS平台实现（荐） 86114931.基于容器的PaaS是趋势 87104492.企业选择PaaS的关注点 88102302.1某世界500强保险集团 89298202.2某全国性股份制商业银行 8922992.3某通讯解决方案提供商 9055012.4某省科技厅医疗大数据项目 90106003.PaaS平台选型要素 91151034.CaaS构建：引擎还是汽车 92289635.容器服务CaaS框架示例 93218076.企业对容器诉求 95216.1对网络诉求 95314816.2对存储诉求 96218807.PaaS应用举例 99273047.1基于Weblogic应用 99272657.2基于Mysql高可用数据服务 101257058.容器的日志和告警 10290359.容器的安全问题 10422018第九章YY互娱私有PaaS平台实践 105205331.运维价值体系 106187572.运维平台化方式 10728302.1面向流程 107212442.2面向服务 108222102.3.拿来主义 109282673.YY互娱PaaS运维平台实践 110239203.1业务场景 110208833.2平台理念 112184363.3实践历程 113268424.YY互娱PaaS运维平台未来规化 13217354第十章PaaS关键技术点和难点 133237621.PaaS建设的意义何在 134116842.PaaS的主要技术有哪些 135233303.容器云的负载均衡如何选择 135224584.PaaS的日志和监控如何进行处理 136255785.PaaS如何更好的实现CI/CD 136178886.PaaS键技术点和难点 13710009第十一章唯品会轻量级PaaS平台 138240771.唯品会现状 13965332.唯品会PaaS构建流程 139137113.唯品会PaaS功能点 143265764.PaaS网络方案和定制 144104675.日志收集和监控 147238966.唯品会PaaS监控 14970077.问题总结 15018373第十二章运营商上PaaS遇到的问题 151255911.运营商IT系统现状 152267222.IT系统集中一体化问题 15218823.硬件资源整合 153222023.1IaaS层面的硬件资源整合 15443343.2PaaS层面的硬件资源整合 15486494.关系型数据库扩展性问题 155183105.构建跨域的PaaS平台 161187716.能力开放 162140937.总结语 16428655第十三章新浪微博基于Docker的混合云架构 164278511.背景，挑战与实现 164139872.混合云架构方案 166130592.112306混合云架构 16678332.2混合云DCP技术架构 167118802.3混合云功能模块 169269393.基础设施 16951674.弹性调度 173293085.编排与实现 17696796.春晚实战&总结 181第一章中国移动网状网PaaS之路1.建设说明中国移动一级业务支撑系统作为中国移动的管理中心和全网业务的核心系统，有内容计费、网状网、BBOSS、统一电渠、一级营销、一级客服等系统，业务模式涵盖了交易、计费、服务等各种移动核心业务模式，系统功能各异复杂度高。1.1建设背景这些系统都是做为独立项目单独建设的。然而，近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。企业在IT平台的建设、开发和维护的过程中，经常会被以下问题所困扰：开发环境管理复杂，开发、测试、生产环境无法进行有效隔离，无法实现自动化的安装部署和应用维护，业务的环境和配置依赖问题常常会给系统迁移带来很大的麻烦；X86化加大了系统的运维压力，日常升级部署工作繁杂巨大，开发/测试/运维人员之间相互抱怨。特别是随着移动X86化推进，资源数量急速膨胀。怎样实现资源集中有效管理，资源动态灵活调配，提高对资源的可监控可管理能力对现有系统构架提出了挑战。另一方面，随着移动融合业务发展，尤其是互联网业务的发展，对系统水平弹性动态扩展、业务连续性保障、故障迅速恢复提出高要求。因此，企业迫切需要引入新的技术和管理方式来应对云计算时代所带来的变革，旧有的平台技术架构亟待升级，开发管理流程亟待优化。做为一级业务支撑中心，怎么实现所有系统的统一资源分配和调度，怎么实现原有烟囱系统的资源共享，怎么实现开发/测试/生产部署的有效分离，怎么实现整个X86集群的统一监控是支撑中心亟待解决的问题。针对以上问题，中国移动业务支撑系统部业务支撑中心（以下简称业务支撑中心）在2015年开始了PAAS平台的摸索，希望通过试点积累PAAS平台的建设和运维经验，为未来建设一级系统PAAS平台打下基础。1.2试点系统选择

中国移动一级业务支撑系统做为中国移动的管理中心和全网业务的核心系统，有内容计费，网状网，BBOSS，统一电渠，一级营销，一级客服等系统，业务模式涵盖了交易、计费、服务等各种移动核心业务模式，系统功能各异复杂度高。这些系统都是做为独立项目单独建设的。然而，近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。企业在IT平台的建设、开发和维护的过程中，经常会被以下问题所困扰：开发环境管理复杂，开发、测试、生产环境无法进行有效隔离，无法实现自动化的安装部署和应用维护，业务的环境和配置依赖问题常常会给系统迁移带来很大的麻烦；X86化加大了系统的运维压力，日常升级部署工作繁杂巨大，开发/测试/运维人员之间相互抱怨。特别是随着移动X86化推进，资源数量急速膨胀。怎样实现资源集中有效管理，资源动态灵活调配，提高对资源的可监控可管理能力对现有系统构架提出了挑战。另一方面，随着移动融合业务发展，尤其是互联网业务的发展，对系统水平弹性动态扩展、业务连续性保障、故障迅速恢复提出高要求。因此，企业迫切需要引入新的技术和管理方式来应对云计算时代所带来的变革，旧有的平台技术架构亟待升级，开发管理流程亟待优化。做为一级业务支撑中心，怎么实现所有系统的统一资源分配和调度，怎么实现原有烟囱系统的资源共享，怎么实现开发/测试/生产部署的有效分离，怎么实现整个X86集群的统一监控是支撑中心亟待解决的问题。针对以上问题，中国移动业务支撑系统部业务支撑中心（以下简称业务支撑中心）在2015年开始了PAAS平台的摸索，希望通过试点积累PAAS平台的建设和运维经验，为未来建设一级系统PAAS平台打下基础。1.2.试点系统选择网状网做为整个一级业务支撑系统的核心系统，是中国移动内外部信息传输交换、服务管控、数据处理、业务支撑、运营开放为一体的综合信息交换枢纽，是连接中国移动集团、31个省公司、各一级业务平台、服务公司、合作伙伴等内外部各应用系统，并对外提供服务的桥梁，是中国移动的企业数字神经网络。目前承载200多个平台的接入，支撑业务达到2000多个，包含金融，客服，业务订购，互联网等各类的业务。峰值业务量目前达到10亿笔/每天，每月结算金额在60多亿。系统承载业务具有容量大，实时性强，波动剧烈，增长迅速，重要性强，客户影响大，无状态业务居多等特点。非常适合做PAAS平台的试点。业务支撑中心和网状网项目技术团队经过大量的研讨，创新的提出了APU（ApplicationProcessUnit）的概念，把资源和应用有效的结合在一起，解决未来的系统的发展和管理瓶颈，并申请了专利。而且通过深入的技术研究和实践探索，在Docker基础上通过增强接口和管理功能，实现了APU概念的落地。结合Kunbernet做为集群管理平台，搭建了能够承载网状网系统的PAAS平台试点。实现了整个平台的容器化改造和集群的部署，管理和监控。2015年3月，搭建群，选Kubernetes+Docker集取部分业务进行POC。2015年5月，开始逐步大规模进行业务的开发改造。2015年7月，基于Kubernetes+Docker的网状网PAAS平台上线，第一步迁移了移动商城业务。2015年9月，建立生产+容灾两个集群，共120个节点，迁移60%的业务。2015年12月，开始逐步迁移全部的业务到PAAS.PaaS技术选型目前适用于容器集群管理和大规模部署的，并且得到大规模生产验证的开源产品有：Kubernetes、ApacheMesos。这两个平台各有特点：2.1.Kubernetes2015年，谷歌公布多年以来的容器集群方面的秘密：Google早些年构建了一个管理系统，它可以用来管理集群、容器、网络以及命名系统。第一个版本被称为Brog，后续版本称为Omega。目前每秒会启动大约7000个容器，每周可能会超过20亿个容器。利用在容器技术上的实践经验和技术积累，Google构建了Kubernetes(简写K8s)。Kubernetes是一个全新的基于容器技术的分布式架构的集群管理解决方案，Kubernetes具有完备的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制，以及多粒度的资源配额管理能力。有了Kubernetes，你可以告诉系统，你的应用程序需要一个数据库、三个服务器、X量的存储等等。Kubernetes主要关注的是对服务级别的控制而并非仅仅对容器级别的控制，Kubernetes提供了一种“机智”的管理方式，它将服务看成一个整体。在Kubernetes的解决方案中，一个服务甚至可以自我扩展，自我诊断，并且容易升级。在Kubernetes的设计理念中，第一次将Service的高度提升到超过Machine，第一次将服务自动化提升到平台高度（监控、部署、扩容）。目前Kubernetes生态环境热度很高，发展很快。2.2.MesosMesos最早由美国加州大学伯克利分校AMPLab实验室开发，Mesos是分布式系统内核，它可以将不同的机器整合在一个逻辑计算机上面。当你拥有很多的物理资源并想构建一个巨大的静态的计算集群的时候，Mesos就派上用场了。有很多的现代化可扩展性的数据处理应用都可以在Mesos上运行，包括Hadoop、Kafka、Spark等，同时你可以通过容器技术将所有的数据处理应都运行在一个基础的资源池中。如果你拥有已经存在的多个工作任务（Hadoop、Spark、Kafka等），那Mesos提供了一个将不同工作任务相互交错的框架。Mesos目前做为DCOS（DataCenterOperationSystem）理念的实现者，也得到了很多企业的关注。但是Mesos如果做为容器集群的管理者，需要通过Marathon框架支撑，另外还需要另外增加很多Kubernetes内置的一些功能，如proxy，serviceDNS，以及集群的动态伸缩要求的和proxy负载策略的数据同步，应用的监控等等。因为，如果企业只是想实现容器集群实现PAAS平台搭建的话，Mesos过于复杂，但是如果企业想实现DCOS平台的话，Mesos是个不错的选择。另外，一个针对Mesos+kubernetes的框架正在开发中，来替换Marathon，提供最理想的方式以构建基于微服务架构的应用程序实现对容器集群的更有效的管理。总的趋势是两者不断的借鉴和融合。2.3.产品对比相关技术在核心特点、量级、复杂性、稳定性、扩展性，二次开发工作量等方面的比较如下表所示：

KubernetesApacheMesos定位专注于容器Docker的集群管理以service的角度定义容器的应用，产生微服务整个框架考虑了很多生产中需要的功能，比如proxy，serviceDNS，livenessProbe等，基本不用二次开发就能应用到生产Mesos是一个分布式系统内核，编织不同类型的主机放在一起当一台逻辑计算电脑。它专注资源的管理和任务调度，并不是针对容器管理的。Mesos上所有的应用部署都需要有专门的框架支撑，如支撑Docker必须安装Marathon。安装spark和hadoop都需要不同的框架。对容器支撑天生就是针对的容器，和应用的云化，通过微服务的理念对容器的进行服务化包装支撑Docker必须安装Marathon框架。Mesos只关注应用层资源的管理。其余由框架完成。对资源的控制Kubernets本身具备资源管控能力，可以控制容器对资源的调用Mesos对所有的主机虚拟成一个大的CPU，内存池，可以定义资源分配，也可以动态调配是否可以分区Kubernetes能通过namespace和node进行集群分区，能控制到主机，CPU和内存可以，可以定义到cpu，内存，磁盘等开发成本原生集成了serviceproxy，serviceDNS，集群动态扩展对proxy的实时更新。基本没有二次开发成本。而且便于多集群的集成要实现生产应用需要增加很多功能，如HAPROXY，SERVICEDNS等，需要自己实现集群扩展和proxy的集成，二次开发成本高。需要专业的实施团队非docker应用的集成对于不能实现docker化的应用，通过外部service方式集成进集群必须自行开发framework来集成到mesos里面通过对以上技术体系的研究和评估，我们认为如果企业只是搭建基于容器的PAAS平台的话，Kubernetes是比较好的选择,如果是要搭建数据中心DCOS的话Mesos+Kubernetes是最优的选择。在技术选型中我们最终选择以Kubernetes+Docker为基础的搭建PAAS平台方案。其优点是已经过Google十多年的生产验证，成熟度高，支持裸机、VM等混合部署，适合多种应用场景，Kubernetes可以用最快的、最简单的、最轻量级的方式来解决目前存在的问题，并帮助进行面向集群的开发。而且很多厂商已经开始支持Kubernetes，例如微软、IBM、RedHat、CoreOS、MesoSphere、VMWare等。社区的热度很高，功能也在快速的增强中。在PAAS平台稳定之后，逐步开始考虑一级业务支撑系统的DCOS平台的建设，整合Mesos和Kubernetes，构建一个稳定性强，支持复杂业务场景，强大弹性扩展能力的电信行业DCOS+Paas平台，为未来的业务快速发展打下坚实的基础。PAAS平台解决方案本方案规划以网状网为先行实践范例，尽可能考虑其通用性和普适性，根据业务特点，对业务类型和架构模型进行抽象，归类出典型的应用场景和架构模型进行方案设计，为其他系统的快速迁移提供参考和最佳实践。PAAS平台建议架构视图如下图所示：3.1.技术架构承载网状网系统的PAAS平台总体技术架构如下：Ku8Manager可视化管理平台负责安装，部署，监控，运维，分析。Kubernetes集群由两类节点组成，Master和Node。Master上运行etcd、APIServer、ControllerManager和Scheduler四个组件，后三个组件构成了Kubernetes的总控中心，负责对集群中所有资源进行管控和调度。Node上运行Kubelet、Proxy和DockerDaemon三个组件，负责对本节点上的Pod的生命周期进行管理。3.2.功能框架以开源技术Docker、Kubernetes为核心引擎，在其基础上自主开发了Ku8Manager可视化管理控制台，Ku8Manager可视化管理平台提供简便的一键式自动化安装、部署配置、基于容器、应用、服务、资源等不同视角的综合监控、系统管理和安全管理。PAAS的功能框架如下图所示：3.3技术方案亮点针对电信行业的特点，我们对Kubernetes做了很多的功能改造和增强，以适用于大规模的生产部署和管理。1）高可用多数据中心之间的服务动态扩展场景一：多集群的统一服务部署：由Kubernetes管理平台自动化部署模块统一对各数据中心进行服务自动化安装部署。可以定义同一个服务在不同数据中心的Kubernetes集群统一部署，并且可以定义在每个cluster部署服务的容器实例的比例。比如按6:4的比例在clusterA和ClusterB上部署服务。场景二：灰度升级：由Kubernetes管理平台自动化部署模块统一对各数据中心自动化进行服务升级。可以实现先在一部分集群部署新版本，稳定之后再平滑升级全部的节点。场景三：动态集群间业务调整：业务高峰期当一个数据中心容量不足时，由Kubernetes管理平台自动进行服务动态扩展，启动容灾数据中心的部分服务来支撑业务。场景四：业务高可用：当主数据中心发生故障（如网络故障）时，由Kubernetes管理平台自动进行容灾切换，由容灾数据中心自动接管所有业务服务。实现高可用的数据中心。2）集群的Master节点高可用缺省的Kubernetes集群只有一个master节点，当Master节点崩溃的时候将会造成整个集群无法管理，因此在生产中我们实现了三节点的高可用master集群，保证了整个集群的高可用：3）网络方案的改造标准Kubernetes+Docker的组网方案是通过软负载均衡+flannel。该类型方案会带来30%以上的网络性能损耗，在高吞吐量的应用中不可接受。因此对标准方案做了如下的改造提升系统性能：增加硬负载均衡器，替代service，提升负载均衡能力和稳定性。实现集群节点状态变化实时与负载均衡器同步，保证集群扩张和节点状态变化实时反应到负载均衡器的策略上。采用直接路由降低跨node间的pod访问网络损耗。跳过IptablesNAT转发提升网络传输效率。4）先进的DockerIMAGE全生命周期管理对DockerIMAGE进行统一管理，提供DockerIMAGE的参考模型和流程指导，DockerIMAGE模板规划、设计、生成及Pod生成的管理流程如下图所示：5）先进的持续集成和灰度发布全过程管理持续集成可以让团队在持续集成的基础上收到反馈并加以改进，不必等到开发的后期才寻找和修复缺陷。通过持续集成工具Jenkins，持续、自动地构建/测试软件项目，监控定时执行的任务。实现持续集成和灰度发布的全过程管理，核心工作流程如下：6）Ku8Manager可视化管理平台提供一键式自动化安装、部署和配置功能集群自动化安装主界面如下图所示，可以几分钟完成几十台机器的集群安装：7）应用视角的服务部署发布在Kubernetes集群中，以Service、Pod、容器的分级视图进行综合管理。新Node加入非常简单，通过相应的参数调整，即可在秒级实现容量的动态调整，如下图所示：8）基于基于服务的的立体化综合监控传统的网管系统，因为一台机器上部署很多应用和实例，所以很难把资源的占用和业务有效匹配起来。但是实现容器化改造之后，每个业务的容器占用的资源能一目了然的看出来，有效的解决了对业务-》资源占用的有效监控。分两种视图：1）主机视图：从设备的角度，查看总体上主机CPU、内存的占用情况，保证每台主机是可用的：2）服务视图：从业务的角度，查看每个业务的Docker容器对CPU、内存关键性能指标，从而能很轻松的看出每个业务对总体资源的占用情况。监控指标如下图所示：(点击放大图像)4.PAAS应用效果4.1.集群规模中国移动一级业务支撑系统PAAS平台所承载的网状网系统应用集群包括移动总部和31省公司，网状网四期之后由1200台X86服务器组成的多个集群，分布在全国。中国移动网状网应用集群架构如下图所示：4.2.应用效果采用Kubernetes+Docker承载网状网的PAAS平台，在2015年底的业务高峰中有力支持中国移动统一认证平台及移动商城等电子渠道业务，同时支撑1亿多活跃用户，交易额日均达10亿人民币，且系统运行稳定。实现业务的灰度发布管理，如：为移动商城平台应用建立两个集群组ummp1和ummp2，两个组的业务中断互不影响，当集群组ummp1业务升级时，由ummp2支撑业务；Ummp1完成业务升级后转为生产支撑业务，再对ummp2进行业务升级。通过轮换的迭代发布，实现快速的灰度发布和应用上线，实现系统上线业务不中断。通过该PAAS平台，极大提高了大规模应用快速部署的灵活性和系统快捷的水平扩展能力。如针对2015年12月1日业务高峰的剧烈波动，实现了对移动商城和统一支付业务节点的动态负载均衡和容器的弹性伸缩，在秒级快速增加了50个容器实例支撑峰值业务量，很好地支撑了业务的波动。同时通过PAAS平台也可构建高可用多数据中心，并实现服务的动态扩展，业务高峰期当主数据中心容量不足或发生故障时，由Ku8Manager可视化管理平台自动进行服务动态扩展和自动进行容灾切换，实现高可用的数据中心。通过采用Kubernetes+Docker的PAAS平台，实现了开发、测试、生产环境的有效隔离和应用的一次构建、随处运行，有效提升了开发和运维管理的效率。通过采用相应的持续集成工具，在开发过程中实现持续/自动地构建项目，自动化测试软件代码，并监控定时执行的任务，实现了持续集成的全过程管理。5.下一步计划继续优化承载网状网系统的PAAS平台，扩展规模，满足2016年业务50亿笔/天的需求。摸索构建统一化的服务组件，如数据库即服务、中间件即服务、消息服务、流程服务、搜索引擎服务、移动化服务、安全服务等。逐步实现对中国移动总部一级业务支撑系统的资源和服务进行统一的监控和管理。。形成云平台标准化技术规范，建立一套符合管理思路、适应性强、易于应用、易于推广的云平台标准化框架、模型和规范，为一级业务支撑系统的云化奠定技术基础。推动其他一级业务支撑系统依据上述平台标准进行系统重构，加强应用系统业务无关性及业务能力化改造，加快业务支撑中心系统由烟囱烟囱型向平台型转变。在此基础上探索Mesos和Kubernetes平台的集成，为下一步建设一级系统DCOS平台做好准备。第二章中国公有云计算产品线1.愿景为啥要谈愿景？就是要大家放开了想：云计算到底能干嘛。我希望未来的应用是：1、开发基础在微信上，可以利用微信的ID登录、通讯录、群组、扫码识别、消息推送、社交分享、支付等功能2、原型设计在云上、代码托管在云上、测试环境在云上3、各种互联网应用、社交应用、电商应用、物联设备应用、SaaS应用，全都开放OpenAPI，开发是基于OpenAPI的组合而成4、云计算服务商提供：AB测试、灰度发布、大流量分流5、云计算服务商提供：虚拟主机和应用容器、分布式存储、分布式数据库、开源中间件，让我不用部署、不用担心版本、不用担心组件依赖6、云计算服务商提供：安全防护、自动备份/转移/恢复、监控预警、在线图形化操作扩容管理、中间件自动补丁升级那我们看看中国的云计算服务商谁更接近这个愿景，谁能把应用开发与测试、应用部署、运维管理与安全防护、大数据分析都一站搞定。这是我今天这篇文章的写作出发点。我们选择了中国一线互联网公司：阿里、腾讯、百度；华为、360；小米、金山、乐视；京东、美团、滴滴；新浪、网易。看看这些排头兵正在做什么、成熟度进展如何。我们看到：小米、滴滴还没有开展公有开放云服务。注意：1、我并没有把外国云含入：amazon、google、微软、IBM、VMWare、Oracle2、我并没有把老牌中国IT商含入：中国电信、世纪互联、浪潮、太极...3、我并没有把新贵含入：如七牛、UCloud、青云...4、我更没有把创业含入：类OpenStack公司、类Docker公司、类DevOps公司2.洞察2.1产品竞争1、产品线竞争发现阿里云在产品线方面确实处于领头位置，其他的云都尚有一段差距。不过腾讯云从产品线研发来看追的非常快。百度云和百度大脑在产品结果层面呈现的不多。2、特色竞争按说：华为偏通信、360偏安全、乐视偏视频、京东偏零售电商、美团偏服务电商，那我们看看是不是这样。但发现，他们的云，和他们的主业关系并不密切，算单独发展。这也意味着，大家是在同一条起跑线，只不过有人跑的比较早而已。华为云在DaaS层面提供了唯一的研发管理云，这个有点特殊，不知道华为是有布局还是能整合什么就整合什么。另外，记得百度也发布了自己的研发管理云，但不是百度开放云事业部搞的。整合自己的原有主干技术优势，看来每家都是一个壁垒啊。事业部制之间老死不相往来。倒是网易云、乐视云做的比较有调调。网易云发挥自己一贯的小精品优势，做的克制，但做一个亮眼一个。乐视云是完全从自己长处出发，围绕视频这个领域猛打，也算一批黑马。去年呢，大家一窝蜂扎到大数据产品商。大家今年都扎堆到视频云产品上了，这就不算特色了。估计下一步，大家都要扎到区块链、人工智能产品。2.2运营竞争1、运维产品线都差不多利用开源软件搭起来了。下一步就是运维的竞争。我看云厂商普遍在：DevOps、运维监控与管理、安全防护方面还需要比较大的进展。这也是下一步产品夯实的重点。2、运营呼叫中心服务、技术论坛/知识库、技术支持工程师的建设，发现各家建设也都比较欠缺。中国的云看似已经进展了5年，但其实连运维层战争都还没有打。今年腾讯、百度、网易、华为高调发布会，表明大佬们都才正式进场了。中国云战争，其实才刚刚开始。2.3客户竞争1、市场格局现在云市场天下三分：创业公司长尾、高速成长的互联网公司/电商公司、传统大型企业大量O2O公司死亡、SaaS公司回归私有部署是个暗点。但今年新成立许多视频公司是热点，让大家纷纷开展云视频产品业务。不少巨头云厂商扎入大客户模式：金融、电信、央企、政府。看似单子很大，但又被深深缠绕在业务需求解决方案、多厂商协同配合打单、长周期招标投标讲标的泥潭中。2、解决方案意外居然发生在大数据领域。上半年，做通用大数据技术平台的纷纷再下一层，开始做分析应用，否则客户买了一套大数据技术平台也不知道干什么用，这就阻碍了大数据厂商的销售。但是大家又对行业业务不熟悉，所以大家又都一窝蜂扎到移动App流量行为分析这个领域。虽然巨头云厂商甚至创业云厂商都在尝试扎大客户，但目前仍然没有一家提供有行业特点的领域解决方案。单独买云来干什么，这个问题仍然深深困扰着云厂商。就如同买大数据技术平台干什么，这个问题也同样深深困然着大数据厂商。而现在的SaaS呢，也在探索着：公有租用（中小/小/小微/创业企业）、专有公有部署（中型及中大企业）、私有部署（大型企业）。这和咱们现在的公有云面临的策略一样。需要行业业务专家、SaaS厂商、大数据技术平台厂商、云厂商、云迁移和云运维服务厂商共同努力才能推开这种三模式。而行业业务专家和行业IT专家，成为推进的关键资源要素。3.云商3.1阿里云一、云计算1、基础云：移动解析HttpDNS、域名服务（域名注册与备案、云解析、SSL证书管理）2、云服务器：云服务器ECS、容器服务、高性能计算服务器HPC、计算资源弹性伸缩管理3、云存储：对象存储OSS、块存储、文件存储、表格存储、归档存储4、云网络：内容分发网络CDN、负载均衡CLB、私有网络VPC、专线接入高速通道、NAT网关5、视频云：媒体转码、视频直播、视频点播二、云运维1、监控：云监控、业务实时监控服务ARMS（RPC调用、数据库binlog、消息、终端日志、业务定制日志）2、管理：资源编排、访问控制、操作审计、密钥管理服务三、安全1、服务器安全：安骑士、安全管家2、应用安全：Web应用防火墙3、APP加固：无4、防DDos攻击（DDos高防IP）、防刷（无）5、内容安全：绿网6、数据安全：数据加密服务、CA证书服务、数据风控、数据安全险四、DaaS1、开发：移动开发框架Weex、IM框架（悟空）、日志服务、API网关2、中间件服务：企业级分布式应用服务PaaS、消息队列、云服务总线CSB3、测试：性能测试4、消息推送：邮件推送/短信推送五、大数据1、云数据库：云数据库、云数据Redis、云数据库OceanBase、云数据库MongoDB、云数据库Memcache、云数据库GreenPlum、云数据库PetaData2、大数据处理套件：E-MapReduce、大数据开发套件、大数据计算服务、分析型数据库3、大数据应用引擎：开放搜索、推荐引擎4、可视化工具：QuickBI、DataV数据可视化5、分析应用：公众趋势分析、郡县图治、画像分析六、人工智能1、自然语言处理：印刷文字识别2、机器学习：机器学习3、图片识别：无4、人脸识别：人脸识别5、语音识别：智能语音交互6、图像分析：电商图像分析、通用图像分析7、机器翻译：机器翻译七、物联网八、通用企业软件1、网站建设：官网、商城2、通信：企业邮箱3.2腾讯云一、云计算1、基础云：移动解析HttpDNS、无线网络接入（维纳斯WNS）、域名服务（域名注册与备案、云解析、SSL证书管理）2、云服务器：云服务器CVM、黑市物理服务器CPM、计算资源弹性伸缩管理AS3、云存储：云硬盘CBS、对象存储服务COS4、云网络：内容分发网络CDN、负载均衡CLB、私有网络VPC、专线接入DC5、视频云：点播VOD、直播LVB、互动直播ILVB、微视频MVS二、云运维1、监控：云监控CM、云拨测CAT2、管理：蓝鲸平台BLUEKING三、安全1、主机与网站安全：HS2、应用安全：无3、APP加固：（乐固CR）4、防DDos攻击（DAYU）、防刷（天御BSP）5、内容安全：无6、数据安全：无四、DaaS1、开发：移动开发工具（TAB）2、中间件服务：消息服务CMQ3、测试：手游兼容性测试MGCT4、消息推送：信鸽XGPush五、大数据1、数据库：云数据库CDB、云存储redis、云数据库MongoDB、云数据库Hbase、云缓存Memcached、分布式云数据库DCDB2、大数据处理套件：TBDS3、大数据应用引擎：结构化数据搜索托管（云搜）4、可视化工具：无5、分析应用：用户洞察分析、区域人流分析六、人工智能1、自然语言处理：OpenAPI开放语义分析平台2、机器学习：机智TML3、图片识别：万象优图CI4、人脸识别：优图FR5、语音识别：无6、图像分析：无7、机器翻译：无七、物联网八、通用企业软件1、智能机器人客服：微金小云客服ICS2、通信：云通信IM、PSTN多方通话PMC、短信SMS3.3百度开放云一、云计算1、基础云：移动解析HttpDNS、域名服务（云解析、SSL证书管理）2、云服务器：云服务器BCC、专属服务器DCC、物理服务器BBC、应用引擎BAE3、云存储：云硬盘CDS、对象存储服务BOS4、云网络：内容分发网络CDN、负载均衡BLB、私有网络VPC、专线接入ET5、视频云：音视频直播LSS、音视频点播VOD、音视频转码MCT二、云运维1、监控：云监控BCM2、管理：无三、安全1、主机安全：云安全BSS2、网站安全：无3、App加固：无4、防刷、防DDos：无5、内容安全：无6、数据安全：无四、DaaS1、开发：百度云API市场2、中间件服务：消息服务Kafka、规则引擎RuleEngine3、测试：应用性能管理服务APM、移动App测试服务4、消息推送：简单消息服务SMS、简单邮件服务SES五、大数据1、云数据库：时序数据库TSDB2、大数据处理套件：百度MapReduce、百度OLAP引擎Palo、百度批量计算3、大数据应用引擎：百度ElasticSearch、百度日志服务BLS、百度结构化数据即席查询BigSQL4、可视化工具：无5、分析应用：六、人工智能1、自然语言处理：文字识别OCR2、机器学习：百度机器学习BML、百度深度学习Paddle3、图片识别：无4、人脸识别：人脸识别BFR5、语音识别：无6、图像分析：无7、机器翻译：无七、物联网1、物联管理：物联接入IoTHub、解析（IoTParser）、管理（IoTDevice）八、通用企业软件1、文档浏览展示服务2、问卷调研服务3.4华为云一、云计算1、基础云：无2、云主机：弹性云服务器、云容器引擎、裸金属服务器、弹性伸缩服务、镜像服务、专属云3、云存储：云硬盘、云硬盘备份、对象存储服务、数据快递服务、数据传输加速、弹性文件服务4、云网络：弹性负载均衡、云专线、VPN5、视频云：无二、云运维1、云监控：云监控服务2、云管理：统一身份认证服务、云审计服务、密钥管理服务、安全指数服务三、安全1、主机安全：主机入侵检测2、网站安全：Web应用防火墙、Web漏洞扫描3、App加固：无4、反DDos、反刷：Anti-DDoS流量清洗5、内容安全：无6、数据安全：无四、DaaS1、开发：无2、中间件服务：云应用引擎、分布式消息服务3、测试：无4、消息推送：消息通知服务5、研发管理：项目管理、配置管理、代码检查、编译构建、测试管理、发布管理五、大数据1、云数据库：关系型数据库、分布式缓存服务2、大数据处理套件：数据接入服务、MapReduce服务、数据调度服务3、大数据应用引擎：无4、可视化工具：多维交互分析服务5、分析应用：无六、人工智能1、自然语言处理：无2、机器学习：机器学习服务3、图片识别：无4、人脸识别：无5、语音识别：无6、图像分析：无7、机器翻译：无七、物联网八、通用企业软件1、云桌面2、通信平台云3.5网易云一、云计算1、基础云：无2、云主机：容器云（网易蜂巢）3、云存储：无4、云网络：无5、视频云：网易视频云二、云运维1、云监控：无2、云资源管理：无三、安全1、主机安全：无2、网站安全：无3、App加固：无4、防DDos、防刷：无5、内容安全：网易易盾6、数据安全：无四、DaaS1、开发：无2、中间件服务：无3、测试：网易易测、App性能监测：网易云捕4、消息服务：无五、大数据六、人工智能七、物联网八、通用企业软件1、通信：网易云信2、客服：网易七鱼3.6新浪云一、云计算1、基础云：无2、云主机：云应用引擎SAE3、云存储：对象存储4、云网络：无5、视频云：云直播二、云运维无三、安全无五、大数据无六、人工智能无七、物联网八、通用企业软件1、云邮箱2、云应用商店3.7乐视云一、云计算1、基础云：无2、云主机：无3、云存储：对象存储4、云网络：直播加速、点播加速、下载加速5、视频云：标准点播、标准直播、移动直播、VR直播二、云运维无三、安全1、主机安全：无2、网站安全：无3、App加固：无4、防DDos、防刷：无5、内容安全：云版权6、数据安全：无四、DaaS无五、大数据1、云数据库：无2、大数据处理套件：无3、大数据应用引擎：无4、可视化工具：无5、分析应用：Data+视频分析、Data+人群洞察六、人工智能1、自然语言处理：无2、机器学习：无3、图片识别：无4、人脸识别：无5、语音识别：无6、图像分析：视频鉴黄7、机器翻译：无七、物联网八、通用企业软件1、云媒体、云新闻2、视频发行平台、互动直播运营平台3、商业化直播服务、一站式视频营销服务、场馆大屏营销服务3.8360云一、云计算1、基础云：高防DNS2、云主机：云主机3、云存储：对象存储4、云网络：云加速、负载均衡5、视频云：无二、云运维1、云监控：无2、云资源管理：无三、安全1、主机安全：云安全2、网站安全：网站卫士3、App加固：无4、防DDos：DDos基础防护5、内容安全：无6、数据安全：无四、DaaS无五、大数据1、云数据库：关系型数据库MySQL、高速缓存服务memcached2、大数据处理套件：无3、大数据应用引擎：无4、可视化工具：无5、分析应用：无六、人工智能无七、物联网无八、通用企业软件无3.9京东云一、云计算1、基础云：无2、云主机：云主机、云镜像3、云存储：云硬盘、对象存储4、云网络：子网、路由器、公网IP、负载均衡、CDN5、视频云：无二、云运维1、云监控2、云管理：子账号管理三、安全1、主机安全：监控报警2、网站安全：防火墙3、App加固：无4、防DDos：DDos基础防护5、内容安全：无6、数据安全：无四、DaaS无五、大数据1、云数据库：关系型数据库、KV存储2、大数据处理套件：数据地图、数据探索、作业调度3、大数据应用引擎：无4、数据可视化工具：无5、分析应用：无六、人工智能1、自然语言处理：自然语言处理2、机器学习：机器学习、深度学习3、图片识别：无4、人脸识别：无5、语音识别：无6、图像分析：无7、机器翻译：无七、物联网无八、通用企业软件无3.10美团云一、云计算1、基础云：SSHKey管理2、云主机：虚拟主机、机械硬盘主机、SSD主机、物理主机3、云存储：对象存储4、云网络：负载均衡5、视频云：无二、云运维无三、安全无四、DaaS无五、大数据1、云数据库：关系型数据库MySQL、MongoDB、Redis、Memcached2、大数据处理套件：大数据计算（Hadoop、Hive、Spark、HBase）、流计算（Storm,Kafka,Flume）3、大数据应用引擎：无4、可视化工具：无5、分析应用：无六、人工智能无七、物联网无八、通用企业软件无3.11金山云一、云计算1、基础云：云解析2、云主机：云服务器、云物理主机3、云存储：对象存储、云硬盘4、云网络：负载均衡、虚拟专有网络、弹性IP、内容分发网络5、视频云：云直播、云点播、云转码二、云运维无三、安全1、主机安全：服务器安全2、应用安全：漏洞扫描3、App加固：4、防DDos：防攻击中心5、内容安全：无6、数据安全：无四、DaaS无五、大数据1、云数据库：关系型数据库MySQL、MongoDB、Redis、Memcached2、大数据处理套件：托管Hadoop3、大数据应用引擎：无4、可视化工具：无5、分析应用：无六、人工智能无七、物联网无八、通用企业软件1、企业云盘第三章中联通CU-DC/OS1.研究背景中国联通作为一个有IT历史背景的公司，和现今其他靠IT驱动的服务业公司一样有一定的历史包袱。由于整个IT系统渐进发展，产生了新老系统并存、资源分散、设备异构、软件环境异构等诸多问题。孤岛式的IT资源和IT能力服务制约了企业转型现代化服务业发展之路。随着云计算出现，一定程度上解决了资源孤岛、共享的问题，但是依然存在物理机资源调度的缺位，且现今虚拟机颗粒度的资源也收到了一定程度的挑战，从业务发展上来说今后的IT资源一定是物理、虚拟、容器（进程级）资源相互并存的。IT业务驱动的企业需要寻找一条IT向I3能力，即创新性、信息化、集成化的IT能力的IT综合治理转型之路。近年来随着中国联通IT系统的大数据应用的不断上升，联通自身的IT资源在现在大数据应用发展的强大需求下面临极大压力。大数据中心3000余台服务器设备中有77%是纯物理机使用，传统的IT资源管理方式造成了物理集群之间无法共享资源，从而造成有限资源的浪费。联通IT系统集中化进程中，能力开放、服务能力供给侧不足也成为了随之而来的问题。所以，在联通资源共享、服务化、开放化层面，需要一个统一的解决方案。2.CU-DCOS发展因此在2016年4月启动了CU-DCOS项目，旨在解决联通IT治理和能力开放等问题。经过初期的技术方案设计，在验证了多种开源技术和商业化产品后，完成了技术路线的选择，确定了CU-DCOS的基础架构。2016年8月份启动了CU-DCOS平台开发，经过近6个月的研发和测试，突破了关键技术43项，完成了9大功能、56小功能的门户开发，通过了技术测试和业务测试共59项。在2017年1月推出了CU-DCOS1.0平台。之后在多个业务系统尝试落地使用，并仍在持续进行产品化迭代研发。现今，CU-DCOS平台已能够面向企业用户提供40余种服务能力，其中包括大数据、数据库、中间件以及技术、应用等服务，已能够面向开发运维流程提供DevOps服务。为中国联通公共创新大数据能力开放平台、中国联通PaaS平台以及中国联通牛人部落实验室提供架构支撑和资源优化，大幅提升IT资源应用效率。CU-DCOS能力平台利用其架构特质，对以下IT环节进行了优化：低运营成本：用户能够通过共享网络、存储、CPU内存等计算资源，在业务高峰期通过弹性扩容方式有效的应对业务峰值，在业务波谷期将资源分享给其他用户，有效的节约了成本。简化设备运维：在原有的IT体系中，研发团队既需要维护应用程序，同时还要维护基础设施。在CU-DCOS平台架构中，开发人员面对的将是第三方开发或自定义的API和URL，底层硬件对于开发人员透明化了，技术团队无需再关注运维工作，能够更加专注于应用系统开发。提升可维护性：微服务应用将调用多种平台的能力服务，组成最终的应用逻辑。目前，例如登陆鉴权服务，云数据库服务等，在安全性、可用性、性能方面都进行了大量优化，通过直接集成平台提供的服务，能够有效的降低开发成本，同时使得应用的运维过程变得更加清晰，有效的提升了应用的可维护性。更快的开发速度：创新项目由于人员与资金等问题，不可能每个产品线都同时进行，通过CU-DCOS平台，能够很快进行产品开发的速度，把工作重点放在业务实现上，把产品更快的推向市场。3.CU-DCOS技术创新CU-DCOS平台旨在通过新一代的云计算架构——容器技术，解决IT面临的实际问题，完成IT资源的集中管理的新一代平台系统。该平台不仅验证了以容器为基础的PaaS平台从模式、到技术的可行性，同时在行业内首次实现了面向大数据、物理资源弹性调度、多租户管理的“资源+数据+能力“的平台架构，在满足公司数据管控要求前提下，实现了大数据能力的开放。3.1创新的独立式技术架构使用Kubernets+Mesos+Docker的架构模式，集成了该领域领先开源技术，发挥了每个开源模块的先天优势，相较单独开源软件更适用于联通生产业务。在有效管理容器化应用的同时，通过Mesos的框架资源调度功能，解决了物理资源完全按需共享的技术难题。

自动化细粒度扩缩容管理：独创的根据资源使用率阈值自动触发和根据时间周期性触发的自动扩缩容能力，搭配业务量越大占资源越多、无业务不占资源的细粒度资源调度模式，将传统的物理节点业务部署方式转变为容器集群管理模式，根据业务需求“一键式”增减服务节点数量。3.2资源的统一管理面向中国联通“两地三中心”的跨地域、跨网络的物理节点，CU-DCOS平台可以实现统一管理调度，各应用能力“按需、按时”自动化资源分配，提高IT资源利用率，降低运营成本。3.3创新的大数据服务CU-DCOS团队为了满足对Hadoop生态体系需求，创新性的研发了基于Myriad的自动化多集群多租户的Hadoop框架。经测试性能稳定，支持多种Yarn生态软件如Hive、Spark等，并能够做到计算存储分离，本地计算，细颗粒度调度，资源预留、超售、抢占等计算资源的多元分配方案。

3.4持续集成/持续交付能力CU-DCOS平台具有的DevOps能力支持快速迭代开发，从源代码到上线全部在系统内流转，当完成迭代上线时，业务应用已经封装为容器镜像并推送到私库，用户可实现不同版本应用的灰度发布，滚动升级。有效降低了业务割接和升级过程中出现的故障率，同时为服务供给侧提供了便捷的研发环境和供给通道。3.5统一服务网关以Gateway方式实现统一服务路由功能，针对不同的租户，实现服务能力化，需求差异化，针对不同需求，提供服务发现功能，让应用之间无缝实现业务上下游串联，真正的做到全流程自动化能力部署。同时优化了现有技术大大提高了服务发现和路由转送的流程，缩短了56%的有效响应时间。

3.6多实例持久化存储CU-DCOS平台提供了多副本、高可用、可共享的分布式存储，为容器增加了持久化存储的能力，解决了容器长期以来有状态部分的问题。在保证数据安全的前提下实现了容器调度的自动化管理，优化了代码保证多个实例都能成功挂载并稳定运行。4.落地应用联通研究院的CU-DCOS平台面向企业内部，已服务支撑以下系统：4.1公共创新大数据能力开放平台支撑了中国联通公共创新大数据能力开放平台，为平台提供底层IT资源的整体调度、集群的动态扩缩容部署、大数据应用的容器化管理和编排以及统一的大数据服务开放等。实现了快速部署、秒级停启各类应用，支持多种大数据服务的集群部署、负载均衡、灾难恢复和弹性伸缩，为公共、专业、创新等各类应用的快速部署提供快速支撑。目前已成为公司开源技术与业务转型相结合的创新型示范项目，相比于传统的分配方式部署时间节省了80%以上，集群间资源利用率之差不超过10%，可靠性大幅度提升。4.2联通PaaS平台的基础架构支撑中国联通PaaS平台的基础架构，支撑整体PaaS平台的资源调度和整合以及容器化封装PaaS能力和编排调度等能力。目前已完成了全部15种PaaS能力的封装，可对外提供服务。PaaS平台上的数十个O域、M域应用已经完成CU-DCOS整体迁移，并且运行稳定。4.3联通牛人部落实验室的基础架构支撑中国联通牛人部落实验室的基础架构，目前已应用于百余台设备并利用CU－DCOS进行统一的部署和资源调度。实现了大规模集群资源的动态管理、灵活的资源控制策略和应用安装部署。成功搭建了开放式实验环境，满足中国联通IT实验室的需要。CU-DCOS的投入应用，将以其创新的技术架构，全面支持中国联通实际管理、生产流程，并在中国联通首次实现以物理资源统一管理调度，各应用能力“按需、按时”分配资源，大幅提高IT资源利用率，降低运营成本。第四章开源PaaS初探1PaaS平台概述PaaS（Platform-as-a-Service,平台即服务）是云计算领域的三个主要组成部分之一，是指将软件研发平台作为一种服务，以SaaS的模式提交给用户。PaaS平台的两类主要客户是开发人员、运维人员。PaaS平台一方面连接IaaS为应用的提供云计算环境，一方面通过SaaS为应用提供平台基础设施服务，因此要求PaaS平台在为应用提供业务功能的同时具备弹性伸缩的能力和智能化运维功能。综上所述，PaaS平台功能架构主要由以下部分构成：(1)支撑应用的基础软件和中间件支撑（如数据库、Web服务、应用框架和消息服务等）(2)基于云计算的应用部署运行环境和开发环境，包括共享应用资源库和开发社区支持等(3)多租户支持与管理PaaS平台逻辑架构主要包括基于上述功能映射形成的各种类型的服务插件，以及服务间隔离设施来保障服务的相互独立性。PaaS平台从云计算框架建立之初就开始发展，初期主要是国内外大型互联网企业，比如Google、SalesForce等，构建了自己的PaaS平台，是独有产权的封闭PaaS平台，未对外公开发布其架构。传统的封闭的PaaS平台主要有三类提供商，一类是互联网企业提供的PaaS平台，典型代表是GoogleAppEngine；一类是原有的SaaS提供商，典型代表是SalesForce的Heroku；一类是以Amazon为代表的从IaaS虚拟化实施起步而逐步扩展出PaaS层平台的提供商。这三类平台以实现其自身的商业价值为主要目标明确了初期PaaS平台的功能范畴和架构要素。随着开源PaaS平台的崛起，新的技术趋势逐步明朗，改变了原有PaaS平台产业链的竞争格局和发展方向。2.主流的开源PaaS平台2011年4月，第一个开源PaaS项目CloudFoundry诞生。随后，开源PaaS平台层出不穷，得到了各大厂家和大量开发者的支持，版本的更新和新思路出现的频率远高于原有封闭的PaaS平台，也推动了PaaS平台架构设计理念的发展演化。2.1CloudFoundryCloudFoundry是VMware公司推出的业界第一个开源PaaS平台，并于2013年发布了最新的2.0版本。CloudFoundry作为基于云环境的PaaS平台，核心是一套消息系统，通过CloudFoundry消息总线组件（NATS）实现了一套模块自注册、自发现的松耦合消息发布订阅机制，并将各种功能抽象为模版、服务通过消息总线连接起来[2]。其最新版本的逻辑架构如图1：对比CloudFoundry的早期版本，新版的主要变化如下：(1)加强了服务总线，统一规范了服务的处理模式。新版的CloudFoundry中内置服务数量大幅减少，新增的DB、存储、消息队列服务，比如Neo4j图形数据库、RabbitMQ消息队列等，均作为标准服务与外部服务和框架一起作为标准服务接入ServiceBroker并提供给应用使用。(2)引入大数据处理。CloudFoundry在DEAPool中提供了日志管理组件Loggregator，支持应用以日志流的方式将日志数据接入到CloudFoundry完成大数据分析，这样就使得大数据库分析服务成为新版PaaS平台对外提供的服务。2.2CloudifyCloudify是Gigaspaces公司推出的基于java实现的PaaS平台。Gigaspaces是业界知名的PaaS提供商，也是高端Java应用服务器产品XAP（eXtremeApplicationPlatform）的提供厂家。Cloudify实现PaaS的主要思路是把云资源以及业务功能单元看作独立的计算节点，通过编排技术分别去关联计算节点，形成可定制的PaaS平台服务。这一设计思想与其早期产品XAP的设计理念一脉相承。这种方式使得Cloudify很轻薄，但也具有相当的服务提供能力，是从另一种角度阐述了PaaS最核心的本质，即将软件研发的平台作为一种服务交付给用户。新版的逻辑架构如图2：对比新旧版本的架构，我们发现的新变化如下：(1)秉承了轻薄化的线路并对功能架构做了增强，如客户端支持从原有的一种接入模式扩展到了三种类型的接入模式。(2)新增了日志数据管理，开始提供大数据分析支撑。通过日志数据管理工具，Cloudify实现了对其自身的日志分析、查询、汇总和存储的支持，遗憾的是还不能对其平台上加载的应用提供类似日志分析的大数据支撑。2.3Docker如果要列举2013年至今开源PaaS平台发展的主要事件，Docker的发布应算其一。Docker是PaaS提供商dotCloud开源的一个基于LXC的高级容器引擎。短短时间内，Redhat在RHEL6.5中集成对Docker的支持,GoogleComputeEngine也支持Docker在其之上运行。Docker平台主要由DockerEngine、DockerHub两部分组成。DockerEngine是应用的运行环境和打包工具，DockerHub则主要包括平台功能的应用开放API。Docker在技术模式上最大的创新在于其改变了PaaS平台实现虚拟化的技术路线，并将一个更加轻量、简洁的可实现PaaS平台模式展示给大众。Docker不是基于传统的Hypervisor技术来构建多个相互独立的虚拟操作系统，而是直接对操作系统本身的功能进行扩展来实现虚拟化，从而使得实现虚拟化的技术层次从操作系统层降低到了操作系统容器内，从而实现了PaaS的轻量化。上述思路的具体的实现主要是：基于Linux的LXC，通过Linuxnamespaces机制做权限的控制和隔离，用Linuxcgroups来进行资源的调度和分配，并通过Linuxaufs文件管理机制实现应用复制、重建、移动，从而实现大规模部署和更新。在其他PaaS平台中作为服务提供给应用的各项基础设施，比如数据库等，在Docker中是以镜像加容器的形式来实现的。Docker镜像、容器及其与Linux的关系如图3：Docker镜像（Images）是基于Linuxaufs机制来实现的。首先建立基础根文件系统（Bootfs），并在其之上建立分层的、与服务对应的Docker镜像，镜像之间是有继承（父子）关系的，每一层镜像的下面一层称为父镜像，最后在镜像之上针对每个应用的实例化就是容器。2.4小结基于上述的分析，上述开源PaaS平台的特征概况小结如表1：3开源PaaS发展趋势我们可以看到以下这些技术趋势在各个开源PaaS平台的架构升级中都有体现：3.1轻量化无论是CloudFoundry对内置服务的缩减，还是Cloudify对轻量化设计思路的坚持，以及Docker的火热，都折射出的PaaS产业链各方对轻量化的认同，都反应了PaaS平台轻量化的发展趋势。降低客户端的难度，让更多的现有应用接入到PaaS平台，让更多的开发人员参与到PaaS平台中，将为PaaS平台的后续发展带来无尽的可能性，也许这就是新时代信息技术的魅力吧。3.2服务外化原有的PaaS平台希望为给用户提供一个集成的开发环境，内置了诸多系统服务，以期降低开发者的门槛，但是却带来了部署繁琐、移植难度大的问题。为了兼顾运营维护的便利性，PaaS平台开始剥离内置的系统服务，将系统服务与第三方服务一视同仁，将包括Mysql等基础数据库的系统服务与第三方服务都作为标准的服务接入到统一的服务框架中，服务框架自身也推动了PaaS平台走向更加开放与分布式。同时，为了支持服务的相对独立，PaaS平台通过服务总线、应用编排、消息总线的组合来支持服务与应用间的互联互通。上述趋势无论在Cloudify、CloudFoundry还是新兴的Dokcer中都可以看到，一方面，PaaS架构变得清晰明确而更加易于大规模部署，一方面也给了应用更加明确的可为空间，只要应用足够便利和广泛，就可以作为服务接入到平台中提供给其他应用。3.3大数据分析随着PaaS平台承载的应用类型越来越多样，面向的用户越来越广泛，PaaS平台上的各种业务数据、客户数据也越来越具有统计分析价值。大数据分析既可以作为PaaS平台自身的资源动态分配的依据，对应用推广和引导应用研发也具有重要的参考价值。目前，越来越多企业、供应商已经认识到大数据需要作为PaaS平台的核心要素为平台运营和应用研发提供支持。无论是CloudFoundry引入数据分析工具，还是Cloudify加强自身平台对大数据分析的支持，我们都能深切的体会到这种趋势。4.结束语开源PaaS平台带动了整个PaaS领域的技术进步，在开源平台具有技术优势的背景下，更多的商业企业采用了开源平台作为基于互联网的新信息平台的基础框架。在互联网信息化的浪潮中，作为原有企业信息化的主要建设者的电信运营商需要抓住机遇，在变革中结合自身的业务、技术发展需要与新技术趋势，调整自身的平台建设和发展策略，为未来的竞争奠定优势。第五章传统企业PaaS上云思考（荐）1.背景说明伴随着Docker技术的兴起，以及容器集群管理平台Mesos、Kubernetes、Swarm、Rancher等的大行其道，仿佛PaaS平台及其相关技术一下进入了黄金时期，各种各样的技术组合，各种各样的技术验证，以及伴随着容器相关的创业公司布道，仿佛只要有了PaaS平台及其相关的技术，就能解决一切的企业IT问题。但是，企业IT，尤其是非互联网传统企业，PaaS平台的构建与业务上云是一个长期化的过程，绝不是一个Docker+kubernetes/Mesos/Swarm构建完以后就是完成了的，IaaS年代是这样，PaaS年代也是这样。

在互联网公司或者自研发型的应用，开发环境与部署运行环境非常的类似，这也是Docker或者容器相关技术在应用上的一个很大的优势（比如构建开发、测试、部署的DevOps流水线），但是在传统企业便不一定能行得通，比如某个企业的IT应用开发维护是外包的，标准软件需要采购、应用开发需要在应用开发商完成、硬件是另外的硬件提供商，到货后需要硬件系统集成、标准软件部署、应用开发部署调试，需要很多供货商来完成，往往以项目经理统筹完成，很难由一套DevOps之类的平台来解决所有问题。那么传统企业PaaS平台设计需要什么样的功能？上云时又需要进行如何改造，这是我们探讨的一些重点。2.传统架构与应用分类2.1经典架构

大家对这种架构耳熟能详，但也请做云计算或者容器技术的同事不要对这种架构嗤之以鼻，但是这种架构在也包含很多的对我们有学习借鉴意义的技术模块：SAN存储：包括高、低、中不同的存储，存储中磁盘的RAID配置、存储池配置、存储的集群配置、存储的容灾备份、数据的热点迁移、数据的缓存、存储之间的SAN交换机配置（划分Zoning，连接主机）等都需要专业的存储工程师（衍生出来了很多的认证），这种存储可以做到高IOPS、低延迟、高可靠性，是目前大多数的分布式存储难以匹敌的，且目前存储厂商在SAN上也做到了虚拟化；主机：小型机、x86服务器，小型机以IBM小型机为例，小型机虚拟化比x86虚拟化出现的年代早了几十年，当时是硬分区技术，后来发展到逻辑分区+IO虚拟化，逻辑分区可以做到分配0.1个CPU的细粒度，同时也在2007年就推出了类似于容器的技术，做到了进程级别的隔离，但因为不开源、不方便打包、镜像管理没有Docker方便，最终只在少数客户处进行了部署使用；DB：传统的数据库厂商比如Oracle为例，很早就推出了RAC技术，同时，2012年左右Oracle研发中心内部就开始使用Container技术搭建DBasaService（这比我们目前大多数的Docker相关的创业公司还早）；APP：以IBMWebSphere为例，十年之前就有WAS集群的概念，可以部分做到横向扩展。

传统企业这种架构统治了企业IT数十年之久，在大的行业，通常以商用中间件、商用DB、小型机、SAN存储部署。这种架构存在扩展性不足的问题，但是在传统企业架构中大量存在。

2.2OLAP与OLTP我们部署一个IT系统，最终的目的是为了解决传统的问题，所谓把线下业务线上化，这些业务最终的服务对象是数据，而数据处理大致可以分成两大类：联机事务处理OLTP（on-linetransactionprocessing）、联机分析处理OLAP（On-LineAnalyticalProcessing）。

当然还有其他的业务类型，比如银行或者运营商的每月出账系统，这种系统为也是一种批处理系统，但是实时性很强，跟HadoopMR所谓的批处理不是一个概念，也不在一个层级。这种应用我们暂时不考虑。

OLTP，也叫联机事务处理（OnlineTransactionProcessing），表示事务性非常高的系统，一般都是高可用的在线系统，评估其系统的时候，一般看其每秒执行的Transaction以及ExecuteSQL的数量。典型的OLTP系统有客户关系管理系统、电子商务系统、银行、证券等。

要求：一致性、高可用性。

OLAP，也叫联机分析处理（OnlineAnalyticalProcessing）系统，有的时候也叫决策支持系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。所以，在这样的系统中，考核的标准往往是磁盘子系统的吞吐量（带宽），如能达到多少MB/s的流量。3.云化需求与分析下面我们分别分析一下这两类应用的云化需求与云化的分析。注意：这些要求分析与要求是在Docker与各类容器管理平台火起来之前总结与做的，不是依据Docker或者容器相关技术的要求做的。所