基于容器技术构建企业PaaS云平台实践

MoPaaS  技术总监    沈阅斌

MoPaaS企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发、应用交付、上线运维等环节,包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等。另外平台提供各种标准化和非标准化的运行环境以及各种运维管理功能,用户可以在秒级按需获取各类资源和环境。使得用户通过MoPaaS平台能够真正简化开发、测试、部署、运维等工作,为企业能够真正实现DevOps提供有力的技术支撑。
一、概述
企业级容器化PaaS平台旨在为企业应用提供底层支撑能力,覆盖应用开发、应用交付、上线运维等环节,包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等,本次分享主要介绍基于容器技术构建PaaS平台所采用的相关技术、涉及的核心功能模块以及相关方案。为满足以上需求,MoPaaS企业版基于Cloud Foundry及Kubernetes等开源技术框架和智能化云平台专利技术来构建。 此外,平台提供各种标准化或非标准的运行环境以及各种运维管理功能,用户可以在秒级按需获取各类资源和环境,平台最大的价值在于解放开发、测试、运维人员,降低用户对应用软件的交付成本及时间。MoPaaS企业版由Cloud Foundry提供标准运行环境、标准中间件服务接入方式、认证授权、软路由、组织管理、资源分配等功能。但Cloud Foundry新的运行时Diego虽然支持运行Docker镜像,但是功能相对较弱,并且运行在Diego中的应用架构必须符合一定的标准。MoPaaS 企业版 使用Kubernetes来提供对非标准运行环境及中间件服务的支持;所以对于不符合Cloud Foundry架构标准的应用,可以方便地运行到Kubernetes 的环境中。这样,MoPaaS企业云平台相对比较灵活,对应用运行环境和应用架构没那么多限制,所以一些老的应用迁移至云平台变得非常容易。MoPaaS管理Cloud Foundry和Kubernetes资源,进行统一的管理和调度。
MoPaaS平台助力用户根据业务需要实现计算资源的动态调配和应用的快捷交付,特别是帮助用户显著节省 IT 支出和应用提供的成本,缩短应用上线时间以及简化IT和应用的管理。此外,作为用户持续创新数字平台以及业务连续性的保证,MoPaaS也帮助企业用户有效地应对市场的变化,通过持续创新不断保持市场竞争力。MoPaaS平台(企业版)总体架构如下:
二、应用运行环境和中间件服务
     
应用运行环境和中间件服务是PaaS平台的核心功能模块,用户发布应用至平台时,只需发布应用本身,应用所依赖的操作系统、软件环境、中间件服务等都由平台提供,通过自动化方式配置和部署。a)应用运行环境PaaS平台需要支持不同类型的应用,应用架构及所依赖的软件环境各有不同。MoPaaS平台目前支持三大类应用运行环境,以及三种应用发布方式。三类应用运行环境包括:1、基于CloudFoundry的标准运行环境标准运行环境由平台预先制作好,优化相关配置后提供给用户使用,适合对环境没有个性化要求的应用,用户无需自己制作运行环境和进行相关配置,申请标准运行环境后,只需要将可执行包推送至平台即可。–多语言和框架:覆盖Go、Ruby、Python、Java、JS、PHP的多语言运行及框架–语言和框架的扩展机制和BuildPack扩展–服务插件及扩展机制:提供多种基础,如代码托管(Git)、数据库(MySQL, PostgreSQL, MongoDB)、缓存(Redis和MemCached)、消息队列(RabitMQ等)、Jenkins,以及众多的第三方服务扩展2、基于Docker的MoPaas镜像MoPaaS镜像,适合对环境配置有个性化要求的应用,用户可以基于MoPaaS基础镜像构建自己的应用镜像来运行,构建时还可以修改基础镜像配置。通过MoPaaS镜像运行环境可以节省用户构建基础镜像的时间,通过用户自定义应用镜像,支持更多的应用类型运行至MoPaaS平台中。

3、基于Docker的自定义镜像

自定义镜像需要用户自行制作运行环境,由用户在本地制作完成镜像后推送至平台运行,自定义镜像方式所有环境完全由用户自己定义,相对比较灵活,可以完全满足用户的个性化需求。

三种应用发布方式:

1、可执行包发布(war、zip)

用户首先需在本地将源码编译打包成可执行包,然后在平台上申请运行环境和中间件服务,通过Web UI或命令行操作将可执行包推送至平台,平台接收到可执行包后会将其Build成一个应用镜像后发布到平台运行。

2、源码发布

用户将代码提交至平台的Git源码仓库或者平台应用关联的一个Git源码仓库,通过手动或者自动触发一个持续集成流程后将应用Build成镜像后发布到平台运行。

