微服务架构-中台和服务代理

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

在原来的多篇文章中，实际上我提出的思路都是会涉及到对已有系统进行重构，这个一方面是底层数据库的重构，也包括上层的微服务模块化和接口服务化重构，但是这种重构本身一定会对业务系统造成一定的影响。而今天这篇文章谈的重点就是，我们将微服务架构思路应用到我们新的业务应用构建中，对于老系统先保留现状，而在新业务应用构建过程中一定涉及到需要使用已有业务系统的业务能力和数据能力提供。

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

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

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

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

这种思路重点就是首先考虑中台能力的微服务模块化，同时将已有业务系统的逻辑层能力进行迁移，然后最终转化为API能力接口朝上层暴露。这些能力接口可以用于构建新的业务应用使用。比如我们说的，当构建一个新的业务应用的时候，如果传统方式下面需要和底层的PMS，SCM，ERP，EAM等多个业务系统打交道和协同，而新的业务应用构建模式就变成了，只需要和中台的API网关暴露的服务接口打交道即可。

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

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

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

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

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

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！