谈基于平台+应用思想下的企业微服务架构转型

今天准备再详细讲解下传统企业微服务架构转型，在中台概念没有出来之前，我们在构建企业内部私有云PaaS平台的时候，已经提出了平台+应用的构建思想。而这个思想在当前中台，微服务架构下仍然适用。

对于企业IT架构转型，实际上我们也看到存在平台+应用全新构建模式，也存在最大化保留IT当前遗留资产进行平滑迁移和适配模式。因此今天重点会对这几种模式进行详细介绍。

基于平台+应用的企业私有云PaaS平台建设核心指导思想对于企业私有云平台建设主要还是围绕通过私有云建设后最大化资源利用率，降低能耗和硬件采购成本，实现数据中心的集中管控和运维，促进企业内部信息化部门的服务化转型等。云计算本身具备的技术特点和优势，由于企业对信息化资产和安全的管控需求，企业信息化应用本身业务规则，逻辑和一致性的高要求等，往往很难真正迁移到当前的公有云平台，这也是诸多大型企业都开始独立建立自己的私有云数据中心和云平台的原因。

目前，很多企业的内部私有云平台建设仅仅还是在解决IaaS层和虚拟化资源池的问题，而这远远没有达到私有云建设的核心业务目标和核心价值所在。因此在启动企业内部私有云PaaS平台建设时，需要进一步明确平台建设的核心指导思想。

集中和系统化

既然私有云谈集中化，那么大系统观就显得更加重要，在大系统观下企业内部的IT建设和业务系统最终就是一个大系统，其他的仅仅是业务模块和组件单元。在企业私有云PaaS平台建设下将彻底打破原有的企业信息化建设中业务系统竖井式的建设模式，真正转变为基于SOA服务化思想下的平台（技术中台）+应用构建模式。

在业务系统组件化后，原有的业务系统边界将被彻底打破，整个企业的信息化系统将转变成为一个平台能力支撑下的多个微服务（业务组件）构成的大系统。在大系统建设模式下涉及到两个方面的整合，一个是向底层的资源池整合和平台化，一个是最顶层的云门户化集成，而大系统中剩余的就是各个业务组件单元。

大系统建设要解决的核心问题就是资源的复用问题和资源的水平调度和扩展问题。

传统的企业信息化建设模式很难真正地按大系统观的思想来规划和建设，大系统建设模式首先要解决企业架构中的业务架构和数据架构问题，然后才是应用架构和技术架构问题。只有按企业架构业务驱动IT思想，分层和组件化的思想才可能真正的理解大系统的概念，分层和分模块地进行建设。

如果引入了企业私有云，我们的信息化建设还是传统的各个业务系统独立建设，后续再考虑协同的模式，那么私有云本身还是停留在技术优势上面，很难真正体现业务价值。

平台和分层化

当我们在谈PaaS（平台即服务）的时候，但是很多时候我们的理解却是它是一个可托管的云端运行平台，可能也包括了在线开发平台，测试平台。但是我们一定要注意到私有云里面的平台不仅仅是解决平台的云化问题，更加重要的是需要解决微服务本身基于SOA组件化思想设计、基于平台搭建和集成问题。

技术平台真正的是可以做到标准化开发方法和开发模式，提升开发效率，将私有云PaaS平台对应用的约束完全固化到开发框架和平台中。平台化一方面解决标准化问题，同时解决可复用问题，还进一步解决前端应用和产品的可配置问题。

在引入了私有云和云本身的分层架构概念后，结合传统的企业应用架构，特别是服务化的分层架构，需要重新对企业私有云下的分层架构进行整合。

即在整个私有云PaaS平台体系下分为资源，服务和应用三个层面。其中资源层既包括了IaaS层物理基础设施，也包括了私有云PaaS技术平台，而应用则包括了各个松耦合的业务组件模块和顶层云门户集成。在平台和应用层之间是服务层构建，通过标准化的SOA参考架构体系，真正实现了平台层服务能力和应用层功能构建之间的解耦。

集成和协同化

