目录
- 基础服务改造
- 核心步骤
- 准备阶段
- 实施阶段
- 基础服务设计
本文诞生于学习架构实践专栏后的深思以及总结,结合公司之前“大泥球”的架构风格,改造服务设计的思维。
改造公司系统服务主要原因: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了解到如何将服务逐步改造成微服务,那么如何打造一个合理的微服务呢???请看下文
关于基础服务设计的核心思想,也需要保证业务上的复用性,故需要把各个基础服务封装成高度复用的共享服务。
首先要明确一个思想:技术的核心价值是为业务服务,故开发中我们除了技术之外的事情,就是了解、学习、分析业务领域;否则如果对业务了解不深入,则会导致服务设计不足(兼容很多服务版本设计)或者导致过度设计(浪费资源,实现一堆不可用的功能);
如何设计微服务呢???
核心:服务边界的划分和功能的抽象设计;
一、清晰的服务边界划分
- 作为基础服务,不主动调用其他服务,保证基础服务职责单一;
- 作为基础服务,不负责与第三方系统的集成;
二、服务内部抽象设计
- 功能上保证设计通用性,对内部数据模型和外部接口进行抽象设计;
- 设计服务接口:同步接口和异步通知;
同步接口:拆分出粗粒度接口、中粒度接口、细粒度接口;
异步消息通知:依据消息详细程度,提成传输效率,拆分粗粒度消息和细粒度消息;