3、镜像发布

用户将自己制作的镜像推送到MoPaaS平台发布。

b) 中间件服务

中间件服务是应用运行必不可少的软件资源,比如数据库,平台通过两种方式提供中间件服务:

1、平台内部提供的中间件服务

平台内部提供的中间件服务以容器方式运行,目前运行在Kubernetes,可提供集群或主从方式保证中间件服务的高可用性。中间件服务运行在容器跟应用很 大的不同是:我们可以要求应用在设计时尽量无状态,但是大部分中间件是需要在本地存储数据的,不可能是无状态的。因此在容器中运行中间件服务的关键是要解 决数据本地存储的问题,目前K8s支持多种PersistenceVolume,可以将数据存储到外挂的网络存储服务上来解决这个问题。

2、平台接入外部提供的中间件服务

有些中间件服务暂时不适合运行到容器,甚至这些中间件有专门的运维团队运维,比如Oracle,像这样的中间件可以独立于平台部署,通过比较松耦合的方式接入到平台供用户使用。具体方案如下:

 

三、应用外部接入方式
     
部署在Diego或K8s上的应用,都是以容器方式运行,容器会被调度和管理,因此我们访问应用时,不能直接访问容器的IP+Port。Cloudfoundry将容器的IP+Port动态更新至Route管理的路由表实现外部接入,默认支持HTTP(S)协议。K8s的Service能够提供很强大的功能,通过ClusterIP作为Pod的对外访问接口,并提供软负载均衡。但是Service的Cluster IP地址只能在集群内部访问,可以通过NodePort方式对外暴露服务。一旦采用NodePort,整个集群的所有节点就可以通过指定的端口访问到应用。如果需要域名访问这个应用的话,只需要将K8s节点的IP+NodePort注册到Route的路由表中实现。如果应用需要支持TCP协议访问,对于Diego管理的容器可以将容器IP+Port动态更新到前端负载均衡。对于K8s,将集群的节点IP+NodePort动态更新至前端负载均衡。实现原 理如下:
MoPaaS平台提供独立的 Router Proxy 模块,动态加载路由表,支持TCP 和 HTTP 的负载均衡,域名映射灵活,可快速变更。 
四、CI/CD在PaaS平台中的应用
     
平台集成了Git作为源码管理仓库,当用户在平台上新建一个应用时,自动会为此应用分配一个Git仓库。应用也可以关联平台外部的Git仓库,源码仓库一旦和应用关联之后,就可以实现将源代码自动发布至平台运行的整个流程。发布之前需要经过一个持续集成流程,持续集成流程可以预先定义,不同的交付团队可能会有差异,只有所有阶段都通过才能发布成功。在开发测试阶段,可以开启自动构建功能,当代码发生变更时自动触发构建流程,并及时反馈集成状态和结果。功能截图如下:
平台通过Jenkins配置整个持续集成流程,整个流程由代码质量检查、单元测试、构建、部署等几个阶段组成。当触发部署时,先判断当前应用在Jenkins平台上是否已经创建对应的持续任务,如果已经存在的话就触发第一个任务,如果不存在则创建这些任务。每一个任务成功执行才会触发下一个任务的执行,组成持续集成流程的所有任务执行过程。任务执行过程中的启动、成功、失败等状态会通过Webhook反馈给平台,平台会记录这些状态,并根据执行结果改变执行流程。实现原理如下:
持续集成可以帮助我们频繁地、自动化地构建应用软件,构建完成后需要将应用发布到平台运行。随着频繁的发布应用到生产环境,风险也会随之增加。所以要做到持续发布,需要通过灰度发布、回滚等机制保证发布过程的安全性。MoPaaS平台支持灰度发布和应用回滚策略,实现应用发布的平滑过渡,保证系统整体的稳定性,避免频繁发布对用户所造成的影响。实现原理如下:

 

上线流程原理如下:

 

五、弹性伸缩与自动化运维
     
