028、架构演进：从单体到微服务的重构策略

028、架构演进：从单体到微服务的重构策略昨天深夜排查一个线上问题，单体服务里一个订单查询接口突然飙到8秒响应。翻日志发现关联的促销计算模块正在全表扫描——这原本只是个边缘功能，却拖垮了整个核心链路。这已经不是第一次了，每次某个非核心功能出问题，整个服务都得跟着重启。站在凌晨三点的屏幕前，我意识到：是时候认真考虑拆分了。为什么拆？先想清楚再动手很多团队看到微服务火了就跟风拆，结果拆出一堆分布式单体——服务是独立部署了，但数据库还是同一个，链路调用比原来还复杂。拆微服务不是目的，而是手段。我通常看这几个信号：团队超过10人挤在一个代码库提交频繁冲突、核心功能和非核心功能SLA要求差异大、某个模块需要独立伸缩或技术栈升级受阻。如果这些症状你中了两个以上，就该认真规划重构了。从哪开始拆？找到那个“松动砖块”不要试图一次性重构整个系统。我习惯先找系统中耦合度最低的模块下手，比如短信通知、文件导出这类边缘服务。这些模块通常有清晰的业务边界，数据独立，对外依赖简单。去年我们重构时就是从“对账报表生成”模块开始的，这个模块每天凌晨跑一次，和其他业务几乎零实时交互。拆出来之后，团队获得了宝贵的微服务部署和运维经验，也建立了信心。# 重构前：所有功能挤在一个大文件里classMonolithicS