Traffic Director 概览

Traffic Director 是应用网络的代管式控制层面。Traffic Director 允许您提供具有高可用性的应用网络功能(包括流量管理和可观测性)的全球高可用性服务。

随着部署中的服务和微服务数量的增长,您通常会遇到常见的应用网络挑战:

  • 如何使我的服务具有良好的弹性?
  • 如何获取服务流量以及服务如何相互通信?
  • 如何了解我的服务相互通信的情况?
  • 如何在不中断的情况下更新我的服务?
  • 如何管理可实现此目标的基础架构?
服务需要相互通信(点击可放大)
服务需要相互通信(点击可放大)

Traffic Director 可以帮助您在基于服务的现代部署中解决这些类型的挑战。最重要的是,它依赖于 Google Cloud 管理的基础架构,因此可提供一流的功能,而无需亲自管理基础架构。您可以专注于解决商业问题的应用代码,让 Traffic Director 管理应用网络复杂度。

服务网格的 Traffic Director

解决应用网络挑战的一种常见模式是使用服务网格。Traffic Director 支持服务网格以及符合您需求的许多其他部署模式。

典型的服务网格(点击可放大)
典型的服务网格(点击可放大)

典型的服务网格

在典型的服务网格中:

  • 将服务部署到 Kubernetes 集群。
  • 每个服务 Pod 都有一个专用代理(通常是 Envoy)作为 Sidecar 代理运行。
  • 每个 Sidecar 代理都会连接到集群中安装的网络基础架构(一个控制层面)。控制层面告知 Sidecar 代理服务网格中的服务、端点和政策。
  • 当 Pod 发送或接收请求时,请求会转到 Pod 的 Sidecar 代理。例如,Sidecar 代理处理请求,例如将其发送到其预期目的地。

在本文档中,代理由六面粉色图标表示。控制层面连接到每个代理,并提供代理处理请求所需的信息。两个框之间的箭头显示流量。例如,Service A 中的应用代码会发送请求。代理会处理请求并将其转发给 Service B

此模型使您可以将网络逻辑移出应用代码。您可以专注于交付业务价值,同时让您的基础架构负责应用网络。

Traffic Director 有何不同之处

Traffic Director 的工作原理与该模型类似,但在重要方面却有所不同。首先,Traffic Director 是 Google Cloud 管理的服务。您无需安装此应用。它不会在您的集群中运行。您无需进行维护。

在下图中,Traffic Director 是控制层面。此 Kubernetes 集群中有 4 项服务,每项服务都连接到 Traffic Director。Traffic Director 提供代理路由请求所需的信息。例如,属于 Service A 的 Pod 中的应用代码会发送请求。与此 Pod 一起运行的 Sidecar 代理会处理该请求,并将其路由到 Service B 所属的 Pod。

Traffic Director 的服务网格示例(点击可放大)
Traffic Director 的服务网格示例(点击可放大)

服务网格进阶

与典型服务网格相比,Traffic Director 支持更多的部署。

多集群 Kubernetes

通过 Traffic Director,您可以获得适用于 Kubernetes 集群的应用网络。在下图中,Traffic Director 为 us-central1europe-west1 中的 Kubernetes 集群提供了控制层面。请求可以在 us-central1 中的三项服务、europe-west1 的两个服务之间以及两个集群中的服务之间路由。

使用 Traffic Director 的多集群 Kubernetes 的示例(点击可放大)
使用 Traffic Director 的多集群 Kubernetes 的示例(点击可放大)

您的服务网格可以跨多个 Google Cloud 区域在多个 Kubernetes 集群进行扩展。一个集群中的服务可以与另一个集群中的服务进行通信。您甚至可以的服务包含由多个集群中的 Pod 组成。

使用 Traffic Director 的基于邻近度的全球负载平衡功能,发送到 Service B 的请求将转到可处理请求的最近 Pod。您还会获得无缝故障转移:如果 Pod 发生故障,则请求会自动故障转移到可在请求中处理的其他 Pod,即使此 Pod 位于不同的 Kubernetes 集群中。

虚拟机

