企业微服务架构转型-实施步骤

在前面的文章中已经谈到过微服务架构转型中的实施策略，今天重点谈下微服务架构转型中的实施步骤。

步骤1:4A和流程平台的下沉和能力开放

在实施微服务架构转型的时候必须将4A（也可先狭义理解为原业务系统的系统管理模块）和流程引擎下沉到平台层共性建设，或者说优先要将这两个模块做为微服务模块剥离出来，同时给上层的业务组件模块提供API服务接口能力。

对于4A模块剥离后，我们希望的是涉及到人员，组织，用户，权限等能力的获取都是通过服务接口实时查询获取，这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易，最主要的还是给业务模块提供流程启动，暂停，获取待办已办列表等关系服务接口信息为主。

进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能，而不再包含共性的技术能力功能。

步骤2：基础主数据模块能力独立建设

将提供共享基础主数据的功能单独剥离出来进行独立建设，比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用，同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地，实时用实时查。

在传统PaaS平台建设中会涉及到MDM主数据平台的建设，到了彻底的微服务架构可能并不存在主数据平台的概念，而是各个类似产品中心，供应商中心，客户中心的各个微主数据中心模块，这些微服务模块也是我们常说的中台的核心数据能力提供中心。

要规划和建设中台，首先要考虑的就是这种基础数据中心，其次才是提供业务支撑和业务逻辑处理的中心。

步骤3：业务模块的拆分到微服务模块或逐步剥离出来

传统企业的微服务架构转型是一个渐进的过程，是一个老的IT架构逐渐被新架构替换，老架构逐步消亡的过程。在步骤1和步骤2这种共性的基础技术和数据能力下沉后，剩余的业务系统迁移和微服务模块拆分就可以开始逐步进行，逐步签出。

对于一个业务系统的业务模块逐步剥离出来，一个关键的策略就是优先剥离耦合性最低的业务功能模块，在这个思路下最可能的实施策略就是先将业务系统支持流程的两端（最前端流程或最后端流程）逐步剥离出来。因为两端的流程往往是耦合性最小的流程。

拿采购系统来举例，前端的招投标模块是最容易剥离出来的，后端的采购过程跟踪，采购评估等模块往往也是最容易剥离出来的。这里拿招投标模块来举例。

注意招投标模块在剥离出来后，横向的交互接口往往并不多，最多也就是招投标执行过程的结果信息或配额信息需要传递到采购管理模块。而对于招投标本身的一些结果数据已经可以下沉到平台层的主数据模块中，而设计到流程处理部分也已经下沉到平台层的流程引擎模块，因此可以看到只要步骤1和2迁移到平台层后，再迁移出招投标模块基本就很容易了。

步骤4：及早的进行统一门户的建设

特别注意，在各个微服务模块建设完成后，单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关系是否进行了微服务架构化，而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。

而这些业务模块基于业务流程，基于业务场景和使用部门的组装和展现，就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录，也还包括了统一的待办集成和任务处理，统一的消息通知等共性功能能力。也就是说，只要是各个微服务模块共性的一些需要展现的能力，都可以集中化到统一门户层去集中处理和展现。

门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。

对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难，对于这个问题后续将在单独进行讨论。