One Network：云无关的服务和面向策略的网络架构

One Network 是一个统一的服务网络覆盖，它简化了跨不同服务和环境之间的策略管理。它旨在提供一个单一的、网络级别的策略执行方法，该方法可以跨公共云和私有云、多云设置和各种部署模型工作。

在2024年旧金山QCon上，我分享了这项为期 7 年的努力的经验和成就。

背景

当谷歌开始使用云计算时，我们是中途加入竞争的。在 2020 年左右，我们的团队拥有了一个由 300 多个产品组成的生态系统，每个产品都在自己的基础设施上运行，并遵循不同的网络路径。这种快速、有机的增长导致我们的服务整合度很差，很明显，发布新功能变得繁琐。每个新功能都必须针对每个产品和网络路径单独实现。

真正的挑战是政策管理。策略是云基础设施中最关键的部分，控制着从安全性到流量策略和合规性的所有内容。由于有这么多独特的产品和网络路径，我们需要一种方法来集中管理策略，而不必修改每个单独的产品。这一认识为“One Network”的构想奠定了基础。

网络复杂性之所以存在，是因为谷歌的基础结构有自己的网络堆栈。该网络堆栈支持搜索和 YouTube 等服务。随着云产品的不断增加，出现了容器系统、虚拟网络和服务网格，它们都需要自己的组网规则。此外，谷歌云平台（GCP）包括虚拟网络，如 Andromeda。此外，像 Kubernetes （GKE）和 Compute Engine （GCE）这样的运行时也添加了它们自己的网络层。服务网格运行在这个基础设施之上，增加了另一层抽象。

由于应用程序是在这些环境中构建的，因此它们运行在具有独立网络路径的不同基础设施上。这就造成了一个复杂的 n 平方问题，我经常将其描述为瑞士奶酪：在一个环境中有效的东西可能在另一个环境中不起作用。这就是 One Network 的灵感来源，一个统一的服务网络覆盖层，为所有这些多样化的环境带来一致性和集成。

One Network 概述

One Network 的目标是实现跨服务的统一策略。为此，我们希望克服异构网络、不同语言运行时以及单体服务和微服务共存的复杂性。这些复杂性跨越多个环境，包括公共云、私有云和多云设置。One Network 的理念是通过问“为什么我需要这么多网络？我不能只有一个网络吗？”来简化当前的状况。

为了进一步解释，One Network 依赖于一个单一的代理，一个管理这些代理的控制平面，以及一个负载平衡器，该负载平衡器支持跨不同云环境的各种运行时，如 GKE、GCE 和 Borg。通用数据平面 API 通过第一方和第三方服务扩展生态系统，并提供可插入第一方和第三方服务的扩展性 API，从而在整个环境中实现统一的第一方和第三方策略。

最初，许多人认为这样的制度“好得令人难以置信”。但后来，来自安全策略、DevOps、网络或应用程序开发相关角色的每个人员都从中获得了一些好处。

One Network 是一种具有宽度、深度和隔离性的解决方案。它的通用性使其能够协调大型环境并提高可观测性。

One Network 原则

我们基于五项原则建立了 One Network。首先，我们要建立一个共同的基础。其次，一切都被视为一种服务。第三，我们的目标是结合所有路径，支持所有环境。

第四，我们创建了一个开放的生态系统，我们称之为服务扩展，它本质上是可插拔的策略。最后，我们在所有路径上统一地应用和执行这些策略。

我们基于五个原则构建了 One Network：

• 在共同的基础上构建。

• 一切都被视为一种服务。

• 合并所有路径并支持所有环境。

• 创建一个开放的生态系统，我们称之为服务扩展，它本质上是可插拔的策略

• 跨所有路径统一应用和执行这些策略。

原则 1：共同基础

让我们从第一个原则开始。下面的 One Network 金字塔解释了我们如何在每一层缩小范围。在基础层，我们使用 Envoy 代理，这是一个可以在任何地方使用的开源代理，无论是在 GCP 上还是在本地。围绕 Envoy，我们构建了基于 GCP 的负载平衡器，适用于虚拟机、容器和无服务器。

最重要的是，我们有 GKE 控制器和 GKE 网关，它们使用相同的基础设施，但仅服务于 GKE 工作负载。

Vertex AI 在顶部；网关只是一个实现细节。所有这些层共享相同的基础设施，并由一个单一的控制平面（Traffic Director）管理。这个控制平面可以按区域、全局或特定于每个产品部署，但它始终是相同的二进制文件和 API，在任何地方都能实现控制和一致的编排。

