Berenberg：

在一个每个人都忙于建设更多事物的时代，一个网络听起来非常独特，而我们也不例外。作为谷歌，我们是云计算领域的后来者。为此，我们的团队开始建设，并在几年内，到2020年，我们通过有机增长拥有超过300个产品和大量的基础设施，拥有多个网络路径。我们的客户注意到这些产品没有集成，我们注意到我们的开发速度实际上很慢，因为每次我们需要发布一个新功能时，我们必须在每个网络路径上的不同基础设施上分别发布n次。

最可怕的部分和最重要的部分是政策。政策是云供应商日夜担心的事情，因为所有的云基础设施都由政策控制。如何确保在每条路径上都按政策控制而没有任何例外，而又不需要修改这300个产品？

为什么建立联系这么复杂？

让我们看看为什么网络如此复杂。左边，您看到的是 Google 产品网络。正如您所知，Google 确实有自己专用的网络，并且他们正在运行 Search 和 YouTube。在此基础上，我们将构建一些云产品，例如这里，Borg 是一个容器编排系统，我们在此基础上构建了 Cloud Run。Cloud Run 顶部有其自己的网络。然后在 GCP 本身上有虚拟网络，称为 Andromeda。在此基础上，我们构建了不同的运行时，例如 Kubernetes GKE 和 GCE，这是一个带有虚拟机的计算引擎。

在那边，再次进行网络连接，GKE 也一样，你知道的，Kubernetes 有它自己的网络层。在其之上有服务网格。然后，同样的事情适用于多云、客户现场或分布式云，这些不同层的地方。那么，发生了什么？在每个环境中我们构建应用程序，这些应用程序再次在不同的运行时上运行，它们具有不同的属性。这种不同网络路径和不同运行时的基础设施组合，造成了我通常所说的瑞士奶酪问题：有些地方可以工作，有些地方则不行。解决方案是什么？解决方案是我们所说的“一张网络”。它是一个统一的服务网络覆盖层。

一个网络（概述）

One Network 的目标是什么？我们说我们希望在服务内统一定义政策，同时受限于我刚刚解释的内容，即它具有计算异构网络、不同的语言运行时、巨 monolith 服务和微服务的共存。这包括不同的环境，包括多云、其他云、公有云和私有云。解决方案是一体化的 One Network，就像一种挫折感。你可以思考，为什么我需要这么多网络？我能不能有一个网络？One Network 就是。政策在网络级别管理。我们迭代到 One Network，因为管理成本和风险的架构变化非常大。它非常关注开源，所以所有的创新都进入了开源，有些则进入了 Google Cloud 本身。

如何解释One Network？我们将基于一个代理。在此之前，每个团队基本上有很多代理战争。一个控制平面来管理这些代理。一个包裹在代理周围的负载均衡器来管理所有运行时，因此包括GKE、GCE、Borg、托管服务、多云。通用数据平面API来扩展生态系统，这样我们可以使用第一方和第三方服务来扩展。统一的策略。

这适用于所有环境。当我在2020年展示这张特定幻灯片时，每个人都说这听起来太好了，简直难以置信。当时就是这样。谁会从One Network中受益？实际上，每个人都会受益。这些是我们列出的从One Network中受益的角色。它们从关注安全策略的人，到关注网络策略的DevOps和网络人员，再到关注大规模微服务或服务 Provision 的SREs。再到那些实际上希望自己的策略而不需要与平台管理员或平台工程人员互动的应用程序开发人员。它具有宽度、深度和同时的隔离，因此是一个分区。同时具有普遍性。每个人都关心大型环境的编排，每个人都关心可观测性。

一个网络原则 - 如何实现？

我们建立One Network的 principles是什么？我们建立在五个原则之上。我们将建立在共同的基础之上。一切皆服务。我们将统一所有路径并支持所有环境。然后我们创建了我们所称的服务扩展的开放生态系统，这些扩展基本上是可插入的策略。然后我们将在所有路径上应用和执行这些策略。

1. 常见基础

