服务网格最近吸引了大量的眼球。每次技术会议期间至少是有几次关于服务网格的讨论，可以轻松地说服人们必须在其基础架构中拥有服务网格。但是，炒作并不能很好地表明新的闪亮技术是否适合您的问题。因此，在下面，我将尝试对服务网格进行反炒作，以期在您决定是否需要它时减少混乱。
历史
让我们回顾历史，看看有关在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。
不必要的开销
不仅在每个服务之前都有一个代理会增加开销并消耗资源，而且您还需要时间（或者一组人） ）进行管理。是的，它可以帮助简化某些任务-是的，现在您可以将带有几行YAML的Canary部署添加到简单的应用程序中。但是，您仍然需要管理代理本身的金丝雀部署，这些代理之前没有代理。问题刚被推高了。
将您的架构限制为代理支持的内容
在阅读本段时，HTTP / 3正在缓慢地推广到Internet。它使用UDP作为传输。为什么使用UDP而不是创建您要求的全新协议？这是因为，除了TCP和UDP之外，其他任何东西都是被容易被屏蔽，互联网上的各种代理（路由器，网关等）“屏蔽”。这种现象被称为ossification。因此，仅保留TCP或UDP是实际选择，甚至UDP也被各种公司代理部分阻止，这减慢了采用速度。
即使您的微服务环境相比Internet而言可能要小得多，您也可以与服务网格进行比较。代理可以通过限制服务之间的通信方式来ossify您的应用程序体系结构。
选择
这对您作为工程师意味着什么？是否需要采用服务网格方法的答案归结为您要改善的微服务环境的状态。与RPC框架相比，服务网格使您能够：
- 与部署服务相比，部署基础架构更改的频率更高。
- 在不更改服务代码的情况下介绍基础设施更改。
要点1.非常重要，无论出于何种原因您都不能经常重新部署服务，例如，可能没人记得它是如何完成的，或者可能还有其他限制。当您的堆栈是异构的时，第2点非常重要。例如，某些服务是用Go构建的，某些是用Java构建的，有些是在Haskell中构建的，等等。定期部署的同类均匀服务定义了服务网格是否是最适合您的解决方案。
结论
围绕服务网格有很多炒作，我认为太多了。但是，在致力于一项技术之前，了解其解决的问题以及制定解决方案的环境至关重要。服务网格并不是最终的“良好实践”，而仅仅是解决一系列问题的一种模式，这是一个沉重的负担。
服务网格是解决许多问题的令人惊奇的技术。并非在每种情况下，它都是最佳解决方案。