服务网格是什么（服务网格的作用分享）

什么是服务网格？

问题： 您能否简单介绍一下服务网格到底是什么以及它与常见的连接挑战有何关系？

Scott： 服务网格背后的理念是，我们倾向于将应用程序分解为不同的服务和组件。一个执行用户注册、查找或评论的组件，然后是一个将所有这些其他后端服务整合在一起的组件。

所有这些服务都需要相互通信，但它们需要一些共同的功能。他们希望对服务流量进行身份验证，以确保它是它声称的人，并防止未经授权的流量或类似性质的东西。

他们想要控制服务之间可能进行的 API 调用类型。服务网格背后的想法是将所有这些功能构建到底层应用程序平台中，这样应用程序开发人员就不必在他们正在开发的应用程序中自己编写这些功能。然后，他们可以专注于为其业务增加价值的功能和特性。

API 网关与服务网格

问题：我们得到的一个常见问题是这与API 网关相比如何？

Scott： 考虑它的最佳方式——至少我是这样想的——是 API 网关更适合服务流量。您可能还会看到它被称为南北交通。这是来自应用程序消费者或一组服务消费者的流量。这通常是源自您的数据中心或云环境之外的流量。它可能来自数据中心的另一部分或来自另一个应用程序的云环境。但无论如何，它是来自服务网格之外的流量。

然后，一旦该流量进入服务网格，服务网格就负责我们所说的服务到服务流量或东西向流量。这就是大型应用程序的各个组件开始相互通信的地方。我们希望将诸如流量路由和速率限制之类的东西应用于该流量。

因此，可以将其视为 API 网关处理南北用户或服务流量，而服务网格处理服务到服务或东西流量。

服务网格与其他网络工具

问： 我们谈论服务网格很像它是一个新事物，但这个概念已经存在了很长一段时间。您能谈谈这与之前的其他网络工具相比如何吗？

Scott：我有网络背景。我在以前的角色中花了一些时间在网络空间。我们在网络世界中有征求意见 (RFC)。这在互联网协议和东西的设计中很常见。并且只有一个 RFC 称为十二个网络真理。它是我们称之为笑话 RFC 的系列之一。

事实 11 是，每个旧想法都会在不同的演示文稿中以不同的名称再次提出，无论它是否有效。这是在试图变得有趣而网络工程师试图变得有趣的背景下，但是如果您考虑一下，如果您已经在该行业工作了很长时间，那么您已经看到了这些趋势然后去，然后他们又回来了。它们可能略有不同。它可能附带一些新技术。那里可能有真正的价值。但它仍然是先前事物的转世或先前事物的演变。这就是我看待服务网格的方式。

我们有这种将逻辑网络与物理网络分离的技术趋势。无论您的物理网络拓扑是什么样的，都与在其上运行的应用程序或工作负载无关。Kubernetes本身就是网络拓扑解耦的一种形式，我们有这些覆盖网络，其中 pod 相互通信。这对于底层网络拓扑的底层网络结构无关紧要。

服务网格是这些技术的演变。而且它并没有过多地关注底层网络的东西。但同样，它带来了应用程序意识和更高级别的功能。

这包括诸如服务到服务身份验证或双向 TLS (mTLS) 之类的东西，即加密和身份验证。这类事情需要服务网格在堆栈中更高，并且更了解它正在与之通信的应用程序和服务，而不是之前的一些迭代，这些迭代在堆栈中较低并且只关注 IP 地址或其他东西那种性质的。这是逻辑网络解耦的演变，并带来了更多的应用程序意识和更多的功能。

服务网格的好处

问题： 您能具体介绍一下服务网格为用户带来的一些好处吗？

Scott：这个问题的答案将取决于你如何定义用户。让我给你两个观点。

消费者

首先，如果您将用户定义为使用您的应用程序的人，例如普通的 Joe 正在使用您通过手机上的应用程序托管的应用程序或类似的东西。如果您在后端实现服务网格，老实说，Joe 不会看到很大的不同。如果你做的一切都正确，他可能会看到你的应用程序更快。他可能会收到更少的关于发生数据泄露、安全漏洞或类似情况的通知。他可能会看到您的应用程序比其他一些应用程序更可靠。而这一切都取决于各种各样的因素。

