微服务：初创公司很可能承受不起的“技术债”
为何过早拆分代码库会不知不觉拖垮团队的开发效率——以及我们该如何应对。
在初创公司，生死存亡的关键在于你迭代、交付功能、为用户创造价值的速度。 这时候，公司的技术架构就显得至关重要了；此外，技术栈和编程语言的选择也直接影响着团队的“手速”。错误的架构，尤其是过早地“赶时髦”上了微服务，很可能严重拖累生产力，导致软件交付目标遥遥无期。
我就亲身经历过这种事：在给一些早期初创公司做新项目（Greenfield Project）时，由于软件架构上一些想当然的决策，最终搞出了一堆半成品服务、脆弱不堪、过度设计、三天两头出问题的本地开发环境，以及一群被不必要的复杂性折磨得精疲力尽、士气低落的团队。
在深入那些具体的坑之前，咱们先算算这笔账：过早引入微服务，你到底要付出多大的代价。
早期微服务：你要付的“买路钱”
| 痛点 | 实际表现 | 开发团队的代价 |
|---|
| 部署复杂性 | 为了一个小功能，得协调部署5个以上的服务 | 每次上线都得折腾好几个小时 |
| 本地开发环境脆弱性 | 泛滥的 Docker 容器、时不时就坏掉的脚本、还有各种针对特定平台的“黑科技”补丁 | 新人上手慢，三天两头崩 |
| CI/CD 重复劳动 | 每个服务一套独立的CI/CD流水线，大量重复逻辑 | 每个服务都带来额外的维护负担 |
| 跨服务耦合 | 号称“解耦”的服务，实际上通过共享状态绑得死死的 | 需求变更响应慢，沟通成本飙高 |
| 可观测性开销 | 分布式追踪、日志收集、全方位监控 | 想把监控搞利索，没几周下不来 |
| 测试套件碎片化 | 测试用例分散在各个服务，不成体系 | 测试用例一碰就碎，心里没底 |
接下来，咱们就来掰扯掰扯，为什么微服务在早期阶段往往会“好心办坏事”，它们在什么情况下才真正管用，以及初创公司如何构建系统才能既跑得快，又能活下来。
单体架构：并非洪水猛兽
如果你在做一款SaaS产品，哪怕只是一个简单的SQL数据库套个壳，随着业务逻辑越来越复杂，内部的复杂度也可能急剧膨胀；更别提你可能还要对接各种第三方服务，处理各种后台任务，进行数据转换。
时间一长，再加上一些没啥必要的功能，你的应用代码不可避免地会变得臃肿混乱。但单体应用牛就牛在：它乱归乱，照样能跑！单体应用，就算再乱，也能让你的团队把精力聚焦在刀刃上：
单体应用最大的好处就是部署简单。一般来说，这类项目都是基于成熟的框架搭建的——比如Python的Django、C#的ASP.Net、Node.js的Nest.js等等。坚持用单体架构，你能享受到那些花里胡哨的微服务给不了的最大福利——背后有庞大的开源社区和项目维护者撑腰，毕竟这些框架当初被设计出来，主要就是为了作为单进程的单体应用来跑的。
我之前在一家房地产初创公司带前端团队，偶尔也给后端团队在技术选型上出出主意。我们那儿有个基于Laravel的应用，它的演进过程就很有意思。一开始只是个给房产经纪人管理订单的小后台，慢慢地就长成了一个庞然大物。
后来，它变成了一个功能非常全面的系统，处理着几百GB的文档，对接了几十个第三方服务。但你猜怎么着？它底层依然是跑在Apache上的一个相对基础的PHP技术栈。
我们团队非常依赖Laravel社区推荐的最佳实践。这种“听话”的好处是，我们既满足了业务方的需求和期望，也成功地把应用的功能扩展了好几个数量级。
有意思的是，我们从来没觉得有必要把系统拆成微服务，也没用上那些更复杂的基础设施模式。就这么着，我们反而避开了很多不必要的麻烦。架构简单，就是我们的核心竞争力。这一点，跟其他人（比如Basecamp那篇著名的“雄伟的单体”(Majestic Monolith)）的观点不谋而合——简单，在早期就是一种超能力。
总有人说单体应用不好扩展，但依我看，很多时候其实是单体应用内部模块划分没做好才惹的祸。
划重点：一个结构清晰的单体，能让团队专心出活儿，而不是天天救火。
可微服务不才是“行业标杆”吗？
不少工程师一上来就想用微服务，觉得这才是“正道”。没错，等规模上来了，微服务确实能派上大用场。但在初创公司，同样的复杂性反而会变成沉重的包袱。
只有当你真的遇到了扩展瓶颈、团队规模庞大、或者各个业务领域需要独立发展的时候，微服务才能值回票价。在那之前呢？你付出了高昂的代价，却享受不到啥好处：重复的基建、脆弱的本地环境、慢吞吞的迭代速度。举个例子，知名的 Segment 公司就曾因此踩坑，最后不得不放弃微服务架构，重回单体——原因无他，投入产出比太低。
划重点：微服务是用来解决扩展问题的工具，不是项目的初始模板。
微服务，错在哪儿？（尤其是在项目早期）
我曾经给一个早期团队当过顾问，他们拆分服务的决定，带来的项目管理和工程协调成本，远比技术上的收益要大得多。架构不仅仅塑造了代码，它还决定了我们如何做计划、如何评估工作量、如何交付产品。这种“组织税”很容易被忽略，直到一切都晚了。
图解：服务越多，协调成本就越高，呈线性增长——如果再算上产品经理、deadline、以及各种不一致的排期，这成本简直是指数级爆炸。
下面这些是早期阶段最容易出现的“反模式”。
1. 拍脑袋划分服务边界
理论上，大家常说要按业务领域来拆分应用——比如用户服务、产品服务、订单服务等等。这套说法通常借鉴了领域驱动设计（DDD）或者整洁架构（Clean Architecture）的理念。这些理念在大规模场景下确实有道理，但在产品八字还没一撇的早期阶段，这么搞很容易在产品形态稳定和得到市场验证之前，就把架构给框死了。最后的结果往往是：
- 数据库共享（名义上拆了，实际上还是耦合）
- 一个简单的业务流程，需要跨好几个服务调用
- 所谓的“解耦”，只不过是把耦合藏得更深了而已
我见过一个项目，团队把用户、认证、授权硬生生拆成了三个独立服务。结果就是，每次部署都巨复杂，构建任何一个API功能，服务间的协调都让人头疼。
说白了，业务逻辑的边界，跟服务的边界，压根儿就不是一回事儿。过早地拆分，只会让系统更脆弱，改起需求来也更费劲。
正确的做法是，根据实际遇到的扩展痛点来“动刀子”，而不是凭空想象，追求理论上的“优雅”。
在我辅导早期团队的时候，我们有时会用一些内部的特性开关或者部署开关来模拟未来可能的服务拆分——这样就不用马上承担实际的运维压力。这给了产品和工程团队足够的时间和空间，在真正拍板定下基础设施方案之前，去自然而然地摸索合理的边界。
划重点：别按理论划分服务，要按实际瓶颈来。
2. 代码库和基建的“摊大饼”
开发一个应用，下面这些事儿通常都挺重要的：
- 代码风格统一（比如用Linter）
- 测试基础设施，包括集成测试
- 本地开发环境配置
- 项目文档
- CI/CD 配置
如果你搞微服务，上面这些事儿就得乘以你的服务数量。如果你的项目是Monorepo（单一代码库），那还好说，可以用一套集中的CI/CD配置（比如GitHub Actions或GitLab CI）来简化管理。但有些团队喜欢把每个微服务都拆成独立的代码仓库，那样一来，想保持代码风格和配置的一致性，就得花老鼻子劲儿了，除非借助额外的工具。
对于一个只有三个人的小团队来说，这简直是灾难。在不同的代码库和工具链之间来回切换，会大大增加每个功能点的开发时间。
用 Monorepo 和统一编程语言来“续命”
办法总比困难多。对于早期项目，最最重要的一点就是——把所有代码都放在一个Monorepo里。这样能保证生产环境跑的是同一份代码，小团队协作起来也更容易，代码审查也方便。
对于Node.js项目，我强烈推荐用 nx 或者 turborepo 这样的Monorepo管理工具。它们都能：
- 简化跨子项目的CI/CD配置
- 支持基于依赖图的构建缓存
- 让你能像用TypeScript库一样（通过ES6
import）来调用内部服务
这些工具能帮你省下不少写“胶水代码”或者重复造轮子搞服务编排的时间。不过，它们也不是万能药，也有自己的取舍：
- 复杂的依赖树很容易迅速膨胀
- CI性能调优不是件轻松的活儿
- 你可能需要更快的构建工具（比如Bun）来保证构建速度
简单说：像 nx 或 turborepo 这样的工具，能给小团队带来Monorepo的高效开发体验——前提是你愿意花心思把它维护好。
如果是用Go语言开发微服务，早期一个不错的做法是使用单个Go工作区（workspace），并在go.mod文件里用replace指令来管理内部依赖。这样，将来等软件规模上去了，也能毫不费力地把各个Go模块拆分到独立的代码仓库里。
划重点：Monorepo + 共享基础设施 = 省时省力，代码一致，头脑清醒。
3. 本地开发环境一团糟 = 开发效率一落千丈
如果想在本地把应用跑起来，就得折腾三个小时，外加一堆定制脚本和 Docker 镜像“全家桶”，那你的开发效率早就被拖垮了。
早期项目经常会遇到这些问题：
- 文档缺失，或者根本没人看
- 依赖库版本老旧，没人更新
- 各种操作系统专属的“骚操作”（比如，嘿，这玩意儿只能在 Linux 上跑）
我的经验是，从别的团队手里接过来的项目，十有八九是只针对某一个操作系统开发的。有些开发者就喜欢在macOS上搞开发，压根儿不管他们的脚本在Windows上能不能跑。我以前带的团队里，就有用Windows的工程师，那可就惨了，经常得重写脚本，或者花大力气去逆向工程，才能把本地环境给跑起来。后来，我们痛定思痛，花了点时间把开发环境在不同操作系统上的配置标准化了，这才减少了新人上手时的痛苦——这点小投入，给每个新来的工程师都省了好几个小时。虽然过程挺折腾，但也让我深刻体会到，让代码能在新同事的任何一台电脑上顺利跑起来，是多么重要。
还有个项目，是一个单枪匹马的开发者搞出来的一套脆弱的微服务。他的做法是把 Docker 容器挂载到本地文件系统来跑。当然，如果你的电脑是Linux，用容器跑进程，代价还算小。
但问题是，后来招了个用旧款Windows笔记本的前端，那简直是噩梦的开始。他为了看个UI，就得启动十几个容器。结果呢？卷挂载、网络、容器兼容性，各种问题层出不穷——而且这套东西的文档还写得烂七八糟。这给新人入职造成了巨大的障碍。
最后没办法，我们临时用Node.js写了个代理，模拟了nginx/Docker那套配置，但没用容器。虽然不怎么优雅，但好歹让那个前端同事能开工干活了。
划重点：如果你的应用只能在一种操作系统上跑，那你团队的生产力就悬了，离崩溃只差一台不兼容的电脑。
小贴士： 理想情况下，最好能做到 git clone <repo> && make up 一条命令就把项目在本地跑起来。如果实在做不到，那也必须维护一份最新的README，里面写清楚在Windows/macOS/Linux上分别怎么操作，最好配上截图。现在有些编程语言和工具链在Windows上确实不太好使（比如OCaml），但主流的技术栈在常用操作系统上基本都没问题；如果你的本地环境只能在单一系统上跑，那多半是你在开发者体验（DX）上投入不够的表现。
4. 技术栈选型失误
除了架构，你选的技术栈也会决定微服务这条路走得有多痛苦——不是每种语言都天生适合微服务架构的。
- Node.js 和 Python： 快速迭代是它们的强项，但要跨多个服务去管理构建产物、依赖版本、保证运行时环境一致性，很快就会让你头大。
- Go： 编译出来是静态二进制文件，构建速度快，运维成本低。如果真到了非拆不可的地步，Go可能是更自然的选择。
尽早选对技术栈非常关键。如果你追求极致性能，或许可以瞅瞅JVM生态圈，它们在大规模部署和微服务架构下的表现都不错。如果你想快速迭代、快速验证想法，不怎么操心部署和扩展的问题，那Python这类语言就挺合适。
团队常常是在项目搞了一半才发现，当初的技术选型有大坑，然后不得不花大力气用别的语言重写后端（就像可汗学院那帮哥们儿一样，被逼无奈把祖传的Python 2代码库迁移到了Go）。
不过话说回来，如果你真有需求，也可以用 gRPC 或者异步消息这类协议来“打通”多种编程语言。很多时候这反而是推荐的做法。比如，当你需要引入机器学习功能或者ETL数据处理任务时，Python凭借其在这些领域丰富的库（这是其他语言望尘莫及的），往往是独立构建机器学习基础设施的首选。但这种决策的前提是，你得有足够的人手来支撑；否则，一个小团队很容易就会被这种跨技术栈的复杂性给活活拖死。
划重点：技术选型要服务于当前的实际约束，而不是你远大的理想。
5. 看不见的复杂性：通信与监控
微服务一上，会带来一堆看不见摸不着的新需求：
- 服务发现
- API 版本管理
- 重试、熔断、降级
- 分布式追踪
- 集中式日志和告警
在单体应用里，一个Bug可能就是一个简单的堆栈信息。但在分布式系统里，问题就变成了“为什么服务B的部署比服务C慢了30秒，服务A就挂了？” 你必须在可观测性（Observability）上投入血本。要想“ 제대로” (韩语： 제대로，意为“好好地”、“像样地”，这里指“正确地、完善地”) 搞定，就得用特定的方式来埋点你的应用，比如集成OpenTelemetry来做分布式追踪，或者如果你用了复杂的Serverless架构，就得依赖云厂商的工具（比如AWS XRay）。但到了这一步，你的工作重心就得从写业务代码彻底转向搭建复杂的监控基础设施了，目的仅仅是为了验证你的架构在生产环境到底是不是真的能跑起来。
当然，单体应用也需要搞点可观测性，但跟在几十上百个服务里用一致的方式做这件事比起来，那可就简单太多了。
小贴士： 记住，分布式系统不是免费的午餐。 选择它，就意味着你选择了承担一整套全新的工程挑战。
微服务：什么时候才真香？
虽然前面吐槽了微服务这么多不是，但有些时候，在服务层面进行解耦确实能带来实实在在的好处。下面这些场景，微服务就能帮上大忙：
- 工作负载隔离：一个经典的例子就是AWS推荐的最佳实践：用S3事件通知——比如一张图片上传到S3后，自动触发一个图片缩放或者OCR识别的处理流程。这么做的好处是啥呢？我们可以把那些复杂、冷门的数据处理库封装到一个独立隔离的服务里，让这个服务只专注于图片处理和输出结果。这样一来，那些只管往S3传数据的上游客户端就跟这个处理服务解耦了，而且因为这个服务功能单一，做监控和运维的开销也小得多。
- 差异化的扩容需求：想象一下你在做一个AI产品。一部分系统（比如Web API）负责触发机器学习任务、展示历史结果，这部分可能并不怎么吃资源，轻量得很，因为它主要就是跟数据库打交道。但另一部分，也就是跑在GPU上的机器学习模型，那可是个资源消耗大户，需要专门的GPU服务器和额外的配置。通过把这两部分拆分成独立的服务，跑在不同的机器上，你就可以根据各自的需求独立扩容了。
- 不同的运行时环境要求：假设你手头有一些用C++写的祖传代码。你有两个选择：要么想办法把它“魔法般”地转换成你项目主要用的语言，要么就得琢磨怎么把它跟你现有的代码库集成起来。根据这些祖传代码的复杂程度，你可能需要写不少“胶水代码”，实现额外的网络协议来跟它交互。但归根结底——由于运行时环境不兼容，你很可能不得不把这个应用单独拆成一个服务。我甚至可以说，就算你的主应用也是用C++写的，但如果编译器配置、依赖库不一样，你想把它们编译成一个单独的二进制文件，也不是件容易的事。
不少大型技术团队也踩过类似的坑，也总结了不少经验。比如，Uber的工程团队就分享过他们转向面向领域的微服务架构的历程——他们这么做，可不是为了追求什么理论上的完美，而是为了解决跨团队协作和系统扩展时遇到的实实在在的复杂性问题。他们的文章很好地说明了，当你具备了相应的组织成熟度和运维能力来支撑微服务时，微服务是可以发挥巨大作用的。
我参与过的另一个项目，巧了，也是个房地产行业的。我们接手了一份来自前一个团队的代码，是用Python跑数据分析任务，然后把结果存到MS-SQL数据库里。我们评估了一下，觉得在它上面再套一个Django应用纯属浪费资源。那段代码的运行时依赖跟我们主项目不一样，而且它本身功能也比较独立，所以我们就让它单独跑着，只有出问题的时候才去瞅瞅。即使我们团队人不多，这种方式也挺管用，因为这个数据分析服务本身很少需要改动或维护。
划重点：只有当不同业务模块的工作负载特性出现明显差异时，才考虑微服务——别光因为它听起来“高大上”。
给初创公司的真心建议
如果你正准备发布第一款产品，我强烈推荐下面这套打法：
- 从单体开始。 挑一个主流框架，把精力放在快速实现功能上。市面上那些成熟的框架，随便拿一个出来都足够你搭个API或者网站，服务好你的用户了。别去追那些花里胡哨的新技术，老老实实走“阳关道”；以后你会感谢现在的自己的。
- All in Monorepo（单一代码库）。 别折腾什么多代码库了。我跟一些创始人合作过，他们想把代码库分开，说是为了防止外包团队复制代码和知识产权——这顾虑有道理。但实际上呢？带来的麻烦远比所谓的安全感要多：编译构建变慢、CI/CD碎片化、团队之间信息不透明。那点儿微不足道的IP保护，根本不值得牺牲运营效率，尤其是在Monorepo内部通过合理的权限控制其实更容易管理这些问题。对于早期团队来说，清晰和速度，远比理论上的安全收益更重要。
- 本地开发环境务必简单到“令人发指”。 最好能做到
make up 一条命令就能跑起来。如果不行，那也得把步骤写得清清楚楚，最好录个屏（比如用Loom），再配上截图。你想想，如果你的代码是要交给实习生或者初级工程师来跑，他们十有八九会卡住，到时候你还得花时间去给他们排查环境问题。我的经验是，把每个操作系统上可能遇到的坑都提前记录下来，能省下大把解释“为什么我这儿跑不起来”的时间。
- 尽早投资CI/CD。 哪怕你做的只是个简单的HTML页面，可以直接
scp 到服务器，也最好把它自动化了，交给CI/CD和版本控制去搞定。一旦这套流程自动化了，你就可以把持续集成这事儿抛到脑后，专心做功能了。我见过太多团队和创始人，在跟外包团队合作的时候，总想在CI/CD上省钱，结果呢？团队成员天天为手动部署这种破事儿搞得怨声载道，士气低落。
- “外科手术式”拆分。 只有当某个模块明显成了整个系统的瓶颈，让你痛不欲生的时候，再考虑把它拆出去。否则，就在单体应用内部下功夫搞好模块化和测试——这样更快，也更容易维护。
最最重要的一点：一切为了提升开发者效率。
开发效率，就是初创公司的氧气。 过早地上马微服务，就像在慢慢地消耗这宝贵的氧气——直到有一天，你会发现自己喘不过气来了。
划重点：大道至简，务实为上，不到万不得已，别轻易拆分。
如果你非要上微服务这条“贼船”
我也接过一些过早上了微服务的项目，如果非要这么干，我能给的建议如下：
- 好好评估一下支撑你微服务架构的技术栈。 大力投入开发者体验相关的工具。一旦服务拆开了，你就得考虑怎么自动化管理这一堆微服务，怎么统一本地和生产环境的配置。在某些项目里，我甚至不得不专门写个CLI工具来做Monorepo里的一些管理任务。我曾经手的一个项目，有十五到二十个微服务部署，为了方便普通开发者在本地一键启动，我不得不写了个CLI工具来动态生成
docker-compose.yml文件。
- 重点关注服务间通信协议的可靠性。 如果是异步消息，确保消息格式一致、标准化。如果是REST API，那就把OpenAPI文档（比如Swagger）搞利索。服务间的通信客户端，很多东西都不是开箱即用的，比如带指数退避的重试机制、超时控制，你都得自己实现。一个光秃秃的gRPC客户端，也需要你手动加上这些东西，才能确保不会被一些偶发的网络抖动搞垮。
- 确保你的单元测试、集成测试、端到端测试体系是稳定可靠的，并且能够随着你引入的服务拆分数量平滑扩展。
- 在那些使用微服务架构的小型项目中，你很可能会搞一个共享库，放一些通用的帮助函数，用来统一实现可观测性埋点、通信逻辑等。这里有个很重要的点——这个共享库一定要尽可能小！ 因为一旦这个共享库有任何大的改动，所有依赖它的服务都得重新编译部署——哪怕那些服务跟这次改动八竿子打不着。
- 尽早考虑可观测性。 应用一上线，就加上结构化的JSON日志，创建各种关联ID（Correlation ID），方便调试问题。即使只是提供一些能输出丰富日志信息的基础工具（在你用上专业的日志/追踪系统之前），也常常能帮你节省大量排查线上诡异问题的时间。
总结一下：如果你铁了心要搞微服务，那你最好提前想清楚，为了让团队里的每个工程师都能顺畅工作，你愿意在额外的开发时间和维护成本上付出多大的代价。
划重点：既然选择了拥抱复杂性，那就下血本把它管好。
总结陈词
过早采用微服务，就像给你的初创公司上了一道沉重的“技术债”，你很可能承受不起。保持简单，才能活下去。 只有当不拆分让你痛不欲生的时候，再考虑拆分。
先生存，后发展。选择那个能满足当前需求的最简单的系统——你后来增加的每一分复杂性，都必须是经过深思熟虑、“挣”来的，而不是凭空添加的。
推荐阅读（大佬们的经验之谈）
#微服务 #单体 #架构 #node.js go](/tags/go)
提供