传统遗留单体系统的微服务架构改造思路和方法

Hello,大家好,我是人月聊IT。

最近,许多粉丝问我关于微服务架构改造的问题。所以,今天我专门录制一期视频,谈谈如何对传统的单体架构进行微服务改造。由于我参与过许多微服务项目,包括逐步改造和迁移遗留单体系统的项目,所以见证了各种各样的改造和迁移方式方法。我简单归类为两大类,四小类。

首先,第一个大类是不拆分。有些项目在进行微服务改造时,实际上并未进行微服务拆分,仅采用像Spring Cloud这样的微服务开发框架和前后端分离。严格意义上,这不是微服务,因为微服务的核心是拆分大的单体结构为小的独立微服务模块。有时,由于其单体结构未进行拆分,它甚至可能没有完全采用微服务开发框架,仅使用Spring Boot开发微服务和外部API网关。这是常见的第一种情况。

第二种情况是进行微服务拆分。严格意义上的微服务拆分要达到完全独立和自治,不仅拆分应用逻辑层,还要完整拆分前端、后端和数据库。

1.数据库的拆分

在拆分过程中,首先要考虑是否拆分数据库。许多项目在进行微服务改造时实际上并未拆分数据库,仅拆分上层应用,这严格意义上不是微服务架构。但是,考虑到项目实际情况,我更推荐这种模式,因为数据库拆分会导致应用层代码发生较大改动。

原单体系统拆分为多个微服务后,如原来的供应链系统包含招标、采购和库存模块,就需要建三个库,必然会出现跨库更新场景。例如,订单保存时要冻结库存,这可能需要调用API接口实现,变成分布式事务问题,而不是原来的数据库事务就能解决。

此外,数据库拆分后,原来通过数据库多表连接解决的问题也会变得复杂,可能需要多次调用API接口,然后在应用层组合和组装返回数据。所以,这些改动会导致应用层代码较大改动。

2.应用逻辑层的拆分

第二,原有应用逻辑层拆分。常犯的错误是拆分得太细,如不仅拆分供应链系统的招标、采购合同、框架协议、采购订单和库存模块,还将供应商物料拆分,导致微服务接口集成异常复杂。

所以,我一直强调应粗粒度拆分应用逻辑层,按领域架构和领域驱动建模思路,不要按具体事件聚合根拆分,而应按业务子域拆分。还是拿供应链系统举例,我认为拆分招标、财务管理和库存模块太细,最好的方式是单独拆分共性基础数据,尽量不拆分核心业务流程的各个阶段和流程,拆分核心流程结束后相关的统计分析模块。

最后是前端。在许多微服务架构实施中,前端通常不进行拆分,只有移动应用前端和传统Web前端。但是,对于企业内部应用,有的根本不是移动应用,没有移动APP,只有传统B/S端,这时推荐前端也进行相应拆分。因为如果前端未进行拆分,核心业务功能和流程在前端仍紧密耦合。

举例来说,现在要修改招标功能,招标业务逻辑微服务可以独立修改和发布,但如果涉及前端修改,整个前端源代码都要重新打包发布。那么,招标前端修改会不会影响采购管理和库存管理微服务应用?你说不清楚,还得进行大量回归测试和验证。所以,我们必须独立理解前端。前端不仅仅是拆分为移动端和Web端,还要根据传统企业IT系统实际情况考虑是否也要拆分前端。

总之,改造传统IT系统或单体系统的常见方法是:理想情况下,数据库、应用逻辑层和前端都需要进行相应拆分和改造。改造后,还需要梳理各微服务之间的横向接口,包括微服务向上层暴露的API和给前端使用的API接口。首先要梳理清这些接口,然后基于接口驱动,自上而下进行。

还有一种简单方式是变通方法,尽量不拆分数据库,拆分微服务应用逻辑层,不拆分前端。当然,究竟采用何种思路,开发团队应根据当前实际成本、效率、开发周期、改造难度等综合权衡。

总之,希望能对大家有所启发。谢谢观看,再见!