应用开发商或平台运营商

另一方面，如果您将您的用户定义为应用程序开发人员或平台操作员，他们是您组织内负责确保您的应用程序可用的人。他们工作得很好。它们很高效。而且它们是安全的，那么服务网格带来的好处就是它可以做的所有这些事情，而不需要您将该功能构建到应用程序本身中。

例如，当我们将应用程序解耦为多个服务时，也就是基于微服务的方法，我们可能希望确保应用程序或服务的一部分在与应用程序的另一部分通信时处理应用程序的特定部分。它应该验证这些服务的身份。我们不希望有人意外或故意启动恶意应用程序，然后说，“嘿，看，我是服务 A”，然后开始通信和发送该数据。我们要确保服务 A 实际上是服务 A。

您可以通过将该功能构建到应用程序中来做到这一点。然后，您必须在每一项服务中重复填充该功能。相反，我们可以做的是我们可以将该功能整合到服务网格中。然后应用程序开发人员和平台运营商可以一次又一次地利用该功能。尽管如此，它还是整合到了服务网格中。这适用于服务网格可以提供的所有各种特性和功能，无论是服务到服务身份验证、mTLS、速率限制还是流量路由。

服务网格与其他方法

问题：为了更深入地了解好处，你能谈谈为什么服务网格与其他任何方法相比吗？

斯科特：嗯，有趣的是，到目前为止，业界还没有任何其他解决方案可以做到这一点。服务网格就是它。您可能会在服务网格上看到不同的变体。您可能会看到使用不同的技术来实现服务网格的概念或其变体，无论它是仅支持容器还是容器和虚拟机，还是它支持哪些编排平台——Kubernetes 或 Kubernetes 以及其他平台。但最终，它们都是服务网格，因为它们都做同样的事情。

它们都提供相同类型的服务到服务流量、流量路由、流量整形、速率限制、身份验证等。这只是它们混合使用哪些组件以及它们使用哪些技术的问题。无论他们使用开源 Envoy 代理还是其他东西，最终都是服务网格。老实说，至少据我所知，我们还没有真正看到该行业创造了服务网格的另一种替代方案。

服务网格层中有哪些功能？

问： 这是一种很棒的表达方式。在我们深入了解这个动手操作之前，还有一个问题要问你。您已经以几种方式讨论过这个问题，但是您能否举几个例子来说明该服务网格层中有哪些类型的功能？

Scott： 我们有我们称之为 AuthN/AuthZ 的东西。这些是说身份验证和授权以执行服务到服务身份验证和授权等事情的简写方式。这两者之间的区别在于身份验证是验证服务是服务所说的那个人。授权意味着允许服务做它想做的事情，比如调用 API 或类似性质的东西。

我们有速率限制。我们有高级流量路由之类的东西，能够在第四层和更高级别路由流量——我们称之为第七层，例如在特定路径或 URL 或 API 调用上。

当我们引入 mTLS 之类的东西时，我们会获得加密并加密有线流量以更安全。我们还获得了身份验证机制，其中服务会说，“嘿，你声称自己是服务 A，你用于 mTLS 的证书说你的服务 A。好的，我可以相信身份是正确的，并且你被允许连接和交流。” 所以我们拥有所有这些类型的功能。

我们还可以对您的环境中正在发生的事情获得一些高级可见性或可观察性。我们可以公开有关流量或插入跟踪的其他指标。

我们可以做一些你称之为混沌工程的有限形式，我们可以将错误注入到应用程序开发人员的流量中，以测试他们的应用程序如何表现，或者在遇到错误或中断时它如何优雅地降级。因此，您可以看到很多功能都融入了服务网格。

演示：使用 Kuma 服务网格的流量权限

在演示中，Scott 展示了您可以使用服务网格做的事情之一：流量权限，这是控制允许谁或什么与其他服务通信的能力。与依赖网络地址范围或传统防火墙技术相比，这是一种在应用程序中实施访问控制的更细粒度的方法。