转载

基于微服务架构下的容器化PaaS平台01(4.11)

在13年我详细写过企业内部私有云PaaS平台的规划和建设相关文章，前面对于微服务架构设计和实施的文章也写了不少，最近感觉基于微服务架构下的容器化PaaS平台还有必要进一步将思考的内容做一下整理，即在出现容器化和微服务架构后，对于传统的私有云PaaS平台究竟出现了哪些转变，以及我们在设计这种容器化PaaS平台的时候又需要考虑哪些内容等。

对于这些问题，首先会做一些零散的记录，后续再进行系统化的整理。

一个PaaS平台核心的管理对象就是业务系统，即每个业务系统都是PaaS平台里面的一个租户，在传统PaaS下我们只需要管理到业务系统这个级别就可以了，在微服务架构结合后则需要管理到微服务模块。即首先是应用注册和管理功能，但是应用注册后，还可以进一步注册多个微服务模块，每个微服务模块是管理的最小单位。每个微服务模块可以独立进行设计，开发，打包和部署，包括后续的运行监控。

PaaS平台应该提供完整的开发者门户功能，实现面向开发者的自服务流程和管控功能，简单来说就是应该实现应用生命周期管理和服务生命周期管理两条核心线条的管理能力。同时对于应用生命周期管理是到微服务模块级别的管理能力。应用-》微服务模块应该是一种松耦合的映射关系。

PaaS平台的开发者门户是面向开发者的，那么最终构建完成的微服务模块发布到哪里去？因此一个完整的PaaS平台构建，还需要构建一个集中的云门户能力。对于云门户至少应该包括传统的4A能力，特别是针对所有微服务模块的系统管理，权限管理能力，面向微服务模块的统一认证和单点登录能力。一个微服务模块里面的菜单和功能注册能力等，这些都应该是云门户统一完成。也就是说微服务模块完全只需要关注业务功能和业务逻辑的实现，在实现完成后统一在云门户进行相关用户，权限，流程等的配置。

4A+流程引擎模块是一个厚PaaS平台最集成的技术平台模块，需要提前规划和建设好。按道理主数据模块也是最基础的模块，也需要在整体应用构建的时候单独拿出来进行规划和建设。

每一个微服务模块的开发，最好是统一采用标准的微服务开发框架，以方便进行统一，因此PaaS平台需要提供相应的开发框架和开发环境能力。微服务模块开发商只需要基于开发框架来实现业务功能。

一个微服务模块的开发涉及到开发环境和集成环境，但是一个微服务模块要能够完整的跑起来往往涉及到消费和订购基础平台，其它微服务模块的服务接口能力。那么在这种场景下有两个思路，一个思路就是即使在开发环境下也需要进行接口服务消费和订购，否则模块无法成功运行。其次就是在开发框架和环境中，实现一个能下沉到本地的SDK服务代理SDK包，微服务模块在实现的时候只需要方便本地SDK包接口方法即可。在SDK包中我们还可以设计本地化的服务接口实现模拟，这样减少在开发环境和开发阶段的集成和耦合。

一个微服务模块要跑起来，必定会涉及到服务消费和订购，因此在服务全生命周期管理里面，首先要实现的就是服务的订购，只有订购了服务才能够在微服务模块进行折现服务的消费。而各个微服务模块提供的接口服务能力首先还是体现在服务总线上，或者说轻量的微服务网关上面。也就是说一个微服务模块开发，一方面是需要将自己提供的接口服务注册到微服务网关，一方面又需要去订购其它微服务模块提供的服务接口。

即基础技术平台（流程引擎，技术服务能力），云门户应用（含4A），微服务网关，PaaS管理门户等，这些功能组件都必须提前部署和准备好，这些是后续微服务模块依托的重要基础能力。

PaaS层究竟应该提供哪些技术服务能力，最基本的仍然是数据库服务（各类结构化数据库和非结构化数据），中间件（应用中间件，消息中间件），缓存，负载均衡，文件存储，任务，通知等，这些都是PaaS平台应该提供的基础技术服务能力。

在PaaS平台化或容器化后，并不代表就只需要监控Docker容器了，对于想要的虚拟机，各种计算和存储资源往往也需要进行监控。对于IaaS层的监控当然也可以在独立的IaaS平台里面来完成，但是当我们在进行中间件监控发现的问题的时候，能够快速的定位到具体的逻辑资源或物理资源上。

比较理想化的状态在前面文章也谈到过，即登录到PaaS平台注册一个招投标模块应用，填写相应注册信息，同时对相关基础接口服务进行订购，然后下载开发框架进行功能的开发，对订购的服务进行消费，完成微服务模块的开发和构建，构建完成的部署包直接进行自动化部署，在测试通过后可以自动发布到云门户环境，形成一个新的微服务模块能力，同时在云门户环境中进一步进行用户，权限和菜单等的配置功能。

要实现和DevOps和持续集成的结合，必须能够和类似GitLab，SVN等源代码管理工具进行集成，同时通过类似Jekins来实现整体的持续集成过程，包括自动下载和更新代码库，自动运行Maven构建脚本进行构建，同时自动将构建完成的内容进行镜像制作等。

镜像 = 部署包+中间件容器+配置信息

一个镜像你可以理解成就是一个可以完整独立运行的小应用服务器。同时镜像可以很灵活的实现复制，迁移，卸载和销毁等能力。镜像可以构建在虚拟机里面，也可以直接构建在物理服务器上。所有的镜像都应该在镜像仓库镜像管理，包括不同的版本。在资源调度的时候能够很方便的从镜像仓库获取镜像快速的进行部署和调度。

在容器化PaaS下，部署是基于镜像的，因此需要提前进行镜像的设计。对于部署需要考虑的就是具体的部署策略和部署规则，包括实例数的最大和最小值分配，资源的动态调度规则等。在部署和发布的时候往往还需要支持灰度发布能力，这个在前面已经有专门一篇文章在说明。

由于微服务模块的部署已经由PaaS平台进行了应用托管和自动部署，而且对于Docker容器实例的分配也是相对灵活动态变化的。 在这种场景下面就需要强调的应用日志采集和日志分析查看能力，这个是PaaS管控平台必须提供的关键能力 。举例来说一个微服务模块部署下去后，开发商不用关心底层的虚拟机和容器，而是在管控平台的日志管理功能就能够看到所有的中间件日志，应用日志等，方面进行问题分析和诊断。

也就是说PaaS平台不仅仅提供应用模块的健康监控和管理，更加重要的是可以对应用的构建日志、部署日志、运行日志进行查询，提供平台上各系统的日志采集、查询、分析工具。如果日志管理能力没有跟上，那么后续微服务模块的应用性能分析，应用监控和故障处理将非常麻烦。

原文 http://blog.sina.com.cn/s/blog_493a84550102xc1x.html

正文到此结束