🙇🏿 👊🏻 👌🏻 什么是服务网络 ✳️ 👭 🚴🏾

大家早上好！

今天，我们很高兴为您提供一篇文章的翻译，该文章简要介绍了一种称为“服务网格”的新技术趋势。在这方面（我们认为），最有趣的解决方案是Istio ，但首先建议的文章是有趣的，首先是对这种现有技术进行明确的比较，并对整个范例进行高级概述。作者Tobias Kunze还写了第二篇关于服务网格的更实用的文章-请求表达是否值得发布其翻译

这篇文章是谈论服务网络优势的两篇中的第一篇。本文介绍了什么是服务网络，其工作方式以及其用途。第二部分探讨了为什么，何时何地使用这样的网络，以及未来的发展。

将应用程序分解为微服务时，很快就会发现，通过网络调用服务比最初想到的要复杂得多，可靠性也不高。现在，必须针对每个客户和每个服务清楚地阐明设计所认为的“正常工作”。客户端必须发现服务终端，确保它们在API版本之间保持一致，并打包和拆包消息。客户还需要跟踪呼叫的执行并管理此类操作，捕获错误，重复失败的呼叫以及在必要时保持超时。客户可能还需要验证服务，日志调用和工具交易的真实性。最后，碰巧整个应用程序必须遵守IAM规则，加密或访问控制要求。

当然，这些问题大多数都不是新问题，并且很长一段时间以来，我们一直在使用可帮助组织消息传递机制的技术，例如SOAP，Apache Thrift和gRPC。但是，最近观察到的是：集装箱的快速分发以及随之而来的服务呼叫的爆炸性增长，水平缩放的程度以及与此相关的服务终端的持续时间短。当复杂性和脆弱性达到新的水平时，就需要封装网络通信并将其带入新的基础架构级别。今天应用最广泛的提供此级别的方法称为“服务网络”。

什么是“服务网络”？

服务网络不是“服务网格”。这是API中介（代理）网络，（微型）服务可以连接到该网络，以完全抽象该网络。正如William Morgan 所说，这是“专用基础架构层，可在服务之间提供安全，快速和可靠的通信。” 服务网络有助于应付开发人员在与远程终端交换信息时面临的许多挑战。但是，应该指出的是，在服务网络的帮助下，主要的操作问题尚未解决。

服务网络如何工作？

典型的服务网络架构。 数据平面中的代理被部署为协同服务器（sidecar），而控制平面则分开放置。

在典型的服务网络中，对已部署的服务进行修改，以使每个服务都带有自己的代理“伴侣” 。服务不会直接通过网络调用其他服务，而是会转向其本地代理伙伴，后者会封装服务之间交换信息的复杂性。这样的一组互连的代理实现了所谓的数据平面。

相反，用于控制整个服务网络中的代理行为的API和工具集称为其“控制平面”。用户在控制平面中设置策略并整体配置数据平面。
为了实现服务网络，既需要数据平面又需要控制平面。

主要参与者：特使，林克，伊斯蒂奥和领事

Envoy是Lyft开发的开源代理服务器。今天，它已在包括Istio在内的许多服务网络中形成了数据平面。 Envoy凭借其便捷的配置API迅速取代了其他代理，该API允许控制平面实时调整其行为。

Linkerd是一个由Buoyant （同时也是第一个服务网络）支持的开源项目。它最初是由Twitter的Finagle之类的Scala编写的，它来自Twitter，然后与轻量级的Conduit项目合并，并重新启动为Linkerd 2.0 。

Istio可能是我们这个时代最受欢迎的服务网络。它由Google，IBM和Lyft联合推出；预计她最终将进入Cloud-Native Computing Foundation （CNCF）项目。严格来说，Istio是一个控制平面，为了形成服务网络，它必须与数据平面结合在一起。 Istio通常与Envoy一起使用，并且在Kubernetes上效果最佳。

领事是控制平面生态系统中一个相对较新的现象。它最适合跨多个数据中心的拓扑，并且专门研究服务发现。 Consul适用于许多数据平面，并且可以在不涉及其他控制平面的情况下使用，例如，无需Istio。他的支持是HashiCorp。

主要优势和优先领域的差异

尽管服务网络的空间在不断发展，但是显然，大多数项目已经想到了在这种网络中应支持的主要功能集：

服务发现 ：发现服务并维护其注册表
路由：智能负载平衡和网络路由，更好的性能测试，自动部署模式，例如蓝绿色和金丝雀配置
稳定性 ：重试，超时和断路器
安全性 ：基于TLS的加密，包括密钥管理
遥测：收集度量并跟踪标识符

除了这些功能（有时基于它们）之外，还有更丰富的功能级别，在这些功能级别上，不同的服务网络之间开始出现严重的差异，这些差异可能对微服务系统的架构师，开发人员和管理人员有价值。例如，Envoy支持WebSockets，但Linkerd 2.0（尚未）。虽然Istio和Consul支持不同的数据平面，但Linkerd仅适用于自己的数据平面。领事拥有自己的内置数据平面，当性能问题成为重中之重时，可以将其替换为功能更强大的数据平面。 Istio被设计为单独的集中控制平面，而Consul和Linkerd则完全分布。最后，在上面讨论的所有服务网络中，只有Istio支持故障注入。如果您正在考虑引入这样的网络，则这些只是一些要考虑的关键差异。

服务网络批评

尽管具有明显的普及性和令人鼓舞的诱人功能，但服务网络并未像预期的那样广泛使用。毫无疑问，这部分是由于它们的新颖性以及整个行业继续形成的事实。但是，谈到服务网络，您不能没有批评。

与服务网络相关的怀疑主要与服务网络带来的额外复杂性，相对较低的生产率以及使用多个集群的拓扑时出现的某些差距有关。

服务网络是模棱两可的平台，在实施的初始阶段，需要在系统本身及其仪器设备的组装上进行大量投资。在容器中添加伴侣似乎很容易，但是，有效的故障处理和重试需要认真的工程工作。当使用生命周期短的应用程序或快速开发的应用程序时，很难证明这种投资的合理性。

此外，与使用直接网络调用相比，服务网络会严重降低应用程序性能。在这种情况下出现的问题有时难以诊断，甚至更难以消除。由于大多数服务网络的目标是与独立的微服务应用程序一起使用，而不是针对相关应用程序的整个领域，因此此类网络通常对许多集群和不同区域的解决方案的实施支持不佳。

简而言之，服务网络并不是寻求灵活地适应不断增长的数字服务团队的架构师和运营商的灵丹妙药。这样的网络是一种战术解决方案；它表示“根本”技术改进，旨在解决主要与开发人员有关的问题。在业务级别，他们不会扭转这种情况。

什么是服务网络