用于发现的 Monoliths，用于优化的 Microservices

Source: Dev.to

我知道，我知道。这又是一篇关于微服务与单体架构的文章。这个争论此时已经让人感到疲惫。然而每当我启动一个新项目时，我仍会权衡相同的问题。并不是因为答案不明确，而是因为答案真的取决于你所在的环境以及你想要学习的东西。
这里没有通用的处方。我学到的是，选择并不是在抽象层面上寻找“正确”的架构，而是挑选适合你的上下文、约束，最重要的是，适合你需要发现的东西。

1. 微服务是优化，单体架构促进发现

微服务是针对特定问题的优化：团队规模、独立部署、技术多样性。它们是对你已经识别出的约束的解决方案。
单体架构则相反，它加速发现。它让你学习边界应该在哪里、在领域逐步显现时进行理解，并在没有分布式系统开销的情况下快速验证假设。

先使用能让你最快学习的方式，然后在真正需要优化的地方再进行优化。

2. 单体架构并不是劣质代码的借口

单体架构的负面印象来源于糟糕的实践，而不是架构本身。糟糕的单体当然存在，糟糕的微服务也同样存在。区别不在于部署模型，而在于你是否遵循 SOLID 原则和清晰的边界来保持良好的设计纪律。

3. 市场速度 vs. 完美架构

交付并学习。团队常常因为争论“完美”架构而阻塞产品开发数月。更好的做法是做可逆的决定，建立清晰的边界，并根据真实使用中学到的东西进行迭代。完美是一个不断移动的目标；动能更为重要。

4. 数据边界从第一天起就很重要

即使从单体开始，也要尽早定义数据所有权。刚起步时在服务之间共享数据库并非本质错误，但你需要干净的边界，以便将来能够实现分离。纠结的数据模型会把团队困在遗留架构中。

5. 及早抽象基础设施

即使所有东西在幕后仍作为单体运行，提前引入 API 网关和服务抽象——这为你在尚未确定最终基础设施形态时提供了灵活性。这是一笔小的前期投入，却能在后期带来显著的可选性。

基于领域的服务：模块化单体

从基于领域的服务开始：按照自然业务边界（DDD 中的有界上下文）组织的模块化单体。这为你提供：

• 从一开始就有清晰的关注点分离
• 团队在各自领域内的自治
• 当时机成熟时向微服务平滑迁移的路径
• 比从第一天就构建分布式系统更快的初始开发速度

当出现实际证据表明需要时再拆分为微服务：独立的扩展需求、团队协作成为瓶颈，或特定技术需求足以证明承担分布式系统运维复杂性的合理性。