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

目录

本文诞生于学习架构实践专栏后的深思以及总结,结合公司之前"大泥球"的架构风格,改造服务设计的思维。
改造公司系统服务主要原因: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了解到如何将服务逐步改造成微服务,那么如何打造一个合理的微服务呢???请看下文

关于基础服务设计的核心思想,也需要保证业务上的复用性,故需要把各个基础服务封装成高度复用的共享服务。

首先要明确一个思想:技术的核心价值是为业务服务,故开发中我们除了技术之外的事情,就是了解、学习、分析业务领域;否则如果对业务了解不深入,则会导致服务设计不足(兼容很多服务版本设计)或者导致过度设计(浪费资源,实现一堆不可用的功能);

如何设计微服务呢???

核心:服务边界的划分和功能的抽象设计;

一、清晰的服务边界划分

  • 作为基础服务,不主动调用其他服务,保证基础服务职责单一;
  • 作为基础服务,不负责与第三方系统的集成;

二、服务内部抽象设计

  • 功能上保证设计通用性,对内部数据模型和外部接口进行抽象设计;
  • 设计服务接口:同步接口和异步通知;
    同步接口:拆分出粗粒度接口、中粒度接口、细粒度接口;
    异步消息通知:依据消息详细程度,提成传输效率,拆分粗粒度消息和细粒度消息;
相关推荐
宇钶宇夕5 分钟前
EPLAN 电气制图:建立自己的部件库,添加部件-加SQL Server安装教程(三)上
运维·服务器·数据库·程序人生·自动化
爱可生开源社区29 分钟前
SQLShift 重磅更新:支持 SQL Server 存储过程转换至 GaussDB!
数据库
贾修行1 小时前
SQL Server 空间函数从入门到精通:原理、实战与多数据库性能对比
数据库·sqlserver
傲祥Ax1 小时前
Redis总结
数据库·redis·redis重点总结
一屉大大大花卷2 小时前
初识Neo4j之入门介绍(一)
数据库·neo4j
周胡杰2 小时前
鸿蒙arkts使用关系型数据库,使用DB Browser for SQLite连接和查看数据库数据?使用TaskPool进行频繁数据库操作
前端·数据库·华为·harmonyos·鸿蒙·鸿蒙系统
wkj0012 小时前
navicate如何设置数据库引擎
数据库·mysql
赵渝强老师2 小时前
【赵渝强老师】Oracle RMAN的目录数据库
数据库·oracle
暖暖木头3 小时前
Oracle注释详解
数据库·oracle
御控工业物联网3 小时前
御控网关如何实现MQTT、MODBUS、OPCUA、SQL、HTTP之间协议转换
数据库·sql·http