您不需要任何服务网格

服务网格在其周围吸引了大量宣传。在每次技术会议期间至少进行了几次有关服务网格的讨论，可以轻松地说服必须在其基础架构中拥有服务网格。但是，炒作并不能很好地表明新的闪亮技术是否可以解决您的问题。因此，在下面，我将尝试对服务网格进行反炒作，以期在您决定是否需要它时减少混乱。

这里有一个教训，我不会成为一个要解决的问题。

让我们回顾一下历史，看看有关介绍Lyft的Envoy的早期文章之一。

事实证明，几乎每个具有中等规模的面向服务架构的公司都存在与Lyft在开发和部署Envoy之前所遇到的相同问题：

一种由多种语言组成的体系结构，每种语言都包含一个半熟的RPC库，包括速率限制，电路中断，超时，重试等的部分（或零）实现。

尽管Envoy本身并不是服务网格，但概述的问题描述了发明服务网格的确切原因。通过强制通信经过服务网格代理（即数据平面），它们为服务添加了“速率限制，断路……”以及其他可靠性，可观察性和安全性功能。此外，它们需要一个单独的组件（控制平面）来控制配置。

但是，在这一点上，很多人都错过了引入服务网格的环境。服务网格能够解决问题不是因为不可能以其他任何方式解决它们。有许多具有战斗力的RPC库正面临着单独的数据平面层的挑战，例如Finagle，gRPC，Armeria，Servicetalk等。毕竟，第一个服务网格-Linkerd 1.0由Finagle支持。 RPC库将需要一个组件来提供服务发现和配置管理，以使其成为真正的网格。例如，服务网格的Zookeeper或Consul，称为控制平面。

为什么要引入一个新概念来解决以前已经解决的问题？没有引入服务网格概念来解决以前从未解决过的问题，而是以不需要对应用程序代码进行任何修改的方式解决这些问题，当难以在其中引入RPC层时，这非常方便现有的异构微服务环境。

当您听到服务网格时，Istio和Envoy可能是您想到的第一件事，但这并不是第一个进入市场的服务网格。率先开发此空间的Linkerd作者在“为什么需要服务网格”中准确地描述了这种情况。有趣的是，在Internet上许多宣传文章中，这种情况经常被忘记或省略。

很好地解决问题，即使很多人都遇到了问题，也无法为技术带来很多炒作。背后总是有一个赞助商。我不知道赞助人是谁，我将推测，但是在开源是基本要求的世界上，很难出售RPC库。那里没有明确的业务模型，这就是为什么大多数成熟的RPC库都是由大型科技公司开源的，而它并不是核心业务模型的一部分。库只是代码，而不是基础架构的一部分。服务网格是另一回事。这是一个孤立的重要基础设施。作为供应商，您不仅可以提供有关配置和部署的咨询，还可以出售围绕它的完整托管解决方案。

现在，我们已经确定了问题，解决方案，最重要的是，提出解决方案的背景已经确定，让我们看一下替代方案。秉承KISS的精神，最明显的方法是使用RPC库作为您的首选语言。这是上下文至关重要的地方：如果您有大量的服务，每个服务都以自己的语言/生态系统编写，并且它们共享的唯一语言是HTTP，那么拥有一个共享的RPC库将变得很困难。也许，您已经部署和运行了一些服务，但是每个人都害怕接触它们，没人知道它们是如何工作的，每次重新部署都是一次冒险。服务网格可以为您提供帮助，因为至少您可以定期向网格中推出新的基础架构功能。

另一方面，如果您在单个应用程序堆栈中编写了一系列健康的服务，那么在引入服务网格之前最好三思而后行。通过简单地引入或发展共享的RPC库，您将获得完全相同的好处，并且避免了维护服务网格的弊端。通过彻底研究服务网格限制，您可以避免陷入幻想破灭的低谷。

您选择的服务网格的生态系统可能与您服务的生态系统不同。漂亮的网站总是让您相信该解决方案是即插即用的，始终有效，而且永远不会失败。实际上，迟早出现的问题，错误，行为怪异都会像往常一样暴露出来。到那时，您需要让工程师在服务网格的生态系统中工作，当该生态系统与主应用程序不同时，该生态系统将有效地限制可以引入更改或解决问题的人员。这很可能会重新引入孤岛，这与整个DevOps精神背道而驰。是的，拥有一个正在进行DevOps-y事务的DevOps工程师团队会反对DevOps。

不仅在每个服务之前都有一个代理会增加开销（通常很重要，在性能摘要中谈论90pt而不是99pt并不会使软件运行更快）并消耗资源，而且您还需要时间（或者一组人） ）进行管理。是的，它可以帮助简化某些任务-是的，您现在可以将带有几行YAML的Canary部署添加到简单的应用程序中。但是，您仍然需要管理代理本身的金丝雀部署，这些代理之前没有代理。问题刚被推高了。

在阅读本段时，HTTP / 3正在缓慢地推广到Internet。它使用UDP作为传输。为什么使用UDP而不是创建您要求的全新协议？那是因为，除了TCP和UDP外，其他任何东西都只是被盒子，互联网上的各种代理（路由器，网关等）“阻止”了。这种现象被称为ossification。因此，仅保留TCP或UDP是实际选择，甚至UDP也被各种公司代理部分阻止，这减慢了采用速度。

即使您的微服务环境相比Internet而言可能要小得多，您也可以与服务网格进行比较。代理可以通过限制服务之间的通信方式来僵化您的应用程序体系结构，并且如果可以绕过代理，则代理并没有太大好处。假设您要构建一个在纯tcp上使用RSocket的反应式应用程序？还是使用角色模型的消息驱动的应用程序？还是可以突破Aeron的性能界限？直到中间的方框意识到协议后，这种情况才会发生。

这对您作为工程师意味着什么？是否需要采用服务网格方法的答案取决于您要改善的微服务环境的状态。正如我们已经建立的，与RPC框架相比，服务网格使您能够：

如果您出于某种原因无法经常重新部署服务（例如，也许没人记得它是如何做的，或者还有其他限制。当您的堆栈是异构的时，例如点2。有些服务是用Go构建的，有些是用Java构建的，有些是用Haskell生成的，依此类推。您处于从部署计划未知的大量异构服务到定期进行均匀部署的同类服务之间的时间间隔，以确定服务网格是否是最佳的为您解决。

服务网格周围有很多炒作，我认为这太多了。但是，在致力于一项技术之前，了解其解决的问题以及制定解决方案的环境至关重要。服务网格并不是最终的“良好实践”，而仅仅是解决一系列问题的一种模式，而且相当繁重。

与其仔细观察，不如不做任何准备-您要做的最后一件事就是发现您已为解决您没有的问题投资了解决方案。服务网格是解决许多问题的令人惊奇的技术。并非在每种情况下，它都是最佳解决方案。

“您不需要任何服务网格”。刚刚发表了一篇新博客文章，对被过度炒作的话题发表了反炒作的看法。 https://t.co/SVXS3nWKzj

-Sergey Tselovalnikov（@ SerCeMan）朱莉娅23，2020