他們將生產環境從nginx遷移到envoy，緣由居然是……

導讀：隨着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/