Traffic Director 使用体验

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的迁移，最终获得的只是Beta版本中的主机路径级别的转发能力，显然是得不偿失的。

但无论如何，放开数据面，提供一个高可用的托管控制面的思路是非常明确的。未来它将会对Istio的功能有更好的支持，提供一个Google托管的更强大的流量控制和可观测能力。总体来看，未来还是比较值得期待。