本月Lyft宣布將Envoy交給CNCF托管
在本月 Lyft 宣布將 Envoy 交給 CNCF 托管后，Envoy 的開發者 Matt Klein 發表博客，簡述了 Envoy 的發展歷史以及開源 Envoy 背后的原因。本文最初發布于 Lyft 官方博客，原文 Envoy joins the CNCF，經原作者授權由 InfoQ 中文站翻譯并分享。
我很高興與大家分享一個消息，Envoy 正式加入 Cloud Native Computing Foundation（CNCF）——Kubernetes 的家園——成為它的第十一個托管項目。Lyft 于 2016 年 9 月 14 日宣布了 Envoy 項目，也就是差不多一年前。這是令人難以置信的一年！ 在這篇文章中，我將簡要敘述該項目的歷史，以及我們是如何到達這個重大日子的。
早期歷史
我在 2015 年 5 月加入了 Lyft。當時，Lyft 已經開始了從單體（monolith）到基于微服務架構的遷移過程，并部署了 30 多個服務。雖然 Lyft 已經體驗到并行和解耦開發的許多優勢，但新架構也帶來了挑戰。首先，Lyft 開發人員面臨著這樣的現實：網絡本質上是不可靠的，當問題發生時，幾乎無法確定問題的根源。物理網絡？虛擬網絡？硬件？應用程序？誰知道？在這一時期，Lyft 的開發人員不愿意將關鍵功能移出單體，因為他們認為我們基于微服務發展起來的基礎設施不太穩定。要讓 Lyft 意識到分布式架構的絕對優勢，我們必須直接解決微服務網絡和可觀察性問題。
在 Lyft 之前，我有幸在亞馬遜的 EC2 以及 推ter 的大規模分布式網絡工作多年。我發現，不同的組織在解決分布式網絡問題上存在很大差異。在 推ter，他們使用 Finagle 作為服務間通信的框架，我也看到了它的優勢和不足。與此同時，我領導了一個基于 C++ 的新邊緣代理開發項目，這個代理至今仍然在為 推ter 的流量提供服務。
我們不可小覷 Finagle 和 Netflix OSS 套件這樣的類庫。它們提供了一組豐富的分布式系統網絡功能，如服務發現、負載均衡、重試、超時、熔斷器、協議轉換、統計、日志、跟蹤等。所有這些都旨在讓網絡對程序開發人員透明。然而，基于類庫的部署方法在 推ter 上是有問題的，盡管將近 100％ 的服務都運行在 JVM 上。由于服務提供者升級和部署緩慢，Finagle 的一次更新可能需要數月才能完成。
我們想復制并擴展 Finagle 的功能，將功能轉移到自包含的進程中，這樣更容易迭代和部署。Lyft 和許多其他公司一樣，也有許多使用不同語言開發的服務，因此進程外代理方式變得尤為重要，這樣可以避免在眾多不同的類庫中重復每個功能。另外，從我在 edge 服務系統方面的工作經驗來看，性能——尤其是在最小化尾部延遲方差（tail latency variance）方面——對于分布式網絡組件來說是至關重要的。
因此，在調研過現有的開源方案無法滿足需求之后，才有了 Envoy。出于性能的考慮，我們選擇 C++ 作為實現語言，并于 2015 年 5 月開始開發。初版于 2015 年 9 月初開發完成并部署。最初，Envoy 被用作 Lyft 的邊緣代理。經過不斷迭代，我們的團隊加入了更多功能，并開始將 Envoy 作為我們的邊車（sidecar）服務間代理。到 2016 年初夏，Envoy 在 Lyft 全面部署，并被用于所有邊緣網絡和服務間網絡，形成了一個超過一百個服務和每秒傳送數百萬個請求的網格（mesh）。更為關鍵的是，Lyft 工程已經進入了一個新階段：開發人員開始信任 Envoy 提供的網絡抽象。關鍵的功能正在被逐步移出單體，而且他們沒有對整個網絡的穩定性和可觀察性提出任何質疑。
開源
Lyft 的業務幾乎完全基于開源技術。沒有它，那些我們所知道的和喜愛的打車服務就不可能延續到今天。鑒于在 Envoy 上的大量開發投入，而且我們也了解到，許多其他組織在從單體到微服務架構遷移過程中，也面臨著同樣的挑戰。我們希望能夠回饋社區，因為社區促進了我們公司的發展。因此，我們決定開源 Envoy，并圍繞它建立社區。
我將不會完整回顧在開源之后的幾個月中發生的事情，因為我已經寫過了。我也不會花很多時間來詳細討論為什么我認為 Envoy 在過去一年中已經有了如此巨大的增長（以前的鏈接帖子有討論這個，如我最近發表的關于通用數據面板 API 的帖子）。
我想說的是，在過去一年里，我們對業界的反應感到十分驚訝。Envoy 的大客戶數量在持續增長，基于 Envoy 構建的產品數量也在增長。在一年前，我們完全不敢想象 Envoy 會成為現代互聯網的基礎網絡技術。然而，一年之后，這個項目正在向這個目標邁進。
捐贈給 CNCF
在 Envoy 社區難以置信地增長的同時，也面臨著很多挑戰。維護一個成功的 OSS 項目所帶來的考驗和困難需要我們投入越來越多的精力去克服，因為這是一個艱難且費力不討好的工作。在過去 9 個月里，雖然 Google 是一個非凡的合作伙伴（我們現在有好幾個 Google 維護者！），但我有時仍然會覺得這個項目受限于我，因時間有限，我無法專注于一些事情上，如市場推廣、社區組織、文檔、開發人員推廣等。因此，我們開始考慮將 Envoy 捐獻給基金會，基金會可以幫忙分擔維護工作。此外，合適的基金會也將有助于推動 Envoy 與現有托管項目緊密協作。
在經過研究討論及正式的申請程序和投票之后，我們在 CNCF 找到了我們的家。Lyft 非常興奮地提供了一項技術，在我們的大規模增長過程中，這個技術對基礎設施的穩定性是至關重要的。我們希望 Envoy 能夠幫助到其他組織。CNCF 組建了一個專家團隊負責處理各種開源事務，在項目最佳實踐方面提供幫助，此外還提供了現有的穩定技術，如 Kubernetes、Prometheus、OpenTracing、gRPC 和 Fluentd，這些技術與 Envoy 還有整個云原生開發社區是互補的。
期待
在撰寫本文時，Envoy 有來自至少 10 個不同組織的 78 位貢獻者，主要維護者在 Lyft 和 Google 工作。總體來說，這個項目一直表現非常好。Lyft 將 Envoy 捐獻給 CNCF，既是回饋開源社區的一種方式，也是對事實的認可：基金會的資源將有助于解鎖下一階段的項目增長。作為一種技術，Envoy 有機會成為現代服務架構的主要構件塊。所有在 Lyft 工作的人，以及所有在諸多不同組織中為 Envoy 工作的人，對與 CNCF 的合作將帶來的美好未來都十分期待。
來自: InfoQ