下一代服務型流量網關
今天,所有的軟件架構都在遷移到雲原生架構。雲原生架構具有以下特點:
-
它由具有彈性設計的微服務架構構建。。
-
按需性能的擴展能力。
-
完全解耦控制邏輯和業務邏輯。
-
旨在實現高可用性和 >99.9% 的正常運行時間 SLA。
並且有四個關鍵性的東西要很好地通過雲原生方式構建並被調度
-
基礎設施運行時資源。底層的計算節點、存儲、網絡,目前,這些資源在都由容器和 Kubernetes 來管理和調度。
-
應用程序數據和狀態。應用程序數據和狀態需要持久化或在集羣範圍內同步。我們可以看到主流的數據庫(SQL/NoSQL)、緩存、隊列等現在都支持分佈式集羣和高可用解決方案。
-
應用服務。這些服務現在由 Kubernetes 編排並由微服務架構管理,其中包括服務發現、服務配置管理、服務網關 / 代理、彈性和容錯、存活和健康檢查、可觀察性(指標、日誌、跟蹤)、等等組成。
-
流量編排。大多數在線服務需要處理來自世界各地的用戶請求。這些流量將用於不同的目的並訪問不同的資源。因此,管理這些流量並將其與雲原生後端服務保持一致非常重要。
關於流量編排,作爲雲原生網關,必須具備以下特點。
-
與微服務架構保持一致。
-
分佈式系統技術的高可用性。
-
使用各種過濾器和 API 聚合的管道來編排流量。
-
符合雲原生架構,如 Service Mesh、FaaS 等。
-
服務可觀察性 - 跟蹤、指標(吞吐量、延遲、錯誤等)、訪問日誌。
爲了實現這一點,在這裏,我們將介紹一個下一代服務流量網關 - Easegress 該軟件是用 Go 編寫的開源軟件(Apache 2.0 許可證),採用 Go 編程語言,天然具備在高併發場景下提供高性能服務的能力。
在說明 Easegress 的功能之前,想先說一下,爲什麼我們要從頭做一個這樣的網關。其實,我們在解決用戶的一些性能問題的時候需要用到一個流量調度的控制系統。在一開始的時候,我們主要是使用 Nginx + Lua 的方式,但在解決用戶問題的過程中發現,對於一個流量調度網關,有兩個非常重要的特點是我們無法避開的。
-
流量調度和編排,而不是一個反向代理。對此,我們需要的是一個 Cloud Native 架構軟件,也就是說,其必須是一個高可用的集羣,而且,需要能夠對流量進行着色,以及對流量的功能能夠動態編排,有 Admin API 和非常好的監控觀測能力。這個方面,Nginx 在集羣方面並不夠好,需要藉助其它第三方的能力來完成。
-
會有各種各樣的業務邏輯的侵入,所以需要非常容易的擴展。需要易擴展,一般來說會有三種技術方案:
-
源代碼修改。這需要軟件使用的語言門檻要足夠低,可以讓業務開發的開發人員能夠擴展代碼。所以,對於 Nginx 的 C+Lua 的方式,我們覺得並不夠好。C 太晦澀也太容易出錯,Lua 的表現能力又不夠複雜。所以,我們使用了 Go 語言。
-
集成其它語言。Nginx 使用 Lua 的能力可以擴展很多代碼能力。Lua 很不錯,但是我們覺得對業務功能的表現力不夠,所以,我們想到了 WebAssembly 引擎,這樣就可以擴展到所有的高級語言代碼上了。
-
第三方集成。通過像 FaaS 這樣的技術進行第三方集成。做到真正的控制邏輯和業務邏輯分離。而且,業務邏輯分離到 FaaS 服務中可以由 Kubernetes 進行伸縮。
這三種方案各有千秋,適用於不同的場景。
-
第一種需要重編譯,擴展能力很強,但需要重新發,而且業務邏輯入侵控制邏輯,也會影響穩定性。
-
第二種可以動態加載,沒有部署負擔,但擴展能力受限。
-
第三種在體外擴展,有性能損失,架構邏輯也很複雜,但是分離的很好,性能有損的業務邏輯在 FaaS 的管理內可以自由水平擴展。
我們認爲,要支持好上述的這些功能,目前整個開源社區中基本沒有,最接近的是 Envo,但可惜是 C++ 的。所以,我們決定用 Go 語言寫一個。
Easegress 的架構構圖如下所示:
圖片源: https://github.com/megaease/easegress/blob/main/doc/architecture.png
Easegress 的主要設計如下:
-
流量處理功能或過濾器可以通過插件機制開發。
-
可以通過管理 API 在運行時運態地將功能或過濾器組織到 Pipeline 中。
-
可以很自由的擴展和注入用戶的自定義和業務邏輯代碼。
-
有兩種類型的控制器有助於管理和集成到整個雲原生架構。
-
流量控制器 - 服務網格、函數即服務 等。
-
系統控制器 - 服務發現、監控、集羣等。
-
應用級協議支持
-
HTTP 1/2/3
-
WebSocket
-
MQTT
此外,Easegress 還具有以下 Cloud Native 功能
-
微服務架構合規
-
Spring Cloud 兼容性
-
Restful API 協議 - API 路由和 API 聚合。
-
服務發現集成 - Eureka、Consul、Nacos、Etcd 和 Zookeeper。
-
彈性和容錯(從 resilience4j 項目移植)- 斷路器、速率限制器、重試器、超時等。
-
雲原生架構集成
-
Kubernetes 入口控制器
-
Service Mesh - 邊車和入口控制器
-
FaaS - Knative
-
高可用性和高性能
-
內置的 Raft 共識和領導者選舉提供 99.99% 的可用性。
-
負載平衡 - 輪詢、隨機、加權隨機、根據 IP/HTTP 頭部 哈希。
-
緩存 - 緩存後端服務響應。
-
可觀察性
-
服務跟蹤 - 內置 Open Zipkin 和針對供應商中立 API 的分佈式跟蹤。
-
吞吐量 - QPS/TPS m1、m5、m15 和錯誤率
-
延遲 - P999、P99、P98、P95、P75、P50、P25
-
帶寬 - 請求和響應數據大小
-
響應 - HTTP 狀態代碼統計信息。
此外,Easegress 具有很好的可擴展性,可以很容易地將自定義特性或功能添加到 Easegress 中,有三種方法可以做到這一點。
-
過濾器或控制器。按照開發指南,您可以使用 Go 語言開發過濾器和控制器。但是這需要重新編譯軟件。
-
WebAssembly。Easegress 支持 WASM 運行時引擎,因此,您可以使用任何支持 WASM 的編程語言開發過濾器,並且 Easegress 可以在運行時加載它。
-
函數即服務 FaaS。Easegress 支持 Knative 集成,因此您可以部署 Easegress 之外的函數服務。這種方式看起來有點重,但在 Kubernetes 的加持下,它是一個可水平擴展的解決方案。
因此,Easegress 可以是一個開發框架或一個二次開發平臺,您可以在之上專注於自己的業務邏輯。
Easegress 有能力勝任如下工作(包括並不限於)。
-
反向代理(負載平衡)-- 負載平衡的若干策略(示例)
-
**服務代理 **
-
服務發現 - Zookeeper, Eureka, Consul, Nacos 等。(示例)
-
FaaS - Knative 集成(示例)
-
Kubernetes 入口控制器 (示例)
-
Pipeline - 編排若個 HTTP 請求 / 響應 過濾器,形成一個管道處理(示例)
-
API 聚合 - 將許多 API 聚合到一個 API 中。(示例)
-
彈性與容錯 - 斷路器、速率限制器、迴流器、時間限制器等。(示例)
-
分佈式跟蹤 - 支持 APM 跟蹤 - Zipkin。(示例)
-
高性能
-
性能優化,如壓縮、緩存等。(示例)
-
秒殺活動。高併發的推廣銷售。(示例)
-
Service Mesh - 這是由 Ease Mesh (我們的另一個開源項目) 一個與 Spring Cloud 兼容的服務網格結構系統所利用的。通過 Ease Mesh,我們可以做到非常厲害的事(敬請期待我們未來的發佈)
-
工作流(IFTTT) - 以工作流的形式運行一些 API。(示例)
-
WebAssembly - 使用 AssemblyScript 來擴展 Easegress。(示例)
等等。
今天,我們期待您對這個新的流量網關提出建議或關注,甚至幫助我們把這個網關做得更好。請隨意提交問題或在我們的 Github 中貢獻代碼 - https://github.com/megaease/easegress
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/lgq10J449RN1ZwWXoxW02A