Traffic Director是由谷歌云平台（Google Cloud Platform）推出的服务网格（Service Mesh）流量控制面（Control Plane）。

Traffic Director可以应用于虚拟机（Virtual Machine），也可以应用于基于Kubernetes管理的容器，它使用Envoy开源的xDS v2 API接口来与数据面的服务代理进行交互。

​

Traffic Director 官网图例

下面，我会从发布现状、主体结构、主要功能、支持场景和使用体验五个方面讲解Traffic Director。

Traffic Director 的发布现状

从发布来看，现状相对来说令人悲观。

在2018年7月推出Alpha版本

在2019年4月推出Beta版本

截止目前（2019-07-01），该功能仍未GA，而且Beta版本涵盖的功能非常有限。

Traffic Director的主体结构

Service Mesh基本结构

这个图是比较基本的Service Mesh架构图。Traffic Director的位置，是充当 Service Mesh Control Plane。

对于数据面，Traffic Director建议使用Lyft公司开源的envoy。当然，一切支持 xDSv2 APIs 的数据面都是可以使用的。

微服务环境下，作为控制面的Traffic Director

Traffic Director 的主要功能

• 全局负载均衡

• 中心化健康检查

• 基于Load的自动扩缩容

• 内嵌的弹性（高可用）

• 强大的流量控制能力

从功能上，我的一篇翻译来的博客 GCP网络深度解析：Traffic Director 如何提供全局负载均衡 已经讲述地比较清楚了；

原理和意义上，敖老师的《Google Traffic Director 详细介绍》 讲的也非常清晰，因此这里不会讲得特别详细，只会针对一些功能与使用的重点。

Traffic Director 的支持场景

从支持来看，Traffic Director目前支持 VM + Pod，这还是令人欣慰的。

你可以在 GCE（Google Compute Engine）和 GKE（Google Kubernetes Engine）上使用。不过从官方的指南来看，Traffic Director只支持自家产品，这是源于Traffic Director在生效的时候会操纵一些Google的API，因而不能直接支持其他的公有云或者私有云。

无论如何，VM+Pod的模式也是顺应了混合云的趋势，控制面不应该和云原生进行太强的绑定，还是要考虑到很多的服务仍有可能部署在虚拟机之中，这也是所有想要把Service Mesh落地的人需要重点考虑的问题。

Traffic Director 的实际体验

首先建立一个GKE集群。云原生的集群，使用Traffic Director 应该比VM要更方便一点。

启动样例service，这个时候需要注意的是Traffic Director 只支持手动注入。也就是需要手动修改 kubectl -f 后面的 yaml 文件，让 container 把 Envoy 的容器也加载进同一个Pod内部。未来有可能会支持自动注入。

和其他的教程一样，这些指导性的操作都可以使用 Console 和 Gcloud 分别配置。即同时支持控制台图形界面操作和命令行操作的能力。（其实背后的API是一致的）

部署的体验总体还算容易，不过对于用户来说，需要比较多的GCP操控经验。否则面对很多GCP的概念还是一头雾水。

Beta版本的配置能力非常地弱。

事实上，在Beta版本的Traffic Director配置页面中，只有两个Tab，分别是“服务”和“规则”。

什么是服务，理论上 VM/Pod + xDS API = 服务

只要你的VM或者Pod注入了Proxy，拥有了xDS API的能力，就算是一个服务了。当然配置服务的时候可以选择一些额外的配置，譬如端口号、平衡模式、健康检查等等。

服务配置
平衡模式的涵义就是流量速率控制，可以选择RPS（Request Per Second）的阈值，也可以选择CPU的比例。当RPC达到阈值，或者CPU达到比例之后，Traffic Director就不会把流量打过来，而是选择最为临近的可用的其他节点。

因为Traffic Director只能用来导引HTTP的服务，因此健康检查也相对容易一些。一般地，只需要每隔5秒检查一下端口可用性即可。连续两次发现端口不可用，即认为服务不健康。

绝大对数流量配置能力还在Alpha阶段，需要单独申请才能试用。

Beta版本下只有一些基础功能，配置界面如下：

路由规则配置
首先，你需要制定一个转发规则，决定目标；

然后你再确定一下主机和路径规则。可以使用主机（Host）、路径（Path）、服务（Service）进行匹配，匹配能力和转发能力都非常差。

Traffic Director 目前还处于测试状态，功能也不全，距离落地仍然很远。对于一个线上应用来说，进行Traffic Director的迁移肯定是得不偿失的。

在官网文档中，作者描述了很多局限性，包括：不支持Istio API、只支持HTTP流量、流量控制还在Alpha测试阶段、暂时与GCP强绑定等等。几乎每个局限性都是生产环境落地的死门。

但无论如何，使用数据面的开放接口并提供一个高可用的托管控制面的思路是非常明确的。在未来的计划中，Traffic Director将会对Istio的功能有更好的支持，提供更强大的流量控制与可观测能力，带来更强的稳定性和灵活性，所以Traffic Director的未来依然值得期待。

相关参考：