这个是大型企业信息化规划建设的一个核心内容，不管是否引入企业私有云都需要考虑集成方面的问题。在引入私有云后传统的企业业务系统间的集成转换为业务组件或模块间的集成，同时在进一步强化分层架构思想后，引入了多层之间的纵向服务集成。

对于集成主要包括两个方面的内容：

首先是数据的集成和数据的融合，这里面涉及到主数据和共享数据中心的建设问题，核心目标就是解决共享数据只有一套，有唯一的源头的创建更新机制，数据以共享数据服务的方式将能力发布出去，供其它业务组件使用。这个和传统数据交换和集成有很大的区别，即在于数据本身不会落地到各个业务系统形成多份数据拷贝，而是按需实时访问和使用。

其次是业务的集成和协同，要完成一个端到端的业务流程和业务协同，最终将转换为业务组件间的服务交互和协同问题，那么核心问题就转变为了业务组件如何划分最合理，最能够保证业务组件之间的内聚性，真正能够实现业务组件的彻底解耦问题。

私有云建设完成后，组件化资源池里面有大量的业务组件，这些业务组件提供业务服务，如果这些业务组件不能很好通过业务服务协同起来完成最终的业务目标，那么资源池化和共享的价值发挥不出来。

对于企业私有云PaaS平台规划和设计可进一步参考：

SOA和云计算-企业私有云PaaS平台建设实践

微服务架构-企业全新构建模式本部分谈下一个企业全新构建IT系统和应用，没有遗留系统负担的情况下，如何基于微服务架构思想进行规划和建设。

谈微服务架构思想实际上是包含了平台+应用思想，业务组件化服务化思想，SOA和云思想，包括当前主流的DevOps思想的一个融合，而不仅仅是简单的微服务架构。因此对于一个新创建的企业要基于微服务架构思想来整体规划内部IT并不是一件容易的事情。

首先我们对整体规划建设进行拆分，主要应该包括以下关键的建设任务和内容。

底层私有云平台建设，这个即考虑全部基于IaaS资源池进行并尽量去IOE架构，当前实际上对于涉及到数据库仍然或涉及到部分的Oracle数据库和集中存储，企业在选型和规划的时候要考虑本身去掉这部分潜在风险。服务器资源可以考虑全部采用X86服务器并进行虚拟化，提供虚拟机资源作为计算能力。

容器云PaaS平台建设，对于PaaS平台建设当前可以基于轻量的Docker容器进行，并通过Kubernates进行资源管理和动态调度。而如果规划建设DevOps支撑平台，即在DevOps平台建设过程中统一建设容器化PaaS平台，当然在DevOps平台中会进一步实现了持续集成和流水线作业能力，实现开发，运行和后期运维监控的一体化管理。通过实施DevOps平台可以进一步对当前的开发团队规划，岗位角色分工，软件过程改进等进一步优化。

在微服务架构实施中，还有一个重点就是制定微服务架构开发框架，标准和规范体系。以指导后续开发厂商按照统一的标准方法，工具和流程进行微服务组件模块和接口服务的开发，确保开发标准和规范一致性，也进一步确保了后续多个微服务模块在集成的时候不会出现问题。

把这些都谈后，再转回谈需要统一建设的技术平台部分。

4A平台，这个是必须建设的内容，不仅仅是实现统一用户，统一认证和鉴权，统一组织，统一审计等内容。在微服务架构下，4A平台进一步扩展传统业务系统中系统管理模块的内容，即能够实现到微服务模块内部的功能菜单和按钮级的操作授权，同时能够实现灵活定义的数据级授权和配置。

公共流程平台，这个公共流程平台也是必须，实现统一的类似内部多租户的流程引擎，实现流程的设计建模，运行，监控的全部统一化。各个业务组件模块仅仅是使用流程平台提供的能力。

技术服务平台，这个实际涉及到消息，缓存，文件，任务，日志，通知，分布式存储等诸多技术服务能力，可以根据企业需要来确定哪些要单独实现为独立的技术服务能力开放提供。这个没有明确的要求，但是根据实际项目实践来看，类似发送短信邮件的通知类服务，文件存储类服务往往都是必须要规划建设的。