a) 弹性伸缩MoPaaS平台提供两种方式实现弹性伸缩:手动和自动。用户可以根据自己的需求,设置相关的定时或周期性的策略,在适当的时机增加或减少资源,从而节约人力和资金成本,保证应用健康平稳运行。手动方式需要人为触发,可以进行横向和纵向伸缩,横向伸缩是指调整应用的实例数量,也就是组成应用集群的容器数量,平台提供智能化的负载均衡。纵向伸缩是指扩展应用单个容器的资源配额,比如内存、CPU等。MoPaaS平台目前可提供横向伸缩方式。平台可根据应用资源的使用情况,如:CPU、内存,或访问情况,如:QPS,对应用进行横向的扩容或缩容。开启自动扩容后,平台将结合用户自己配置的策略,联合监控数据,自动的创建和释放实例,全程无需人工参与,实现资源合理利用最大化。通过对最小实例数的设定,可保证应用实时可用数量。自动弹性伸缩的实现方案如下:
Route组件将访问日志记录至文件,通过LogAgent实时采集访问日志数据发送至消息队列。日志结构包括域名、请求时间、Method、URI、协议、响应状态、下行流量、请求来源、浏览器信息、请求容器信息、响应时间等。通过这些日志数据可以统计出外部对应用的并发访问量、下行流量、成功率、响应性能等指标。MoPaaS收集到这些访问日志数据之后,通过定时执行数据库存储过程进行统计、分析、合并、清理。MoPaaS统计最近10秒内的平均每秒并发量,根据用户预先设置好的弹性伸缩规则,计算得出当前并发量所需实例数量,然后通过下发指令给容器平台如Cloudfoundry、Kubernetes实现弹性伸缩功能。

功能截图如下:

 

b) 自动化运维

自动化运维主要包括健康检查和故障恢复。

健康检查包括对平台的自动化监控和检测,一旦监控到性能超标或宕机故障,则触发相关事件。如应用出现故障,则重新启动实例,物理机故障时,实例将迁移至其他主机,相当于一次部署过程。

 

在传统监控基础上,增加健康检查机制,用户能够一目了然的看到整个流程的各个节点运转情况,实例自动重启与迁移,报警大量减少,人力减少,只有自动恢复失败时才报警。不仅仅减少了人力的投入,也是一种降低成本的表现。

 

六、控报警和日志管理
     
运行在Cloudfoundry的容器监控数据由Doppler组件统一收集,我们通过Firehose组件可以采集到所有应用的性能数据,如健康状态、 CPU使用率、内存使用率、IO、磁盘使用率等等。运行在K8s上的容器通过cAdvisor采集,并统一汇总至Heapster,Heapster可以 将数据存储至时序数据库Influxdb中,平台通过查询数据库进行报表展示以及根据预先设置的阈值进行报警。
开发测试阶段,日志打到标准输出stdout,可以通过平台提供的Webconsole实时输出,如果需要持久化日志信息,平台提供一个Log4j SDK,这个SDK支持日志输出到一个消息队列中,应用需要持久化日志,只需要通过这个日志SDK输出日志即可,日志被打到消息队列后,由ELK存储日志,平台可以通过ElasticSearch提供的接口搜索需要的日志。 
七、应用云化的设计原则
     
在我们实施的多个PaaS项目中,遇到的最大的问题是应用迁移,由于客户有些应用迁移时要求应用架构、软件版本等与未迁移前保持一致,因此并不是100%的应用都可以往PaaS平台上迁移,平台支持非标准化运行环境已经在很大程度上支持了不同环境要求不同架构的应用迁移,但是如果有可能的话,比如应用方允许修改依赖的环境或应用架构以更好的迁移至PaaS平台,或者新开发的应用,像这样的应用的话最好符合一些云化的设计原则,具体要求如下:1、容器和应用实例定位• 容器和实例与 IaaS 解耦,依赖域名或配置管理定位2、数据持久化• 持久化数据存放在 DB、NFS、或其它共享存储• 日志保存至第三方服务实例迁移时内部数据不保留3、状态管理• 平台不提供状态保存管理,不依赖Proxy 会话保持功能• 状态保存至第三方服务,以支持水平扩展、负载动态均衡和故障转移4、优化 MTTR• 使实例的重启和重建变得更快捷
八、关于Anchora(安尚云信)和MoPaas
 
Anchora (安尚云信) 基于领先的自主技术打造专业开放的企业级PaaS云平台 — MoPaaS,以满足中国企业级用户实现持续创新的需求。MoPaaS 云平台产品和服务包括MoPaaS企业版软件、融合一体机系统以及企业公有云PaaS服务以顺应中国云平台市场的演进。MoPaaS助力企业用户根据业务需要实现计算资源的动态调配和应用的快捷交付管理,帮助用户简化IT基础和应用的管理来减少业务运维成本,以及增强业务交付能力来提高企业的市场竞争力。MoPaaS产品领先性和竞争力也得到了广泛的认可,近年来获得多个行业奖项,并在2015年底被国际知名市场调研公司Forrester 评为中国企业级云平台市场的强劲表现者。Anchora的客户广泛分布在多个行业和领域,包括金融保险、能源制造、交通运输、电子商务、电子政务、智慧城市,以及园区和高校孵化器等。Anchora 一直致力于打造全方位开放云服务生态圈,与超过100家云计算产业链上下游企业建立了战略合作伙伴关系,以共同孵化中国云计算市场,更好的为用户提供丰富灵活的服务。

