如何正确将Django单体架构应用迁移至微服务架构

Django单体转微服务没有放之四海而皆准的银弹，但行业内经过大量线上场景验证的渐进式迁移路径，完全可以避开你们当前方案的各类问题。你们现在给每个微服务直连原生产库、全量执行python3 manage.py inspectdb导出所有模型的做法，本质是把单体时代的代码耦合换成了更难排查的数据库层强耦合，循环导入只是最早期的小问题，后续还会出现多服务并发写数据冲突、单表结构调整联动所有服务报错、跨服务数据一致性无法保障等更严重的故障。

先明确核心原则 #

微服务拆分的核心要求是数据自治，即每个服务只能持有自己负责业务域的数据库表的读写权限，绝对不允许多个服务直连操作同一张业务表，所有跨服务的数据交互必须通过约定好的接口完成。

分阶段落地步骤（支持零停机、可随时回滚） #

不要一开始就把所有模块拆成独立Django项目，按阶段推进风险最低：

阶段1：单体内部先划清业务边界（拆分前必须做，不要上来就建独立项目） #

• 先在现有运行的单体Django项目内按业务域收拢代码：比如用户域、订单域、支付域、通知域分别收口到独立的app，明确每个域对外暴露的服务层方法，严格禁止跨域直接import其他域的Model类，跨域逻辑调用只能走提前定义好的服务层接口
• 把所有跨模块的数据库外键改成逻辑外键：将原来的ForeignKey字段替换为存关联ID的IntegerField/UUIDField，去掉数据库层面的跨表外键约束，这一步能解决后续拆分时90%以上的循环导入问题
• 这个版本上线后稳定跑2~4周，把边界划分不合理的地方调整到位，再做物理拆分

阶段2：单体内先做垂直拆库 #

• 按照划好的业务域，把对应域的表从原公共库迁移到独立的业务库中，在单体项目的settings.py里配置多数据库连接，通过Django自带的Database Router把不同域模型的读写请求路由到对应的库
• 这一步必须把所有跨库的JOIN查询全部改造掉，换成先通过服务层分别查对应域的数据，再在内存中组装结果，禁止任何跨库关联查询，不然后续服务根本拆不出去
• 拆库后的版本上线验证稳定后，再进入服务拆分步骤

阶段3：逐步抽离独立服务 #

• 优先抽离和核心业务耦合最低、变更最频繁的边缘模块，比如通知服务、文件服务、日志服务这类，不要一开始就动订单、用户这类核心链路模块
• 新抽离的微服务绝对不要直连原公共库或者其他服务的数据库：过渡阶段可以在原单体里给对应模块做带内部鉴权的HTTP接口（用DRF实现即可，初期不用强行上RPC、服务网格这类重组件），新微服务只维护自己主权范围内的模型，需要访问其他域的数据时，全部通过调用对应接口获取
• 等新服务稳定运行后，再把对应业务域的表读写流量完全从原单体切到新服务，原单体中只保留对应接口的调用客户端，不再直接操作这部分表

阶段4：存量模型的正确处理方式 #

你们现在用的inspectdb工具不是不能用，但要严格限制使用范围：

• 只有当某张表的所有权完全划转到当前微服务时，才执行inspectdb把这张表的模型定义导入到当前服务，其他服务主权下的表绝对不要导入
• 导入后的模型要做精简，删掉所有和当前服务业务逻辑无关的字段、关联定义，只保留当前服务需要的字段，不要全量复制原模型的所有内容
• 所有跨服务的数据交互一律走接口，不要图省事直连其他服务的库查询，初期开发量稍大，后续能省掉无数排障成本

常见避坑提醒 #

• 不要一开始就堆技术栈：K8s、服务网格、RPC框架、分布式事务这些组件等你服务拆到一定规模、确实有需求的时候再加，初期用最简单的HTTP接口做跨服务调用完全够用
• 不要追求一步到位：整个迁移周期按半年到1年规划非常正常，允许很长一段时间内存在「单体+微服务」混跑的过渡状态，不要试图几周就完成全量拆分
• 循环导入本质是边界划分错误：如果两个模块拆分后出现互相导入模型的情况，说明这两个模块本身耦合度极高，本来就应该归属于同一个服务，不要硬拆

内容的提问来源于stack exchange，提问作者elece