微服务在大规模协调和协作方面或许简化作业，但将全部辛勤尽力转化为本钱，最终却成了别人获利的渠道。

作者好像指出微服务是云服务商的一场诡计。译自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 工程团队发布他们的博客文章以来，很多人争论他们的改变是单体结构的重大成功，仍是带有新品牌的老掉牙的微服务架构，或者是对“服务”是什么的语义误解。不管实际如何，他们的故事依然是对微服务好处被宣传为无限的引人注目的例证，似乎复杂性可以简单地脱离系统。实际上，它依然躲藏在那里，等待着你撞到很多硬性限制之一。

这些挑战和硬性限制在单体结构中依然存在。可扩展性、更全面的监控以及对布置的更好的最终用户体会是咱们永久不会彻底满足的尽力类型。即使要使它们到达一半正确的水平，也需求时间、专业知识、毅力、发明力和很多的费用。可是有了单体结构，至少这些本钱是你要承当的。你的成功也是如此。

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

本文在云云众生（yylives.cc/）首发，欢迎我们拜访。