《企业级融合云平台架构设计思路》 MoPaaS CEO 鲁为民讲演分享(三)

继《企业级融合云平台架构设计思路》 MoPaaS CEO  鲁为民讲演分享(二)整合第三方服务
鲁为民:我们怎么来实现第三方服务集成和融合,怎么实现微服务的架构呢?MoPaaS有多种方式来实现。其中之一我们可以利用Cloud Foundry 的服务代理器来实现。服务可以通过服务节点来接入我们的平台当中,并方便的提供相应的服务注册和发现机制。通过这种或其它的服务整合方式,不管是MoPaaS的核心服务还是第三方的外部服务,对于用户来说是透明的,使用体验都是一致的,不需要把它们进行区分。同时我们支持各种各样的开发运维,存储以及大数据、移动等服务,通过前面提到的机制可以很好地融合在一起。

 

 

 

 

 

 

 

 

 

应用交付

对于应用交付MoPaaS也提供多种模式,一种是敏捷的交付模式,这个是基于Cloud Foundry来实现的,用户(比如开发者)仅提供应用程序, PaaS 引擎提供其它一切支撑。 PaaS 将“runtime +服务容器 + 程序”打包并保存;解包后将进程放入容器中运行。这就大大降低了用户使用云平台的门槛。另外一种就是高度灵活的交付模式,很多应用需要的服务不是太通用,你可以将程序和环境清单提供给平台,平台根据清单到相关来源获取需要的环境。这个主要通过容器服务来实现。这两者分别满足不同的需求。敏捷的模式能照顾到大多数应用需求,余下的需求通过容器服务灵活的交付模式来满足。

 

 

 

 

 

 

 

 

 

 

 

 

 

对于应用交付,我这里还多说一点。我们能够用MoPaaS融合云平台方便地实现应用服务的灰度发布,你可以根据域名或者用户的特征来让不同用户访问不同的应用版本,你可以获得用户的使用数据,你也可以更好地确定你这个应用的版本是否符合期望的要求。应用交付也需要支持包括应用发布预览、发布和回滚,这些流程是通过MoPaaS能够得到很好的实现。

MoPaaS开放的生态系统

MoPaaS 融合云平台也致力于打造全方位开放云服务生态圈。目前与超过100多家云计算产业链上下游企业建立了战略合作伙伴关系,以共同孵化中国云计算市场。MoPaaS主要侧重于提供PaaS云平台引擎,依靠合作伙伴提供各种各样的互补服务,MoPaaS统一整合起来后把服务无

缝地提供给用户。

 

 

 

 

 

 

 

 

 

 

 

 

在结束讲演之前,我将本讲演的主要思路梳理一下。一是我们前面了解到企业IT变化的趋势是更多从基础设施往应用层面体现;二是企业云平台不仅仅提供工作负载资源的整合,更多侧重应用交付;三是云平台融合趋势,IaaS、PaaS和SaaS的界限越来越模糊;四是云平台融合将为应用交付提供更好的快速敏捷、规模弹性以及安全可靠;五是融合云平台可以更好支持云原生应用;六是云原生应用架构可以通过微服务架构来设计并实现。

    谢谢大家!
提问环节
主持人:感谢鲁老师的分享!接下来是提问环节,共有3个提问的机会,大家好好把握。提问:我看到咱们那个胶片里面说MoPaaS支持各种企业云和私有云,因为你们可能在公有云和IaaS合作,但我们在使用服务时看不到IaaS,只看得到你们,私有云和公有云接口不一样,你们怎么解决这个问题?

鲁为民:是的,在MoPaaS公有云服务中,虽然我们使用的是合作厂商的IaaS服务,但IaaS的细节被MoPaaS封装了,用户不必直接管理IaaS资源。另外,关于你问到MoPaaS和私有云IaaS的融合针对不同的IaaS技术可能不一样。私有云IaaS技术包括各种商用和开源的技术,通过使用MoPaaS的云提供商接口(CPI),我们都已经有很好的兼容支持。

提问:看MoPaaS支持动态资源调配,我就想问,我们的应用部署上去,可能有自己的API,我想把我的规模变大变小,我们之间微应用和PaaS之间怎么传递信息?

