微服务隐含成本的星际之门

微服务在大规模协调和协作方面可能简化工作，但将所有辛勤努力转化为成本，最终却成了他人获利的渠道。

作者似乎指出微服务是云服务商的一场阴谋。译自 Falling into the Star Gate of Hidden Microservices Costs，作者 Sarah Morgan 是 Scout APM 的高级产品经理。她在软件行业拥有超过 18 年的经验，主要在波士顿的初创公司工作。她还是 Product School 的特邀演讲嘉宾和产品战略顾问...

这篇文章是系列文章的第二部分。请阅读第一部分。

微服务的支持者声称它能提供更高的开发速度和可靠性；在容器编排器的帮助下进行更全面的测试以及纵向或横向的扩展；以及在工具选择方面拥有更多的灵活性。他们并没有错：当你使用微服务架构构建时，你很可能会在软件开发生命周期（SDLC）的早期阶段看到成本的改善，主要是由于服务的解耦。

这些人利用这种早期的微服务优势来论证单体架构是不灵活的，而且很难完全理解。虽然单体架构可能并不完美，但他们的结论忽略了一个基本定律：你无法从一个封闭的系统中汲取能量，也无法在没有某种反应的情况下，通过魔法般地简化你的SDLC并使其更便宜运营。

上次，我们谈到了一个有意构建的单体架构几乎总是在技术复杂性和开发者人体工程学的方面胜过微服务。微服务确实可以做到这些，但只有在额外的开销下，而这些意外的开销几乎总是流向你的组织之外。远离你的控制和治理。

唯一真正了解这种抽象外观给你带来的代价的方法是追逐单体架构的这个概念，就像《2001：太空奥德赛》中的戴维·鲍曼博士一样，进入能量、成本和错失机会的浩瀚星门。

微服务经常被吹捧的一个好处是，开发人员可以灵活使用不同的语言、框架、库和数据存储来构建他们负责的服务。现实是开发人员更倾向于使用他们熟悉并且效率最高的环境，导致技术栈的扩散。一门新的学科，平台工程，已经形成以应对这种模式，通过“黄金路径”——一套语言、工具、库、配置和依赖的平台——来规范内部开发实践。

谁受益？你的云服务提供商。标准化的最后一站是部署的时刻，在这一刻，你的 API 或应用被抽象成一个或一小部分请求，位于特定的域名上，执行操作并返回数据。你的微服务越不凝聚，你对它们的部署就越缺乏控制，你就越依赖于云服务提供商的灵活性和弹性来完成工作。你越依赖于一个服务，你就越有可能与一个友好的销售人员聊一聊升级到他们的企业定价层。

假设每个团队都依赖于微服务的灵活性来构建最适合他们的方式。你的生产基础设施现在需要六种不同的数据存储，一堆混合了服务器/无服务器资源和共享库的资源。如果让每个团队负责配置和提供他们需要的基础设施，你将拥有一片混乱的复杂性海洋，任何DevOps或ITOps团队都难以理解，更不用说维护了。

谁受益？你的CI/CD提供商。这些分散的技术栈以可靠且可扩展的方式部署的唯一方法是通过自动化，这意味着你更加依赖于你的流水线能够可靠地工作，并在海量碎片化的变更突然破坏时迅速通知你。每次CI/CD运行都会慷慨地增加你每月的分钟和存储总数，更不用说不同计算能力的运行器了，你还需要支付额外的座位来保持人们的参与。

David Heinemeier Hansson，Basecamp的CTO和Ruby on Rails的创始人，曾经写道：“在几乎所有情况下，用网络调用和服务分区替换方法调用和模块分离，即便是在一个统一的团队和应用中，也是一种疯狂的做法。”

这些调用横跨了巨大的物理距离，经过了许多网络、提供商、API网关等等的层层环节，本质上是昂贵的。它们引入了应用程序失败的新的、通常难以观察到的方式。你将需要开发新的防御机制来对抗这些错误，比如批处理和异步通信，并且加入新的可观测性工具，以帮助捕捉不影响最终用户体验但表明底层存在较大问题的 API 优雅失败。

谁受益？你的第三方提供商，例如 API 网关、服务网格、消息队列等等。最初是服务解耦导致了几乎完全的断开，唯一将它们重新组合的方式就是复杂化你的基础设施，并支付某人来收集和控制你认为已从系统中剥离的能量。