查看下面的 One Network 架构，你可以看到从左到右、从移动到边缘、再到云数据中心、多云和本地环境（on-prem）的路径。

三个主要的构建块是：Traffic Director 控制平面，Traffic Director 和数据平面之间的开源 xDS APIAPI 链接，以及开源数据平面本身（Envoy 或 gRPC）。数据平面的开源特性使我们能够跨云和环境进行扩展，而不仅限于 GCP。

谷歌投资了 Envoy 代理，它于 2016 年推出，是一个现代的代理，包括配置 API、通用数据平面 API、外部 AuthZ 及处理钩子。它还提供了专门的 API，比如速率限制。Envoy 支持 L4 （TCP）和 L7 （HTTP）过滤器，可以是通过 WebAssembly 提供的第一方或第三方服务。有两种类型的 WebAssembly 部署：一种链接到 Envoy，改变所有权；另一种在进程外运行。谷歌在开源代理 WebAssembly（Wasm）项目上投入巨大。使用 Wasm 过滤器，你可以将第一方和第三方代码加载到数据平面中。

这些过滤器支持基于请求、基于响应或请求-响应的流量，具体取决于你需要如何处理请求。Traffic Director 管理所有过滤器配置到数据平面的交付。

Traffic Director 是谷歌内部的一个工具，它充当 xDS 服务器，融合动态和静态配置。它为谷歌的全球负载平衡器（GSLB）提供动力，优化搜索和 YouTube 等服务的流量。

它处理全局路由、后端容量和集中式运行状况检查，以消除 n 平方运行状况检查的开销并释放数据中心吞吐量。与自动扩缩集成后，它可以立即响应流量激增。当管理员创建策略时，Traffic Director 将在所有数据平面上执行该策略。

原则 2：一切都是服务

第二个原则是——一切都是服务。下面是一个真实服务的示意图。

One Network 使你能够通过应用治理、编排策略和管理小型独立服务来管理这样的服务。

每个微服务都被都被视为一个服务端点。这样就可以对这些服务端点进行编排和分组，而无需应用程序开发人员修改服务实现，因此一切都能在网络上完成。

有三种方法可以管理这些服务端点。第一种是经典模型：在工作负载（例如在多个地区运行的购物车服务）之前添加负载平衡器，它将成为你的服务端点。

第二种模式是生产者-消费者关系。例如，SaaS 提供商可以在谷歌云上构建其服务，并使用Private Service Connect通过单个服务端点将其暴露给客户。

在这种设置中，生产者不需要暴露他们的内部架构；消费者只与端点交互。当你希望保持实现细节的私密性，或者当你在公司内拥有多个团队需要访问的共享服务时，此模式非常有用。每个消费者都可以将其策略应用于端点，并且可以根据需要暴露尽可能多的端点。

第三种类型是无头服务，通常出现在单个信任域中的服务网格中。没有网关或负载平衡器；服务被简单地表示为一组 IP 端口。

这里一个明显的例子是 AI 模型：模型创建者（生产者）将推理堆栈隐藏在私有服务连接后面，应用程序消费者可以在不知道其内部工作原理的情况下连接到它。

原则 3：统一所有路径并支持所有环境

第三个原则涉及统一网络路径和环境。这样做的主要原因是允许在所有服务中应用相同的策略。为了统一路径，我们要先识别它们。我们将许多可能的网络路径归纳为八种主要类型：

1. 互联网 -> 工作负载

2. 互联网 -> SaaS

3. VPC -> 工作负载

4. VPC -> SaaS

5. 工作负载 -> 工作负载

6. 工作负载 -> SaaS

7. 工作负载 -> 互联网

8. SaaS -> 互联网

对于每个路径，我们绘制了实现策略实施所需的网络基础设施。这包括针对面向互联网的流量的外部负载平衡器、针对内部流量、服务网格、出口代理和移动环境的内部负载平衡器。

让我们逐一查看一下它们：对于 GKE，服务通常通过网关和负载平衡器呈现。我们采用了 Envoy 作为独立部署，并将其转变为托管负载均衡器。

我们花了一年多的时间对其进行开源加固，使其能够处理互联网流量。有全球和区域部署。全球部署适用于需要为全球受众提供服务或需要跨区域容量的客户，而区域部署适用于那些关心数据驻留、隔离或可靠性的客户。这两个选项都连接到所有运行时。

下一个部署模型是服务网格。Istio 现在是使用最广泛的服务网格之一。服务网格的突出之处在于它们如何将服务到服务的通信分解为不同的关注点：服务发现、流量管理、安全性和可观测性。

