本文总结描述：随着云原生技术的快速发展和推进，企业混合云平台规划和厚PaaS平台建设将加速推进。公有云服务解决了传统的数据库，消息，缓存等技术中间件的服务化提供。而私有云PaaS涉及到的4A，流程引擎，组织，跨模块集成能力等能力也需要进一步解决，才能够形成一个完整的方便企业应用快速云化的厚PaaS平台。

企业私有云PaaS平台建设

在我前面聊企业私有云PaaS平台建设，聊企业配合数字化转型加速上云的相关文章中，经常会谈到一个关键概念，即平台+应用，同时这个平台是厚平台。

什么叫厚平台？

简单来说就是只要和业务无关的内容都可以下沉并统一建设，然后再以服务的方式提供给上层应用使用。

在这里还是先聊下12年联通集团启动的企业私有云PaaS平台建设项目，远行是做为ESB企业服务总线集成商和整体产品集成负责人参与了该项目。该大项目超过10个以上的软件服务商参与，集中办公人员就上1000人，现在差不多10年过去了，可以聊聊当时进行私有云PaaS平台规划和应用建设的一些背景。

09年启动的ERP集中化建设

联通集团实际是在09年就启动了ERP集中化建设，由于当时刚完成了整个电信改制，北方十省的老网通合并到联通，一切方兴未艾，也正好给了进行ERP全国大集中建设的契机。就单纯的ERP集团化大集中这个事，实际移动集团是17年才开始建设。

而当时远行仍然是以SOA集成平台规划和建设实施方式参与到该项目。

而当时围绕Oracle ERP系统，还构建了集中化的报账平台，主数据，项目管理系统，预算系统，资金系统等多个集中化的业务系统。

这个集中化项目实际规划和建设都相当成功。

但是基本还是传统的烟囱式建设模式，即招标各个系统建设厂商，然后再通过SOA集成平台进行接口集成。当时来说比较有前瞻性的规划就是SOA和MDM两个系统作为双中心同时启动并行建设，即一开始就考虑到基础数据的统一问题。

除了传统的烟囱式建设外，整个IT基础设施架构基本为传统架构，服务器基本都采用小型机，存储采用EMC存储，数据库采用Oracle数据库。现在看起来这些成本投入感觉很高，但是实际在当时确是最保险，也最可靠的一种IT基础设施架构模式。

也正是因为这个架构模式，带来了另外一些问题。

这些问题关键并不是IT基础设施建设和购买的成本，更加重要的问题体现在两个方面，其一就是厂商在系统上线后话语权增加，逐渐反而被开发商绑架；其次就是在业务和并发量起来后，特别是在年结期间数据库性能出现瓶颈，而且这个瓶颈很难去简单通过集群扩展。

12年启动私有云PaaS平台建设

实际在10年，阿里和淘宝就开始了去IOE，全部采用X86服务器和Mysql数据库来替代传统的Oracle数据库，IBM小型机和EMC存储等商用产品。这个去IOE不仅仅是成本方面的考虑，更加重要的仍然是前面说到的性能和可扩展性的考虑，特别是在数据库层面如何通过水平和垂直拆分来最大化的进行弹性扩展。

在12年联通启动uCLoud项目后，实际有几个重点。

其一就是去IOE，除了少量类似集成平台，流程平台等核心技术平台仍然采用少量小型机和集中存储资源外，其余技术服务和上层应用全部采用X86服务器资源构建的虚拟化资源池。这个在当时集团性大项目建设中绝对是超前的。

其二就是组件化，一个传统应用被拆分了20个左右的业务模块，然后拆分为3到4个标段，招标给3到4个不同的软件供应商进行应用开发。也就是说传统的一个大应用现在变成了3个厂商共同开发的。和当前谈的单体拆解微服务很类似，但是当时没有微服务概念。

其三就是厚PaaS，即不是简单地提供数据库和中间件资源池服务，还提供流程，4A，消息，缓存，文件，通信等各种技术服务能力。也就是我前面谈到的，只要是和业务无关的技术能力都下沉到PaaS平台统一构建。