让我们从第一个开始。这是我在思考如何解释任何层的 narrowscope 时拼凑在一起的一个网络金字塔。我们从共同目的 Envoy 代理开始，并且我们会更多地讨论它。它是一个开源代理，可以在 GCP 或任何本地环境中使用。然后我们围绕它构建基于 GCP 的负载均衡器，这些负载均衡器实际上可以为虚拟机、容器、无服务器计算提供服务。你可以在其基础上构建 GKE 控制器，现在你有了 GKE 网关，它使用相同的底层基础设施，但现在只服务于 GKE 服务和工作负载，并且理解 GKE 部署的行为。

金字塔的顶端是您完全看不到网关的地方，因为它已被完全集成到Vertex AI中，例如，我们的AI平台。这只是实现细节。所有这些都使用了跨产品和路径相同的基础设施。所有这些层都由一个控制平面控制，我们称之为Traffic Director。它有一个正式的API和一切。当我提到单个时，它实际上并不意味着单个部署，而是可以区域化、全球化运行，或者如果需要隔离，可以为每个产品专门化运行的相同控制平面。它是一个相同的二进制文件在各处运行，因此您可以以相同的方式控制和编排它。

这是One Network架构，Northstar。我想从左边向右边为您讲解一下，您可以看到不同的环境。它从移动设备开始，到达边缘，然后到达云数据中心，再到达多云或本地部署。有三个常见的构建模块，有一个控制平面，Traffic Director，它控制所有的这些部署。Traffic Director和数据平面之间有开源API，这些API调用xDS API。然后是数据平面。数据平面都是开源的，基于开源。它们或者是Envoy，或者是gRPC，这些都是开源项目。拥有这个开源的数据平面，使我们能够将其扩展到多云，到达移动设备，基本上到达任何GCP之外的地方，因为它不再具有专有性。稍微谈谈Envoy代理，它于2016年上映，我们非常喜欢。

我们喜欢它的原因是，它是一个具有所有高级路由和可观测性的现代化新代理。它立即得到了采用。谷歌对此进行了大量投资。我们喜欢它的原因不是因为它是一个优秀的代理，而是因为它是一个拥有这些惊人API的平台。它有三组API。它在代理本身中的控制平面和数据平面之间有配置API，用于配置其最终一致性API。它们提供了管理平面和控制平面功能。有数据平面的通用API。有一个外部AuthZ API，可以进行允许和拒绝操作，因此您可以轻松插入任何AuthZ相关的系统。有一个名为external proc的API，基本上您可以插入任何东西，并且它可以修改其后的内容，您可以修改正文，然后将其返回。这非常强大。然后是用于代理Wasm的WebAssembly二进制API。

还有特定的API。Envoy一开始就有的RLS（速率限制服务）很有趣，它可以通过外部AuthZ实现，因为AuthZ是更通用的，因为它也允许和拒绝，但在这里它是专门的。我们看到在未来我们将会有更多的这种专用API。例如，当我们想到LLM防火墙API时，你可能会认为入站流量可以被分类为AI流量，你可以应用特定于AI流量的规则。你可以进行安全检查。你可以进行黑名单操作。你可以进行数据泄露防护（DLP）。数据平面本身也有过滤器。

Envoy代理有过滤器，包括L4（TCP）和L7（HTTP）过滤器。有两种类型的过滤器，其中一种与Envoy关联并更改所有权。如果作为云提供商进行关联，那么这意味着只能是我们的过滤器，如果客户自行运行，则是他们的。我们不能混合使用。WebAssembly过滤器是一个可以在数据平面中加载第一方和第三方代码的运行时。Google在开源代理Wasm项目上投入了大量资金，并且我们实际上已经发布了一款产品。这些过滤器可以被更改，可以是基于请求、响应或请求-响应，具体取决于您需要如何处理。所有这些都由Traffic Director进行配置。

谈论Traffic Director，它是一个xDS服务器。它做的事情结合了两件事情。它将快速变化的动态配置，例如权重和健康状况，与静态配置（例如如何部署特定的网络设备）结合起来。我们把Traffic Director背后的这个魔法叫做GSLB，即Google全球服务负载均衡器。它是一个全球优化的控制平面。这是谷歌用于为搜索、YouTube、Gmail等发送流量的相同算法。任何与谷歌相关的工作都使用这个负载均衡器。