在微服务架构中，你可以选择两条路径：首先，每个团队负责监控其服务的健康和性能，一直到轮班和故障排除手册。他们的部署速度直接与平均故障恢复时间（MTTR）相关，因为当问题出现时，他们还负责开发和部署适当的修复。

这对于孤立的错误很有效，但是对于神秘地穿越多个微服务的问题呢？

这就是第二条路径的出现的地方。你有一个专门的团队，称之为ITOps/DevOps/DevSecOps/平台工程等等，负责创建一个“单一视图”的可观测性仪表板。通过足够的投资，他们将能够看到一切，了解一切，并解决在本地测试环境中由于基础设施复杂性而无法复制的最复杂的问题。

谁受益？昂贵的可观测性平台。在你的微服务架构中，你将为每个节点、容器和无服务器功能付费。为每个团队所需的每个座位增加更多费用。为机器学习驱动的洞察力支付更多费用，这是你不可避免地需要的，以帮助你精确定位异常并查找根本原因，需要翻阅十几个 API 调用。

当你在微服务架构中部署应用程序时，你有许多扩展的选择。这基本上是微服务崛起的核心价值主张——以技术为驱动的初创公司早已将他们整个的工程努力组织在一个假设的恐惧周围，即他们的公司将会迅速而深刻地增长，以至于无法跟上负载。

在 Kubernetes 环境中，每个服务都可以通过编辑单个 YAML 配置文件的几行来实现独立的垂直扩展（使用更多的计算资源）或水平扩展（分布在更多的 pod/node 中）。在你的可观测性平台中看到某个服务运行得有点“热”吗？提高它的 CPU 请求。这没起作用？尝试将其副本数量从三个加倍到六个，让 ReplicaSet 处理其余的事务。

微服务扩展的简单性很容易掩盖底层的低效性。以亚马逊 Prime Video 的经验为例，他们使用基于微服务的工具来识别块损坏和同步问题。由于他们使用 AWS Lambda 和 Step Functions 的方式，他们在期望负载的约 5% 处迅速遇到了硬性扩展限制。

即使有企业规模的预算，唯一的解决方案是将微服务架构放弃，回到一个可以更好地依赖可扩展的 EC2 和 ECS 实例的单进程单体结构。

谁受益？再次是你的云服务提供商。他们承诺给你可扩展性，并以更高的月度账单提供了一种多彩的应急解决方案。作为回报，你能够奢侈地假装，至少在更长一段时间内，重构并未即将来临。

我们并不会主张单体结构是完美的。但一个经过有意设计的单体结构对每个缺陷都有一个可理解的解决方案，与微服务架构不同，你解决的每个问题都会在内部范围内创造一个改进的反馈循环。

要改进单体结构在某个方面——性能扩展、新开发人员入门的便利性、代码的质量——你需要投资于应用程序本身，而不是将问题抽象到第三方或接受更高的云计算账单，希望规模会解决你的问题。

关于他们的经验，亚马逊 Prime Video 团队写道：“将我们的服务转移到单体结构后，我们的基础设施成本减少了超过 90%。它还提高了我们的扩展能力。……我们所做的更改使 Prime Video 能够监视我们客户观看的所有流，而不仅仅是观众最多的那些。这种方法导致了更高的质量和更好的客户体验。”

自亚马逊 Prime Video 工程团队发布他们的博客文章以来，很多人争论他们的转变是单体结构的重大胜利，还是带有新品牌的老掉牙的微服务架构，或者是对“服务”是什么的语义误解。无论现实如何，他们的故事仍然是对微服务益处被宣传为无限的引人注目的例证，仿佛复杂性可以简单地离开系统。实际上，它仍然隐藏在那里，等待着你撞到众多硬性限制之一。

这些挑战和硬性限制在单体结构中仍然存在。可扩展性、更全面的监控以及对部署的更好的最终用户体验是我们永远不会完全满意的努力类型。即使要使它们达到一半正确的水平，也需要时间、专业知识、毅力、创造力和大量的费用。但是有了单体结构，至少这些成本是你要承担的。你的胜利也是如此。

拥有成本和胜利的另一种好方法？不仅要有意地构建一个单体结构，而且要在一个单一代码库上进行。接下来，我们将回到我们的单体系列的第三部分，重点讨论单一代码库作为代码、对话和协作相遇的神奇点。