为什么我们回归了模块化单体架构
软件团队正在改变其策略。许多团队花费了数年时间将应用拆分为微服务。现在，他们正在将这些碎片重新整合。他们并不是在构建旧的、混乱的单体架构，而是在构建模块化单体架构。
微服务会产生隐藏成本。分布式系统增加了巨大的复杂性。许多团队采用微服务是因为跟风，而不是因为他们需要那种规模。如果你的团队规模较小，微服务可能会拖慢你的进度。
模块化单体架构兼具两者的优点。它保持为一个可部署的单元，但代码被组织成严格的模块。你可以在无需承担运行分布式系统高昂成本的情况下，获得清晰的边界。
比较这两种方法：
• 部署：单体架构使用一个单元。微服务使用多个单元。 • 边界：单体架构使用严格的代码规则。微服务使用网络。 • 通信：单体架构使用简单的函数调用。微服务使用网络调用。 • 开销：单体架构的运维成本较低。微服务成本较高。
什么时候应该选择模块化单体架构？
- 你的团队工程师人数少于 50 人。
- 你需要降低云基础设施成本。
- 你希望简化调试和测试。
- 无论如何，你的服务通常都需要一起部署。
现实中的公司已经在这样做。Shopify 使用模块化方法来管理数百万商家。Amazon Prime Video 将特定的工作负载从微服务迁回了单体架构。他们发现基础设施成本降低了 90%。
如果你的团队规模较小，不要为了 Netflix 那样的规模而构建。从模块化开始。只有当数据表明你确实需要时，才提取出独立服务。
使用此清单来查看你是否需要进行整合：
- 你在调试服务连接上花费的时间是否比构建功能还多？
- 你的云账单增长速度是否快于用户增长速度？
- 你是否只有不到 5 名 DevOps 工程师来维护众多服务？
- 工程师是否需要跨 3 个或更多服务追踪一个请求来查找 Bug？
如果你的回答是“是”，那么模块化单体架构很可能是正确的选择。
Optional learning community: https://t.me/GyaanSetuAi