现在来回顾这个项目，实际并不是特别成功，规划的4个大应用，实际只成功上线了一个应用。没有成功的原因主要有两个方面。

第一个就是当前去IOE，组件化，PaaS厚平台任何一项都是超前。那么几个超前的事情都放在一起规划建设，难度可想而知。特别还是上层的模块拆分到了20多个这种细粒度，更加导致了后续集成，联调复杂度呈指数级增长。

还有一点就是这个项目本身集中化建设，原来一个软件厂商一套产品可以在31个省重复卖和实施，现在集中化后反而这些市场和生意没有了，因此这也间接导致了有些厂商出现了消极应对的心态。这也直接导致了项目开发，集成和推进难度极大。

PaaS技术平台建设中的问题

多年以后，现在可以谈谈当时PaaS平台规划和建设中的一些问题点。

首先看下应用托管和资源动态调度这块，这块当时采用Cloud Foundry进行构建，但是实际很多管控平台能力，自服务能力并没有达到。而且没有实现类似当前DevOps最佳实践里面的完全自动化部署和持续交付。那么接近上100个业务模块，都需要人工去处理相关的操作和部署，这个工作量实际相当大，而且部署出现问题来回沟通也浪费大量时间。

其次是Mysql数据库集群，当时采用淘宝开源Corba进行定制扩展，形成统一的DaaS服务层。当时DaaS服务层实际有很多的Mysql原生特性已经不支持，包括一些复杂的SQL，关键语法，也包括分布式事务等实际都支持的不好。同时由于底层数据库进行了水平和垂直拆分，导致前端涉及到跨库查询等操作的功能实现都极其复杂。

再次就是组件化拆分的问题，前面已经谈到一个传统的应用系统拆分为了20个以上的微服务组件，而且每个组件都独立数据库，独立设计开发，这直接导致了后续应用集成难度极大。由于当时我们在负责产品集成，我们要完成一个端到端场景的SIT集成测试，往往要协调上10个供应商，好几十个组件模块才能够完成。这种应用的集成难度已经不是线性，而是呈现指数级的增长。

最后就是整个组件模块的持续集成和发布问题，前面谈到在我们当时实施PaaS平台项目的时候，并没有实现完全的自动化持续集成和持续交付，这就导致这个过程中需要投入大量的资源手工来处理代码检查，编译构建，部署，后续的运维管控等一系列的问题。即使是一个全场景的集成测试，从启动到环境准备完成往往就需要2天以上的时间，这完全无法满足当前的自动化和敏捷响应的需求。

云原生为何加速的企业PaaS平台和云化建设

做任何一件事情，始终都要有敢于吃螃蟹的人，虽然你可能失败或成为先烈。但是总有人需要勇敢地踏出第一步，即使失败你所有的努力也将为你后续的实践积累宝贵的经验。

在17年所有，联通研究院又开启了企业内部容器云PaaS平台的研发和建设，分别建设了天宫，天梯，天眼和天擎四个平台，实现了完整的云原生技术平台能力。同时该PaaS平台支撑了联通企业内部多个业务系统的高效运行。

而这件事情对于移动和电信，差不多是2020年才开始大面积启动内部系统的上云计划，也就是说联通又一次走在了前面。12年启动做私有云PaaS平台这件事，当时超前的一些问题点是否在现在都有了更好的解决方案和落地实践，我们可以结合云原生再来回顾下。

组件化-》微服务

早期的互联网组件化是什么？更多的则是组件化模块+Dubbo服务集成。

但是在15年后，微服务的概念被越来越多的人所认识，相应的微服务开发框架和环境，微服务拆分，前后端分离，微服务治理，类似服务发现，安全，限流等各种微服务治理能力多得到了快速的发展。

微服务技术也日渐成熟。

微服务架构在实施过程中有两个关键问题，一个是微服务拆分的问题，一个是后期的微服务管控治理问题。第一个问题随着企业架构规划方法，领域建模方法推进整个拆分方法也逐步成熟，而对于微服务管控从早期的SpingCLoud完整框架体系和服务网关到当下的ServiceMesh服务网格，也是逐步走向成熟和稳定。

