MoPaaS提供企业级容器化PaaS平台核心模块及技术解决方案

今天主要和大家分享MoPaaS在提供企业级容器化PaaS平台解决方案中涉及到的一些核心模块及其技术解决方案。也很希望能和各位作一些深度地探讨。

MoPaaS企业级容器化PaaS平台旨在为企业应用提供底层支撑能力，覆盖应用开发、应用交付、上线运维等环节，包括代码的管理、持续集成、自动化测试、交付物管理、应用托管、中间件服务、自动化运维、监控报警、日志处理等,通过MoPaaS平台能够真正简化开发、测试、部署、运维等工作，为企业能够真正实现DevOps提供有力的技术支撑。

平台提供各种标准化和非标准的运行环境以及各种运维管理功能，用户可以在秒级按需获取各类资源和环境，平台最大的价值在于解放开发、测试、运维人员，显著节省 IT 支出和应用交付成本，缩短应用上线时间。

MoPaaS企业版基于Cloudfoundry V3及Kubernetes框架构建，Cloudfoundry提供标准运行环境、标准中间件服务接入方式、认证授权、软路由、组织管理、资源分配等功能，Cloudfoundry新的运行时Diego支持运行Docker镜像，但功能相对较弱，并且运行在Diego中的应用架构必须符合Cloudfoundry的标准。所以对于不符合CF架构标准的应用，将其运行到Kubernetes上。

Kubernetes主要提供对非标准运行环境及中间件服务的支持，相对比较灵活，对应用运行环境和应用架构没那么多限制，所以一些老的应用迁移至云平台会更加容易一些。MoPaaS管理Cloudfoundry及Kubernetes资源，进行统一的管理和调度。

总体架构如下：

接下去主要围绕以下几个方面介绍：

1、应用运行环境和中间件服务
2、应用外部接入方式
3、CI/CD在PaaS平台中的应用
4、弹性伸缩与自动化运维
5、监控报警和日志管理
6、应用云化的设计原则

应用运行环境和中间件服务

应用运行环境和中间件服务是PaaS平台的核心功能模块，用户发布应用至平台时，只需发布应用本身，应用所依赖的操作系统、软件环境、中间件服务等都由平台提供，通过自动化方式配置和部署。 由于PaaS平台需要支持不同类型的应用，应用架构及所依赖的软件环境各有不同，因此平台支持三大类应用运行环境，以及三种应用发布方式。

1、 基于CloudFoundry的标准运行环境

标准运行环境由平台预先制作好，优化相关配置后提供给用户使用，适合对环境没有个性化要求的应用,用户无需自己制作运行环境和进行相关配置，申请标准运行环境后，只需要将可执行包推送至平台即可。
多语言和框架：覆盖Go、Ruby、Python、Java、JS、PHP的多语言运行及框架

2、 基于Docker的MoPaaS镜像

MoPaaS镜像，适合对环境配置有个性化要求的应用，用户可以基于MoPaaS基础镜像构建自己的应用镜像来运行，构建时还可以修改基础镜像配置。

3、 基于Docker的自定义镜像

自定义镜像需要用户自行制作运行环境，由用户在本地制作完成镜像后推送至平台运行，自定义镜像方式所有环境完全由用户自己定义，相对比较灵活。

三种应用发布方式：

1、可执行包发布（war、zip）

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

2、源码发布

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

3、镜像发布

用户将自己制作的镜像推送到MoPaaS提供的私有镜像仓库后发布至平台运行。

中间件服务是应用运行必不可少的软件资源，平台提供标准化的扩展机制及服务插件：如代码托管（Git）、数据库（MySQL, PostgreSQL, MongoDB）、缓存（Redis和MemCached）、消息队列（RabitMQ等）、Jenkins，以及众多的第三方服务扩展，平台通过两种方式提供中间件服务:

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

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

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

有些中间件服务不能将其运行到容器，甚至这些中间件对硬件环境有专门要求，有专门的运维团队运维，比如Oracle，像这样的中间件可以独立于平台部署，通过比较松耦合的方式接入到平台供用户使用。

具体方案如下：

应用外部接入方式

部署在Diego或K8s上的应用，都是以容器方式运行，容器会被调度和管理，因此我们访问应用时，不能直接访问容器的IP+Port。