Global优化了RTTs和后端的容量。它找到最佳路径和最佳权重来发送。它还具有集中式健康检查，因此您不需要在数据平面进行n的平方次健康检查，因为实际上我们注意到，如果您进行n的平方次健康检查，最终会使得数据中的80%吞吐量只是健康检查，只剩下20%用于实际流量。消除这80%的开销是很好的。此外，它与自动扩展集成，因此当流量激增时，您不需要逐步扩展，您可以直接一步扩展，因为您知道将来的流量是多少，并且同时流量会重定向到最近的位置。Traffic Director在这里处理策略编排。因为当管理员创建策略时，它会将其传递给Traffic Director，然后Traffic Director将此策略应用于所有数据平面，并在那里强制执行。

2. 一切即服务

第二个原则是所有东西都是服务。这实际上是一个真实服务的图表。它是一个内部云服务。想想我们如何管理这样的服务？不同的颜色代表不同的含义。不同的框代表不同的含义。线条纵横交错。你如何推理这样的应用程序？如何进行治理？如何在这些之间编排策略？如何管理这些小的独立服务，或者如何将它们分组到不同的组中？One Network 在这里有所帮助。

这些微服务中的每一个都被设想为一个服务端点，它使该策略能够编排和分组这些服务端点，并在不实际接触这些服务本身的情况下对它们进行编排，因此所有操作都是在网络上进行的。有三种类型的服务端点。有一种经典的客户工作负载服务端点，例如，您使用负载均衡器，将其放在前面，就得到了一个服务端点。您隐藏了例如在两个不同地区后面的商品购物车服务。这通常是服务实现的方式。

第二个是较新的模式，其中生产者和消费者之间存在关系。例如，你有一个SaaS提供商，他们在GCP上构建了一个SaaS，然后通过Google Cloud称为Private Service Connect的产品暴露给消费者，该产品通过一个单一的服务端点实现。所有权是分开的，生产者不需要向消费者暴露他们的架构。消费者不知道所有这些生产者正在运行的东西。他们看到的唯一东西是一个通过端点操作的服务。在这种情况下，你可以将生产者视为公司外部或共享服务外部的第三方。

如果你的公司内部有一个共享服务，并且你希望多个团队使用它，那么这就是一种你需要实现的架构，因为你想将自己的实现与使用分离，然后允许每个客户或消费者在服务端点上放置他们的策略。你可以通过消费者暴露一个服务端点，暴露一个服务，或者暴露多个服务。还有无头服务。这些通常由服务网格定义，通常位于单个信任域内。

在这种情况下，服务只是作为抽象存在的，因为这里没有网关，也没有负载均衡器。它们只是后端的一堆IP端口。一个例子 obvious 的是人工智能。我们把这个模型看作是一个服务端点。在这里，生产者是模型创建者，消费者是生成式人工智能应用开发人员。例如，生产者推理堆栈隐藏在专用服务连接后面，所以没有人知道它在那里做了什么。然后不同的应用程序连接到这个特定的服务端点。

3. 统一所有路径并支持所有环境

第三种方法是统一路径和环境。为什么我们要这样做？是为了在服务之间应用统一的政策。要统一路径，我们首先必须识别路径。你可以在这里看到我们识别出的八条路径。这其实是一个概括，实际上还有更多，但我们把它们概括为八条。

然后，对于每一个网络基础设施，您需要实现路径来应用策略。您可以看到，既有用于互联网流量的外部负载均衡器，也有用于内部流量的内部负载均衡器、服务网格、egress代理，甚至是移动设备。让我们一个一个地开始查看。GKE网关和负载均衡器，通常这就是服务实现的方式。我们所做的工作是将Envoy（最初部署的负载均衡器）变成一个托管负载均衡器，并且我们花费了一年多的时间在开源中强化它，使其可以用于互联网流量。我们还有全球和区域部署。