Kubernetes 越来越受欢迎,但许多工作负载都部署到虚拟机 (VM)。Traffic Director 也能够解决这些工作负载的应用网络问题:基于虚拟机的工作负载可以轻松与基于 Kubernetes 的工作负载进行互操作。

在下图中,流量通过外部 HTTP(S) 负载平衡进入您的部署。它被路由到 asia-southeast1 的 Kubernetes 集群中的 Service Aeurope-west1 中的虚拟机上的 Service D

使用 Traffic Director 的虚拟机和 Kubernetes 示例(点击可放大)
使用 Traffic Director 的虚拟机和 Kubernetes 示例(点击可放大)

Google 提供了一种无缝机制,用于通过 Traffic Director 设置基于虚拟机的工作负载。您只需向 Compute Engine 虚拟机实例模板添加一个标志,我们会处理基础架构设置。这包括安装和配置用于提供应用网络功能的代理。

无代理 gRPC

gRPC 是一个功能丰富的开源 RPC 框架,可用于编写高性能微服务。利用 Traffic Director,您可以轻松向 gRPC 应用提供应用网络功能,例如服务发现、负载平衡和流量管理(了解详情)。

在下图中,gRPC 应用将流量路由到一个区域的 Kubernetes 集群中的服务,并路由到在不同区域的虚拟机上运行的服务。其中两种服务包括 Sidecar 代理,还有一些服务是无代理的。

使用 Traffic Director 的无代理 gRPC 应用示例(点击可放大)
使用 Traffic Director 的无代理 gRPC 应用示例(点击可放大)

Traffic Director 支持无代理的 gRPC 服务。这些服务使用的是最新版本的开源 gRPC 库,支持 xDS API。这意味着您的 gRPC 应用可以使用 Envoy 使用的相同 xDS API 连接到 Traffic Director。

连接后,gRPC 库会处理服务发现、负载平衡和流量管理等应用网络功能。gRPC 本身会发生此操作,因此不需要服务代理 - 这就是所谓的无代理 gRPC 应用。

Ingress 和网关

对于许多用例,您需要处理并非由 Traffic Director 配置的客户端的流量。例如,您可能需要将微服务入站流量传输到微服务。您可能还需要将负载平衡器配置为反向代理,使其先处理来自客户端的流量,然后再发送到目标。

在下图中,外部 HTTP(S) 负载平衡器为外部客户端启用 Ingress,流量路由到 Kubernetes 集群中的服务。内部 HTTP(S) 负载平衡器将内部流量路由到虚拟机上运行的服务。

适用于 Ingress 的 Cloud Load Balancing 的 Traffic Director(点击可放大)
适用于 Ingress 的 Cloud Load Balancing 的 Traffic Director(点击可放大)

Traffic Director 可与 Google Cloud Load Balancing 配合使用来提供代管式入站流量。只需设置外部或内部负载平衡器,然后配置负载平衡器,以将流量发送到您的微服务。在上图中,公共互联网客户端通过外部 HTTP(S) 负载平衡访问您的服务。客户端(例如位于 Virtual Private Cloud (VPC) 网络中的微服务)使用内部 HTTP(S) 负载平衡来访问您的服务。

在下图中,europe-west1 区域中的虚拟机运行一个代理,该代理充当三项未运行代理的网关。来自外部 HTTP(S) 负载平衡器和内部 HTTP(S) 负载平衡器的流量会路由到网关,然后路由到三个服务。

用于配置网关的 Traffic Director(点击可放大)
用于配置网关的 Traffic Director(点击可放大)

对于某些用例,您可能需要设置 Traffic Director 以配置网关。此网关本质上是反向代理(通常是在一个或多个虚拟机上运行的 Envoy),用于侦听入站请求、对其进行处理并将它们发送到目标位置。该目标可以位于任何 Google Cloud 区域或 Google Kubernetes Engine 集群中。您甚至可以通过混合连接从 Google Cloud 外部访问该 Google Cloud 的目标。

多环境

无论是在 Google Cloud、本地环境、其他云中,还是所有这些服务中的服务,您的基本应用网络挑战都保持不变。如何获取这些服务的流量?这些服务如何相互通信?

