在美國西雅圖召開的首屆EnvoyCon大會上，來自Pinterest、Yelp和Groupon的工程師們展示了他們目前的Envoy Proxy用例。最重要的信息是，Envoy Proxy似乎離實現他們的願景越來越近了：爲現代網絡提供“通用[代理]數據層API”，其中包括邊緣網關、服務網格和混合網橋。
正文：
在美國西雅圖召開的首屆EnvoyCon大會上，來自Pinterest、Yelp和Groupon的工程師們展示了他們目前的Envoy Proxy用例。最重要的信息是，Envoy似乎離實現他們的願景越來越近了：爲現代網絡提供“通用[代理]數據層API”。大型商業組織正委託Envoy管理各種用例的生產流量，其中包括邊緣網關、服務網格和混合網橋。
在過去的一年裏，Pinterest工程團隊已經把“周邊負載均衡器”模型遷移到基於Envoy的邊緣代理，其中所有的生產邊緣流量現在都通過Envoy。Pinterest的流量站點可靠性工程師（Site Reliability Engineer，簡稱SRE）Derek Argueta描述了現有基礎設施是如何部署到AWS公共雲中的，並使用一個第7層AWS經典彈性負載均衡器和一個Varnish緩存來提供入口流量管理。該解決方案遇到的挑戰包括ELB擴展問題、TLS終止不夠理想和缺乏對動態上游處理（如，在部署新服務或舊實例退出時更新路由）的有效支持。在分析了當前可用的網絡代理之後，該團隊還發現遷移到Envoy的其他動機，包括擴展API、更有效的可觀察性以及與服務網格計劃的一致性。
最初的Envoy遷移工作集中於創建新的邊緣解決方案，該方案提供了與現有堆棧相同的特性，包括服務A/B部署、機器人檢測和CDN請求籤名。在遷移過程中遇到了幾個小問題，包括Envoy的積極的默認斷路、編排跨容器的熱啓動以防止流量下降，和各種HTTP的問題（與Hyrum的定律有關）。因此，該工程團隊投入了大量的研發力量以調試Envoy問題。這是個挑戰，原因是邊緣工程團隊中現有的技能特別側重於基於硬件的企業負載平衡器解決方案。
對Pinterest用由Envoy支持的邊緣新解決方案實施“基於階段的”A/B部署，Argueta提供了一個全面的概述。爲了與現有的部署系統兼容，這是作爲“定製解決方案”實施的。在新特性推出的過程中，部署了該服務的多個版本，通過一系列添加到Zookeepe的主機、IP和的階段數據控制路由。數據通過定製的控制計劃傳遞給邊緣Envoys，該控制計劃由與端點發現服務（endpoint discovery service，簡稱EDS）API交互的邊車進程組成。
在可觀察性方面，創建了一系列圖表和控制面板，並進行了迭代，目的是提供“高信噪比”及幫助SRE及其他工程師快速識別問題和相關的潛在原因。對邊緣Envoy配置了警報，用於監視高資源使用情況、連接錯誤和協議錯誤。未來要做的工作包括提供Thrift支持和Memcached集成、添加MySQL和Apache Kafka過濾器，並把API身份驗證移到邊緣Envoy。
接下來是由來自Yelp的軟件工程師Ben Plotnich和技術負責人John Billings分別就“如何用Envoy（和其他遷移）來DDOS你自己”進行了演示。John Billings一開始就提到應用程序開發人員主要關心的是，快速交付沒有錯誤的代碼以解決客戶的問題，而新RPC技術的應用或通信超時值的設置等問題卻沒那麼在意。因此，在2014年，Yelp的基礎設施工程團隊實施了他們所謂的“服務網格第1版”。它從應用程序到基礎設施抽象了一些網絡通信處理，通過運行中心化的（和人工配置）HAProxy路由層實現。這和來自傳統的面向服務體系結構（service-oriented architecture，簡稱SOA）的企業服務總線（enterprise service bus，簡稱ESB）模式有點類似。
儘管有用，但需人工重複加載HAProxy（和相關的工程工作）再加上擴展的問題，致使架構團隊又實現了“服務網格第2版”，它是基於AirBnb的SmartStack的服務發現解決方案。該解決方案仍然使用HAProxy，但是利用邊車進程自動實施了很多常規操作任務。這意味着不需要等待人工操作來實施配置更改，也不再存在人工擴展問題。
儘管這個解決方案成功地運行了4年，但在2018年進行的一項應用程序“開發人員幸福感”問卷調查結果中，揭示了一些有改善潛力的領域。這包括實施動態請求路由的能力和在將其暴露給用戶流量（無需運營工程師的時間）之前獲得訪問生產Canaries的能力。通過對相關的操作風險進行評估，探索了3個潛在的解決方案：因爲工程團隊已經熟悉HAProxy，可以擴展它提供該功能；轉而使用Envoy，可以借鑑Lyft、谷歌和IBM的成功案例；或者切換到Linkerd，這是另一個流行的開源服務網格實現。最終決定使用SmartStack提供的底層架構模式，遷移到Envoy支持的服務網格。
基礎設施工程團隊實現了“meshd”，這是一個Envoy的簡單控制平面，用Python編寫而成（因爲該團隊熟悉Python），並使用平面文件加載配置。應用“增量開發”原則，確定了一個精簡的用例，和一個用meshd實現端到端的解決方案以驗證該方法。
Plotnick討論瞭如何識別提供最大影響(最少入侵)的“切點”，從而引導他們實現供開發團隊使用的瘦客戶端庫。這些瘦客戶端提供的功能包括：上下文傳播、設置x-envoy-*報頭和數據編組。客戶端庫也是實現功能標識的理想位置，通過在現有的和Envoy支持的新解決方案之間路由的切換來實驗。
在Envoy支持的新網格的開發過程中，應用了持續集成和持續交付原則，端到端的自動測試取代了先前解決方案中的人工驗證。
在演示的結尾部分提醒道，儘管用像Envoy這樣的新技術很有趣，但對工程來講，主要的關注點應該是解決用戶問題，畢竟，這是成立組織和團隊的原因。
隨後，Groupon的軟件工程師Tristan Blease和高級軟件工程師Michael Chang做了題爲“縮小本地和雲之間的差距：一個關於Envoy+混合邊界的故事”的演講。Groupon目前在內部運行其大多數應用程序負載，但是，計劃最終運行混合棧，其中包括部署在Kubernetes上的公共雲和容器化服務。
目前的棧使用各種技術來處理邊緣和內部流量，而計劃的遷移創造了新的需求，需要評估這些需求：避免人工配置流程、圍繞可觀察性提供“更強大的故事”、實現TLS和對服務到服務通信的訪問控制。他們的工程團隊實驗並確定了他們的“理想架構組件”，其中之一是Envoy。
Tristan Blease和Michael Chang提供了對目前和計劃的系統架構全面的概述，討論了把流量從本地遷移到雲以及從雲遷移到本地的挑戰，Envoy實例將部署成邊緣代理節點，負責不同環境之間的路由流量。Envoy的配置將主要用NoSQL數據庫存儲，只需一點點粘合就可以作爲控制平面工作，提供主機、路由和端點數據給相關的Envoy管理xDS API。
請從EnvoyCon Sched頁面下載有關演講的幻燈片，另外在CNCF的油管頻道上有很多演講的視頻。
原文作者：Daniel Bryant，發佈於2018年12月31日
原文鏈接：The Many Faces of Envoy Proxy: Edge Gateway, Service Mesh, and Hybrid Networking Bridge，https://www.infoq.com/news/2018/12/envoycon-service-mesh