鲁为民:MoPaaS支持应用规模的动态横向扩容。它遵循一定的弹性扩容规则,我们根据负载的几个指标,比如流量、内存的使用等等来定义这些规则,一旦满足一定的阀值,我们增加或者减少应用实例个数,它自动也可以半自动完成。比如说,当应用负载变化到应用实例增加条件,根据规则平台将启动横向扩容机制来增加应用实例数目。在公有云出于安全的考虑,我们支持用户半自动的扩容。自动伸缩这个模块可以在私有云PaaS平台中提供。

提问:老师,在PaaS里面,您刚才说可以解决开发生产环境不一致的问题,怎么解决,有没有什么具体的方法?

鲁为民:开发测试环境在PaaS当中,实际上它把底层一些资源通过PaaS进行了屏蔽,通过软件定义这个层面来保证一致。比如建于PaaS之上的生产环境、测试环境和开发环境除了资源大小可能不一样外,其它的环境基本一致。所以如果应用在测试环境当中能够跑起来,在生产环境肯定能够运行。所以也就是说把基础层资源和应用层面虚拟化以后,MoPaaS可以屏蔽掉物理层面的不一致性。

 

 

 

 

 

 

 

 

 

提问:老师,你这边采用微服务架构,微服务架构利用到什么粒度,如果是粒度细的话,你服务之间的数据如果要做服务统计,接口和数据层面会不会有什么问题?

鲁为民:微服务的“微”有点误导,因为我个人认为“微”这个字有待商榷的。我们说微服务,一定不要机械地去理解“微服务”就是“微小的服务”。微服务某种层面是一种单一的服务,这种服务可能来满足完整的一个功能,这种处理是现实中比较好的做法。我们不建议从微颗粒度微的程度来定义微服务。对用户应用微服务化来说,你将所用的服务切到什么程度,重要的是你要保持用户服务功能的需求。所以我们微服务化的时候,并不严格按照微字面形式理解,而是按照需求和功能层面来决定微服务颗粒度。实际上有些在你看来,特别是传统的应用,在目前要将服务切到过细是不现实的,更多是维持整体的服务。实际上,我们在客户那儿实施部署MoPaaS项目时,有很多服务的规模相当大;比如,贵安新区的智慧城市,像它有很多商业的软件提供的服务,比如地球信息处理服务,如果我们要严格拘泥“微服务”的定义,服务的规模不是“微”的规模了,但是我们在第一期实现的时候,我们把这个服务没有拆分,以前是什么服务,照用什么服务。这样一方面让客户将应用迁移到MoPaaS平台的难度降低,另一方面客户的某些传统应用可能调用某些固定的服务,以前调用这些独立运维的服务,现在还调用这个服务,不需要改动很多,因此不需要将服务拆分为服务1、服务2、服务3。这也是一个现实的做法,而不需要机械地把一个服务降减到最低的限度。另外,微服务如果切割得过很细,服务数目规模显著增加,如果没有很好的服务管理机制,将会带来额外的问题。这样的话微服务的红利基本上享受不了,相反还有管理服务和APIs方面的问题出现,相应成本还会增加。
主持人:好的,提问就先进行到这里,再次感谢鲁总的精彩分享。

《企业级融合云平台架构设计思路》 MoPaaS CEO 鲁为民讲演分享(二)

继《企业级融合云平台架构设计思路》 MoPaaS CEO  鲁为民讲演分享(一)
怎样实现云原生架构
鲁为民:我们是怎样实现云原生架构的?首先是基于容器,同时提供跨系统API介入管理,还有服务协同和融合,以及服务的敏捷基础设施资源的提供。特别是基于这种架构,我们可以很容易的打造垂直领中的PaaS云平台。因为通过云原生和微服务架构,我们可以充分解耦各种垂直服务,可以更灵活的提供和整合服务资源。这也是为什么MoPaaS可以在短时间内支持企业用户打造适合其行业场景需求的PaaS平台。
那现在的问题是我们对云原生应用的设计有什么要求?这个问题的答案与当今的云计算的架构分不开的,这种架构对硬件的要求大大降低,各个硬件节点可以是高度不可靠的,但由软件定义一切并搞定相关云平台的主要需求。原则上,云原生应用的设计必须考虑和基础设施数据之间分离,云应用可能有状态、必须持续地保存,很大程度上能够高可用。对于基础设施,因为软件提供相关的保护,你必须容忍节点的不可靠,必须支持状态不能维持等等。我们在云平台设计当中是怎么考虑这些,或者说我们要设计云原生应用当中要考虑哪些方面?
关键的一点

