谷歌用TrafficDirector实现ServiceMesh中gRPC服务无代理化

许多组织开始采用服务网格，因为它解决了繁琐而复杂的网络问题，尤其是在大量使用微服务的环境中。它还允许他们在集中的位置管理应用程序网络策略，例如负载均衡和流量管理策略。但是采用服务网格在传统上意味着（1）管理基础架构（控制平面），以及（2）运行代表你的应用程序处理网络的Sidecar代理（数据平面）。

谷歌构建了由Google Cloud管理的控制平面Traffic Director，以解决采用服务网格的第一个障碍--你无需管理另一基础架构（控制平面）。今天，很高兴分享解决第二个问题的新方法--你无需管理大量的Sidecar代理。有了Traffic Director对无代理gRPC服务的支持，你就可以将无代理gRPC应用程序带到基于代理的服务网格中，甚至可以拥有一个完全无代理的服务网格。

Traffic Director对无代理gRPC服务的支持

Traffic Director对无代理gRPC服务的支持基于一个简单的想法：如果Traffic Director可以配置Sidecar代理来代表gRPC客户端进行负载均衡，那么为什么不直接配置gRPC客户端呢？

您可能知道，gRPC是一个高性能且功能丰富的开源RPC框架，它是您每天使用的许多Google Cloud Platform（GCP）服务的基础。 GCP在Google Cloud客户端库中使用它，您可以使用该库访问Cloud Storage，Cloud Pub / Sub等服务。 gRPC处理连接管理，双向流和其他关键网络功能。简而言之，这是构建基于微服务的应用程序的绝佳框架。

但是，gRPC开箱即用，仅提供基于DNS的名称解析和简单的负载平衡。对于服务网格功能（例如，动态发现服务的后端或基于全局邻近性的负载平衡），客户传统上已经转向了sidecar代理。这些Sidecar代理提供了强大的服务网格功能……但它们也是要管理的其他基础架构。

gRPC + xDS

为了使无代理gRPC成为可能，我们在最新版本的gRPC中添加了xDS API支持。 xDS API与流行的Envoy代理使用的开源API相同。它们使xDS控制平面（例如Traffic Director）能够为gRPC客户端配置服务信息，例如端点地址，运行状况，优先级（基于接近性和容量）以及调出服务时要使用的策略。

此外，我们为您的gRPC应用程序增加了对GCP管理的本机gRPC运行状况检查的支持。 Traffic Director从这些运行状况检查中收集数据，并将其用于确定服务端点的运行状况（如上图所示）。

这些附加功能使您能够获得服务网格的好处，而不必在gRPC应用程序旁边部署sidecar代理。

无代理gRPC入门

我们希望使您尽可能容易地获得服务网格的好处。其中很大一部分是减少了对其他基础架构的需求。而且，无代理gRPC入门的过程也很容易：

• 将您的gRPC应用程序更新到最新版本


• 使用新的`xds` gRPC名称解析器


• 添加一个小的引导文件


• 在Traffic Director中配置服务和策略

更广泛地说，您可以将无代理gRPC服务视为在服务网格中部署服务的另一种方式（类似于基于Sidecar代理的服务）。 Traffic Director允许您在服务网格中部署基于代理的gRPC服务和基于代理的gRPC服务。

我们完全希望客户运行包含两个部署模型的服务网格。我们甚至使单个gRPC客户端可以通过无代理路由调用某些服务，并通过Sidecar代理调​​用其他服务。

何时使用无代理gRPC服务

我们看到无代理gRPC方法的三个主要用例：简化的gRPC的采用（归功于托管的网络体验），服务网格中的高性能服务以及将服务网格引入无法添加Sidecar代理的环境。

• 托管网络可简化gRPC的采用 ：我们一直在考虑采用gRPC作为其现代化应用程序堆栈的一部分的客户进行交流。 gRPC的好处很明显，但是就其本身而言，gRPC无法解决客户端负载平衡，服务发现和全局故障转移之类的问题。为了解决这些需求而构建了Traffic Director对无代理gRPC服务的支持，从而使采用gRPC作为现代化部署的一部分变得更加容易。


• 资源效率和性能 ：代理会消耗资源，随着您扩展到成百上千的代理，这些资源可能会开始增加。此外，高性能应用程序可能会发现通过多个Sidecar代理（客户端Sidecar代理，Server Sidecar代理以及再次返回以进行请求/响应交换）发送​​请求时，很难达到性能目标。
  在我们的测试中，我们发现，与sidecar代理相比，无代理gRPC可以节省与网络相关的CPU成本。基准测试表明，引入sidecar代理会由于额外的网络跃点而导致延迟。无代理方法有望在这两个方面节省费用。
  最后，我们认为，这种性能提升对于新兴用例至关重要，例如用于电信网络功能和5G /边缘计算的服务网格部署。


• 适用于无法添加Sidecar代理的服务网格 : 我们已经与不一定能在部署中添加Sidecar代理的客户进行了交谈。某些托管计算环境不允许您启动多个进程（一个用于应用程序，一个用于代理程序）或更改实例的网络堆栈（例如，使用iptables）。在这种情况下，无代理gRPC应用程序提供了一种获得服务网格好处的好方法。

后续

企业网络是异构的。我们构建的Traffic Director具有灵活性，因此我们可以支持满足您需求的部署选项。支持的部署选项包括Envoy Sidecar代理，Envoy中/网关代理（包括我们的内部HTTP（S）负载均衡器，其在后台使用Traffic Director）以及现在的无代理gRPC应用程序。

此初始版本专注于服务发现和负载平衡。我们知道服务网格的承诺远不止于此（例如，基于第7层的流量管理和安全性），但是我们对第一步非常兴奋。我们今天宣布的流量管理功能，以及新的GCP管理的gRPC运行状况检查，只是使服务网格轻松添加到gRPC应用程序的第一步。

PS: 本文属于翻译，原文