日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡

作者 | Higress 團隊

1前言

K8s 通過 Ingress / Gateway API 將網關標準化，逐步將安全網關、流量網關、微服務網關內聚，解決從單體到微服務到云原生多層網關的復雜度，合久必分，分久必合，多層網關已成過去，網關多合一成潮流，成為 K8s 開發者和微服務開發者共同關心的話題。

2Higress 1.0 正式發布，即官方推薦生產可用

Higress 是阿里云開源的下一代網關，從 2022 年 11 月在云棲大會上宣布開源，走過大半年時間，發布了 GA 版本 1.0.0，即官方推薦生產可用。回顧 Higress 的發展歷程，經歷了三個階段：

Higress 的技術選型和首次業務落地（2020.05~2020.11）

Higress 的創建源于阿里內部的“本地生活戰役”，核心技術目標是實現阿里巴巴業務域與螞蟻業務域之間 RPC 直接調用，但因阿里巴巴與螞蟻業務域網絡是隔離的，即網絡是不通的，很自然想到利用網關來解決此問題。利用網關來解決阿里巴巴與螞蟻跨業務域 RPC 互通問題，首先要對網關做技術選型。選型期，除了關注技術方案是否完美支持 HTTP/gRPC 協議、支持豐富路由策略以及是否業內主流技術，還關注是否支持熱更新。

熱更新是我們的核心關注點。

Tengine/Nginx 的配置更新需要 reload，reload 需要重啟 worker 進程，重啟時會引起流量抖動，對長連接影響尤為明顯。在網關的集群規模非常大時，更是不能隨意的做 reload，這時就會引發一個矛盾點：業務向網關提交配置后，希望能快速驗證，但受限于 reload 機制和穩定性要求，無法滿足業務快速驗證與快速試錯的訴求。

如何解決這點呢？

一是采用兩層網關，即流量網關 + 業務網關；二是實現網關原生支持配置熱更新。除了對比不同方案的優劣勢，我們也調研了 Envoy 作為網關在業界的趨勢，結論是目前 Envoy 作為 K8s 中的 Ingress Provider 增長最快的事實（Ingress Provider 指 K8s Ingress 規范具體實現，因 K8s Ingress 自身只是規范定義，是 K8s 下外部流量進入集群內部的網關規范定義），我們最終選擇了 Envoy 來實現兩層網關，并完美支撐雙 11 大促每秒數十萬的請求流量。

Higress 的重要演進和服務更多業務場景（2020.12~2021.10）：

隨著在阿里巴巴和螞蟻的成功落地，越來越多的業務場景找到了我們。

這個過程中，Higress 實現了東西向、南北向全域流量的調度分發，東西向上不僅支持跨業務域的螞蟻 RPC 互通，也擴展到了混合云的云上云下 RPC 互通場景，覆蓋釘釘文檔、阿里視頻云、達摩院的店小蜜、智慧數字人等。

2021 年，阿里巴巴開啟了中間件三位一體戰役，目標是用云產品支撐集團業務。我們開始將孵化成熟的 Higress 技術沉淀為云產品，即目前阿里云上提供的 MSE 云原生網關，一方面面向廣大的公有云用戶提供托管的網關服務，另一方面也對內服務集團。

Higress 對外開源，通過社區力量加速發展（2021.11~ 至今）：

隨著 Higress 成為云產品服務于更多外部用戶，我們逐步發現用戶對 Higress 提出了更高的要求，其中反饋較多的大的需求點是插件擴展、Waf 防護、多注冊中心、Nginx Ingress 注解兼容以及 HTTP 轉 Dubbo 協議，當然也有很多小的需求點在此就不一一列出，因此該階段我們重點發力在上述用戶反饋的高頻需求。

開源已經成為軟件發展的必然趨勢與快速路徑，因為社區的力量是非常強大的。

因此我們將這套經過內部實踐沉淀下來的網關方案 Higress 正式對外開源，以 Kube.NETes Ingress 網關為契機帶來了流量網關與微服務網關融合的可能性，結合阿里內部實踐沉淀 Higress 實現了流量網關 + 微服務網關 + 安全網關三合一的高集成能力，同時深度集成了 Dubbo、Nacos、Sentinel 等，能夠幫助用戶極大的降低網關的部署及運維成本，而且能力不打折。

3為什么 Higress 能替代多層網關，成為下一代網關

Higress 是 標準化、高集成、易擴展、熱更新的云原生網關。無縫集成容器和微服務生態，是云原生時代的默認選項。

高集成，連接微服務生態

Envoy 提供了 EDS/DNS/STATIC 等多種類型的 Cluster，Higress 基于此具備了對接多種服務發現的能力，可以實現：

1. 通過 Nacos 發現服務 （EDS）
2. 通過 Zookeeper 發現服務 （EDS）
3. 通過 K8s Service 發現服務 （EDS）
4. 通過 DNS 域名發現服務 （DNS）
5. 通過配置靜態 IP 發現服務 （STATIC）

通過 Higress 控制臺可以很方便地進行相應的服務發現配置：