然后，全球部署是为那些有全球受众的客户或真正关心跨区域容量重用的客户使用的，或者一般情况下需要四处移动的客户，而区域部署是为那些关心数据驻留的客户使用的，特别是关心传输中的数据或希望实现区域化的客户，因为区域化涉及到隔离和可靠性部署。我们两者都提供。所有这些都与所有运行时相关。

这里的第二次部署是一个服务网格。Istio 可能现在是使用最广泛的服务网格。关于它们最有趣的部分是，它们非常清楚地定义了服务到服务通信的需求。它需要服务发现。它需要流量管理。它需要安全性。它需要可观测性。一旦将这些分离到这些独立的领域，就很容易独立地插入每个部分。对于 Google 产品，我们有基于 Istio 的云服务网格，但它由 Traffic Director 支持，还支持 gateway API 以及 Istio API。它适用于虚拟机、容器、无服务器。这是现成的。

那么，谷歌在服务网格方面早有涉及，甚至在服务网格成为热门术语之前就已经存在。谷歌服务网格与 Istio 或任何其他服务网格之间的区别在于，我们实现了无代理。我们有一种名为Stubby的专有协议。我们有一个控制平面，它连接到Stubby。我们通过配置来部署Stubby。基本上，它和你现在看到的一样是一个服务网格。我们将这个无代理服务网格的概念暴露给我们的客户和开源用户，gRPC 使用与 Envoy 相同的 API 与控制平面进行通信。

显然，这使我们能够减少消费，因为您有额外的代理。基本上，它是超级平坦的，没有任何维护，因为您不需要安装代理，没有生命周期管理，这里没有额外开销。部署架构类似但略有不同的还有GKE数据平面v2，它基于Cilium和内核中的eBPF。它简化了GKE部署网络。由于没有sidecar，可扩展性得到了提高。安全始终开启，并具有内置的可观测性。对于L7功能，它会自动将其重定向到中间的L7负载均衡器。

移动，其实我们没有产品化。这是一个概念，但我们运行了几年，非常有趣。这将One Network扩展到移动设备，带来了非常有趣的行为，因为首先，与工作负载或以计算为中心的系统不同，由于功耗原因，无法与控制平面保持持久连接。握手方式有点不同。此外，这将需要Traffic Director建立一个缓存来支持。我们在一亿台设备或设备的模拟上进行了尝试，结果非常理想。它使用Envoy Mobile。这是Envoy代理的演变，通常用于Envoy Mobile，这是一个被链接到移动应用程序的库。

其中一个有趣的使用案例是，如果你有1亿个设备，并且其中一个设备行为异常或者你需要确定某个设备，拥有控制平面可以让你识别出那个特定设备，向那个特定设备发送配置，并获取所需的可观测性，或者关闭那个特定设备。这个价值是存在的。另一个也在进行中的项目是控制平面联邦。现在你可以考虑多云或本地环境，客户在GCP之外运行类似的部署，但不是由GCP管理的。现在你正在运行自己的Envoy或你正在运行自己的gRPC无代理网格，使用本地Istio控制平面。在这个架构中，我们使用本地Istio控制平面来执行这种动态配置。确保后端的健康状态被传播，以便如果Traffic Director与本地xDS控制平面之间的连接中断，那么本地或云上的部署仍然可以正常运行，直到他们重新连接。

然后，你仍然只有一块玻璃，你可以管理多个此类的本地或混合云部署或销售点部署。你可以想象，这些可以从一个地方扩展到数千个。将这一切整合在一起，这就是它的样子。我们已经看过这张图片。你拥有所有的负载均衡器和网格，并且它们跨越包括移动和混合云在内的各种环境。

4. 服务扩展开放生态系统

那是一个支柱。我们如何利用这个支柱来实现基于策略的架构？我们引入了服务扩展的概念。对于之前讨论的每个API，无论是外部AuthZ进行允许和拒绝，还是外部处理器，在每一个点上，都有可能插入这些策略。这里的例子是，例如，客户想要自己的AuthZ。他们不喜欢我们提供的AuthZ。他们将能够插入。或者，另一个例子是Apigee，这是我们用于API管理的产品。有了服务扩展，改变了API管理的实际实施方式，因为以前你需要一个专用的API网关来管理API。