监控运维平台，这个平台实际上包括了传统的IT网管监控，同时还包括了当前的APM业务性能监控两个方面的内容。同时两者内容本身又相互集成和融合。由于采用了容器化PaaS，实际上微服务开发商对底层资源的情况并不清楚，因此更加需要这样一个监控运维平台能够同时监控到业务性能和资源层性能，并实时预警。

除了技术平台外，再来看下业务中台部分可以规划建设哪些内容。

主数据平台建设，基于当前企业信息化规划建设实施，对于业务中台部分能够统一考虑的只有基础主数据部分内容，因为这部分是共性基础数据服务提供能力。当然基于微服务架构模式下，实际上也没有独立的主数据平台概念，实际上应该只有类似供应商，产品，客户等微服务模块。

中间即是满足各个业务能力实现的微服务模块应用，相互独立自治，松耦合。微服务模块间通过轻量的Http API即可进行交互和协同。当然在这个过程中涉及到微服务网关的使用等。

最上层规划统一门户平台，门户平台重点就是实现业务功能在应用层的简单组装和配置，类似App Store商店一样，最终的业务用户可以根据自己的需求安装相关的业务系统应用。即门户具备足够的灵活定制能力。同时对于DevOps平台最好和前端门户结合，即通过DevOps平台发布和部署的微服务可以直接发布到最终的门户应用上面。

平滑迁移和接口能力适配模式图片传统企业转型微服务架构，实际上我们思考最多的就是如何进行平滑迁移和逐步过渡，如何在转向微服务架构的过程中对已有的遗留业务系统影响最小，并对已有的遗留系统逐步进行平滑迁移。

在原来的多篇文章中，实际上我提出的思路都是会涉及到对已有系统进行重构，这个一方面是底层数据库的重构，也包括上层的微服务模块化和接口服务化重构，但是这种重构本身一定会对业务系统造成一定的影响。

而今天这篇文章谈的重点就是，我们将微服务架构思路应用到我们新的业务应用构建中，对于老系统先保留现状，而在新业务应用构建过程中一定涉及到需要使用已有业务系统的业务能力和数据能力提供。

为了达到这点，提出不碰触已有业务系统逻辑层实现，全新建设中台各个微服务模块中心的思路，在建立这些中心的时候可以先不用去触碰底层的数据库，而是基于已有的数据库来构建上层的各个中心。

各个中心就是我们说的业务或数据能力提供中心，各个中心完全微服务模块化，内部也包含业务规则和逻辑的实现，这部分和已有业务系统的逻辑层部分内容是重复的，但是不要紧。可以理解为已有业务系统的逻辑层逻辑在重新梳理和解耦后，迁移到新的中台层的各个微服务中心中。

各个微服务中心直接和已有业务系统的底层数据库打交道，而不是和已有业务系统提供的WS服务或逻辑层API打交道，这样做的目的是尽量减少多层WS服务调用带来的分布式事务处理问题。

在构建微服务中心的时候，这个时候就不再是单纯的原子服务提供，也包括了组合服务能力提供，即各个微服务中心能够提供领域层服务能力。这个组合服务在实现的时候可能需要访问底层多个数据库，但是对于前端应用来说并不关系，对于底层实现逻辑对上层透明。

这种思路重点就是首先考虑中台能力的微服务模块化，同时将已有业务系统的逻辑层能力进行迁移，然后最终转化为API能力接口朝上层暴露。这些能力接口可以用于构建新的业务应用使用。

比如我们说的，当构建一个新的业务应用的时候，如果传统方式下面需要和底层的PMS，SCM，ERP，EAM等多个业务系统打交道和协同，而新的业务应用构建模式就变成了，只需要和中台的API网关暴露的服务接口打交道即可。

而中台各个模块的API接口能力的实现本身是包含了业务规则的，包含了能力组合的，这些不是单纯的代理回原来的业务系统逻辑层，而是重新实现了一遍，是原有业务系统逻辑层能力的迁移。这种迁移虽然导致业务规则逻辑有两套，但是也为传统业务系统最终的微服务化打下了坚实的基础。