隨著云原生技術的發展，不少企業開始從傳統架構向云原生架構演進，但這過程中傳統架構部署的服務無法被 K8s 的 Ingress 發現并路由成為一個阻塞點，導致業務架構無法平滑地向云原生平滑演進。Higress 依托于 Nacos 等注冊中心的能力，無論服務是否部署在 K8s 集群內，都可以發現服務并進行請求路由。如上圖所示，業務在遷移過程中，可以通過 Higress 將 5% 的灰度流量導入部署在 K8s 上新架構的服務中，進行灰度測試驗證，逐步切流，從而實現業務架構平穩升級。

對于灰度能力，Higress 實現了和 OpenKruise Rollout 進行聯動，可以實現服務灰度發布。整個 Rollout 過程，可以實現自動整合 Deployment、Service、Ingress 一起工作，并向用戶屏蔽底層資源變化。用戶無需手動編輯多個 K8s 資源，即可輕松使用金絲雀發布，A/B Test 等灰度機制。

易擴展，提升網關的業務使命

將插件的生命周期劃分為三個階段：

1. 插件開發階段
2. 分發集成階段
3. 運行生效階段

Envoy 提供的 Wasm 插件機制，解決了插件運行生效階段的問題，基于 ECDS 配置更新機制，插件代碼和配置發生變更均不會導致連接斷開，并且插件運行在安全沙箱中，即使代碼邏輯出現空指針等異常，也不會導致網關發生 Crash。

在插件開發階段，Higress 基于 Proxy Wasm 生態提供了更容易上手的 C++ 和 Go 語言的 Wasm 插件 sdk，在 sdk 中封裝了插件路由和域名級生效的機制，開發者只需關心插件配置解析和運行邏輯即可，在分發集成階段，Higress 定義了 Wasm 插件的 OCI 鏡像規范（ https://higress.io/zh-cn/docs/user/wasm-image-spec），將插件的 README 文檔，配置字段約束信息，以及 Wasm 文件等一起打包在一個 OCI 鏡像中，可以通過支持 OCI 格式的鏡像倉庫進行存儲和拉取。并且可以通過 Higress 控制臺快速啟用插件：

Higress 的插件機制和傳統的基于 OpenResty Lua 擴展的插件機制最本質的區別，也是往往最容易被開發者忽略的是插件分發集成的環節。傳統的 Lua 插件擴展機制，插件自身的版本生命周期是跟著網關的版本走，插件版本更新，以及自己開發插件都需要重新部署網關。而 Higress 依托于 OCI 鏡像進行網關插件的版本管理和分發，實現了插件版本生命周期和網關版本的解耦，用戶只需調整一行插件 OCI 鏡像地址，即可完成插件的熱更新，整個過程網關連接不會發生斷開，流量完全無損。

基于此，在網關上的業務插件邏輯可以很方便地實現熱更新。Higress 也基于此能力提供了很多業務認證和安全相關的官方插件，開箱即用。

標準化，降低改造綜合成本

因為 Envoy 是面向配置管理服務器設計的配置系統，對程序友好，對手寫配置并不友好。因此像 Istio 設計了 VirtualService/DestinationRule/AuthorizationPolicy 等等 CRD 抽象，來解決 Envoy 配置復雜的問題，Istio 的 CRD 本身是解決 ServiceMesh 下復雜的服務治理場景而設計，而對于網關路由場景，更多用戶需要的是 Ingress 這樣更簡單的 API 標準。

Higress 結合阿里內部實踐以及阿里云產品沉淀，積累了基于 Ingress API 的豐富的路由策略擴展能力，同時還兼容大部分 Nginx Ingress 能力，并且可以通過 Higress 提供的控制臺來創建路由，開箱即用：

Higress 控制臺目前對接的底層模型是 Ingress API，如果你對 Gateway API 有了解，會發現 Higress 控制臺上的路由模型，也完全可以用 Gateway API 進行描述：

apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: foo spec: parentRefs: -name: foo-example hostnames: -"foo.example.com" rules: -matches: -path: type: PathPrefix value: /foo headers: -type: Prefix name: x-higress-header value: hi queryParams: -type: Exact name: higressQuery value: hi method: POST backendRefs: -name: foo-service port: 5678

Gateway API 標準目前還處在 beta 階段，尚未完全定稿，生產使用我們更多還是建議用戶使用 Ingress API，避免后續 Gateway API 標準改動帶來 Breaking Change。Higress 對 Gateway API 的支持正在開發中，可以看到基于上面的模型，借助 Higress 控制臺可以幫助用戶屏蔽底層 API 路由標準的代際差異，實現路由從 Ingress API 平滑遷移到 Gateway API，根治對技術標準追趕的焦慮。

K8s 帶來了云原生的路由標準 Ingress/Gateway API，如同 POSIX 定義 Unix 可移植操作系統標準，歷時 35 年經久不衰，云原生的路由標準的生命周期一定會遠超過 K8s 本身。

熱更新，提升接入層穩定性