从单纯的组件化开发，到当前完整的微服务开发框架和管控治理体系，这是一个长足的发展。简单来说就是你不能只考虑如何拆分，如何组件化开发而不去关心后续的集成和管控。而当前则是整个微服务从需求到开发，从集成到管控全部管理起来。

PaaS平台-》K8s+Docker容器云

在12年实施私有云PaaS平台的时候，实际采用的是开源Cloud Foundry平台，并定制PaaS管控治理平台，但是实际效果并不太好。

主要原因还是整个从构建，集成到最终部署发布的过程没有完全的自动化。而且本身Cloud Foundry平台基于虚拟机进行调度，在我们进行POC和压力测试的时候，基于CPU和内存负荷进行的自动化弹性扩展并没有达到期望的快速和敏捷效果。

而当前主流的PaaS平台已经变成了类似Kurbernetes+Docker的容器云PaaS平台，而且已经相当成熟，基于轻量Docker容器的调度和编排效率也远远高于传统的虚拟机。同时本身进行了组件化和微服务化，拆分的微服务也更加适合部署到轻量的容器资源中。

持续集成-》DevOps

腾讯devops流水线

在12年我们实施私有云PaaS平台项目的时候，实际我们已经在推持续集成和每日构建，但是整个从需求到设计，开发到集成，测试到交付上线的过程并没有完全自动化打通。这也就导致了在整个开发和集成过程中，存在大量的人工沟通和协同操作，这也极大了影响了整个应用开发和交付的效率。

而当前CI/CD持续集成和部署已经发展成为了成熟的DevOps方法论，并且形成了一套完整的开源工具链技术进行支撑。通过可视化的流水线设计和编排，我可以完成整个研发过程的全流水线和自动化作业，同时在整个自动化过程中增加类似安全，代码检查，自动化接口测试等各种管控手段。要知道在12年我们实施PaaS项目的时候，代码的安全和合规性检查全部都是靠人工去运行检查工具完成。

面对上100个组件或微服务模块，自动化的持续集成和交付是必须的，否则将极大地影响到整个应用的开发和交付效率。

简单总结你可以看到，涉及到的研发过程管理，持续集成和交付，PaaS平台，微服务等各种主流的技术问题在云原生时代都得到了解决，这些都为企业私有云PaaS平台的建设奠定了更好的基础。也就是是8年前做这件事情超前，那么现在企业做PaaS平台，做混合云就正是时候，特别是对于大型的集团性企业来说。

那么剩下的关键点就是整个云化迁移，上云规划方面的问题。而里面最重要的又是业务架构的规划，微服务的拆分等。只要解决业务架构和微服务拆分，把握好拆分颗粒度，确保拆分模块松耦合，那么整个云化建设成功的概念就相当大。

云原生推动厚PaaS平台建设

在私有云PaaS平台的规划和建设中，我们始终在强调一个点就是平台+应用的构建方式。这个平台就是云平台，而云平台的发展本身有不断在演进。从最初的只提供弹性计算和弹性存储服务的资源服务，到提供应用托管的中间件服务，再到当前提供各种流程，4A，消息，缓存等共性技术服务能力的PaaS平台。

当前我们说PaaS平台。

如果说是Kurbernetes+Docker的容器云PaaS平台，那么这是一个狭义的PaaS平台的概念，而一个广义的PaaS平台一定是包括了更多的共性技术服务能力提供。对于企业内部信息化来说这些能力既包括了技术能力，也包括了公共基础服务，可复用组件。

1.技术能力：消息，缓存，日志，文件，通知

2.公共能力：流程，4A平台

3.可复用组件：表单引擎，报表引擎，各类基础组件等

也就是说企业私有云PaaS平台整个范畴更加广泛，只要是和业务无关的，或者可以抽象来和业务无关的都可以做为共性能力提供。同时企业的PaaS平台一定是覆盖了开发态，运行态和运维态全生命周期的。

因此类似当前的微服务开发平台，低代码开发平台等都可以纳入到PaaS平台范畴。

