单体应用与微服务：用例和决定清单

问题“单体还是[微服务0？”是软件工程中回答最差的问题之一。答案很差，因为它几乎总是由时尚、课程或模仿大型科技公司决定，而几乎从来不是由团队面临的真正问题决定的。

这篇文章是写给那些真正需要做出决定的人的。技术领导者、CTO、产品经理面临着架构的选择。我不会为某一方辩护为优越者。我将展示每个用例的用例，并提供一份诚实的清单，供您根据自己的情况（而不是 Netflix 的情况）做出决定。

这个论文很简单，也不受欢迎：对于大多数项目来说，大多数时候，制作精良的整体是正确的选择。微服务解决了许多团队尚未解决的特定问题，过早采用它们是您犯下的最昂贵的错误之一。

每个架构到底是什么

Monolith 是作为一个单元构建的系统：一个应用程序、一个部署、一个主库。一切都在一起，紧密地结合在一起。长期以来，这个词带有不公平的贬义语气，[monolith2] 并不是混乱的代名词。组织不良的整体是一团糟。组织得很好，很简单。

微服务将系统分割成小的、独立的服务，每个服务都拥有一种功能，通过接口进行通信。他们以分布式复杂性为代价获得了自主权和粒度可扩展性。

它们之间的选择本质上并不是技术性的。这是一项业务决策：关于团队规模、变革速度、规模和对运营复杂性的容忍度。

[monolith3 通常是正确的答案。

当团队规模较小时，他会获胜。很少有开发人员可以在单个代码中自然地协调，而不需要维护数十个服务的开销。当产品处于早期阶段，仍在弄清楚它是什么时，它会获胜，因为改变[单体4]内的边界是微不足道的，而改变服务之间的边界是痛苦的。

当规模适中时，它会获胜，绝大多数系统从未达到证明分发合理的数量。当操作简单性很重要时，它就会获胜：一次部署，一个地方调试，一个堆栈需要掌握。在公共部门和精益团队中，这种简单性通常可以保证连续性。

微服务在特定条件下大放异彩。

当团队规模较大并且多个团队需要并行工作而不会相互干扰、服务和部署的每个所有者时，他们就会获胜。当规模非常不平等时，系统的某些部分需要其他部分不需要的资源，只允许扩展所需的资源，他们就会获胜。

当不同各方有不同的技术需求并证明不同的堆栈是合理的时，他们就会获胜。当故障隔离至关重要时，当一个功能在任何情况下都不能推翻另一个功能时，它们就会获胜。

请注意这种模式：所有这些情况都假设存在尺寸问题。大团队、大规模、大复杂性。没有问题，解决方案就会变得沉重。

选择之前，请如实回答。第二组的回答越多，平衡就越倾向于[微服务5。

有利于[整体6。 团队少于，比如说，十几个人吗？产品还在验证它的本质吗？当前的规模对于单个系统来说是否合适？团队是否对分布式系统缺乏经验？操作简单性和基础设施成本低是优先考虑的吗？如果大多数人都是“是”，那么就继续使用整体架构。

有利于微服务的迹象。 多个团队在相同的代码上相互运行，部署变成一个队列？是否存在尺寸显着不同的部件？是否真的需要不同的堆栈？是否因业务需求需要隔离故障？组织在[可观察性7?、自动化和分布式操作方面已经成熟吗？如果大多数人都同意，那么迁移就开始证明自己的合理性。

如果您只需要一个问题：“这周[微服务8]会为我解决哪些具体的痛点？”如果答案很模糊，“变得更现代”，“为未来做好准备”，那么你还不需要它们。如果它是具体且痛苦的，也许你需要它。

成熟需要谈论第三种方式。决策很少需要是二元的和明确的。

对于大多数人来说，最明智的路径是模块化**[单体9**：单个系统，但内部组织成边界清晰的模块，就好像它们是尚未分离的服务一样。您可以获得单体应用的操作简单性，并且当特定模块确实需要成为服务时，提取会容易得多，因为边界已经存在。

这条路径避免了两个相反的错误：泥团整体，以后无法分离，以及[微服务10]的过早爆炸，让小团队窒息。从简单开始，保持边界清晰，让架构在真正的压力下不断发展。

##反思：错误选择的隐性成本

这两种错误都会付出代价，但它们是不同的。

当你需要时选择一个整体[微服务11]会产生协调摩擦和规模限制，这些都是真正的问题，但它们会逐渐出现并给予反应时间。过早选择微服务会立即造成分布式复杂性：小团队淹没在网络、数据一致性和分布式调试中，并浪费数月时间构建基础设施而不是产品。这个错误往往更致命，因为它消耗了刚起步的人最稀缺的资源：时间。

整体架构与[微服务12]并不是关于哪种架构更好的争论。这是一个关于你有什么问题的问题。如果没有规模、团队或隔离问题，微服务就不是进步，而是复杂性，收费很高但交付很少。

成熟的决策从简单开始，并根据需求不断发展。优秀的技术领导者会抵制为可能永远不会到来的未来而构建的诱惑，并选择能够解决当前问题的架构，而不会关闭明天的大门。

如果您现在正处于这个十字路口，那么在做出决定之前，值得诚实地检查一下清单。我还有其他关于[微服务13架构、可扩展性和用例]的博客文章，如果您想分解您的特定场景，那么这是值得进行的对话。