Cloudfoundry将容器的IP+Port动态更新至Route管理的路由表实现外部接入，默认支持HTTP(S)协议，K8s的Service能够提供很强大的功能，通过提供ClusterIP作为Pod的对外访问接口，并提供软负载均衡，但是Service的ClusterIP地址只能在集群内部访问，可以通过NodePort方式对外暴露服务。一旦采用NodePort，整个集群的所有节点都可以通过指定的端口访问到应用。

如果需要域名访问这个应用的话，只需要将K8s节点的IP+NodePort注册到Route的路由表中实现。如果应用需要支持TCP协议访问，对于Diego管理的容器可以将容器IP+Port动态更新到前端负载均衡。对于K8s，将集群的节点IP+NodePort动态更新至前端负载均衡。

实现原理如下：

平台提供独立的 Router Proxy 模块，动态加载路由表，支持TCP 和 HTTP 的负载均衡，域名映射灵活，可快速变更。

CI/CD在PaaS平台中的应用

平台集成了Git作为源码管理仓库，当用户在平台上新建一个应用时，自动会为此应用分配一个Git仓库。应用也可以关联平台外部的Git仓库，源码仓库一旦和应用关联之后，就可以实现将源代码自动发布至平台运行的整个流程。

发布之前需要经过一个，持续集成流程，持续集成流程可以预先定义，不同的交付团队可能会有差异，只有所有阶段都通过才能发布成功。在开发测试阶段，可以开启自动构建功能，当代码发生变更时自动触发构建流程，并及时反馈集成状态和结果。

功能截图如下：

平台通过Jenkins配置整个持续集成流程，比如整个流程由代码质量检查、单元测试、构建、部署等几个阶段组成，当触发部署时，先判断当前应用在Jenkins平台上是否已经创建对应的持续任务，如果已经存在的话就触发第一个任务，如果不存在则创建这些任务，每一个任务成功执行才会触发下一个任务的执行，组成持续集成流程的所有任务执行过程，包括启动、成功、失败等状态都会通过Webhook反馈给平台，平台会记录这些状态，并根据执行结果改变执行流程。

实现原理如下:

持续集成可以帮助我们频繁地、自动化地构建应用软件，构建完成后需要将应用发布到平台运行，频繁地发布应用到生产环境，风险也会随之增加。所以要真正做到持续发布，需要通过灰度发布、版本回滚等机制保证发布过程的安全性。

MoPaaS平台采用灰度发布策略，平滑过渡，保证整体的稳定性，避免频繁发布对用户所造成的影响。

实现原理如下：

上线流程原理如下：

缩与自动化运维

平台提供两种方式实现弹性伸缩方式：手动和自动。
用户可以根据自己的需求，设置相关的定时或周期性的策略，在适当的时机增加或减少资源，从而节约人力和资金成本，保证应用健康平稳运行。

手动方式需要人为触发，可以进行横向和纵向伸缩，横向伸缩是指调整应用的实例数量，也就是组成应用集群的容器数量。

纵向伸缩是指扩展应用单个容器的资源配额，比如内存、CPU等。

自动方式目前只提供横向伸缩，可以根据并发量、CPU、内存等指标进行配置。

开启自动扩容后，平台将结合用户自己配置的策略，结合监控数据，自动的创建和释放实例，全程无需人工参与，实现资源合理利用最大化。

通过对最小实例数的设定，可保证应用实时可用数量。

根据并发量的实现方案如下，通过实时分析结果进行弹性伸缩

Route组件将访问日志记录至文件，通过LogAgent实时采集访问日志数据发送至消息队列。日志结构包括域名、请求时间、Method、URI、协议、响应状态、下行流量、请求来源、浏览器信息、请求容器信息、响应时间等。
通过这些日志数据可以统计出外部对应用的并发访问量、下行流量、成功率、响应性能等指标。

MoPaaS收集到这些访问日志数据之后，通过定时执行数据库存储过程进行统计、分析、合并、清理。
MoPaaS统计最近10秒内的平均每秒并发量，根据用户预先设置好的弹性伸缩规则，计算得出当前并发量所需实例数量，然后通过下发指令给容器平台如Cloudfoundry、Kubernetes实现弹性伸缩功能。

功能截图如下：

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

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

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

监控报警和日志管理

运行在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使实例的重启和重建变得更快捷

原标题：基于容器技术构建企业PaaS平台实践