微服务架构转型-中台构建

Posted 2021-04-14 远见先行

企业在进行微服务架构转型的时候，一定不是把原来遗留IT系统全部抛弃后而全部基于微服务架构重新构建新的业务系统，因此转型过程中我们更加需要考虑遗留架构下中台如何演进，或者说企业在基础的ERP，MES，CRM，供应链等业务系统都存在的情况下，中台如何演进。

思路1：以服务组件和服务能力开放思路来构建中台

如果原来的业务系统已经存在同时又不希望对已有的系统进行大的改造和变更，那么在这种情况下中台构建的一个思路就是构建一个服务平台，或者我们常说的OpenAPI能力开放平台。这个平台的重点是服务组件，而不是业务组件，服务组件本身并不太承载业务规则和逻辑的实现。

也就是说把服务组件的实现，API接口服务的开发和暴露从原有的业务系统中单独拿出来进行构建，这里的服务组件既可以是数据服务组件，也可以是业务服务组件，同时还可以在中台进行服务的组合，形成组合服务组件，然后再有服务组件暴露API接口开放出去。

如果业务服务组件那么可以路由回已有的业务系统，如果是数据服务组件则可以直接访问业务系统的后台数据库来进行数据服务能力的实现。在服务组件层，我们仍然可以按照业务域，或者按照数据分类对服务组件进行划分，比如订单中心，库存中心，供应商中心，产品中心等，但是这些服务组件本身没有业务规则的实现，更多仅仅是服务能力的暴露。

也就是说我们对传统的业务系统进行横切，在数据库或逻辑层上增加了一个服务层，这个服务层是所有业务系统共同的业务服务能力层，提供和暴露服务能力。这种服务能力的暴露可以用来构建新的业务系统需要。而对于传统已有的业务系统本身可以不做任何改动。这样至少可以保证新业务系统的构建灵活和解耦。

思路2：基础共性数据能力下沉思路来构建中台

简单来说就是将基础主数据能力，大范围共享数据从原有的业务系统中剥离出来，将这些剥离的内容单独构建为一个个独立的微服务模块。这些微服务模块的重点是提供和暴露各类共享数据服务能力。比如我们可以将供应商管理内容从采购系统中剥离出来，单独建设一个供应商中心，然后将供应商的查询，变更等能力暴露出去，单独供其它业务系统使用。

由于这种思路更多的都是基础和共性数据能力的下沉和剥离，类似传统IT架构中MDM主数据平台的建设，因此相对来说对业务系统的影响较小，也容易进行剥离和单点构建。同时这类微服务模块本身没有太复杂的业务规则和逻辑需要实现，相对来说更加容易实施和集成。

在思路1和思路2两种方式进行中台构建的时候，API服务的暴露最好都是以查询服务能力为主，这样可以最小化的对原有的业务系统和数据库逻辑造成影响。简单来说，如果一个遗留业务系统后续更多的是提供查询能力给其它业务系统使用，那么ESB集成商在了解数据库结构后，也完全有能力来构建完成的中台服务层。在前面我有一篇文章专门讲到过，ESB集成商本身两个发展方向，一个是产品化的纯技术平台，一个是能够提供标准化和模块化服务资产的厚服务平台。

思路3：遗留业务系统进行前后端分离和组件拆分改造

相对前两个来说，这个思路是工作量和改造难度都最大的一个思路。比如原来的一个采购管理系统，需要全面进行微服务架构改造，由原来的单体应用改造为供应商管理，物料管理，采购需求，采购订单，采购执行，采购绩效评估，采购基础数据等微服务模块。

那么这种改造就相对困难，首先就是原有的业务系统要进行完成的垂直拆分，即单体应用从数据库到逻辑层再到前端展现都需要纵向独立的拆分松耦合的微服务模块。其次是单个微服务模块本身我们也希望将前端和后端之间进行分离，中间插入一个关键的服务层解耦。

在这种改造模式下，各个微服务模块需要涉及到和外部其它业务系统相互协同的就可以独立构建为独立的各个中心，比如供应商中心，物料中心，采购订单中心等。这些中心就会纳入到中台进行统一管理和能力开放。即各个纳入到中台的中心既满足了采购本身的业务流程和业务需求，同时又能够发布为API接口服务，供外网的其它业务系统访问和调用。