每个区域可以独立管理。谷歌云的服务网格基于 Istio，由 Traffic Director、网关 API 和 Istio API 支持。它可以跨虚拟机、容器和无服务器工作。早在 Istio 之前，谷歌就使用无代理方法和称为 Stubby 的协议来提供服务网格。控制平面将直接配置 Stubby，因此它的功能就像一个没有 sidecar 代理的现代服务网格。

我们已经将这种无代理网格的理念向客户和开源社区公开。gRPC 使用与 Envoy 相同的控制平面 API，减少了开销，因为不需要安装或管理代理。

一种类似但略有不同的方法是 GKE 数据平面 v2，它使用 Cilium 和内核中的 eBPF。这简化了 GKE 的网络，通过消除 sidecar 提高了可伸缩性，并提供了始终在线的安全性和内置的可观测性。对于 L7 特性，流量会自动重定向到 L7 负载均衡器。

移动设备是另一个有趣的领域。尽管我们没有将此产品化，但我们尝试将 One Network 扩展到移动设备。

由于功率限制，移动工作负载无法保持与控制平面的持久连接，因此握手与 Traffic Director 缓存配置不同。

我们使用 Envoy Mobile（一个连接到移动应用程序的库）在 1 亿台设备上进行了模拟测试。这种设置允许识别和管理单个设备，提供配置，收集可观测数据，或在必要时关闭恶意设备。

另一个正在进行的项目是控制平面联合，它与客户在 GCP 外部运行部署的多云或本地环境相关。在这里，你可能有自己的 Envoy 部署或带有本地 Istio 控制平面的无代理 gRPC 网格。

本地控制平面处理动态配置和运行状况传播，因此，如果与 Traffic Director 的连接丢失，则本地部署将继续运行，直到重新连接为止。这种设置为数千个内部部署或多云部署提供了一个单一的管理视图。

将所有这些部分结合在一起，架构跨越了负载平衡器和跨环境的服务网格，包括移动和多云，所有这些都统一在一个通用的策略和控制框架下。

原则 4：服务扩展开放生态系统

第四个原则是构建一个开放的服务扩展生态系统。在建立骨干网络之后，下一步是弄清楚如何将其用于策略驱动的架构。这就是服务扩展（Service Extensions）的用武之地。服务扩展基于Envoy的ext_proc过滤器，并从数据路径启用可编程性。对于每个 API，比如允许/拒绝决策或外部处理器的外部AuthZ，都有机会插入自定义策略。

对于授权，有些客户希望使用他们自己的 AuthZ 系统，而不是我们提供的默认 AuthZ 系统。有了服务扩展，他们可以简单地插入自己的授权。

另一个例子是 API 管理。传统上，API 管理需要一个专用网关，比如 Apigee。但是有了服务扩展，API 管理就变得无处不在了，可以在任何需要的地方使用，无论是在边缘、服务之间、出口还是在服务网格中。这将 API 管理的视角从一个点的解决方案转变为整个网络中存在的东西。

类似地，客户或竞争对手可以为 Web 应用程序防火墙（WAF）等安全工具引入他们自己的 WAF。开放的生态系统意味着客户可以在相同的基础设施上选择使用哪种 WAF，而不必构建额外的组件或处理令人头疼的集成问题。

看一下 One Network 架构，现在你可以看到这些扩展可以插入到任何的点上——路由、安全性、API 管理或流量服务。有两种主要的服务扩展类型。首先，有服务扩展插件，它们最近进入了公开预览。它们本质上是无服务器函数：你提供代码，我们为你运行，通常在边缘进行快速头部操作或其他轻量级任务。

第二种是服务扩展标注：SaaS 集成没有大小或所有权限制——只是对带有开源通用外部处理或外部授权 API 的外部服务进行标注。

有一个 PDP（策略决策点）代理，它允许你在代理后面插入多个策略，从而支持策略缓存和复杂策略操作等功能。每个策略都是由我们的服务目录AppHub管理的服务工具。

展望未来，我们正在考虑通过一个带有生命周期管理的市场来管理所有这些扩展，因为可用扩展的数量只会增加。

在这一点上，有方法推荐和选择正确的工具（比如在不同的 WAF 之间进行选择）来帮助客户做出明智的决定是很重要的。

原则 5：应用和执行统一策略

第五个也是最后一个原则是关于如何跨服务应用和执行统一策略。我们总结了四种主要的编排策略类型。

