知識星球導讀：隨著Service Mesh在最近一年進入人們的視野，Envoy 作為其中很關鍵的元件，也開始被廣大技術人員熟悉。本文作者所在公司已經從 nginx 遷移到 Envoy。
隨著我們下一代產品釋出，我們將代理軟體從 nginx 切換到 Envoy 。
我們很早就開始關註 Envoy。 公司的一些人之前在 Twitter 工作，其中一些人和 Matt Klein 一起組建了 Twitter 的邊緣代理 TFE。 我們知道 Lyft 正在計劃建立一個基於 TFE 的開源代理模型，我們對此很感興趣。 不幸的是，我們剛開始做自己產品的時候它還沒有準備好，所以起初我們還是使用 nginx。
我們很高興看到 Envoy 的最初功能集合中包含了大量靈活運用微服務的想法。 我們更加興奮地看到它的社群已經成型並且技術已經成熟。 現在 Envoy 提供的功能(相比於 nginx)可以使我們能夠更快地為客戶提供新功能。當然，Envoy 的功能路線圖也非常令人興奮。
選擇代理
在啟動Turbine Labs時，我們就知道負載均衡將成為我們基礎架構的關鍵組成部分。
在2015年秋季的時候，代理軟體並不是我們今天看到的樣子。
我們選擇 nginx 是因為它輕巧，經過大量生產環境測試，開源，相對來說易於擴充套件，並且擁有蓬勃發展的使用者群體。然而我們必須做很多額外的工作才能在 nginx 之上構建一個全功能的流量管理解決方案。
服務發現，統計管理和更細粒度的負載均衡是現代基礎架構的關鍵特性。 我們在 nginx 之上來實現這些功能，雖然已經花了很長時間，但仍有很多工作要做。
相比之下，Envoy 有很多非常有用功能（如 gRPC，tracing 等等），同時提供類似（或更好）的效能，穩定性和社群。
剋服反對意見
採用任何新技術都需要考慮相反的意見。 由於我們已經部署了代理服務，不僅需要考慮到自己的問題，還需要考慮到客戶提出的問題。 對於開源專案，這些問題通常分為以下幾類：
-
當它失敗時，它是如何失敗的？
-
獲取幫助容易嗎？
-
需要改很多程式碼嗎？
-
要多少錢？
我們一直密切關註 Envoy 的開發進展，並對它的成熟速度感到驚訝。已經有不少公司在生產環境使用 Envoy。Envoy 現在是一個 CNCF 專案，這意味著社群是透明和開放的。 程式碼貢獻者來自很多公司，我們也在其中。
成本也是需要考慮的因素。隨著 sidecars 成為更普遍的部署方式，代理會得到更廣泛的應用。 雖然許多客戶將繼續集中式執行負載均衡，但我們希望代理軟體可以優雅地支援邊車部署模型。
Envoy 採用 C++ 11 編寫，執行時佔用的記憶體很少，與依賴較重執行時的代理相比，顯著減少了 sidecars 部署的負擔。
服務提供方的好處
應始終謹慎對待技術堆疊的大型更改。我們沒有輕易轉向 Envoy，但我們獲得的好處以及我們可以傳遞給我們客戶的好處非常顯著。
可管理性
從一開始，Envoy 就被設計為可以大規模管理。 我們已經做了很多工作來使我們的基於 nginx 的代理可管理，但是這個配置介面不太容易地暴露給其他工具。
Envoy 資料平面 API 為其集中管理提供了一個開放標準。 我們可以提供一個集中的，開放的控制點，而不是複製配置檔案。
可擴充套件性
nginx 是一個非常成功，穩定的開源專案。 其配置檔案和模組生態系統具有較大的外圍應用，並有大量現有使用者支援。 給 nginx 貢獻核心程式碼是非常有挑戰性的，這導致在許多情況下需要編寫自定義模組或 Lua 指令碼以擴充套件其功能。
Envoy 更為聚焦，使用更為現代的語言支援改變代理行為。過去幾個月中，我們向 Envoy 提交了超過 30 個功能，其中包括 OSX 構建 ，子集負載均衡和 upstream 日誌記錄等主要功能。
服務使用方的好處
更豐富的群集模型
我們在 nginx 上做了一些擴充套件，從而增強其 upstream 模型並新增更多細節。在同時部署同一服務的多個版本時，僅僅瞭解實體的主機和埠是不夠的。
Envoy（透過我們貢獻的補丁）允許將任意元資料附加到服務實體，以及定義基於該元資料定義路由規則。這使先進的流量管理技術成為可能，例如增量釋出， 藍/綠版本，無縫整體分解和生產測試 。
多協議支援
NGINX支援很多協議。 Envoy 的架構可以輕鬆地新增對新協議的支援，並且它也提供了多種協議支援。 雖然 HTTP 佔據了網際網路流量的很大一部分，但增加對 Redis，Mongo，Dynamo，websockets 和 gRPC 流量的可見性也是非常重要的。
動態服務發現
隨著微服務，容器變得越來越流行，服務拓撲變得更加動態。配置檔案中的伺服器串列很快就會過時。 Envoy 使用一種最終一致的模型來進行 API 驅動的服務發現，並且能夠很好地處理變化頻繁的實體。
我們目前從各種平臺收集資料，而 Envoy 的群集發現服務（CDS）為我們提供了比固定配置檔案更自然的抽象。 Envoy 透過支援監聽器發現服務（LDS）和路由發現服務（RDS）支援路由拓撲發現，從而進一步加強了這一點。 最終允許從中央控制點動態重新配置大部分服務拓撲，這非常有用。
網路策略
微服務意味著網路更加依賴於服務抽象邊界。 隨著相互依賴的服務數量日漸增長，系統100%沒問題的時間會變少，整個系統經常有部分功能處於降級狀態。
管理網路策略（如重試，超時和速率限制）對於在面對系統健康問題時保持順暢的客戶體驗至關重要。Envoy 允許在代理（每個路由） 和客戶端（每個請求的基礎上）配置這些策略。 這可以靈活地實現（難以用 nginx 實現的）極細粒度彈性策略。
監測
Envoy 使用行業標準的請求日誌，還提供與各種監測系統的整合。 它還提供對 Zipkin 和 Lightstep 的原生支援，以便追蹤整個請求鏈。
如何更快遷移
我們對遷移到 Envoy 的過程非常滿意。 它穩定，快速，輕便，並擁有一個偉大的社群。 它的架構使其非常適合微服務，但它同樣適合做邊緣代理。 作為基礎服務，使用配置API而非靜態配置檔案真是太棒了。
如果你已經開始使用 Envoy，或者正在考慮遷移到 Envoy，那就可以考慮使用我們的服務。憑藉廣泛的服務發現和卓越的管理介面，我們可以幫助您快速，平穩地部署和運營 Envoy。
英文原文：
https://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d
更多 Envoy 介紹：
https://www.envoyproxy.io/
相關閱讀：
微博開源的Motan RPC最新進展：新增跨語言及服務治理支援
本文作者Mark McBride，由方圓翻譯，轉載本文請註明出處，技術原創及架構實踐文章，歡迎透過公眾號選單「聯絡我們」進行投稿。
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
