在技术团队里，我亲身经历了
从一个 2~3 人初创阶段的团队到百人规模技术团队的演变
也见证了技术栈和系统架构从传统到现代的变迁
从最初使用的JSP，到如今前后端分离+SpringCloud的微服务架构
我们的技术、架构和运维模式经历了翻天覆地的变化。复盘一下自己走过的路，尤其是微服务拆分过程中所踩过的那些坑，背过的锅。。。
这里来复盘一下，传统项目改造成微服务架构时，系统拆分所踩过的坑。
总结起来应该就是这两坑货：
坑一：服务拆分边界不清晰
坑二：拆分粒度过细，过度拆分
我们的项目是原本就有的系统，随着公司的发展。老板钱多了想做大做强、招架构师、招总监、系统用户量大了等问题，所以系统需要升级，需要改造。
当下一般来说就是改造成微服务架构，那么
第一步，就是产品对业务进行拆分；
第二步，就是技术根据拆分好的业务，创建对应的微服务；
.....
产品的业务模块
这是个电商系统，不过与传统电商系统多出来的就是有商品的申请、对商品申请的审核、商品的制作这几个业务。
首先是产品经理把系统划分出相应的业务模块，
- 1、 业务申请
处理用户的商品下单申请，收集订单信息主要包括证照、申请表等材料。
- 2. 订单审核
对用户订单进行审核，确保订单合法有效如证照是否真实、申请表填写是否正确。
- 3. 生产制作
生产商品并管理订单的生产过程，跟踪制作进度和资源。
- 4. 用户管理
用户账户信息，处理注册、登录和权限。
- 5. 支付与结算
处理订单支付、退款、结算及发票等相关事务。
- 6. 物流与配送
管理物流信息，协调配送流程和状态更新。
- 7. 消息通知
发送系统消息和通知，确保用户及时了解信息。
- 8. 报表与分析
生成业务报表，提供数据分析支持决策。
当时技术团队就根据产品的型业务模块一一对应来生成相应的微服务。
微服务拆分
那么目前微服务拆分的依据就是根据业务模块来拆分，好样并没有毛病。
- 业务中心：负责业务的申请、用户上传相应的材料
- 审核中心：负责业务申请的审核
- 生产中心：负责商品的生产
- 用户中心：负责用户与权限的管理
- 支付中心：负责订单的支付、发票等
- 物流中心：负责商品的物流跟踪
- 消息中心：负责 MQ、短信、邮件等消息
- 报表中心：负责系统报表生成、使用等功能
- 日志中心：负责系统业务日志、系统日志的管理
- 存储中心：负责系统所有文件的存储与管理
- 监控中心：负责系统监控管理
拆分下来整个系统就变成这 11 个微服务，不多也不少了。另一个兄弟团队拆分出 30 来个微服务。拆分完后就是开发了，这时各种坑就出现了
总结
引用淘宝技术团队的一句经典的话：
" 好的架构是进化来的，不是设计来的，好的功能也是进化来的 "。
为了避免微服务拆分过细，一般服务可以将关联紧密业务模块放一起，随着业务和团队的发展，再逐步细化微服务的拆分。比如，在电商平台中，最初订单和支付是合并在一个服务中的，随着业务复杂性增加，可以将支付拆分出来变成独立的服务。
如果重新拆分的话或许会是这样的：
- 业务中心
-
- 责任：负责订单的全生命周期管理，包括订单提交、审核、生产等。
- 合并模块：
-
-
- 提交订单信息（业务中心）
- 审核提交订单（审核中心）
- 生产订单中的商品（生产中心）
-
- ERP中心
-
- 责任：处理支付、发票，以及库存管理相关的功能。
- 合并模块：
-
-
- 支付、发票（财务中心）
- 库存管理（商品中心）
-
- 用户中心
-
- 责任：管理用户信息、用户权限、以及与用户相关的功能。
- 合并模块：
-
-
- 用户基本信息（用户中心）
-
- 消息中心
-
- 责任：负责系统内的短信、邮件等通知功能。
- 模块：
-
-
- 短信、邮箱（消息中心）
-
- 监控中心
-
- 责任：记录和监控系统日志，用于分析和审计。
- 模块：
-
-
- 日志（日志中心）
- 监控服务
-
- 数据中心
-
- 责任：负责生成报表，以及存储订单相关的文件和图片。
- 合并模块：
-
-
- 报表（报表中心）
- 存储订单相关的图片、文件（文档中心）
-
这样微服务的数量从 11 个减少到 6 个 ，功能模块的相关性增加，每个服务的责任范围更大，但仍然保持了适当的解耦。这样可以简化服务管理，同时保留扩展和维护的灵活性。
我是栈江湖，如果你喜欢此文章，不要忘记关注+点赞哦！你的支持是我创作的动力。如果你有任何意见或建议，欢迎在下方留言。若转载，请注明文章来源。