即提供API能力的中台服务层构建完成后，可以看到对传统的业务系统进行重构也很简单的了。即传统的业务系统原有的逻辑层能力大部分已经完成了迁移，我们需要做的仅仅是对前端展现层和能力组合协同部分进行重构和迁移即可。

其次我们看到这种方式下，在数据库后续进一步拆分情况下，我们提供的服务接口本身是不需要进行变更的，即上层的业务应用不需要变更，这个时候只需要对服务实现逻辑进行调整接口。这种解耦本身是相对有必要，原因就是我们在传统架构朝微服务架构转移的时候，并不一定一开始就要考虑数据库层的垂直拆分。

中台服务的提供我们希望是要将原来业务系统核心的业务能力重新抽取出来，因此涉及到要定制开发服务接口来暴露这些业务服务能力，而且最好的方式就是只依赖于原有业务系统的数据库，而对业务系统原来业务逻辑层已有的业务逻辑能力等进行重写。只有这样才能够真正形成后期完全可以复用的业务能力中台。

所有中台的各个中心都按微服务架构模式单独设计实现，单独补充并提供接口能力，最终API接口统一注册到API网关朝上层或外部统一提供。也就是说各个中心之间本身松耦合，同时各个微服务中心和已有的各个遗留业务系统之间本身也是一种松耦合的关系。

在这种方式下的缺点即是业务逻辑和能力实现往往有两套，在迁移过程中出现的变更需要两处同时修改。

中台接口能力适配的三种方式

图片如上面图所示，在构建新的中台能力服务层的时候，为了对已有的业务系统影响最小，我们需要重新构建中台能力接口，这个接口涉及到一定的适配和定制开发工作量。具体接口的实现本身又包括了三种方式，这个在前面一篇博客文章也谈到过，即：

直接连接遗留系统的数据库，来重新开发接口服务。通过遗留系统已有的JAR包引入，来重新开发接口服务。通过遗留系统已有的WS或Rest等接口服务适配，来重新开发接口服务。可以看到三种模式中对于数据库这种模式是对业务系统依赖最小的模式，但是这个模式本身也是需要我们重新进行大量的完整性校验，业务规则的模式。这种模式本身就可以看到对遗留业务系统的部分业务规则和能力进行了重写，即这部分业务逻辑规则已经在朝中台能力层逐步迁移。

这种迁移形成的接口服务能力，一方面是构建全新的业务应用可以使用。而同时，我们建议是及时对于PMS或SCM等业务系统，如果有全新的业务模块需要开发，也完全可以基于中台已有的接口服务能力进行，只有这样才容易实现后续的业务系统逐步迁移到中台架构上。

数据重构和服务组合是中台另外一个关键能力

图片对于服务组合和轻量服务编排可以先参考我的另外一篇文章

从ESB服务组合编排到NetflixConductor微服务编排

在中台能力构建的时候，一定要考虑数据重构和能力组合，即中台的能力接口不是简单的数据库CRUD能力暴露，也不是已有的遗留接口的简单适配和代理接入。而是真正根据业务流程和业务需求驱动，识别关键的业务能力，将业务能力转变为服务。这种服务本身是粗粒度的，有明确的业务含义，有点类似我们在领域架构设计里面经常谈到的领域服务能力。

领域服务本身统一，有提供领域数据对象的数据类服务，也有提供业务逻辑和规则处理的业务类服务，这些都是领域服务能力。在前期中台构建的时候我们看到数据类服务相对容易构建，但是业务类服务本身较难，因为遗留系统已经实现的业务处理规则和逻辑在代码里面，如果我们用数据库适配模式很容易遗漏已有的业务规则实现。

因此在前期中台服务能力构建的时候，建议还是先以查询能力服务能力开放为主来构建。当然我们也可以提供一些基础的领域对象导入服务能力，这种导入服务提供一些基础的数据完整性校验能力，形成业务系统的单据草稿。而实际的业务单据规则处理和流程仍然还是在遗留业务系统中。

服务组合是中台存在的另外一个关键价值，即我们可以根据业务需求一次返回组合后的领域对象数据，这个领域对象可以是多层结构，可以一次返回。这个领域对象也可能是涉及到多个数据库表之间的关联。如果多个数据库表是跨物理数据库的。我们可以