首先是细分。如果你从平面网络开始，但希望创建边界，则可以通过仅公开某些服务并隐藏其他服务来进行分段。这迫使流量通过可以执行策略的特定阻塞点。由于一切都被视为服务，因此控制哪些服务是可见的或隐藏的变得简单直接。

第二种类型是对将策略应用于所有路径。实际上，每个应用程序都可以通过多个网络路径访问。例如，一个服务可能同时接收互联网和内部流量。当你需要快速应用策略（以响应事件）时，你希望确保它覆盖到服务的每个路径，而不必手动跟踪它们。编排系统处理这个问题，以编程方式跨所有路径应用策略。

第三种类型是在应用程序边界应用策略。一个应用程序定义了一个包含其服务和工作负载的边界。例如，一个电子商务应用程序可能包括前端、中间层和数据库，而另一个应用程序可能处理目录。

应用程序可以调用彼此的服务，但管理员可以在给定的应用程序中设置边界策略。例如，只有一个特定的服务可以访问互联网，其他所有服务都阻止了外部通信。这意味着需要对该应用程序中的所有工作负载强制执行诸如阻止公共 IP 或出口流量之类的策略。

第四种类型是服务级别的交付策略，这在大规模中特别有用。不需要在数千个单独的虚拟机上配置防火墙或设置，你可以将它们分组为单个服务，一次性设置策略，并让它在所有后端上进行编排。

策略实施和管理遵循策略管理点、决策点和执行点的概念。One Network 数据平面充当执行点。策略提供者提供服务扩展和管理点，允许客户在更广泛的级别上定义策略，例如针对整个应用程序或一组工作负载，并从那里对它们进行编排。

例如，考虑谷歌的服务泄流概念。

如果你在半夜被呼叫，第一步就是从受影响的服务或区域引流流量。这不会降低任何东西；它停止向那里发送新的流量，因此你可以在不影响用户的情况下进行调试。一旦问题得到解决，你就可以逐渐取消泄流并恢复流量。

流量通过各种数据平面进入——应用程序负载平衡器、服务网格、gRPC 无代理网格或 Envoy 网格——所有这些都针对给定的区域。对于 One Network，当你通过 xDS API 应用泄流时，流量会同时在所有这些路径上转移。你可以立即移动所有流量，也可以根据需要逐渐增加流量。

另一个例子是 CI/CD 金丝雀发布。当推出一个新的服务版本时，来自不同客户端的流量——通过负载平衡器的网站用户，通过内部负载平衡器的呼叫中心代理，通过服务网格的销售点系统，甚至多云流量——可以统一定向到新版本。

配置是集中提供的，由系统处理流量转移，在出现问题时支持受控的部署和快速缓解。

未来的 One Network

看看我们今天的成就，One Network 已经走过了很长的一段路。首先，架构现在已经到位了：中心组件已经完成，多云连接已经启动并运行。我们已经扩展了该系统以支持多云环境、谷歌Edge，并且正在进行联合工作。

这是一项多年的努力。Envoy One Proxy 项目始于 2017 年，而正式的 One Network 计划始于 2020 年。

高级管理人员很早就承诺了一个长期愿景，这项工作涉及十多个团队。到目前为止，我们已经交付了 125 个单独的项目，现在，谷歌云的大部分网络基础设施都建立在 One Network 上。由于它基于开源技术，因此可以集成其他开源系统。

One Network 适合你吗？

如果你正在考虑像 One Network 这样的项目，第一个问题是你是否得到了高管的支持。这不是一个可以个人即可单独承担的项目。组织的优先级也很重要。考虑策略的执行和遵从是否是你公司最关心的问题。考虑你的多云策略，以及开发人员的效率在多大程度上取决于基础设施。

有一个长期的愿景是必不可少的，但同样重要的是关注短期进展。一次处理一个项目，我们逐渐改善网络，并在发现问题时缩小差距，而不是追求一个单一的大成果。

总结

谷歌的 One Network 为网络路径、环境和策略管理提供了统一的架构。这一旅程跨越了数年，建立在跨团队合作和开源原则之上。

对于考虑类似方法的组织来说，高层支持、明确的优先级和迭代的意愿是至关重要的。与此同时，这项工作正在进行中——像移动和联邦这样的新边界仍在进行中——这一进展表明了逐步构建长期愿景的价值。One Network 的最终目标是使云基础设施更易于管理、适应性更强，并准备好支持组织的未来目标。

原文链接：

https://www.infoq.com/articles/one-network-service-policy-architecture/