自2005 年首次推出以来，关于采用微服务架构、整体服务架构还是两者混合的争论已经成为大多数工程组织做出的最不可逆的决策之一。即使迁移到不同的数据库技术通常也比从单体迁移到微服务或从微服务迁移到单体更便宜。
从 2010 年代大多数超大规模企业参与多年的整体架构到微服务迁移，到Kelsey Hightower 关于分布式整体架构的危险的标志性推文，业界在很多方面都围绕着这场争论进行了完整的讨论：
2020 年预测：在人们发现分布式单体应用程序的缺点后，单体应用程序将重新流行。 – @KelseyHightower
尽管大众情绪普遍远离微服务，但许多工程组织两者都有，通常是一个或多个早期但不完整的迁移工作的回忆。该策略着眼于同时采用这两种方法的理论组织，我们将其称为“理论合规公司”，该公司正在寻求确定其前进的道路。
这是理论合规公司的服务架构策略。
这是一本关于工程策略的书的探索性草稿章节，我正在#eng-strategy-book中集思广益。因此，一些链接指向其他草稿章节，包括已发布的草稿和非常早期的未发布的草稿。
阅读本文档
要应用此策略，请从顶部的Policy开始。要了解此策略背后的想法，请按预留顺序阅读各部分，从“探索”开始，然后是“诊断”等。相对于默认的结构，本文档从两方面进行了重构，以提高可读性：首先， Operation被折叠到了Policy中；其次， Refine已经嵌入到Diagnose中。
有关此结构的更多详细信息，请参阅制作可读的工程策略文档。
政策
我们的服务架构政策记录在此处。此政策的所有例外情况都必须上报给当地的员工工程师批准，然后与该员工工程师一起上报给 CTO。如果您对政策有疑问，请在#eng-strategy中提问。
我们的政策是：
-
业务部门应始终在自己的代码存储库和整体中运行。他们不应该提供许多不同的服务。他们很少应该在其他业务部门中工作。细节上存在细微差别：做出使我们更接近前面的句子的决定。
-
跨业务单元整体的新集成应该使用 gRPC 来完成。这里的重点是新的集成；迁移使用其他实现（HTTP/JSON 等）的现有集成是可取的，但并不紧急。
当决策很微妙时（例如对现有端点的更改），请针对业务速度而不是技术纯度进行优化。当决策远非微妙时（例如全新的端点），请遵守策略。
-
除了新的业务单元之外，我们不允许新的服务。您应该在最合适的业务部门整体或现有基础设施存储库中工作。除非与新业务部门相对应，否则提供新服务始终需要 CTO 在
#eng-strategy中批准。通常不会获得批准，除非新服务需要与现有整体服务显着不同的非功能性要求。例如，如果在更改（例如我们现有的支付服务）之前需要更高的合规性审查，或者是否需要更高的每秒请求，等等。
-
尽可能将现有服务合并到业务部门整体中。我们认为，将现有服务重新整合为整体的每一个选择都应该“在细节上”做出，而不是从自上而下的战略角度出发。因此，我们通常鼓励团队逐步减少其业务部门整体之外的现有服务，但尊重团队根据当地情况做出正确的决定。
诊断
理论合规公司在分解我们的庞然大物方面有着复杂的历史。我们还增加了业务部门的数量，同时限制了对核心业务部门的投资。这是一个复杂的时代，需要应对很多限制。为了提高可读性，我们将诊断分为两个部分：“业务约束”和“工程约束”。
我们的业务限制是：
-
我们按年订阅向其他公司销售企业对企业合规解决方案。有一个主要的、已建立的业务线，以及两个较小的部分验证的业务线，旨在附加到已建立的业务线以增加平均合同价值。
-
公司有2000人。其中大约 500 人在工程组织中。在这 500 人中，大约 150 人致力于“基础设施工程”的最广泛定义，例如开发人员工具、计算和编排、网络、安全工程等。
-
该业务是盈利的，但收入同比增长 10-20%，由于相对于公开市场可比公司的表现略有不佳，这给我们的董事会带来了持续的支出压力。除非我们能够将同比增长提高 5-10%，否则他们预计我们的自由现金流每年将提高 5-10% ，这会危及我们维持长期基础设施投资的能力。
-
主要业务增长正在萎缩。该公司的战略包括组建更多相邻业务部门，以提高新产品的平均合同价值。我们需要在不增加总体预算的情况下为这些业务部门提供资金，这意味着新业务部门的预算必须从我们的核心业务或平台团队中抽离。
除了需要为我们的新业务部门提供资金外，我们还面临着提高核心业务效率的持续压力，这意味着要么加速增长，要么减少投资。在减少投资的同时加速增长具有挑战性，这表明大部分改进将来自于减少投资
-
我们根据业务部门分配平台成本的方法与每个业务部门创造的收入成比例。我们的核心业务产生了我们的大部分收入，这意味着它承担了我们平台成本的大部分，即使这些成本是由新业务线推动的。
这意味着，即使由于组建多个业务部门而给平台团队带来的负担增加，我们仍然面临着减少平台支出的巨大财务压力，因为它主要表现为核心业务的成本，而我们必须提高核心业务的效率。这意味着我们对任何增加基础设施开销的事情都没有容忍度。
我们的工程限制是：
-
我们的基础设施工程团队有 150 名工程师，支持 350 名产品工程师，并且可以肯定的是，基础设施在可预见的未来不会大幅增长。
-
我们在过去六个月内设立了两个新业务部门，并计划在明年再设立两个新业务部门。每个业务部门由一名总经理领导，该业务部门内的工程和产品主要对总经理负责。我们的 CTO 和 CPO 仍然制定实践标准，但这些实践标准或总经理的指示是否是任何特定辩论的最终决定，都取决于具体情况。
例如，一个业务部门一直不愿意支持其产品的随叫随到轮换，因为他们的总经理坚持认为这是一种浪费的做法。因此，该团队通常不会响应页面，即使他们的服务负责影响共享功能的稳定性。
-
我们对服务和整体架构如何随着时间的推移为产品和基础设施组织产生开销进行了建模，并且坚信，一般来说，支持更多服务的基础设施会产生更多开销。我们还发现，在我们的组织中，由于团队重组而导致的服务所有权发生变化，抵消了离开整体后所带来的大部分初始生产力收益。
-
前面的两个观察结果之间存在一些矛盾：拥有更多服务通常会产生更多开销，但不负责任的业务部门破坏共享整体服务的开销甚至更大。例如，我们可以更轻松地对行为不当的服务的使用进行速率限制，而不是错误地共享服务中行为不当的代码路径。
-
我们还提供支付服务，将客户的资金转移给我们。我们对此服务更改的合规性和安全性要求明显高于我们的大多数软件，因为爆炸半径本质上是无限的。
-
我们的主要编程语言是 Ruby，它通常依赖于阻塞 IO，而面向服务的架构通常比单体架构花费更多的时间在阻塞 IO 上。同样，Ruby 在序列化和反序列化 JSON 负载方面效率相对较低，而我们的服务架构需要将其作为跨服务通信的一部分。
-
我们之前曾尝试进行分解，但有许多挥之不去的部分迁移，这些迁移与我们当前的业务部门所有权结构并不完全一致。随着时间的推移，这些新服务的数量持续增长，这给今天的基础设施和未来的产品团队带来了更多的负担，因为他们试图通过各种团队重组来维护这些服务。
探索
在 2010 年代末，大多数大型或规模化公司都在某种程度上采用了服务。很少有人采用微服务，大多数采用者选择面向服务的架构。 Kelsey Hightower 关于 2020 年分布式单体的危险的标志性推文捕捉到了逆转的开始，越来越多的公司认识到运营面向服务的架构的负担。
除了对这些负担的更广泛认识之外，最初推动服务架构的许多云基础设施挑战也开始变得温和。如今，大多数基础设施工程师只知道如何使用云原生模式进行操作，而不是从面向机器的方法开始。 PostgreSQL 等标准数据库技术显着提高了功能。云提供商拥有快速的本地缓存，可以快速检索经过验证的上游包。云计算的供应和成本是可以承受的。慢速编程语言比十年前更快。非类型化语言具有通往类型化代码库的合理增量路径。
这种转变的结果是，如果你观察一家新兴公司，它特别有可能拥有一种后端和一种前端编程语言的整体。然而，如果你观察一家成立五年多的公司，你可能会发现几乎任何东西。一种特别常见的情况是具有大多数功能的整体架构，而分散在整个组织中的团队范围的宏服务不一致。
远离零利率政策也影响了趋势，因为面向服务的架构往往需要更多基础设施才能有效运行，例如服务网格、服务配置和取消配置等。经过适当调整，面向服务的架构应该成本具有竞争力，并且在复杂的工作负载中可能具有优势，但在成本削减的环境中很难维持对基础设施团队所需的投资。这鼓励新公司将自己限制在单一方法上，并促使现有公司试图扭转其分解先前单一方法的努力，但结果好坏参半。