大的原则大家可能都知道,所谓12因素应用的原则,这是Heroku的创始人根据PaaS的特性总结出来的。关键的一点,我们要实现容器或者应用实例定位不依赖物理的节点或者网络,它必须充分和IaaS解耦,要支持数据的持久化,使用共享和存储,将日志保存在第三方存储服务上。另外,实例的迁移,不管是什么原因,内部的数据必须不动,也没有义务迁移。对于应用状态的管理,因为大多基础设施不提供状态保持,因此应用运行中必须能够维持状态,以使得应用中用户的会话能够保持畅通。平台本身不为应用提供状态的保护和管理,应用也不能依赖相关设施的会话保持功能,所以服务的状态必须保存在第三方服务当中去。最重要的一点,和传统应用设计不一样,应用设计中要优化的参数可能不同,这是什么概念呢?比如说在云平台环境中,如果应用出现问题,我们更多需要靠应用的重启来恢复,而不是试图花时间修复这个特别的故障。这样能够更好的实现应用的扩容,实现故障的恢复和转移,以及实现负载均衡。因此,云原生应用设计中优化重启时间(MTTR)尤为重要。

我们在云平台服务架构的设计中,必须考虑容器和基础设施的解耦,所以在应用云化设计当中,应用的实例必须和IaaS解耦,也就是说,你不能依靠IP或者端口来定位这个应用,定位这个容器。而是通过域名、应用层面的一些ID来对它们定位。当然更不能依靠物理环境。另外,我们实现资源访问的负载均衡时,为什么要实现应用的无状态或者用一种可靠的方式来维持这种状态?因为在负载均衡的情况下,同一个应用不同实例分布在不同容器中运行,但这些实例都是支持同一个用户访问的会话,其状态不能保存在单个的本地容器中,如果状态没有很好的管理,就不太可能实现稳定通畅的会话。另外我们如果要支持高可用,比如在部署区域(Zone)层面的高可用,那么我们要在设计应用时确保应用不在当地自己管理状态,因为数据不保证在当地进行持久保存。此外,在故障恢复的时候,也必须考虑数据和状态的持久化,同时整个平台提供一个好的健康检测机制,这种健康检测是主动的,一旦应用出现问题故障,不是试图修复应用实例的这个故障,而是将它重启,因此,应用重启时间(MTTR)的设计优化变得非常重要,这使得整个重启的过程就变得非常主动,从而有效的实现故障恢复。
融合云平台设计的实例
接下来我讲一下融合云平台设计的实例。刚才主要讲云原生主要是从应用层自上而下看,接下来我则自下而上去说明,还是同样解决企业当前业务交付的问题。对这个问题我们重新来看一下,首先是在很多企业的IT环境当中,开发生产环境往往高度不一致,应用交付的效率不高,但当今市场的变化很快、需要应用交付的速度适应这种变化,也就是说应用迭代和试错效率需要非常高,怎么解决这个矛盾?其次是开发运维工具的管理,这些不同开发测试工具或者通过向不同厂商采购获得,或者自己开发或利用多种多样的开源来实现等等。这些服务工具往往是零散的、异构的,部署和管理都是很难统一。在这些工具和服务的数量增加到一定程度的时候,很难有效地使用和管理它们。我们可以通过将它们这些工具作为服务整合到PaaS平台当中来方便地解决这个问题。另外,业务的发展需要应用产品更新周期更快,而之前很多应用与基础设施高度绑定,实际上很多应用是直接通过物理的服务器来支撑提供服务的,再加上互联网环境的复杂,服务稳定性很难保证而且应用性能也难保证。这些因素导致应用体验差,产生用户的流失。当然还有各种安全问题。这些问题变得日趋严重,使得开发运维越来越困难,怎样解决这些问题?PaaS云平台正是为此而生。而我们希望进一步利用融合云平台这种技术为这些问题提供更加高质量、高效率、低成本的解决方案。

MoPaaS融合云平台的特点
MoPaaS融合云平台有什么特点?一是其架构满足用户多元的需求,一方面是偏基础层面对资源的弹性管理,另一方面是偏业务层面,支持业务应用的快捷交付。我们采用微服务架构实现服务的高度分布、隔离以及安全。同时通过灵活的架构来支持多形态企业云的需求,我们不但支持私有云、公有云,还支持混合云。MoPaaS平台本身支持并建立了开放的云服务生态圈,可以让平台自己能够融合多种多样的服务,它也让其用户快捷整合第三方服务,打造其自身业务的云生态。所以整体来说是比较完整地满足了融合云平台的需求。融合多元的需求,可以用多种技术来实现,比如说我们容器和编排基于Cloud Foundry,Docker和Kubernetes等一系列技术,另外我们和合作厂商共同打造统一融合及管理的IaaS-PaaS解决方案,能够让用户一站式实现IaaS和PaaS层面相关资源的调度以及业务的交付。另外我们要保证融合云平台能够应对市场需求不断演化,提供一种灵活可变的架构能够满足用户现在和今后的业务需求。MoPaaS的架构简单来说可以描述如下:上层通过微服务实现业务灵活的交互;下层通过容器和虚拟机来管理多元资源的调配;此外对于融合云平台的监控、管理和运维是由统一运维管理系统来提供。
                       