在下图中,Traffic Director 将流量从在 Google Cloud 中运行的服务路由到 Service G(在其他公有云中运行)和 Service EService F,两者均运行于本地数据中心。Service AService BService C 使用 Envoy 作为 Sidecar 代理,而 Service D 是无代理 gRPC 服务。

用于跨环境通信的 Traffic Director(点击可放大)
用于跨环境通信的 Traffic Director(点击可放大)

使用 Traffic Director,您可以将请求发送到 Google Cloud 外部的目标。这允许您使用 Cloud Interconnect 或 Cloud VPN 以专用方式将流量从 Google Cloud 内部的服务路由到其他环境中的服务或网关。

设置 Traffic Director

设置 Traffic Director 包含两个步骤。完成设置过程后,基础架构处理应用网络和 Traffic Director 可根据您的部署情况保持所有内容处于最新状态。

部署应用

首先,将您的应用代码部署到容器或虚拟机。我们提供了可让您轻松地将虚拟机实例网络基础架构(通常是 Envoy 代理)添加到虚拟机实例和 Pod 的机制。此基础架构是为了与 Traffic Director 通信并了解您的服务。

配置 Traffic Director

接下来,您需要配置全球服务,并定义如何处理流量。您可以使用 Google Cloud Console、gcloud CLI、Traffic Director API 或其他工具(如 Terraform)配置 Traffic Director。

完成这些步骤后,Traffic Director 就可以配置您的应用网络基础架构。

基础架构处理应用网络

当应用向 my-service 发送请求时,您的应用网络基础架构(例如 Envoy Sidecar 代理)会根据从 Traffic Director 收到的信息来处理请求。这使得 my-service 的请求可以无缝路由到能够接收请求的应用实例。

监控和持续更新

Traffic Director 监控构成您的服务的应用实例。这让 Traffic Director 发现服务运行状况良好或服务容量已发生变化(例如,创建了新的 Kubernetes Pod 时)。根据此信息,Traffic Director 会不断更新您的应用网络基础架构。

特性

Traffic Director 的功能向您的微服务提供应用网络功能。本部分将讨论一些主要内容。

全代管式控制层面、运行状况检查和负载平衡

您希望将时间花费在管理基础架构上,而不是花费在管理基础架构上。Traffic Director 是一项具有正常运行时间服务等级协议 (SLA) 的全代管式解决方案,因此您无需安装、配置或更新基础架构。您受益于 Google 用于进行运行状况检查和全球负载平衡的同一基础架构。

基于开源产品构建

Traffic Director 使用 EnvoyIstio 等流行开源项目使用的控制层面 (xDS) API。如需查看受支持的 API 版本,请参阅 xDS 控制层面 API 页面。

提供应用网络功能的基础架构(Envoy 或 gRPC,具体取决于您的使用场景)同样是开源的,因此您无需担心后者会被锁定专门的基础架构。

扩缩

从一次性应用网络解决方案到包含数千项服务的大规模服务网格部署,Traffic Director 可满足您的伸缩要求。

服务发现以及跟踪您的端点和后端

当应用向 my-service 发送请求时,该请求将由您的基础架构无限期处理并发送到正确的目标。您的应用无需了解有关 IP 地址、协议或其他网络复杂性的任何信息。

全球负载平衡和故障转移

Traffic Director 使用 Google 的全局负载平衡和运行状况检查,根据后端近距离、运行状况和容量优化流量平衡。通过自动将流量故障转移到运行状况良好且具有容量的后端,您可以提高服务可用性。

流量管理

借助高级流量管理,包括路由和请求操作(基于主机名、路径、标头、Cookie 等),您可以确定流量在服务之间的流动情况。您还可以对 Canary 部署应用重试、重定向和基于权重的流量拆分等操作。故障注入、流量镜像和离群值检测等高级模式使 DevOps 使用场景可以提高弹性。

可观测性

您的应用网络基础架构会收集遥测信息(如指标、日志和跟踪记录),这些信息集中在 Cloud 操作中。收集之后,您可以获取数据洞见并创建提醒,以便在出现问题时获得通知。

后续步骤

详细了解 Traffic Director 功能,例如:

了解 Traffic Director 提供的各种功能

如果您已准备好开始使用,请阅读我们的设置指南