在这里，API管理变得无处不在。它会可用，因为One Network非常庞大，可以在任何地方进行插接。同一种API管理可以在任何地方使用，无论是在边缘、服务到服务的通信、还是在出口、网格上。这从点解决方案变成了策略或价值服务的无处不在的存在。这里的另一个例子是第三方WAF。我们有自己WAF，但我们的竞争对手可以带来他们自己的WAF。这是一个开放的生态系统。客户可能能够在同一基础设施上选择和使用不同的WAF。他们不需要插入额外的东西，然后试图将其连接在一起。所有这些都可用。

One Network架构应有尽有。之前我们讨论过它在某一点上的样子，现在你可以看到如何在任何地方、任何一点上插入它，无论是路由策略、安全服务、API管理还是流量服务。它实际上是如何运作的呢？我们有三种类型的服务扩展。其中之一是基于Wasm的服务插件，它刚刚进入公开预览阶段。然后是Callout。这在本质上是无服务器的。你提供代码，我们会为你运行。

通常，人们喜欢将其放在边缘，这样可以立即进行头部操作和其他小功能。然后是服务调用，这本质上是已插入的SaaS。在这里，没有大小或所有权的限制。它只是一个对服务的调用。然后，我们称之为PDP代理。它是一种允许在代理后面插入多个策略以进行缓存的架构。不仅用于缓存，然后您可以对这些策略和那些策略进行操作，然后执行其他操作。这就像对多个策略进行操作。

这些策略都作为服务工具表示，并由AppHub（我们的服务目录）管理。未来，我们计划通过市场来管理所有这些策略，并进行生命周期管理，因为将会有许多这样的策略。问题是人们将如何选择一个WAF而不是另一个WAF。你需要有一个推荐系统。你需要担心如何选择。

5. 制定和执行统一政策

最后但同样重要的是，如何应用和执行统一服务？我们实际上提出了四种编排策略的概念。其中之一是创建分割。如果你有一个扁平网络并希望将其分割，你可以通过暴露一个服务而不发布其他服务来实现分割。这会导致流量通过一个瓶颈点，而在那里，你可以应用策略。这很容易做到，因为一切都是服务，所以现在很容易控制哪些服务是可见的，哪些服务是不可见的。

第二个方法是将策略应用到所有路径。实际上，每个应用程序都有多条路径通向它。例如，将互联网流量和内部流量引导到相同的服务和相同端点是非常常见的部署方式。当发生某些事情时，如何快速将策略应用到所有路径？因为您是在保护该应用程序及其背后的工作负载，而不是担心是否涵盖了所有路径。您应该将这种知识传递给可以去编排路径的编程系统。

第三种方法是将策略应用于整个应用程序。一个应用程序定义了一个边界，所有这些服务和工作负载都位于这个边界内。例如，一个典型的业务边界，一个电子商务应用程序包含前端、中间层、数据库。然后，不同的应用程序包含目录和其他东西。那么，一个应用程序可以调用另一个应用程序的服务。在一个给定的应用程序内，安全管理员可以说，在边界上有一些策略。

例如，只有这个服务可以连接到互联网。应用程序内部的任何东西都无法连接到互联网。这意味着该策略需要应用于每个工作负载，例如，不分配公共IP或不允许出站流量。第四个是将策略交付到服务级别。这是大规模管理。想象一下，你需要为每台VM配置防火墙或一些配置。这样，你就有上千个。相反，你可以将这台VM分组到一个服务中，在服务上设置策略，然后在每个单独的后端进行编排。

通过这个策略管理点、策略决策点和策略执行点的概念，这就是策略执行和策略管理的实现方式。我们之前提到One Network数据平面是策略执行点。策略提供者提供服务扩展和One Network管理点。基本上，它允许客户对更大粒度的组（例如应用或工作负载）提供策略，以实现编排。让我们举几个例子。它是如何工作的？在Google有服务汇流池的概念。

