单体架构、模块化单体架构与微服务：诚实的决策框架

最初发布于 spectredev.xyz。在此交叉发布，供 Dev.to 社区阅读。

在单体架构、模块化单体架构和微服务架构之间如何选择？以下是你的初创公司真正需要的、坦诚且带有主观见解的决策框架。别再盲目模仿网飞（Netflix）了。

你的架构选择不应由网飞（Netflix）或优步（Uber）正在做什么所驱动。它应该由你当前的现状所驱动：你的团队规模、流量水平、部署成熟度以及资金续航能力。关于单体架构与微服务架构的争论，针对你的具体情况确实有一个正确的答案。只是这个答案并不是大多数博客文章所给出的那一个。

以下是我们在帮助初创公司和成长阶段的公司做出这一决策时所使用的框架。

为什么大多数团队从一开始就犯了错

我最常看到的错误是：创始人阅读了关于爱彼迎（Airbnb）或格拉布（Grab）如何从单体架构迁移到微服务架构的文章，然后决定从第一天起就构建微服务架构，因为他们认为这就是规模化应有的样子。

事实并非如此。那是规模化之后的样子。这两者是有区别的。

当这些公司拆分他们的单体架构时，他们拥有数百名工程师、成熟的持续集成/持续部署（CI/CD）流水线、专门的平台团队，以及多年处理自身领域边界问题的运营经验。他们并不是从零开始。他们是在解决因增长而出现的问题，而不是在预判一个可能永远不会到来的问题。

在尚未实现产品市场契合度之前就开始使用微服务架构，是将工程资源浪费在基础设施而非产品上的最快方式之一。我们曾亲眼目睹这种情况发生。看着这一切令人痛苦。

单体架构并不是一种糟糕的架构。它是一个起点。而且对于大多数团队来说——诚实地讲，对于拥有单一产品且工程师人数在 10 到 15 人之间的团队——它是正确的选择。

在传统的单体架构中，所有应用程序代码都存在于一个可部署单元中。一个代码库、一个数据库、一个部署流水线。其好处是真实存在的，但往往被低估。

在早期，开发速度确实更快。服务之间没有网络延迟，没有分布式事务的复杂性，也没有服务发现的开销。你可以一次性对整个代码库进行重构。调试也很直接，因为所有东西都在一个进程中运行。

问题随后才会出现。随着团队的增长，代码库变得越来越难以导航。不同的团队开始相互干扰彼此的工作。由于每次更改都会部署所有内容，部署变得缓慢且充满风险。就在这时，架构开始与你作对，而不是帮助你。

表明你已经不再适合单体架构的真正信号不是流量，而是团队协作的摩擦和部署的痛苦。

这里有一个反直觉的观点：对于大多数认为自己需要微服务架构的初创公司来说，模块化单体架构实际上是更好的答案。

模块化单体架构仍然是一个单一的可部署单元，但其内部结构被刻意划分为隔离的模块，每个模块都有清晰的边界、独立的数据所有权，以及关于模块间交互的严格规则。可以将其视为在单体架构的部署模型中融入微服务架构的纪律性。

实际结果是：你获得了微服务架构的大部分架构清晰度，却无需承担其运营开销。你可以强制执行团队对模块的所有权。你可以更快地推进，而无需

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。