云计算之PaaS经典案例30.docx
《云计算之PaaS经典案例30.docx》由会员分享,可在线阅读,更多相关《云计算之PaaS经典案例30.docx(156页珍藏版)》请在冰豆网上搜索。
云计算之PaaS经典案例30
梅峰谷大数据资料整理小组
云计算之PaaS经典案例汇总-中篇
版本号
V1.0
日期
2017-10-15
来源
梅峰谷大数据
本文档版权由梅峰谷大数据所有。
未经书面许可,任何单位和个人不得以任何形式摘抄、复制本文档的部分或全部,并以任何形式传播。
梅峰谷大数据资料整理小组
2017年10月
第一章中国移动网状网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.
2.PaaS技术选型
目前适用于容器集群管理和大规模部署的,并且得到大规模生产验证的开源产品有:
Kubernetes、ApacheMesos。
这两个平台各有特点:
2.1.Kubernetes
2015年,谷歌公布多年以来的容器集群方面的秘密:
Google早些年构建了一个管理系统,它可以用来管理集群、容器、网络以及命名系统。
第一个版本被称为Brog,后续版本称为Omega。
目前每秒会启动大约7000个容器,每周可能会超过20亿个容器。
利用在容器技术上的实践经验和技术积累,Google构建了Kubernetes(简写K8s)。
Kubernetes是一个全新的基于容器技术的分布式架构的集群管理解决方案,Kubernetes具有完备的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制,以及多粒度的资源配额管理能力。
有了Kubernetes,你可以告诉系统,你的应用程序需要一个数据库、三个服务器、X量的存储等等。
Kubernetes主要关注的是对服务级别的控制而并非仅仅对容器级别的控制,Kubernetes提供了一种“机智”的管理方式,它将服务看成一个整体。
在Kubernetes的解决方案中,一个服务甚至可以自我扩展,自我诊断,并且容易升级。
在Kubernetes的设计理念中,第一次将Service的高度提升到超过Machine,第一次将服务自动化提升到平台高度(监控、部署、扩容)。
目前Kubernetes生态环境热度很高,发展很快。
2.2.Mesos
Mesos最早由美国加州大学伯克利分校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.产品对比
相关技术在核心特点、量级、复杂性、稳定性、扩展性,二次开发工作量等方面的比较如下表所示:
Kubernetes
ApacheMesos
定位
专注于容器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平台,为未来的业务快速发展打下坚实的基础。
3.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、云计算服务商提供:
安全防护、自动备份/转移/恢复、监控预警、在线图形化操作扩容管理、中间件自动补丁升级
那我们看看中国的云计算服务商谁更接近这个愿景,谁能把应用开发与测试、应用部署、运维管理与安全防护、大数据分析都一站搞定。
这是我今天这篇文章的写作出发点。
我们选择了中国一线互联网公司:
阿里、腾讯、XX;华为、360;小米、金山、乐视;京东、美团、滴滴;新浪、网易。
看看这些排头兵正在做什么、成熟度进展如何。
我们看到:
小米、滴滴还没有开展公有开放云服务。
注意:
1、我并没有把外国云含入:
amazon、google、微软、IBM、VMWare、Oracle
2、我并没有把老牌中国IT商含入:
中国电信、世纪互联、浪潮、太极...
3、我并没有把新贵含入:
如七牛、UCloud、青云...
4、我更没有把创业含入:
类OpenStack公司、类Docker公司、类DevOps公司
2.洞察
2.1产品竞争
1、产品线竞争
发现阿里云在产品线方面确实处于领头位置,其他的云都尚有一段差距。
不过腾讯云从产品线研发来看追的非常快。
XX云和XX大脑在产品结果层面呈现的不多。
2、特色竞争
按说:
华为偏通信、360偏安全、乐视偏视频、京东偏零售电商、美团偏服务电商,那我们看看是不是这样。
但发现,他们的云,和他们的主业关系并不密切,算单独发展。
这也意味着,大家是在同一条起跑线,只不过有人跑的比较早而已。
华为云在DaaS层面提供了唯一的研发管理云,这个有点特殊,不知道华为是有布局还是能整合什么就整合什么。
另外,记得XX也发布了自己的研发管理云,但不是XX开放云事业部搞的。
整合自己的原有主干技术优势,看来每家都是一个壁垒啊。
事业部制之间老死不相往来。
倒是网易云、乐视云做的比较有调调。
网易云发挥自己一贯的小精品优势,做的克制,但做一个亮眼一个。
乐视云是完全从自己长处出发,围绕视频这个领域猛打,也算一批黑马。
去年呢,大家一窝蜂扎到大数据产品商。
大家今年都扎堆到视频云产品上了,这就不算特色了。
估计下一步,大家都要扎到区块链、人工智能产品。
2.2运营竞争
1、运维
产品线都差不多利用开源软件搭起来了。
下一步就是运维的竞争。
我看云厂商普遍在:
DevOps、运维监控与管理、安全防护方面还需要比较大的进展。
这也是下一步产品夯实的重点。
2、运营
呼叫中心服务、技术论坛/知识库、技术支持工程师的建设,发现各家建设也都比较欠缺。
中国的云看似已经进展了5年,但其实连运维层战争都还没有打。
今年腾讯、XX、网易、华为高调发布会,表明大佬们都才正式进场了。
中国云战争,其实才刚刚开始。
2.3客户竞争
1、市场格局
现在云市场天下三分:
创业公司长尾、高速成长的互联网公司/电商公司、传统大型企业
大量O2O公司死亡、SaaS公司回归私有部署是个暗点。
但今年新成立许多视频公司是热点,让大家纷纷开展云视频产品业务。
不少巨头云厂商扎入大客户模式:
金融、电信、央企