Servicemesh公有云服务
- 1: Traffic Director介绍
- 1.1: Traffic Director概述
- 1.2: Traffic Director官方资料
1 - Traffic Director介绍
1.1 - Traffic Director概述
Google Traffic Director 是与 AWS App Mesh 对标的 Service Mesh 产品。Traffic Director通过xDS协议与数据平面的Envoy进行通讯，可分别与Google Cloud的 MIG 和 NEG 两款产品结合去提供Service Mesh的能力。
Traffic Director的功能与开源Istio项目中的Pilot-discovery相似，也复用了Istio的不少技术实现（比如，通过iptables完成流量透明拦截）。Traffic Director支持全球负载均衡、集中式的集群健康检查、流量驱动的自动扩缩容等功能，帮助客户在全球部署与管理高弹性的无状态应用。
参考资料：
1.2 - Traffic Director官方资料
1.2.1 - Traffic Director官方资料概述
来自Traffic Director官方网站的介绍资料，Traffic Director的口号是：
Enterprise-ready traffic management for open service mesh.
适用于开放式服务网格的企业级流量管理工具。
-
用于服务网格的流量管理
服务网格是一种强大的抽象，在提供微服务和现代应用程序方面越来越受欢迎。在服务网格中，具有服务代理（如Envoy）的服务网格数据平面移动流量，服务网格控制平面为这些服务代理提供策略，配置和智能。Traffic Director是GCP完全托管的服务网格流量控制平面。借助Traffic Director，可以跨多个区域中的群集和VM实例轻松部署全局负载均衡，下放健康检查到服务代理，以及配置复杂的流量控制策略。Traffic Director使用开放的 xDSv2 API与数据平面中的服务代理进行通信，从而确保您不会被锁定在专有接口中。
- 完全管理，有SLA保证
作为Google托管的服务，Traffic Director提供了99.99％的生产级SLA：如果出现问题，我们的运维会处理，而不是您的运维。您无需担心部署和管理控制平面，这意味着您的员工可以专注于您的业务。
- 先进的流量管理让事情变得简单
使用Traffic Director轻松部署所有内容，从简单负载均衡到高级功能，如请求路由和基于百分比的流量拆分。
-
建立弹性服务
通过将服务以VM或容器的方式部署在多个区域，并使用Traffic Director通过自动跨区域访问和故障转移提供全局负载均衡，从而使您的服务保持正常运行。
-
与部署无缝扩展
Traffic Director旨在无缝地处理部署的增长。随着服务数量的增长，Traffic Director可以无缝扩展以管理所有服务，即使是大型安装也是如此。
-
按照您的步调进行现代化
Traffic Director适用于基于VM（Compute Engine）和容器化应用程序（Google Kubernetes Engine或自我管理的Kubernetes），可以逐步引入到您的服务。
Traffic Director的特性如下：
-
开放服务代理的流量管理
Traffic Director为兼容 xDSv2 标准的开放服务代理（如Envoy）提供GCP托管的流量管理控制平面。
-
适用于VM和容器
使用托管实例分组部署Traffic Director管理的VM服务实例，并使用网络端点分组部署的容器实例
-
全局负载均衡
使用Traffic Director，您可以在多个区域中部署服务实例，以实现弹性和可访问，同时只需要一个服务IP。这意味着，例如，您的GKE服务可以位于多个集群中，而每个集群可以位于不同的区域中。如果最靠近用户的实例发生故障或过载，则流量将无缝地定向到另一个可用实例。
-
大规模的健康检查
Traffic Director提供由GCP交付的大规模健康检查。这将从Envoy/服务代理卸载健康状况检查到Google弹性系统，允许您扩展健康检查到所有大小的部署。此外，您的实例本身不会因网格大小的运行状况检查而不堪重负。
-
具有请求路由和丰富流量策略的流量控制（alpha）
Traffic Director支持高级请求路由功能，如流量拆分，启用基于各种header值（包括cookie）的canarying，url重写/重定向，故障注入，流量镜像和高级路由功能等用例。Traffic Director还支持许多高级流量策略，包括许多负载均衡方案，熔断器和后端异常检测。
-
为服务提供智能，快速的自动扩展功能
Traffic Director为您提供按需驱动的自动缩放功能，允许您仅为您使用的内容付费，同时快速智能地扩展，而无需访问您的云提供商且无需任何预热要求。
来自 Envoy 创始人 Matt Klein 的评价：
Traffic Director可以更轻松地将Envoy和服务网格的优势带入生产环境。随着Envoy提供通用数据平面，Traffic Director提供了完全托管的流量控制平面，其开放式接口可以避免锁定。Traffic Director的SLA，全局负载均衡和丰富的流量控制有助于减少企业和云原生终端用户的流量管理的工作。
参考资料
Traffic Director官方网站首页：
1.2.2 - Traffic Director概念
服务网格在部署微服务和其他现代应用程序时变得越来越流行。在服务网格中，数据平面使用服务代理（例如Envoy）来控制流量，而服务网格控制平面则为服务代理提供策略、配置和智能。
服务网格作为控制平面
服务网格减少了运行服务必须编写和维护的网络开发代码量。相反，服务代理会在您的业务逻辑旁边执行网络功能。需要服务控制平面来管理服务代理。
Traffic Director 是Google Cloud Platform完全托管的服务网格流量控制平面。使用Traffic Director，您可以轻松地跨多个区域中的集群和VM实例部署全局负载均衡，从服务代理下放运行状况检查，以及配置复杂的流量控制策略。Traffic Director使用 开放标准API（xDS v2） 与数据平面中的服务代理进行通信，确保您不会被锁定到专有解决方案，并且可以使用您选择的服务网格控制平面。
Traffic Director作为微服务环境中的控制平面
使用Traffic Director进行全局负载平衡
Traffic Director 通过服务代理为您的内部微服务提供全局负载平衡。您可以在多个区域中部署具有实例的内部微服务（基于服务代理）。Traffic Director为服务代理提供运行状况，路由和后端信息，使他们能够针对服务执行到多个云区域中的应用程序实例的最佳流量路由。
在下图中，全局负载均衡部署具有三个全局微服务：Front End，Shopping Cart 和 Payments。在托管实例上运行的每个服务分组到两个区域，us-central1 和 asia-southeast1。Traffic Director使用全局负载均衡算法，将来自加利福尼亚用户的流量定向到部署的微服务us-central1，而来自新加坡用户的请求则定向到微服务 asia-southeast1。
传入的用户请求被路由到Front End微服务。安装在具有Front End的主机上的服务代理然后将流量引导到Shopping Cart。使用Shopping Cart安装在主机上的服务代理将流量定向到Payments微服务。
全局负载平衡部署中的Traffic Director
在以下示例中，如果Traffic Director收到运行状况检查结果，指示运行购物车微服务的VM运行状况us-central1 不佳，则Traffic Director会指示服务代理服务器前端微服务将流量故障转移到运行的购物车微服务asia-southeast1。由于自动扩展与Google Cloud Platform中的流量管理集成在一起，因此Traffic Director会向托管实例组通知 asia-southeast1其他流量，并且托管实例组的大小会增加。
Traffic Director检测到Payments微服务的所有后端都是健康的，因此Traffic Director指示Envoy的购物车代理将一部分流量发送到客户配置的容量，asia-southeast1并将剩余流量 溢出到us-central1。
下面是找到的一个动态展示全局负载平衡工作方式的图片：
Traffic Direcotor和Istio
Istio 提供了一个控制平面来保护，连接和监控微服务。它有三个组成部分：Pilot 负责流量管理，Mixer 负责可观察性，Istio Security 负责服务到服务的安全性。
Traffic Director 提供 GCP 托管的 Pilot 以及全局负载平衡和集中式运行状况检查等其他功能。但请注意，在此Beta版本中无法使用 Istio API配置Traffic Director; 您可以使用GCP API进行配置。Traffic Director和Pilot使用开放标准API（xDS v2）与服务代理进行通信。
限制
- Beta版本的Traffic Director仅支持GCP API。Beta版本的Traffic Director不支持Istio API。
- Traffic Director仅支持HTTP流量。
- Traffic Director流量控制功能是 Alpha 状态。
- Traffic Director支持共享VPC，不管是主机项目中的所有负载均衡资源，还是服务项目中的所有负载均衡资源。但是，只有具有至少一个使用共享VPC网络名称定义的转发规则配置的项目的服务帐户才能用于访问Traffic Director。
- Traffic Director不支持VPC 对等（peering）。
- Traffic Director Beta仅支持GCP网络中的客户端负载均衡，其名称在转发规则中指定。
- 您只能在Beta版本中使用Traffic Director配置GCP端点。我们不支持在本地或在另一个云中使用端点。
- 本文档讨论了Envoy代理，但您可以将任何 开放标准API（xDS v2）代理 与Traffic Director一起使用。但请注意，Google仅使用Envoy代理测试了Traffic Director。在此测试期间，Traffic Director仅支持Envoy版本1.9.1或更高版本。
参考资料
- Traffic Director官方文档 Traffic Director concepts
1.2.3 - Hybrid and Open Services with GCP, Envoy and Istio
背景
2018年7月，google 在 Cloud Next ‘18 会议上的演讲，介绍 google traffic director：
https://www.youtube.com/watch?time_continue=2759&v=4U4X_OzJaNY
What if you could deploy hybrid/multi-cloud services seamlessly without having to build or operate the requisite services management infrastructure? What building blocks are available today and what does the road ahead look like? We bring together folks from Google Cloud and Lyft to answer these questions. Google/Google Cloud have decade plus experience in delivering production-grade services like Borg, Cloud Load Balancing, Kubernetes Engine and more recently driving Istio, a fast-growing open source platform for managing (micro)services. Lyft developed and open sourced Envoy, a high performance proxy aiming to make the network transparent to applications, and transformed its own monolithic app into a sophisticated Envoy-based ““service mesh””. In this talk-cum-panel, Google and Lyft bring together unique perspectives on multi-cloud services management and also provide a sneak peek into Google Cloud’s new traffic management service for Envoy-powered (micro)services.
如果可以无缝地部署混合/多云服务而无需构建或运维必需的服务管理基础设施，该怎么办？ 现在有哪些构建模块可用，前方的道路将会是如何？ 我们汇集了Google Cloud和Lyft的人员来回答这些问题。 Google / Google Cloud在提供Borg，云负载均衡，Kubernetes引擎等生产级服务方面拥有十多年的经验，并且最近推动了Istio，这是一个用于管理（微）服务的快速增长的开源平台。 Lyft开发并开源Envoy，一个高性能代理，旨在使网络对应用程序透明，并将其自己的单体应用转换为复杂的基于Envoy的“服务网格”。 在这个谈话中，Google和Lyft将多云服务管理的独特视角结合在一起，同时也可以先睹为快，看一看Google Cloud为Envoy-powered（微）服务提供的新的流量管理服务。
内容摘要
有一个趋势应用拆分。当客户将单体应用拆分到微服务时，客户关注的并不是微服务，或者和微服务相关的各种技术，他们真正关注的是什么？是微服务可以给他们带来什么。
另一个趋势是：在混合云和多云环境下部署和管理服务。客户可能使用公有云，如gcp和其他，也可能混合使用私有云。
因此，该如何简化混合和多云服务的部署？
需要做的第一件事情是将通用的核心部分从服务中移除，典型如网络通信代码：负载均衡，错误注入，失败恢复。第二件事情是管理所有这些服务，而且不要自己直接管理，而是需要有提供服务托管的基础设施。
引入 Service Mesh 和 控制平面。
envoy 是这个技术设施中非常重要的一部分，envoy 提供了上图中 proxy 列出的功能。以下模块都会使用 envoy 的能力。
比较重要的几点：最终一致的服务发现/API 驱动/为可观测性设计。
Traffic Director 用来帮助管理服务。前面谈到，客户真正关心的是应用逻辑或者业务逻辑，希望剩余部分可以由其他人提供。
首先是托管在 GCP 上，其次这是一个企业就绪的控制平面，用于前面我们提到的服务代理。更重要的是，可以让service mesh跨区域，可以支持全局负载均衡。提供中央化健康检查，这意味着不用每个代理都彼此相互检查。还提供流量驱动的自动伸缩。
Traffic Director 和 proxy 之间使用开放API，即 xDS v2 API。
跨区域部署，就近访问：
如果发生故障，则failover到另外一个region：
istio介绍
Traffic Director 将取代 Pilot 的位置，所有pilot能提供的功能，Traffic Director 都将提供。这也是采用 open xDS v2 API的原因，以便在 pilot 和 traffic director 之间切换。
Google 和 Google Cloud 将 all-in on hybird，希望 hybird 的服务也可以从 Traffic Director 中受益。因此，Traffic Director 不仅仅给运行在 GCP 中的proxy提供服务，也要提供服务给 on-prem（本地）部署。
采访
Envoy 使用的API非常类似google 内部API
1.2.4 - Traffic Director & Envoy-Based L7 ILB
背景
2019年4月，google 在 Cloud Next ‘19 会议上的演讲，介绍 google traffic director：
https://www.youtube.com/watch?v=FUITCYMCEhU
We are excited to announce Traffic Director and Envoy-based L7 ILB, our new GCP services for Service Mesh and Istio. Traffic Director is toil-free, GCP-managed control plane with SLA for Service Meshes. In Istio environments, Traffic Director provides a GCP-managed Pilot for your service mesh. Traffic Director delivers traffic management and multi-region global load balancing for service meshes built using open proxies like Envoy and through the open xDSv2 APIs. It provides policy driven traffic routing, enabling you to control the flow of traffic between services. All of this makes load balancing, scaling, A/B testing, canary roll outs, and blue-green deployments toil-free to set up.Traffic Director also provides centralized high fidelity health checking, and traffic driven autoscaling. Envoy-based Layer 7 Internal Load Balancing (L7 ILB), another flavor of Traffic Director, brings modern traffic management capabilities to traditional environments. With L7 ILB, Traffic Director controls a pool of GCP-managed Envoy proxies under the hood but presents this service as a traditional Layer 7 ILB middle proxy to front your legacy apps. Traffic Director supports VM-based, Kubernetes and GKE apps and more enabling you to modernize at your pace from your starting point. Join us to get a deep dive into Service Mesh Networking, Traffic Director and L7 ILB through a series of demos and real world customer use cases and best practices.
我们很高兴地宣布 Traffic Director 和 Envoy L7 ILB，这是我们为Service Mesh和Istio提供新的GCP服务。 Traffic Director是无痛，GCP托管的控制平面，具有用于Service Mesh的SLA。在Istio环境中，Traffic Director为服务网格提供GCP托管的Pilot。 Traffic Director为使用Envoy等开放代理和开放式xDS v2 API构建的服务网格提供流量管理和多区域全局负载均衡。它提供策略驱动的流量路由，使您能够控制服务之间的流量。所有这些都使得负载均衡，伸缩，A/B测试，金丝雀推出和蓝绿部署变得容易.Traffic Director还提供集中式高保真健康检查和流量驱动自动伸缩。基于Envoy的第7层内部负载平衡（L7 ILB）是另一种Traffic Director，它为传统环境带来了现代化的流量管理功能。借助L7 ILB，Traffic Director可以控制GCP管理的Envoy代理池，但是将此服务作为传统的第7层ILB中间代理提供给您的旧版应用程序。 Traffic Director支持基于VM，Kubernetes和GKE的应用程序以及更多功能，使您能够从起点开始进行现代化。加入我们，通过一系列演示和现实世界的客户使用案例和最佳实践，深入了解Service Mesh Networking，Traffic Director和L7 ILB。
内容摘要
TBD
文本简化版本
演讲的内容有一个简短的摘要版本，以文章的形式提供在 Google Cloud 上：