微服务 vs. 单体架构：你应该构建哪一种？
一位创始人曾请我评审一份架构方案。
那家代理机构提出了 11 个服务、一个消息队列和一个服务网格。而这仅仅是为了一个用户量为零的简单预订工具。
这是一个陷阱。
架构决策决定了你的托管账单、交付速度和招聘计划。在给开发人员预算之前，你必须了解其成本。
单体架构 (The Monolith)
单体架构使用单一的代码库、单一的部署和单一的数据库。它非常简单。
在项目初期，你并不清楚你的领域边界。如果过早拆分服务，你就会把时间浪费在移动那些本不该存在的“墙”上。当团队规模较小时，单体架构更容易管理。你可以直接调用函数，而不是去搭建 API。当凌晨 2 点出现 Bug 时，错误会直接指向代码，而不是网络故障。
微服务 (Microservices)
微服务解决的是组织层面的问题。它们允许不同的团队按照各自的进度交付代码。Netflix 使用微服务来防止单个故障导致整个系统崩溃。
然而，你每天都要为此付出代价。网络调用会增加延迟。数据一致性变得难以维护。你需要专门的工具和庞大的团队来管理日志和链路追踪。如果没有足够的人力，你最终会得到一个“分布式单体”。这会让你既承受了网络带来的所有复杂性，又无法获得任何独立性。
模块化单体 (The Modular Monolith)
这是折中方案。它是一个应用，但在代码的不同部分之间设有坚固的边界。例如，计费模块无法触及订单模块的核心逻辑。
Shopify 和 GitHub 都采用了这种方法。你既能获得清晰的边界，又能避免“网络税”。当应用的某个部分最终需要独立扩展时，你可以轻松地将其拆分出来，因为边界早已定义好了。
如何决策：
- 团队规模：如果你只有三个人，你无法同时管理多个独立服务以及必要的轮值值班。
- 产品稳定性：如果你的产品每周都在变，那么到下个月，你的服务边界就会变得不再适用。
- 运维能力：你是否有自动回滚和日志聚合功能？如果没有，微服务会让你痛不欲生。
- 规模：不要为了假设性的增长而构建。要针对你目前能看到的具体路径进行构建。
如果你的回答是“还没有”，那就构建一个模块化单体。
不要仅仅因为“微服务”这个词听起来很现代就要求使用它。告诉你的合伙人产品的功能是什么，以及谁来负责维护它。
产品之所以夭折，是因为它们从未发布。一个整洁的单体架构是让产品快速触达用户的最快方式。先构建它。让流量告诉你，何时该进行拆分。
可选学习社区：https://t.me/GyaanSetuAi