第3章：单体架构 vs 微服务架构

这一章，我们来聊聊ERP架构里最核心的一个选择题——单体还是微服务？

说实话，这个问题我这些年被问过不下百次。每次技术选型评审会上，总有人拍桌子说「必须上微服务」，也有人坚持「单体够用就别折腾」。两边都有道理，但关键得看场景。

3.1 单体架构：老牌选手的底气

单体架构，说白了就是把所有功能都塞进一个进程里。ERP系统最传统的做法就是这样——财务、采购、库存、生产，全在一个应用里跑。

优点很明显：

• 开发简单：一个项目，一套代码，IDE里直接跑。我早期做ERP时，一个团队5个人，三个月就能出一个可用版本。
• 部署省心：打一个WAR包，丢到Tomcat里完事。运维同学最喜欢这种，不用操心服务间调用。
• 调试方便：出问题了？本地起一个实例，断点一打，从头跟到尾。我在项目中遇到过好几次，微服务出问题要查三个服务才能定位，而单体半小时就搞定了。
• 事务好管：数据库本地事务，ACID稳稳的。财务模块的记账操作，你想想看，跨服务搞分布式事务有多头疼。

但缺点也扎心：

• 牵一发动全身：改一行代码，整个应用要重新部署。我记得有一次，只是改了个报表的字体颜色，结果触发了全量回归测试，折腾了两天。
• 扩展性差：某个模块负载高了？对不起，你得把整个应用都扩容。采购模块流量大，但财务模块根本不需要那么多实例，白白浪费资源。
• 技术栈锁定：选了Java就是Java，想混用Python做数据分析？没门。

3.2 微服务架构：拆分的艺术

微服务，就是把一个大系统拆成一堆小服务。每个服务独立部署、独立扩展、独立技术栈。

优势在哪？

• 独立部署：采购团队改采购的，财务团队改财务的，互不干扰。我在一个电商ERP项目里，库存服务一天能发布5次，而财务服务一个月才发一次。
• 弹性伸缩：双十一大促，订单服务扩到100个实例，用户服务保持10个就行。你想想看，单体能做到吗？
• 技术多样性：订单服务用Go，报表服务用Python，数据服务用Java。各取所长，不纠结。
• 故障隔离：库存服务挂了，不影响财务和采购。我曾经见过一个单体ERP，一个报表查询把数据库连接池打满了，结果所有用户都登不进去了。

但坑也不少：

• 分布式复杂性：服务间通信、数据一致性、链路追踪，每个都是大坑。我刚开始搞微服务时，光搭一个服务网关就折腾了一周。
• 运维成本高：需要容器编排、服务发现、配置中心、监控告警。小团队根本玩不转。
• 数据管理难：每个服务有自己的数据库，跨服务查询怎么办？报表怎么办？我曾经在一个项目里，为了做一个跨三个服务的报表，写了整整两天的数据聚合代码。

3.3 两者对比：一张表说清楚

维度	单体架构	微服务架构
开发效率	初期高，后期低	初期低，后期高
部署复杂度	低，一个包搞定	高，需要CI/CD流水线
扩展性	垂直扩展为主	水平扩展，按需伸缩
故障影响	全局影响	局部隔离
技术栈	单一	多样化
团队要求	全栈工程师	领域专家+DevOps
适合阶段	初创期、稳定期	成长期、爆发期

3.4 迁移策略：从单体到微服务

如果你已经在用单体，想往微服务迁移，我建议你按这个步骤来：

1. 先别急着拆：先把单体代码整理好，模块边界划清楚。我见过太多人，代码一团糟就开始拆，结果拆完更乱。
2. 从边缘模块开始：选一个耦合度低、业务独立的模块先拆。比如报表模块、通知模块。别一上来就动核心交易流程。
3. 做好防腐层：拆出来的服务，要和老系统做好接口适配。我习惯用API网关做统一入口，新旧系统都能接。
4. 数据先分离：服务拆了，数据库也得拆。但别一次性拆完，可以先做逻辑分离，再物理分离。
5. 逐步替换：拆一个，稳定一个，再拆下一个。别想着三个月全拆完，那是不可能的。

3.5 我的建议

嗯，说了这么多，最后给个实在的建议：

• 别盲目追微服务：如果你的ERP用户不到1000人，团队不到10个人，单体完全够用。别为了技术而技术。
• 也别死守单体：当你的业务模块之间需要独立迭代、独立扩展时，微服务是必然选择。
• 折中方案：其实还有一种「模块化单体」的玩法——代码层面拆成模块，部署层面还是一个包。这样既保留了单体的简单，又有了微服务的模块化思维。我个人比较推荐这种过渡方案。

记住一句话：架构没有银弹，只有适合不适合。你想想看，一个卖煎饼的摊子，需要搞中央厨房吗？不需要。但如果你要开100家连锁店，那就必须标准化、模块化了。ERP架构也是这个道理。