结合单体架构迁移总结一点经验
-
定义边界：通过领域驱动设计（DDD）划分限界上下文，明确微服务的拆分粒度。
-
分析旧系统：梳理单体功能模块、依赖关系和数据库表结构，找出高内聚低耦合的拆分点。
-
统一网管制（API Gateway）：在前端与旧系统间引入网关，作为流量入口和路由控制中心。
-
开发首个微服务：优先拆分变更频繁或性能瓶颈明显的模块，独立部署。
-
路由配置规则：在网关配置流量规则，将该服务的所有请求路由到新服务，其余继续走单体。
-
数据库适配：新服务用独立数据库，通过数据库同步、API调用保证数据一致性，逐步去耦。（可选哈，不一定数据库也换）
-
逐步迁移：按优先级逐个拆分模块为微服务，每次切部分流量，验证稳定后继续。
-
旧系统下架：当所有模块迁移完毕、单体无流量，即可下线单体。
痛点
大的单体要拆主要是有以下的痛点
- 维护成本高，多人协作，版本多，冲突不断，要花很多时间做代码的合并。版本管理混乱。
- 核心业务稳定，边角业务上线，核心任务也要一起发布，风险大。
- 数据库混乱，一个大的系统多数据源可以说是家常便饭，耦合严重。造成业务逻辑混乱
什么情况不适合拆？
团队就10人一下，系统一大堆，没有时间做这种业务的细分。来一个系统做一个系统，线上用的人也不多，预期也不会有大的增长。没有那种线上运维焦虑的系统。大可不必搞微服务。
总结
关于微服务拆分的经验有很多
比如：
康威定律
两个披萨原则
三个火枪手原则
绞杀者模式
如果真的要做单体装微服务可以借鉴这些原则