想象一下，现在是凌晨3点，你收到了页面。你会怎么做？你先排水，后思考。这就是谷歌SRE的做法。排水是什么意思？你将流量从你收到页面的地方或从那个服务上转移开。你要排水什么？你可以排水微服务。你可以在区域或地区排水。微服务可以是VMs，可以是容器，可以是无服务器，也可以是一组微服务。流量只是被行政性地转移开了。没有东西被关闭。它仍然是可用的，但它不再接受服务。你的缓解措施已经完成，因为实际上流量已经移动。希望其他区域没有受到影响。你可以自由地调试发生的事情与正在部署的版本。然后一旦你找到问题，你就可以恢复排水，慢慢逐步将流量重新引入，越来越多。恢复到正常设置，然后等待下一次凌晨3点的页面出现。

它如何与One Network配合工作？你可以看到通过不同数据平面、应用负载均衡器、服务网格、gRPC无代理网格或Envoy网格流入的流量，它们现在都指向区域1。然后我们通过xDS API进行drain，流量同时在它们之间转移。在这里，我们只是向你展示了完全转移，但你可以想象转移10%的流量、转移20%的流量，或者你需要转移的任何百分比的流量。或者你可以立即进行drain。

另一个例子是CI/CD Canary发布，我们希望将流量引导到新版本。你可以看到这里有不同客户端，实际上是通过一些网站经过应用负载均衡器的人类。有一个呼叫中心通过内部负载均衡器，销售点通过Envoy边车服务网格，甚至多云本地环境也通过无代理网格。钱包服务有两个版本。有v1和v2。我们在顶部提供，它传递配置，然后我们开始使用v2版本的流量。

将来的网络

一个明天的网络，今天我们在这里，将一切整合在一起。还是同样的画面。我们基本上已经完成了中心部分。多云：我们已经实现了连接，并将其扩展到多云。我们正在处理联邦问题。我们有边缘，当然。我们正在处理移动。这是一项多年的投资。Envoy 的 One Proxy 项目始于 2017 年。One Network 于 2020 年开始。我们的高级管理层承诺有一个长期的愿景。这个努力跨越了 12 个以上的团队。到目前为止，我们已经交付了 125 个独立项目。大多数 Google Cloud 网络基础设施支持 One Network。因为它是基于开源的，所以开源系统可以插入到那里。

一个网络适合你吗？

One Network是否适合你？需要考虑的最重要问题是，你是否有执行层的支持来开展类似的工作？我不会建议任何人单独去做。否则，还需要考虑组织目标。公司的政策是否是公司非常关心的事情？合规性是否是超级重要的事情？多云策略、与基础设施相关的开发人员效率。这些都是开展如此大型项目时需要考虑的重要因素。计划长期愿景，但执行短期胜利。

这基本上是一个成功的故事，因为我们没有这个大的成果。我们一次只做个项目，一次只改善网络，填补瑞士奶酪中坏的洞。我们在这里没有太多谈论生成式人工智能。这就是为什么我们决定请Gemini为One Network写一首诗并画一幅图。如下所示。这实际上是一首相当不错的诗。我喜欢它。欢迎阅读。

问题与解答

参与者：有了所有这些侧车容器和在所有这些服务上运行的Envoy，添加所有这些小跳转会带来多大的延迟？

Berenberg：当它们是本地的时候，它们就处于显微镜下。这是网络运作的方式。我们没有引入任何新东西。

参与者：如今有防火墙、负载均衡器，但您现在在每个服务旁边添加了一层代理，这在今天并不存在。

Berenberg: 不，我们没有。我们所做的，是将所有的负载均衡器标准化为基于Envoy的。我们将所有的服务网格标准化为基于Envoy和gRPC的。无论人们在运行什么，我们都继续运行。我们只是标准化了我们正在运行的网络设备的类型。

参与者：对于那些还没有或不使用服务网格的组织来说，在之前我可以与服务A通信到服务B，现在变成了服务A，代理，代理，服务B。

Berenberg: 没错。这是考虑到Envoy代理，作为一个附加组件它会引入延迟。这就是为什么代理是gRPC。它不会引入任何延迟，因为它只有到控制平面的附加组件通道。你不需要将上下文更改到任何其他地方。我相信它是在1微秒以下。