在中台能力实现的时候，调用多次底层原子服务返回多个数据集对象。在中台实现的时候对多个数据集对象进行数据组合，并返回组合后的领域对象。中台层对接口服务进行标准化和规范化

中台层在接口服务实现的时候，最好在适配的过程中对对接口服务进行标准化和规范化，即提供标准的WS或Rest接口服务能力，服务预先制定的服务契约或规范要求，同时符合日志审计，安全管控要求。

中台层的标准WS接口服务最后统一注册和接入到API网关，这样API网关本身能够更加轻量，不需要做太多的适配，数据映射，转换等工作。而重点是实现服务代理和统一服务目录提供，负载均衡，日志审计，安全能力，流量控制能力即可。

即这种模式类似于构建了一个厚中台+轻API网关的模式。

中台能力最终暴露-从API网关到能力开放平台图片通过API网关将中台能力接口对外统一提供和管理

对于企业的中台能力服务层，如果是新规划建设，完全可以采用微服务架构和容器化技术进行建设。其中我们可以进行中台各个中心的规划，对于每个中台中心就是一个独立的微服务模块，可以进行完全独立自治的设计开发和后期运维管理。

每个微服务模块进行独立部署，可以与容器云平台结合，通过容器资源池来实现计算节点的动态扩展能力。同时对于动态扩展的计算节点在上层进行负载均衡，提供统一的IP地址出口。该层的负载均衡能力需要和容器资源池动态扩展自动结合，因此需要实现微服务框架和容器平台Kubernates资源调度层的融合能力。

在类似用户中心，项目中心，订单中心等原子服务中心上层，还需要构建领域组合服务中心，实现原子服务的能力组合。该组合能力提供需要调用原子中心的各个原子服务能力。

由于组合服务本身存在分布式事务的问题，因此需要考虑对于前期组合类服务的提供，最好以查询组合类服务接口为主，对于查询类组合服务出现服务异常一般不存在具体回退的问题。

中台各个服务中心将其负载均衡后的服务地址再次接入到上层的API服务网关中，通过API网关提供统一的服务目录，同时通过API网关来实现安全，日志，流量控制，服务代理等关键能力。对于API网关的详细介绍和说明，可以参考我发布的上篇文章。

一文详细讲解API网关核心功能和API管理扩展

由于当前中台服务能力中心的构建以代理适配模式为主，即数据源头仍然是已有的遗留系统的各个数据库，因此对于中台能力中心实际上不需要有自己的Ower数据库，仅仅是业务逻辑层的服务部署包。除非出现传统业务系统所有业务功能迁移到中台的情况，才涉及到需要重新规划中台模块对应的数据库。

在中台能力服务层构建的时候，可以采用远行提供的DevOps支撑平台，该支撑平台提供对容器化资源池，部署流水线，微服务架构，API服务网关等整体打包解决能力。可以进一步实现中台能力层的快速开发和交付上线。对于远行DevOps支撑平台的介绍可以参考我博客前面发过的文章。

从API网关到能力开放平台

图片首先对于能力开放平台我在前面的思考里面做了一件重要的事情，就是将能力引擎和能力运营两者分开，能力引擎即我们常说的能力聚合网关，ESB服务总线，API网关等。可以看到能力开放平台构建你可以选择任何一个能力引擎都没有关系，只要能力引擎能够满足标准的能力注册接入，能力基础管控（安全，日志，流控）即可。

在能力引擎剥离后，最重要的就是能力运营平台。

在我们没有谈能力开放平台的时候，我们会在能力引擎上方增加一个能力管控平台。而能力管控平台主要做两个方面的事情，一个是实现API接口服务的全生命周期管理，一个是实现接口运行后期的运行监控治理。因此对于能力引擎上方，我们可以考虑拆分为三方面内容

能力开发中心：面向开发者，帮助开发者快速进行能力接入和消费能力运营中心：将能力服务作为商品去卖，因此涉及到服务订购签约，计费等关键功能能力运维中心：实际上包括运维中心和运行监控中心两个方面的内容。而在这之上即是我们常说的门户层，实际的门户也应该包括了运营门户，开发者门户，合作伙伴门户。这里要注意的是门户层更多的是集成和聚合了底层各个业务模块的功能，只是区分业务场景和角色进行聚合。

