在美國西雅圖舉行的首屆EnvoyCon會議上，來自eBay的工程團隊討論瞭如何將Envoy作爲網絡邊緣，以替代基於硬件的負載均衡器。他們的關鍵經驗包括，測試至關重要，這樣能夠驗證跨一系列真實場景的性能特徵；必須從組織和技術的角度仔細控制新舊邊緣系統之間的遷移；“可編程的邊緣”會帶來很多的優勢，但是也有一些挑戰。
Bala Madhavan和Qiu Yu是來自eBay的技術人員，均爲軟件工程師，他們首先討論了eBay在美國的數據中心，但是他們要在全球範圍內運行連接點（points of presence，PoP）以減少延遲，從而爲終端用戶提供更好性能。他們使用了“軟件支撐的基礎設施”，在每個PoP上部署了一個Kubernetes集羣，並且在每個集羣的邊緣上有一個“north-south”網關，用來管理所有針對外部的傳入和傳出流量。
eBay的邊緣團隊在每個Kubernetes集羣中將Envoy運行在多個容器裏面。針對就緒（readiness）和存活（liveness）狀態的探針會確保容器能夠按照預期的方式運行，並確保所有動態恢復過程都能順利完成。7層路由和部署控制是由一個定製Kubernetes Custom Resource Definitions (CRDs)來進行管理的，他們還使用Ingress註解實現自定義特性的規範。除此之外，他們還實現了一個自定義的發現服務，用於處理如下的Envoy管理xDS API，並負責進行部署和路由：路由發現服務（routing discovery services，RDS)、監聽器發現服務（listener discovery service，LDS)、端點發現服務（endpoint discovery service，EDS)以及集羣發現服務（cluster discovery service，CDS)。
從基於硬件的負載均衡器到Envoy支撐的邊緣解決方案的遷移是漸進式的。在遷移過程中，第一步就是識別和實現已有方案和新Envoy方案之間的差異，eBay團隊已經將相關的代碼貢獻給了上游的Envoy開源項目。另外，他們還添加了對專有證書管理系統集成的支持，並且對data plane進行了一些定製（這些定製功能還沒有往上游貢獻）。它們會處理連接預取（prefetching），根據特定的需求丟棄請求或者將請求重置到特定的路由，而且提供了一個“默認的上游集羣”來優雅地進行錯誤處理。支持BBR，同時添加了對谷歌新TCP流控制算法的支持，以及尚未明確說明的“SSL和TCP優化”。
Madhavan和Yu展示了響應時間的圖表，用以說明新的基於Envoy的實現要比之前傳統的硬件負載均衡器表現更好。它們還以Envoy HTTP過濾器的方式實現了一個額外的緩存層，這個緩存層支持動態對象緩存，能夠使用外部緩存存儲和Envoy的RingHash負載均衡器在多個緩存存儲之間共享緩存的數據，首字節響應時間（time-to-first-byte，TTFB）提高了一個數量級。
在可觀察性方面，在每個PoP上會運行一個Prometheus集羣，另外還有一箇中心化的Grafana用來實現可視化。告警是使用Alertmanager和外部檢查來實現的，還包括用來進行異常探測的靜態和動態閾值。整個邊緣技術棧是通過Helm Chart在Kubernetes中進行安裝和配置的，Helm Chart會作爲部署的唯一來源。
總結一下所學習到的經驗，最重要的就是需要進行測試。硬件和軟件的交叉校驗是非常重要的，爲了確保用戶不會遇到性能下降的問題，實時用戶監控（real user monitoring，RUM）是必不可少的。DC和PoP的故障恢復要進行測試，還需要運行額外的混沌（chaos）試驗。“平滑工作負載遷移”的經驗包括建議進行跨功能（團隊）的規劃和驗證，以可控的方式在邊緣解決方案之間切換流量，同時密切觀察運維指標。
他們提到的挑戰包括運行新系統時增加PoP的數量所帶來的運維操作、跨PoP探測配置漂移以及爲集羣管理提供工具支持。通過API驅動Envoy代理的方式實現“可編程的邊緣”會提供很多的優勢，但是也遇到了很多的挑戰。例如，control plane是“自行構建還是集成”、與已有的（遺留）組件進行集成、如何操作指標和相關的性能數據，以及硬件專家所組成的運維團隊如何調試和解決基於軟件的方案。
演講幻燈片的PDF版本可以在EnvoyCon Sched頁面上“Running Envoy as an Edge Proxy”下載，演講的錄像可以在CNCF YouTube頻道觀看。
查看英文原文：Running Envoy as an Edge Proxy at eBay: Replacing Hardware Load Balancers with a Software Solution