在进行了组件化和微服务化开发后，所有的微服务之间要集成和交互，相关的API接口能力要对外开放和协同，因此API网关和能力开放平台也是构建PaaS平台必不可少的一个内容。这个在传统的PaaS平台架构里面叫IPaaS平台。

当然上面谈的都是和业务无关的技术服务或公共服务能力提供。

在前面几年，中台的概念很火，而中台的核心是共性业务能力的下沉，并以可复用的接口服务开放给上层业务应用构建使用。但是对于业务中台或数据中台，我们一般也不将其纳入到PaaS平台的范畴。

如何才是真正的厚PaaS平台？

图片来自网络

对于这个问题我在前面已经给出过明确答复，衡量一个PaaS平台是否是完整意义上的厚PaaS平台，一个关键衡量指标就是。从申请资源使用-》到申请服务使用。

简单来说就是你不会接触到任何资源层的内容，你接触的已经是资源的上层。再简单点来说就是你不会基础到虚拟机，包括容器这种资源层的东西你都不应该接触到。

你不会去申请一个虚拟机，或申请一个容器资源，然后自己再去操作虚拟机或容器，进行应用的安装或部署操作，这些都是资源层的操作。你只能够是通过PaaS平台提供的API服务接口，或者定制的管控自服务平台，动态地将你的应用部署下去。

最早期的PaaS，只做了应用中间件资源池，即将应用部署包动态的部署下去，同时通过应用托管实现了应用中间件集群的资源动态扩展和调度能力。

其次是实现数据库即服务能力，即数据库本身也不是你申请虚拟机自己安装数据库，而是直接使用数据库即服务能力，PaaS平台会提供一个数据库服务能力的入口或连接地址，具体底层数据库的安装，数据库的集群扩展你也不用关心。

好了，在解决了数据库和应用中间件后，基本实现了PaaS平台应有的能力提供。

那么问题来了，如果遇到你的应用架构需要使用消息中间件的场景，那么这个消息中间件能否通过PaaS平台自动部署下去，通过部署下去后也能够动态扩展和配置。如果不能，你就需要申请虚拟机资源安装消息中间件。也就是说在这个时候你又接触到了资源层的能力，没有做到绝对意义上的将对资源的使用转为对服务的申请和使用。

因此你需要PaaS云平台提供消息中间件技术服务能力，而不是你去申请资源安装中间件，这就是类似消息，缓存，安全，日志，运维监控等各种能力为何也需要PaaS化的关键原因。

公有云和私有云之间关于平台层的分歧

对于公有云厂商可以看到，实际很少提供前面谈到的类似4A平台，组织引擎，流程平台等技术服务能力。因为公有云厂商认为这个不是技术平台，而是更类似于业务平台。但是在企业信息化应用开发构建中，这些又是关键的基础平台，这些平台能力被上层多个应用使用，属于共性能力，需要共同建设。

因此私有云PaaS构建一定涉及到类似4A，流程引擎，报表，自定义表单，API接口集成，ETL数据集成等共性能力。这些共性能力虽然不涉及到具体的业务功能实现，但是确实业务快速构建的基础能力。

其次，对微服务模块，公有云提供的是CI/CD能力，应用自动化部署和托管能力，但是对于究竟几个微服务模块组成一个完整的应用，这些微服务间存在哪些集成和协同关系，公有云PaaS平台并不关心，同时公有云PaaS平台从主观意识上认为是各个微服务间并不会发生复杂的集成和交互。而实际情况却是对于企业应用开发，更加关注从应用-》微服务间的层级关系，关注的是整个应用的部署和交付，关注微服务间的集成接口关系等。

当这些分歧没有逐个解决的时候，要将企业内部的应用构建全部迁移上云并不容易，或者说即使仓促迁移上云，那么后续在应用模块集成和微服务治理管控上也会出现大量问题。

欢迎关注 @人月聊IT 分享数字化转型，企业架构规划，云原生，思维和个人成长类文章。个人公众号 何明璐，可以搜索关注，文章每周一，三，五定期更新。