图片具体的能力开放平台内容应该包括如下几个方面：

开发接入平台

能力开放平台是构建一个大生态体系，那么对于API接口服务能力的提供不仅仅需要依靠自有能力，更加重要的就是要依赖于开发商和合作伙伴的可共享能力接入。那么就必须为开发商提供一整套方便他们进行API快速开发，快速接入的平台，工具，标准规范流程，以方便他们进行API接入，同时尽量实现API接口服务接入中的自服务过程。

具体来说开发接入平台可以提供API的快速开发工具或开发环境，API开发框架，API开发指南和示例参考，API开发流程，API开发规范，API接口测试方法，API接口服务开发接入流程指南等。所有这些目的就是要让接入的API遵循一套标准的方法和流程，同时让开发商能够快速理解和学习掌握，方便API快速接入。

能力平台（能力库+服务目录）

这里的能力平台更多是能力引擎平台，实际上就是应该是ESB总线引擎，API网关或其他API接口服务集成平台。该引擎重点就是实现API接口的注册接入，API的服务代理和统一服务目录提供，API的安全，日志，流控，监控等各种拦截能力。能力平台简单来说就是要形成标准的API接口服务能力目录并向上提供。

在原来我们谈能力平台的时候往往会将能力引擎和上层的能力运营平台进行整合，形成一个完整的大平台系统，而这次在思考的时候进行拆分，拆分的目的就是实现底层引擎和上层能力运营平台的解耦。即上层的能力运营平台实际上可以兼容和适配底层多种能力引擎，这样更加方便进行组合。

运行监控平台(对API接口服务的运行监控）

运行监控平台即要实现对API接口服务的运行监控，性能分析，异常问题的实时告警和预警，接口服务运行的统计分析等。同时对于运行监控平台还需要基于最基本的原子服务监控层面进行延展，即向下还涉及到具体的中间件，数据库的资源监控，向上还涉及到服务链，端到端业务流程的监控。即：

资源监控：服务器层面，中间件层面（包括数据库，应用服务器中间件），JVM监控服务监控：最基本的原子服务监控能力，服务运行监控，也包括服务链监控能力，APM监控流程监控：实现端到端业务流程的监控，而最终的流程监控可以通过服务链监控进行串联运营管理平台

运营管理平台是整个能力开放平台中关键的生态应用，即我们涉及到的平台提供商，运营商，开发商，服务和内容提供商，运营商等最终都会使用运营管理平台，通过运营管理平台实现最终服务的整合。

运营管理平台在前面自己已经谈过多次，实际上底层可以参考电商平台的原型，而里面最重要的就是服务受理和订购中心，产品或服务配置中心，服务开通，服务计量和计费中心，客户中心几个关键模块。最终解决的问题就是让我们开放和接入的API服务接口能够最终配置为可以销售和运营的产品，并进行计费。

营销平台

大部分在构建能力开放平台的时候往往不会涉及到营销平台，但是类似典型运营商的BSS域就一定会有营销中心和本地化的服务网厅，而这些网厅的服务人员就需要一个营销平台为用户提供各种服务能力。在我们谈物联网云平台的时候也谈到过，在构建智慧家庭的完整生态平台的时候，往往还涉及到我们的产品服务地推，这些也涉及到需要有相应的平台和应用进行支撑。

运维平台

运维平台属于后生命周期，即在产品服务订购后，需要对服务消费中的问题进行处理和解决，并提供相应的售后服务能力，因此这块实际上需要有一个面向最终客户的运维管理平台和运费服务平台来进行支撑。

自服务平台(开发商门户，合作伙伴门户等）

自服务平台面向最终提供给用户的功能聚合，并实现客户的自服务能力。因此自服务平台本身又是一个面向用户角色的功能聚合平台。可以看到对于前面谈到的服务接入，能力共享运营，运维服务，服务运行监控等各个子平台都需要向最终的用户提供功能服务，而自服务平台则是这些功能服务能力面向用户的聚合，而不是全新构建的新功能。