Traffic Director介紹
Traffic Director 是 Google Cloud 推出的完全託管的服務網格流量控制平面。
援引來自Traffic Director官方網站的介紹資料，Traffic Director的定位是：
Enterprise-ready traffic management for open service mesh.
適用於開放式服務網格的企業級流量管理工具。
目前 Traffic Director 還處於測試階段，尚未GA：
- 在2018年7月的 Cloud Next ‘18 大會上，Google Cloud 推出了 Traffic Director 的 alpha 版本
- 在2019年4月的 Cloud Next ‘19 大會上，Google Cloud 推出了 Traffic Director 的 beta 版本
Traffic Director推出的背景
在詳細介紹 Traffic Director 的功能之前，我們先看一下 Traffic Director 推出的背景。由於 Traffic Director 剛推出不久，資料非常少，所以下面的內容有很多來自僅有的一點 Traffic Director 的演講和官方文檔。
在Cloud Next ‘18 /19 介紹Traffic Director的演講中，都談到 Traffic Director 推出和下列兩個趨勢有關：
- 微服務的普及和Service Mesh技術的興起
- 混合雲和多雲部署
從微服務到Service Mesh
近年來微服務架構大熱，傳統的單體應用按照微服務的理念進行拆分。
但是當應用從單個巨型單體拆分爲數量大增的微服務之後，新的問題出現：如果高效的部署、連接、管理這些服務，並提供安全和監控能力？如果按照傳統的侵入式微服務框架的思路，則開發人員就不得不在進行微服務改造時，承受微服務拆分帶來的各種技術複雜度。
但是，當將單體應用拆分到微服務時，客戶關注的並不是微服務或者和微服務相關的各種技術，他們真正關注的是：微服務可以給他們帶來什麼。因此，必須要有一種解決方案，抽象並屏蔽掉微服務實現的技術細節。
服務網格就是這樣一種功能強大的抽象層，在微服務交付方面得到了越來越多的使用。其核心價值有兩點：
- Separates applications from app networking / 分離應用和網絡
- Decouples operation from development / 解耦開發和運維
混合雲和多雲環境
考慮另一個趨勢：在混合雲和多雲環境下部署和管理服務。客戶可能使用公有云，如GCP或其他公有云，也可能混合使用私有云。
在這種場景下，該如何簡化混合和多雲服務的部署？Traffic Director的思路是這樣：
- 引入ServiceMesh技術：通過ServiceMesh將通用的核心部分從服務中移除，典型如網絡通信代碼中的負載均衡，錯誤注入，失敗恢復，流量管理，路由，安全等。
- 託管：需要ServiceMesh來管理服務，但最好不要自己直接管理ServiceMesh，而是使用提供託管的基礎設施
控制平面與託管
在服務網格中，服務網格數據平面與服務代理一起傳輸流量，而服務網格控制平面爲這些服務代理提供政策、配置和智能建議:
Traffic Director 是 GCP 專爲服務網格打造的完全託管式流量控制平面，其架構如下：
託管式服務的好處是有服務等級協議 (SLA) 的保障，下面是Google Cloud官方對此的聲明：
作爲 Google 的一項託管式服務，Traffic Director 提供生產級 99.99% 可用性的 SLA：如果出現問題，收到通知並負責解決問題是我們的運營人員，而不是您的。您不必擔心部署和管理控制平面，因而您的員工可以專注於發展業務。
當然目前 Traffic Director 還是beta測試階段，上述SLA保障需要在GA之後才能提供。
最後我們援引 Matt Klein（Envoy 作者）的這段致辭作爲Traffic Director推出的背景總結，雖然這段話有做託的嫌疑：
“Traffic Director 可以更加便捷地將 Envoy 和服務網格的優勢運用到生產環境。由於 Envoy 提供通用型數據平面，Traffic Director 可提供具有開放接口的完全託管式流量控制平面，避免鎖定於某一種產品。Traffic Director 的 SLA、全球負載平衡和豐富的流量控制措施可幫助企業和雲原生最終用戶減少流量管理工作。”
這裏列出的功能我們後面會詳細解析，重點看”開放接口”/“避免鎖定” 這兩個關鍵詞：這可以說是Google乃至整個CNCF/Cloud Native社區一直念念不忘反覆提醒的關鍵字，極其強調標準接口和避免供應商綁定。
與此對應的是，Traffic Director 採用了開放的 xDS v2 API 與數據平面中的服務代理進行通信。xDS v2 API 來自 Envoy， 目前已經成爲 Service Mesh 的事實API標準。Traffic Director 通過採用 xDS v2 API 這樣的開發API實現了其倡導的避免綁定。
Traffic Director的功能
全局負載均衡
這個功能是 Traffic Director 在各種演講和介紹中強調的最多的功能，其官方介紹爲：
Traffic Director 將服務作爲虛擬機或容器部署在多個區域中來保證它正常運行，並使用 Traffic Director 通過自動化的跨區域溢出和故障轉移來提供全局負載均衡。
“作爲虛擬機或容器”我們在下一節展開，先看看 Traffic Director 提供的全局負載均衡是什麼。
這是 Traffic Director 官方給出的示例，圖中的三個服務分別部署在兩個不同的區域。在 Traffic Director 的控制下，流量按照就近原則被髮送到具有可用容量的最近的服務實例：
故障轉移是指，如果最接近客戶端服務的實例已關閉或過載，則 Traffic Director 會控制流量無縫轉移到下一個最近區域中的健康實例。
跨區域溢出則是指當流量超出當前區域部署的實例的承受能力之後，會突破就近路由的原則，將部分流量導流到其他區域。這背後的邏輯是：就近路由的收益的是本地訪問的低網絡延遲，在流量突發時，寧可犧牲延遲也要將流量引導到其他區域以保證可用性。
下面這個動畫可以更生動的展示上述描述的”全局負載均衡”/“故障轉移”和”跨區域溢出”的功能：
適用於虛擬機和容器
在上面的示例中，提到”Traffic Director 將服務作爲虛擬機或容器部署在多個區域中”，這是 Traffic Director 重點強調的另外一個重要功能：支持虛擬機和容器，而且支持混合使用。
下面這張圖片強調了服務部署的多樣性：三個服務分別是自己管理的 docker 服務 / 基於虛擬機的服務 / 部署在 GKE 的服務。
Traffic Director 官方文檔給出的解釋是：
“按您的節奏進行現代化改造”
Traffic Director 既適用於基於虛擬機 (Compute Engine) 的應用，也適用於容器化應用（Google Kubernetes Engine 或自行管理的 Kubernetes），並可以增量方式逐步應用於您的服務。
這背後的考慮是：service mesh 和 k8s 的普及，不會一蹴而就，基於虛擬機的服務會長期存在，因此提供對基於虛擬機服務的支持和打通與容器服務的交互訪問就至關重要。這個思路同樣出現在AWS的app mesh產品中，app mesh也是強調同時支持VM服務和容器服務。
Service Mesh技術的典型使用場景是運行和管理已經拆解爲微服務並按照雲原生理念開發的服務，但是考慮到大量遺留應用存在的現實， Traffic Director 通過支持VM服務，可以爲這些非雲原生服務引入高級功能。這個做法在我們之前的介紹中，被戲稱爲”先上車再買票”，即在不做應用大規模改造的前提下先體現享受Service Mesh帶來的部分紅利，再慢慢逐步和分批做應用改造。
注意：在 Traffic Director 的支持中，基於虛擬機的服務和基於容器的服務採用一致的流量管理功能，兩者並沒有功能上的差別。
混合雲和多雲支持
最近看到 Google Cloud 提出要”All in Hybird Cloud”，在這個大背景下，Traffic Director 提供對混合雲和多雲環境的支持：
這是完整的應用改造示意，從原有在私有環境下運行的單體應用，轉換到在公有云和私有云上的 service mesh 中運行的多個微服務：
集中式健康檢查
Traffic Director 官方文檔對集中式健康檢查給出的介紹是：
大規模執行運行狀況檢查
Traffic Director 通過 GCP 進行大規模運行狀況檢查。因此，運行狀況檢查從 Envoy/服務代理分流到 Google 的彈性系統，這樣您就可以對各種規模的部署進行大規模運行狀況檢查。另外，您的實例本身不會因網格規模的運行狀況檢查而不堪重負。
解釋一下這裏所說的”因網格規模的運行狀況檢查而不堪重負”：
大型服務網格會生成大量的健康檢查流量，因爲每個sidecar代理都必須對服務網格中的所有服務實例進行健康檢查。隨着網格的增長，讓每個客戶端代理健康檢查每個服務器實例，這種做法會產生一個 n^2 健康檢查問題，這將成爲增長和擴展部署的障礙。
Traffic Director 對此給出的解決方案是提供集中式健康檢查，Traffic Director 會提供一個全局分佈的彈性系統監控所有服務實例。然後，Traffic Director使用 EDS API 將聚合的健康檢查結果分發到全局網格中的所有代理。如下圖所示：
這樣Proxy就不需要自行實現健康檢測，只要接受 EDS 更新即可（當然客戶端被動健康檢測還是需要的，當發生無法連接等錯誤時還是需要處理的）。
這裏 Traffic Director 的做法和 Istio 的標準做法是很類似的，Istio 在 k8s 上部署時，是依賴 k8s 的探測機制來做服務的探活的。Traffic Director 的 health check 機制沒有找到詳細的介紹資料，暫時不清楚具體的機制，Traffic Director 的介紹中只是提到這個功能是由 GCP 統一提供。
集中式健康檢查這個功能也算是一個賣點，畢竟，雖然 Envoy 自帶健康檢測機制，但是如果由客戶端來實現健康檢測，的確是需要每個客戶端都檢查所有其他服務，連接太多，請求太多，而且隨着服務數量和實例數量的增加，健康檢測的開銷會直線上漲。由平臺/基礎設施/雲等來統一提供集中式健康檢查，再通過 xDS/EDS API 下發結果應該會是一個通用的做法。
流量控制
Traffic Director 目前提供流量控制功能，包括流量路由和策略執行。官方文檔的介紹描述如下：
通過請求路由和豐富的流量政策進行流量控制（Alpha 版）
Traffic Director 支持高級請求路由功能，如流量拆分、啓用 Canary 更新等用例、網址重寫/重定向、故障注入、流量鏡像，以及基於各種標頭值的高級路由功能，包括 Cookie。此外，Traffic Director 還支持許多高級流量政策，包括多種負載平衡方案、熔斷和後端異常檢測。
您可以使用 Traffic Director 輕鬆部署一切功能：從簡單的負載平衡，到請求路由和基於百分比的流量拆分等高級功能。
從最新的 Traffic Director 的介紹PPT上看到，Traffic Director 的流量控制功能包含兩個部分：
- Routing Rules：定義請求如何路由到網格中的服務
- Traffic splitting
- Traffic steering
- Timeouts and retries
- Fault Injection
- Mirroring
- Traffic Policies：用於服務的路由相關策略
- Load balancing schemes.
- Outlier detection.
- Circuit breakers
- Timeouts
熟悉 Istio API 和 Envoy xDS API 的同學就會發現這些功能非常眼熟，基本上和 Isito / Envoy 提供的功能相同。
和包括Istio在內的所有Service Mesh產品一致， Traffic Director 也在強調說這些功能都是可以在不修改應用代碼的前提下獲得，這是理所當然的重要賣點。
但是注意：目前這些功能都還是 alpha 階段，因此支持度應該不會像 Istio 那麼齊全。
我們快速過一下目前提供的功能（圖片來自 Google Traffic Director 的演講PPT）：
Traffic Splitting/流量拆分，支持百分比拆分，這是 version based routing，用於實現金絲雀發佈/藍綠部署/AB測試等：
Traffic Steering，這是 content based routing，支持 Host / Path / Header 匹配：
在匹配完成之後，除了做流量拆分之外，還可以由其他的功能，如錯誤注入。Traffic Director 支持的錯誤注入同樣有 Delay 和 Abort 兩種：
熔斷和異常檢測，支持每服務配置，具體的配置方式也和 Istio / Envoy 差不多。
流量鏡像功能，也稱爲影子流量。流量會複製一份發送給接受鏡像流量的服務，Traffic Director的實現會在發送給鏡像服務的請求的 Host/Authority header 中增加一個 “-shadow” 後綴。鏡像請求是發出去就不管的，無視應答，和Istio的處理方式一致。
總結：在流量控制這塊功能上，Traffic Director 除了因爲是 alpha 版本，可能功能支持不夠齊全之外，基本和 Istio / Envoy 是一致的。考慮到 Traffic Director 支持 xDS V2 API，和目前只支持Envoy（理論上兼容任何支持 xDS v2的代理，但是實際只測試過Envoy） 的現狀，Traffic Director 在流量控制上和 Istio / Envoy 高度一致也就非常容易理解。
需要特別指出的是：目前 beta 版本的 Traffic Director 只支持用 GCP 的 API 來設置流量控制的規則，目前還不支持直接使用 Istio 的API （CRD）。但是，預計未來將提供支持，從Roadmap上也看到有和 Istio 集成的規劃。
基於流量的自動伸縮
Traffic Director 前面支持的功能，基本都有不出意外的感覺，畢竟熟悉 Istio/Envoy 體系的同學對這些功能都瞭如指掌。而 自動伸縮這個功能是一個特例。
援引 Traffic Director 官方文檔對此功能的描述：
根據您的服務規模智能快速進行地自動擴縮
Traffic Director 可根據您的需求自動擴縮，您只需按實際用量付費，並且快速智能地進行擴容，無需聯繫雲服務提供商也不必進行任何預熱。
看到這段描述，第一反應是：這不是 serverless 嗎？按需伸縮，按使用付費。
Traffic Director 在提供標準的 service mesh 功能的同時，也引入了 serverless 的特性。下面是 Traffic Director 中自動伸縮功能的實現方式：
Traffic Director 根據代理向其報告的負載信號啓用自動伸縮。Traffic Director通知 Compute Engine autoscaler 流量變化，並讓 autoscaler 一次性增長到所需的大小（而不是像其他 autoscaler 那樣重複步驟），從而減少 autoscaler 對流量峯值做出反應所需的時間。
自動伸縮的功能不僅僅可以用於常規的按照請求流量進行擴容和縮容，也支持某些特殊場景，如前面在介紹全局負載均衡時提到的：如果最接近客戶端服務的實例已關閉或過載，則 Traffic Director 會控制流量無縫轉移到下一個最近區域中的健康實例。
此時由於原來兩個區域的流量都進入了一個區域的Shopping Car服務，可能出現流量超出當前承受能力的情況，此時 Traffic Director 會指示 Compute Engine autoscaler 增加Shopping Car服務的容量。同理，Payments 服務的容量也會隨之增加。
按照 Google Cloud 官方博客文章的介紹， Traffic Director 在這塊的處理非常的複雜而智能：在新增加的容量生效之前，Traffic Director 會暫時將流量重定向到其他可用實例 - 即使在其他區域也是如此。（也就是前面所說的跨區域溢出，其指導原則是可用性目標高於低延遲目標）一旦 autoscaler 增加了足夠的工作負載容量以維持峯值，Traffic Director 就會將流量移回最近的zone和region，再次優化流量分配以最小化每個請求的RTT。
從這裏可以看到， Traffic Director 結合使用了 Service Mesh 的路由控制能力和 Serverless 的按需自動伸縮的資源調度能力，在故障處理和自動運維上表現非常突出。
可以說，Traffic Director 在 servicemesh 和 serverless 整合的道路上邁出了重要的一步。這是一個非常有創新的想法，值得借鑑和學習。
功能限制
Traffic Director 官方文檔中列出了一些目前的功能限制，這裏摘錄其中比較重要的部分：
- Beta版本的Traffic Director僅支持GCP API。Beta版本的Traffic Director不支持Istio API。
- Traffic Director僅支持HTTP流量。
- Traffic Director流量控制功能是 Alpha 狀態。
- 本文檔討論了Envoy代理，但您可以將任何 開放標準API（xDS v2）代理 與Traffic Director一起使用。但請注意，Google僅使用Envoy代理測試了Traffic Director。在此測試期間，Traffic Director僅支持Envoy版本1.9.1或更高版本。
和Istio的關係
在瞭解 Traffic Director 之後，相信很多人會和我一樣有同樣的問題：Traffic Director 和 Istio 到底有什麼關係？
簡單介紹Istio：Istio提供控制平面來保護，連接和監控微服務。它有三個組成部分：Pilot 負責流量管理，Mixer 負責可觀察性，Istio Security（Citadel） 負責服務到服務的安全性。
Traffic Director 和 Istio 的基本區別在於，Istio 是一個開源產品，而 Traffic Director 是一個完全託管的服務。
在具體的功能模塊上，Traffic Director 將取代 Pilot 的位置：所有 Pilot 能提供的功能，Traffic Director 都將提供。這也是採用 open xDS v2 API的原因，以便在開源的 Pilot 和 Traffic Director 之間切換。
總結說：Traffic Director 提供了 GCP 託管的 Pilot ，以及全局負載均衡和集中式健康檢查等其他功能。
但請注意，當前 Traffic Director Beta 版本還無法使用 Istio API 配置 Traffic Director，暫時只能使用GCP API進行配置。
在 Sidecar 的注入上，Istio 支持自動注入，而 Traffic Director 目前需要手工注入 Sidecar，不過未來 Traffic Director 應該會支持自動注入，畢竟這個功能實現上並不複雜。
Traffic Director 的 Roadmap 中，有和 Istio 進一步集成的計劃，從下圖上看是準備引入 Istio Security（Citadel），以提供安全特性如mTLS，RBAC等。
暫時未看到有引入 Mixer 的信息。
Traffic Director Roadmap
援引最新 Traffic Director 介紹的PPT，Traffic Director 的 Roadmap 中未來準備加入以下內容：
-
安全方面的集成，要支持 mTLS/RBAC，看前面的圖片是打算引入Istio Security （Citadel）模塊。
-
可觀測性集成：按說是Istio Mixer模塊，但是沒見到介紹，懷疑是不是因爲 Mixer 在性能上的拙劣表現，導致Traffic Director 可能採用其他方案，後續關注。
-
hybird/Multi-cloud支持
-
通過 Istio API 來進行控制
-
和其他控制平面組建聯邦
![]()
Traffic Director 分析
從前面的功能介紹中可以看到，Traffic Director 的重要賣點和特色在於：
- 對混合雲/多雲的支持
- 對VM服務（或者說非雲原生服務）的支持
- 整合了 serverless 的部分特性
其他功能不是說不重要，而是相對來說比較常規化，即託管的服務網格理論上說應該都會提供這些功能：
- 完全託管，無需運維，GA後提供SLA保證
- 流量管理（包括路由和策略）/安全/可觀測性
- 全局負載均衡
- 集中式健康檢查
從產品定位上說，Traffic Director 只提供控制平面，對於數據平面理論上只要兼容xDS v2 API即可，也就是說 Traffic Director 完全關注在控制平面，前面列出來的幾個重要的賣點也都屬於控制平面的創新和深耕，和數據平面關係不大，或者說數據平面只需簡單的提供底層支持。從這點上看，和Istio專注在控制平面，而將數據平面完全委託給 Envoy 的做法可謂一脈相承。
在API的選擇上，Traffic Director 的做法是支持開放的 xDS v2 API，以及計劃中的通過 Istio API 來進行配置。一方面在產品層面上和開源的Envoy/Istio保持一致，另一方面也通過這種方式實現了其一直宣傳的不鎖定的目標，對於市場宣傳和爭取客戶應該是有利的，也有助於實現混合雲和多雲戰略。
目前 Traffic Director 還處於 beta 測試階段，尤其流量配置更是還在 alpha 階段，產品的成熟度還不夠高，roadmap中也還有很多非常重要甚至急迫（如可觀測性）的內容有待完成。因此不適合對 Traffic Director 過早的做判斷和評論，我的觀點是 Traffic Director 代表的產品方向應該是非常有前途，可以給客戶帶來實際價值。這是Google 在ServiceMesh領域（甚至是Serverless領域）新的探索和嘗試，期望有好的結果。
對 Traffic Director 的理解，我的觀點是不能單獨的只看 Traffic Director 這一個產品，而是要結合近期 Google 陸續推出的幾個相關產品：
- Google Cloud Service Mesh：ServiceMesh產品，簡單理解爲 Istio 的GCP託管版本（猜測可能是兼容Istio API的內部實現/擴展版本），探索方向爲在公有云上提供 Service Mesh 託管服務
- Google Cloud Run：Serverless 產品，簡單理解爲 knative 的GCP託管版本（猜測依然可能是兼容 Knative API的內部實現/擴展版本），探索方向爲在公有云上提供 Serverless 託管服務
- Anthos：Hybird/Multi-Cloud產品，號稱業界”第一個真正的混合和多雲平臺”，探索方向爲 Google 宣稱要 “All in”的混合雲市場
然後再來看，作爲託管版 Service Mesh 控制平臺而推出 Traffic Director 產品，我們前面列出的三個賣點和特色：對混合雲/多雲的支持；對VM服務（或者說非雲原生服務）的支持；整合 serverless 的部分特性。和這三個新產品可謂交相呼應。
摘錄兩句從最近的 Google Cloud Next 大會信息中看到的話，是不是更有體會？
- Write once, Run Anywhere/一次寫好，哪都能跑
- Use open-source technology easily and in a cloud-native way / 以雲原生的方式，輕鬆使用開源技術
Google / Google Cloud 在下一盤很大的棋，一盤圍繞雲和雲原生的大棋:
以云爲戰場，以kubernetes爲根據地，以開源開放不鎖定爲口號，以雲原生爲旗幟，以ServiceMesh和Serviceless爲橋樑連接起應用和基礎設施，以混合云爲突破口……劍指當前雲計算市場排名第一/第二的AWS/Azure。
參考資料
Traffic Director目前能找到的資料不多，基本都是Google Cloud放出來的新聞稿/博客和官方文檔，還有兩次cloud next大會上的介紹演講及PPT。第三方的介紹文章非常的少，因此在調研和整理資料時不得不大量引用來自Traffic Director官方渠道的資料和圖片。
- Traffic Director concepts: Google Cloud 上的 Traffic Director 官方文檔
- Google Cloud networking in depth: How Traffic Director provides global load balancing for open service mesh：來自Google Cloud網站的官方博客文章，發表時間爲 2019-04-18
- Google Cloud’s Traffic Director — What is it and how is it related to the Istio service-mesh?：來自Medium網站的博客文章，原作者爲 Iftach Schonbaum，發表時間 2019-04-16
- Introducing Traffic Director: Google’s Service Mesh Control Plane：來自 InfoQ 網站的文章，發佈時間 2019-04-25
- Traffic Director & Envoy-Based L7 ILB for Production-Grade Service Mesh & Istio: Google 在 Cloud Next ‘19 大會上的主題演講，發表時間 2019-04-10（本文的很多圖片摘錄自這個演講的ppt）
- Hybrid and Open Services with GCP, Envoy and Istio: A Talk with Google and Lyft : Google 在 Cloud Next ‘18 大會上的主題演講，發表時間 2018-07-26
作者簡介
中年碼農
我目前研究的方向主要在Microservice、Servicemesh、Serverless等和Cloud Native相關的領域，歡迎交流和指導
本文轉載自敖小劍的博客。
原文鏈接：
https://skyao.io/post/201905-google-traffic-director-detail/