(未完待续)

《企业级融合云平台架构设计思路》MoPaaS CEO鲁为民访谈(一)

7月15号在深圳举办的2016 ArchSummit全球架构师峰会还是召集来了各路技术精英强将。在这场盛会上MoPaaS也备受海内外IT精英人才的关注,在MoPaaS的创始人鲁为民专场分享的“企业级融合云平台架构设计思路”更是座无虚席,分享后也有很多技术达人纷纷提出自己关心的问题,想必都是大家都希望了解的内容。我们就全程把内容整理分成三个部分呈现给大家,今天我们先分享第一部分。
开场
接下来把时间交给今天的第一位演讲嘉宾,MoPaaS创始人和CEO鲁为民先生,他今天将分享的主题是“企业级融合云平台架构设计思路”。

鲁为民:谢谢主持人。也谢谢大家今天上午来到基础云服务设计案例专场。我是MoPaaS的创始人,我在这里主要和大家分享我们关于开放的企业级融合云平台的设计思路。我们主要是从一个云平台技术提供商的角度来切入这个问题。
我首先介绍一下我们公司以及产品和服务。我们是专业的企业级云平台解决方案和服务的提供商,我们主要是提供企业级云平台的产品,叫做MoPaaS。和传统的PaaS定义相比,MoPaaS提供的功能在范围上有相当的扩展,以便为更大限度地满足用户多方面的需求。MoPaaS功能上包括两方面,一是支持业务持续交付的应用生命周期管理,包括相关的流程工具以及解决方案;另外一块是提供资源的弹性管理和动态调配,这部分和IaaS服务形成互补。我们公司提供企业级云平台产品和实施,主要是针对企业级用户;另外,考虑到云平台的产品交付的不仅仅限于平台软件本身,更多是交付运维能力,因此我们也提供平台运维管理系统以及运维服务。

 MoPaaS企业云平台产品和服务也获得了市场的广泛认可。去年全球知名的市场调研公司Forrester对中国企业级云平台服务提供商进行了全面的评估,MoPaaS被评为强劲的表现者(Strong Performer),并且得分排名仅次于第一梯队的阿里云、微软Azure以及亚马逊AWS,领跑在第二梯队,。我们拥抱开放的云平台技术,MoPaaS本身基于开源的Cloud Foundry 和 Docker 技术。特别是Cloud Foundry 是目前PaaS的开放标准,我们是首批Cloud Foundry基金会的成员,目前基金会的成员包括IBM、VMWare、Cisco、HP和SAP等在内的全球主要IT厂商。我们公司有近4年的企业级PaaS平台产品和服务交付和运维实践。我们三年前在中国提供首个开放的PaaS服务——MoPaaS。

用户需求着手                             
我们不管是做什么产品来解决相关问题,必须首先从用户需求着手。就云平台服务来说,云平台的融合是企业级IT需求的演进趋势。我可以从以下几方面来了解这些需求:

 第一,目前企业用户需求呈多元化趋势。多元化可从两个层面来看:一是横的层面,用户的业务多元化,需要提供种类不同、规模大小不一、应用领域各异的多种应用。二是从纵层面来说,需求随着时间的推移不断随市场需求变化, IT架构一定要适应这种变化,以满足市场的需要来更多地增强自己竞争能力。所以,企业IT架构必须能够融合各种需求。