Higress 基于 Envoy 引擎，為適應現代應用和微服務架構的需求，對傳統流量網關（本文以 Nginx 為例）的不足之處進行改進，實現了真正的配置熱更新，并讓流量網關和微服務網關的融合成為可能。

Nginx 的配置變更 reload ，會導致 downstream 和 upstream 連接都斷開觸發重連，在高并發場景下，downstream 并發重連將導致 Nginx 的 CPU 飆升，最嚴重的還是 upstream 的并發重連，很可能打垮后端業務程序的線程池，造成雪崩。

而 Envoy 依托于精確的配置變更管理，做到了真正的熱更新。在 Envoy 中 downstream 對應 listener 配置，交由 LDS 實現配置發現；upstream 對應 cluster 配置，交由 CDS 實現配置發現。listener 配置更新重建，只會導致 downstream 連接斷開，不會影響 upstream 的連接；downstream 和 upstream 的配置可以獨立變更，互不影響。再進一步，listener 下的證書 (cert)，過濾器插件 (filter)，路由 (router) 均可以實現配置獨立變更，這樣不論是證書 / 插件 / 路由配置變更都不再會引起 downstream 連接斷開。

4Higress 生產實踐最佳參考

可觀測

Higress 提供了自帶的 prometheus 和 grafana 可以開箱即用，同時也支持對接用戶自建的監控系統，詳細請參考：《基于 Prometheus 實現 Higress 流量觀測》： https://higress.io/zh-cn/docs/user/prometheus

安裝部署

可以使用 Helm 一鍵完成 Higress 的生產安裝部署

helm repo add higress.io https: //higress.io/helm-chartshelm install higress -n higress-system higress.io/higress --create- namespace--render-subchart-notes -- sethigress- console.domAIn= console.higress.io

通過增加 helm 參數 --set global.local=true 可以在本地 PC 環境基于 k3s/kind 等工具，進行全功能測試和試用：

詳情可以參考：

《Higress Quickstart》：https://higress.io/zh-cn/docs/user/quickstart

《Higress 安裝部署》：https://higress.io/zh-cn/docs/ops/deploy-by-helm

微服務生態集成

不論 Dubbo/SpringCloud 服務是否部署在 K8s 集群內， Higress 都可以實現對接。因此在 K8s 場景下，用戶可以將 Nginx Ingress 這類流量網關和 Spring Cloud Gateway 這類微服務網關合并，統一替換為 Higress。

《Higress 對接 Dubbo 服務》：https://cn.dubbo.Apache.org/zh-cn/overview/what/ecosystem/gateway/higress/

《Higress 對接 SpringCloud 服務》：https://higress.io/zh-cn/docs/user/spring-cloud

性能壓測數據

Higress 和 Nginx 對比，在 HTTP1 上會略遜一籌，但在現代化協議如 gRPC/HTTP2 上則比 Nginx 好很多。

《gRPC 吞吐是 Nginx 的 4 倍》：https://gist.Github.com/johnlanni/aac7480c17b0fde05fa64a20fc93b165

而如果你使用的是 K8s Nginx Ingress，因為其 Lua 代碼性能較差，即使在 HTTP1 場景下，Higress 性能也更好，具體數據可以參考：

《K8s 網關選型初判》：h ttps://xie.infoq.cn/article/0a2c9ac4ed139bc28f881d7c3

企業用戶落地

Higress 自從 4 月份發布 1.0.0 RC 版本以來，在社區有大量用戶進行安裝和測試，幫助 Higress 變得更成熟，并且適應了更多系統和安裝環境。同時有多家企業完成了 Higress 技術的落地。

開源軟件的發展離不開社區用戶的實踐，用戶的參與和貢獻是推動開源項目成功的關鍵因素。在這里，我們歡迎更多的社區用戶加入 Higress 實踐落地的行列！歡迎到 Higress GitHub issue（ https://github.com/alibaba/higress/issues/1）登記信息，社區將邀請您加入 Higress 落地支持群，我們會為落地用戶提供指導和幫助。

5社區：回顧和展望

Higress 一路走來，保持一個月發布一個版本的頻率，一共完成了 183 個 PR 的合并，發布了 13 個 Release，完成了 5 個里程碑：

Higress 在 1.0 版本 GA 后，將繼續保持高投入，并快速迭代。社區未來三個大版本的核心功能規劃如下：

• 1.1 版本（6 月）
  • 實現 HTTP2RPC API
  • 支持非 K8s 場景下使用
• 1.2 版本（7 月）
  • 支持和 Skywalking 等更多可觀測生態集成
  • 完整實現 Gateway API
• 1.3 版本（8 月）
  • 實現 API 管理產品形態建設
  • 推出獨立的 Wasm 插件集市項目

其中 Wasm 插件生態會作為 Higress 社區長期重點投入方向，目前在中科院開源之夏 /CCF 編程之夏 / 云原生編程挑戰賽等活動中均有 Higress Wasm 插件相關的項目推出，完成項目既能收獲項目獎金，還能收獲開源榮譽，歡迎有興趣的同學參與。