如何将现有系统逐步优化成微服务设计

news2025/1/19 17:02:00

本文诞生于学习架构实践专栏后的深思以及总结，结合公司之前“大泥球”的架构风格，改造服务设计的思维。
改造公司系统服务主要原因：1、代码类似“屎山”，牵一发而动全身，维护成本高，且迭代慢；2、业务数据均存放在一个数据库中，几百张数据表，也是在业务代码中随意Join关联表；

基础服务改造

核心思想：梳理业务功能、划分业务领域、构建微服务、逐步剥离、平滑替换；
其中需要业务团队频繁对接以及沟通成本极高，但是也是归还历史技术债，就是一个字：撸起袖子，加油干~哈哈哈
公司也是有N条业务线，具体不阐述，但是业务线之间相互独立，背后对应的是同一个数据库，如图

这种规划现状带来的问题：

业务系统功能重复建设：功能重复，也意味着多个系统中散布着相似甚至相同的数据逻辑。由于这些数据逻辑的高度耦合，对数据库表字段的任何升级处理都会影响相关业务，违反开闭原则，导致系统的整体稳定性和可维护性受到严重影响。这种情况造成了“牵一发而动全身”的局面，难以进行灵活的功能扩展和系统优化。
数据库可用性差：若存在慢查询，导致资源阻塞，严重影响系统的可用性，甚至可能导致服务不可用。这种情况不仅影响用户体验，还可能对业务造成重大损失。其次，多系统同时访问数据库，数据库的连接数也会造成不够用，连接失败；

核心步骤

准备阶段：为微服务改造做好前期的准备工作，包括圈表、收集SQL 和 SQL 拆分。
实施阶段：实际落地微服务，包括微服务开发、服务接入和数据库独立。

准备阶段

一、圈表
1.划分服务边界：
1.1:确定微服务具体包含哪些表，即服务的数据模型；
2.拆分原则：
2.1:保证既容易拆分数据库，又可以控制服务粒度，也让业务功能内聚；
2.2:符合服务边界的表，且与其他业务表关联不大；表的数量不多，保持在十几张左右；
2.3:毕竟基于现有系统改造，避免引起太多变化，减少对业务系统的影响，故先不对数据库的表结构调整，可以考虑放入后期服务升级的版本中处理；

为什么服务改造要从数据库表出发，而不是从功能入手呢？？？

从现有数据库表出发，比业务功能要清晰明了，更加直观；确定哪些表，进而大致确定服务应该具备哪些功能；
从表出发，可以保证服务包含的是完整的业务功能表结构，降低表拆分得复杂度，避免一个表的一部分字段属于A服务，而另一部分字段属于B服务的情况；

二、收集SQL

服务开发团队负责提供一个标准化的 Excel 模板，各业务系统开发团队负责收集具体的 SQL;分配职责，确定人员的工作边界，不然会产生中台服务接口功能定义不清晰的问题。
模板应包括以下字段：
SQL 语句：具体的 SQL 查询语句。
业务场景：SQL 语句所对应的业务场景说明。
访问频率：SQL 语句的访问频率（高、中、低）。
表名：涉及的数据库表名。
针对以上SQL 语句封装成服务接口，提供给业务系统使用；

三、拆分SQL

因为收集的SQL语言不可能仅限于当前服务的数据库，也会产生于其他服务的数据库产生关联；故需要要求各个业务团队先进行拆分，保证最后提供给服务开发团队的 SQL，只包含访问当前服务数据库的相关表;
通过SQL拆分，保证历史系统拆分新服务时，与其他数据库表的直接联系，降低耦合关系；
其次，SQL拆分，一定会涉及各个业务系统的改造，故也需要各个业务团队的配合和支撑；
最后，等待新微服务构建完成后，业务系统接入微服务，则完成现有SQL的替换；

实施阶段

四、构建微服务

主要包括接口设计、代码开发、功能测试等步骤；
依据梳理的SQL，对接口做一定的通用化设计，避免为每个 SQL定制一个单独的接口，以此保证服务的复用能力。
第一版的服务主要是做好接口设计，聚焦业务功能，以保证服务能够落地，业务系统能够顺利对接为目标。
持续迭代服务，内部做技术性优化，保证对外提供的服务接口不变；

五、接入微服务

经过功能和性能验证后，业务系统可以直接接入新服务接口；
由各个业务开发团队逐步接入，替换原来的 SQL 语句；
接入新服务的难度不大，但需要耗费比较多的时间，故需要公司各个层次的人员相互配合与支撑；

六、数据库独立

当服务接入完成，所有的 SQL 语句都被替换后，业务系统是通过服务来访问数据库的；
将原业务系统的数据相关表迁移到新服务对应的独立水库；将原来的直连数据，演变为通过新服务访问数据库；
服务和数据库独立，从物理层面，切断业务团队对这些表的依赖，也是趋向企业数字化改革的一步；
要避免业务系统还有遗漏的 SQL 语句，避免它们还在直接访问库存的表。我们可以在迁库前，通过代码扫描做好相应的检查工作。

基础服务设计

上part了解到如何将服务逐步改造成微服务，那么如何打造一个合理的微服务呢？？？请看下文
关于基础服务设计的核心思想，也需要保证业务上的复用性，故需要把各个基础服务封装成高度复用的共享服务。
首先要明确一个思想：技术的核心价值是为业务服务，故开发中我们除了技术之外的事情，就是了解、学习、分析业务领域；否则如果对业务了解不深入，则会导致服务设计不足（兼容很多服务版本设计）或者导致过度设计（浪费资源，实现一堆不可用的功能）；

如何设计微服务呢？？？
核心：服务边界的划分和功能的抽象设计；

一、清晰的服务边界划分