从 0 到 1：初创公司单体架构向微服务演进的时机

在技术圈有一种极其不健康的“大厂崇拜症”。很多初创公司的技术总监刚招来 3 个程序员，就迫不及待地引进了 Spring Cloud Alibaba 全家桶：Nacos、Gateway、Sentinel、Seata 安排得明明白白，把一个简单的电商 CRUD 系统拆成了 10 个微服务。

结果业务还没上线，团队一半的时间都花在了排查“为什么服务 A 调不通服务 B”、“为什么分布式事务总是回滚失败”这种基础设施问题上。

在 2026 年的务实架构观中，我们极度推崇 “宏伟的单体（Majestic Monolith）”。

1. 为什么第一天绝对不要用微服务？

微服务的本质，不是为了解决性能问题，而是为了解决“人的问题”与“团队协同问题”。

当你的项目只有不到 10 个开发人员时，单体架构（所有的代码在一个工程里，连着同一个数据库）拥有无与伦比的优势：

开发极快：没有 RPC 接口定义，没有网络序列化开销，直接 new Service().doSomething()。
天然的强一致性：一个 @Transactional 搞定所有跨表逻辑，不用去碰那些让人掉头发的 Saga 或是 TCC 分布式事务。
极低的运维成本：打成一个 Jar 包，扔到单台服务器或者简单的 Docker 里就能跑。

如果性能遇到瓶颈，在初期最简单的做法是：垂直扩展（买更好的 CPU 和更大的内存），或者水平扩展（多部署几个相同的单体实例，前面挂个 Nginx 做负载均衡）。

2. 触发微服务拆分的三个关键信号

只有当你的单体应用遭遇了以下三种无法通过“加机器”来解决的瓶颈时，才是你拔出微服务这把手术刀的时候。

信号一：代码合并的灾难（人月神话的破灭）

当研发团队扩张到 20 人甚至 50 人以上，所有人都在同一个 Git 仓库里疯狂提交代码。每天早上来公司的第一件事就是解代码冲突。A 组改了一个公共工具类，直接导致 B 组和 C 组的业务逻辑在生产环境集体崩溃。 此时，你需要用微服务的物理边界，来强行隔离不同团队的职责（康威定律）。

信号二：资源类型的严重撕裂

在一个单体应用中，可能既有“订单服务”（I/O 密集型，需要大量内存缓存），又有“图片压缩与报表导出服务”（CPU 密集型，需要大量计算算力）。当遇到大促时，图片服务把 CPU 榨干了，导致同在一个 JVM 里的订单服务线程被饿死。你发现无论怎么加机器，总有一部分资源是严重浪费的。 此时，你需要将不同资源消耗特性的模块拆分，独立进行弹性扩缩容。

信号三：发布爆炸半径过大

哪怕只是修改了首页上的一个文案错别字，你也需要重新编译整个几百兆的单体应用，耗时 10 分钟重启整个进程，并且承担可能因为其他模块隐患导致整个系统无法启动的风险。 此时，微服务能将每次发版的“爆炸半径”控制在单个领域内。

3. 架构拆分的“第一刀”怎么切？

决定要拆了，千万不要按技术层拆（比如把 Controller 拆个服务，Service 拆个服务）。 必须按业务领域（Business Capability）来拆。

先剥离边缘、无状态的计算服务：比如把发邮件、发短信、图片处理这种最容易剥离的独立成微服务。
抽取公共底座（核心域）：将最核心的用户系统（User）独立出来，因为所有模块都要查用户。此时旧单体通过 RPC 调用独立出来的用户微服务。
最痛苦的战役：拆分数据库：微服务拆分的核心不仅是代码，而是数据。严禁两个微服务直连同一个物理数据库表！如果有跨库的连表查询（JOIN），必须通过应用层的 API 聚合，或者将数据同步到 Elasticsearch 中建立宽表供查询。

总结

架构演进不是赶时髦，而是在为业务的野蛮生长买单。忍受单体的臃肿，直到它真正成为效率的阻碍；然后像外科手术一样，精准地、按领域地切分出微服务。这就是最稳健的架构师之道。