第二,在之前企业IT架构的关注点从基础设施的提供逐渐转变支持业务交付。目前IT架构需要更多地贴近业务,人们也希望IT应用平台架构能够加快应用的市场投放,第三,IT架构需要支持和用户的交互,将用户的需求及时地反映在产品设计当中。IT基础设施和应用平台架构的融合可以有效增加产品的价值,驱动业务的增长。
就企业云服务来说,如何支持这样一些转变?首先云服务不仅仅需要从工作负载资源整合来考虑,更多的是我们需要提供一种应用交付的能力。在云服务当中分别由IaaS和PaaS来满足这两个需求。这两者高度互补,IaaS提供自动化IT基础资源交付和管理,PaaS更多是管理工作负载以及怎么将应用投放市场直接影响业务。PaaS相对于IaaS是一种新的应用开发部署的方式,这种变化需求并不苛刻,而且它给企业用户带来的价值是不可低估的。我等下会更详细的讨论这点。特别是,PaaS作为云计算服务的“最后一英里“的技术”,它可以帮助云服务落地,真正实现云服务的红利。
界限变得越来越模糊
因为IaaS、PaaS、SaaS相互渗透,不断的融合;言下之意就是说IaaS、PaaS、SaaS相互之间的界限变得越来越模糊。这种界限的模糊反映到产品当中来,不外乎两方面:一方面是资源管理,需要灵活动态地提供多元资源管理,包括IaaS的管理虚拟机级别的资源,以及PaaS的更细颗粒度层面的资源调度,提供容器化的资源。根据业务的要求,通过IaaS和PaaS提供相应颗粒度的基础资源和应用资源。另一方面是应用交付,提供业务快捷持续交付的工具和流程,也就是简化应用生命周期的管理,提供高效的应用和开发服务以及部署和运维的能力。
我们MoPaaS首先是从PaaS角度来试图解决上面的问题。我先花点时间谈一下我们理解的PaaS平台级服务。首先是应用交付平台,提供开发、测试、部署和运维应用程序的能力,还有支持多种多样的编程语言,也就是应用开发的语言,同时它必须按应用的需求来调配资源,这种调配资源不仅仅是从IaaS层面,从虚拟机层面,而是从实体层面来解决这样的问题。它支持横向扩展。顺便说一下,横向扩展与传统的纵向扩展不一样,它可以很方便快捷地进行线性的扩容,同时不中断你的业务。PaaS不仅仅支持公有云,也要为企业级用户提供私有云和混合云。
目前有一个大家比较关注的概念,所谓“云原生”,这个概念应该是和云平台服务同时产生的。到底它的需求是什么样?首先云原生的应用,现在没有统一的定义,但我们理解它是指在云计算环境下可以可靠地规模化运行的应用。这种应用可以在云平台开发,开发好以后可以部署在不同云环境当中,云原生架构要提供多种多样的支撑性软件堆栈,为云应用在云平台当中规模化运行提供方便。云原生概念的产生是为了更好的支持和实现用户驱动的创新。通过云原生的概念,可以支持与用户更容易更紧密的交互使得产品开发和投放可以及时的获得用户的反馈,从而有效驱动业务的增长。云原生的架构催生平台技术的融合,满足用户多元需求,这个概念和融合云平台实际上是殊路同归。云原生有些什么优势?它能够造就不断变化的软件架构,能够让自身业务更好适应市场的需求,以及能够维持用户的市场竞争力。为什么它可以满足这些需求?它首先是实现云应用的标准化部署和运维,通过构建微服务来实现,即通过各种离散的服务来构建规模化应用;另外,在技术的实现发展上基于容器让每个服务在容器中独立运行;云原生应用架构通过服务容器之间的通讯来实现服务之间的协同。
融合云平台
融合的云平台以及云原生应用怎么可以实现同一个目标?前面提到云原生应用在云环境上的可靠地规模化运行。融合云平台是自下而上,云原生是自上而下,都可以实现类似的目标:第一是应用交付的灵活快捷,提供新的业务的交互模式,应用迭代和试错的成本大大降低,时间大大缩短,同时基础和资源的调度可以快捷地完成;第二是可以实现弹性的规模化,它支持横向多级的扩容,不仅仅是虚拟机的层面,而且实现容器以及应用实例的横向扩容,根据需求可以高效按需提供这种资源。另外可以实现应用运行的安全可靠:首先提供需要的可见性,它对事件和故障可以系统化检测、定位以及报警,实现高度的容错性,以及故障的自动恢复等。

云平台、云原生和微服务,他们之间的关系现在就比较清楚了。融合云平台和云原生已经讲了,实际上是一件事情的两个方面。云原生的应用是通过微服务架构实现的,微服务是独立开发、独立部署、独立拓展的服务,它的建模是围绕相应的业务领域做的;它可以自动更新、自动创立、并自动提供服务;它采用分布式架构独立部署各个服务,并提供故障隔离。融合云平台提供云原生应用的支撑。微服务构成融合云平台架构的关键部分。
这就是本期给大家分享“企业级融合云平台架构设计思路”访谈(一)。如果您有想要知晓的技术信息,请在我们微信号中留言,有可能下期我们所讲的主题就是您所关心的哦!
今天就到这里,我们下期见!