作者 | Higress 團(tuán)隊(duì)
1前言
K8s 通過 Ingress / Gateway API 將網(wǎng)關(guān)標(biāo)準(zhǔn)化，逐步將安全網(wǎng)關(guān)、流量網(wǎng)關(guān)、微服務(wù)網(wǎng)關(guān)內(nèi)聚，解決從單體到微服務(wù)到云原生多層網(wǎng)關(guān)的復(fù)雜度，合久必分，分久必合，多層網(wǎng)關(guān)已成過去，網(wǎng)關(guān)多合一成潮流，成為 K8s 開發(fā)者和微服務(wù)開發(fā)者共同關(guān)心的話題。
2Higress 1.0 正式發(fā)布，即官方推薦生產(chǎn)可用
Higress 是阿里云開源的下一代網(wǎng)關(guān)，從 2022 年 11 月在云棲大會上宣布開源，走過大半年時間，發(fā)布了 GA 版本 1.0.0，即官方推薦生產(chǎn)可用。回顧 Higress 的發(fā)展歷程，經(jīng)歷了三個階段：
Higress 的技術(shù)選型和首次業(yè)務(wù)落地（2020.05~2020.11）
Higress 的創(chuàng)建源于阿里內(nèi)部的“本地生活戰(zhàn)役”，核心技術(shù)目標(biāo)是實(shí)現(xiàn)阿里巴巴業(yè)務(wù)域與螞蟻業(yè)務(wù)域之間 RPC 直接調(diào)用，但因阿里巴巴與螞蟻業(yè)務(wù)域網(wǎng)絡(luò)是隔離的，即網(wǎng)絡(luò)是不通的，很自然想到利用網(wǎng)關(guān)來解決此問題。利用網(wǎng)關(guān)來解決阿里巴巴與螞蟻跨業(yè)務(wù)域 RPC 互通問題，首先要對網(wǎng)關(guān)做技術(shù)選型。選型期，除了關(guān)注技術(shù)方案是否完美支持 HTTP/gRPC 協(xié)議、支持豐富路由策略以及是否業(yè)內(nèi)主流技術(shù)，還關(guān)注是否支持熱更新。
熱更新是我們的核心關(guān)注點(diǎn)。
Tengine/Nginx 的配置更新需要 reload，reload 需要重啟 worker 進(jìn)程，重啟時會引起流量抖動，對長連接影響尤為明顯。在網(wǎng)關(guān)的集群規(guī)模非常大時，更是不能隨意的做 reload，這時就會引發(fā)一個矛盾點(diǎn)：業(yè)務(wù)向網(wǎng)關(guān)提交配置后，希望能快速驗(yàn)證，但受限于 reload 機(jī)制和穩(wěn)定性要求，無法滿足業(yè)務(wù)快速驗(yàn)證與快速試錯的訴求。
如何解決這點(diǎn)呢？
一是采用兩層網(wǎng)關(guān)，即流量網(wǎng)關(guān) + 業(yè)務(wù)網(wǎng)關(guān)；二是實(shí)現(xiàn)網(wǎng)關(guān)原生支持配置熱更新。除了對比不同方案的優(yōu)劣勢，我們也調(diào)研了 Envoy 作為網(wǎng)關(guān)在業(yè)界的趨勢，結(jié)論是目前 Envoy 作為 K8s 中的 Ingress Provider 增長最快的事實(shí)（Ingress Provider 指 K8s Ingress 規(guī)范具體實(shí)現(xiàn)，因 K8s Ingress 自身只是規(guī)范定義，是 K8s 下外部流量進(jìn)入集群內(nèi)部的網(wǎng)關(guān)規(guī)范定義），我們最終選擇了 Envoy 來實(shí)現(xiàn)兩層網(wǎng)關(guān)，并完美支撐雙 11 大促每秒數(shù)十萬的請求流量。
Higress 的重要演進(jìn)和服務(wù)更多業(yè)務(wù)場景（2020.12~2021.10）：
隨著在阿里巴巴和螞蟻的成功落地，越來越多的業(yè)務(wù)場景找到了我們。
這個過程中，Higress 實(shí)現(xiàn)了東西向、南北向全域流量的調(diào)度分發(fā)，東西向上不僅支持跨業(yè)務(wù)域的螞蟻 RPC 互通，也擴(kuò)展到了混合云的云上云下 RPC 互通場景，覆蓋釘釘文檔、阿里視頻云、達(dá)摩院的店小蜜、智慧數(shù)字人等。
2021 年，阿里巴巴開啟了中間件三位一體戰(zhàn)役，目標(biāo)是用云產(chǎn)品支撐集團(tuán)業(yè)務(wù)。我們開始將孵化成熟的 Higress 技術(shù)沉淀為云產(chǎn)品，即目前阿里云上提供的 MSE 云原生網(wǎng)關(guān)，一方面面向廣大的公有云用戶提供托管的網(wǎng)關(guān)服務(wù)，另一方面也對內(nèi)服務(wù)集團(tuán)。
Higress 對外開源，通過社區(qū)力量加速發(fā)展（2021.11~ 至今）：
隨著 Higress 成為云產(chǎn)品服務(wù)于更多外部用戶，我們逐步發(fā)現(xiàn)用戶對 Higress 提出了更高的要求，其中反饋較多的大的需求點(diǎn)是插件擴(kuò)展、Waf 防護(hù)、多注冊中心、Nginx Ingress 注解兼容以及 HTTP 轉(zhuǎn) Dubbo 協(xié)議，當(dāng)然也有很多小的需求點(diǎn)在此就不一一列出，因此該階段我們重點(diǎn)發(fā)力在上述用戶反饋的高頻需求。
開源已經(jīng)成為軟件發(fā)展的必然趨勢與快速路徑，因?yàn)樯鐓^(qū)的力量是非常強(qiáng)大的。
因此我們將這套經(jīng)過內(nèi)部實(shí)踐沉淀下來的網(wǎng)關(guān)方案 Higress 正式對外開源，以 Kube.NETes Ingress 網(wǎng)關(guān)為契機(jī)帶來了流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)融合的可能性，結(jié)合阿里內(nèi)部實(shí)踐沉淀 Higress 實(shí)現(xiàn)了流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān) + 安全網(wǎng)關(guān)三合一的高集成能力，同時深度集成了 Dubbo、Nacos、Sentinel 等，能夠幫助用戶極大的降低網(wǎng)關(guān)的部署及運(yùn)維成本，而且能力不打折。
3為什么 Higress 能替代多層網(wǎng)關(guān)，成為下一代網(wǎng)關(guān)
Higress 是 標(biāo)準(zhǔn)化、高集成、易擴(kuò)展、熱更新的云原生網(wǎng)關(guān)。無縫集成容器和微服務(wù)生態(tài)，是云原生時代的默認(rèn)選項(xiàng)。
高集成，連接微服務(wù)生態(tài)
Envoy 提供了 EDS/DNS/STATIC 等多種類型的 Cluster，Higress 基于此具備了對接多種服務(wù)發(fā)現(xiàn)的能力，可以實(shí)現(xiàn)：
- 通過 Nacos 發(fā)現(xiàn)服務(wù) （EDS）
- 通過 Zookeeper 發(fā)現(xiàn)服務(wù) （EDS）
- 通過 K8s Service 發(fā)現(xiàn)服務(wù) （EDS）
- 通過 DNS 域名發(fā)現(xiàn)服務(wù) （DNS）
- 通過配置靜態(tài) IP 發(fā)現(xiàn)服務(wù) （STATIC）
通過 Higress 控制臺可以很方便地進(jìn)行相應(yīng)的服務(wù)發(fā)現(xiàn)配置：
隨著云原生技術(shù)的發(fā)展，不少企業(yè)開始從傳統(tǒng)架構(gòu)向云原生架構(gòu)演進(jìn)，但這過程中傳統(tǒng)架構(gòu)部署的服務(wù)無法被 K8s 的 Ingress 發(fā)現(xiàn)并路由成為一個阻塞點(diǎn)，導(dǎo)致業(yè)務(wù)架構(gòu)無法平滑地向云原生平滑演進(jìn)。Higress 依托于 Nacos 等注冊中心的能力，無論服務(wù)是否部署在 K8s 集群內(nèi)，都可以發(fā)現(xiàn)服務(wù)并進(jìn)行請求路由。如上圖所示，業(yè)務(wù)在遷移過程中，可以通過 Higress 將 5% 的灰度流量導(dǎo)入部署在 K8s 上新架構(gòu)的服務(wù)中，進(jìn)行灰度測試驗(yàn)證，逐步切流，從而實(shí)現(xiàn)業(yè)務(wù)架構(gòu)平穩(wěn)升級。
對于灰度能力，Higress 實(shí)現(xiàn)了和 OpenKruise Rollout 進(jìn)行聯(lián)動，可以實(shí)現(xiàn)服務(wù)灰度發(fā)布。整個 Rollout 過程，可以實(shí)現(xiàn)自動整合 Deployment、Service、Ingress 一起工作，并向用戶屏蔽底層資源變化。用戶無需手動編輯多個 K8s 資源，即可輕松使用金絲雀發(fā)布，A/B Test 等灰度機(jī)制。
易擴(kuò)展，提升網(wǎng)關(guān)的業(yè)務(wù)使命
將插件的生命周期劃分為三個階段：
- 插件開發(fā)階段
- 分發(fā)集成階段
- 運(yùn)行生效階段
Envoy 提供的 Wasm 插件機(jī)制，解決了插件運(yùn)行生效階段的問題，基于 ECDS 配置更新機(jī)制，插件代碼和配置發(fā)生變更均不會導(dǎo)致連接斷開，并且插件運(yùn)行在安全沙箱中，即使代碼邏輯出現(xiàn)空指針等異常，也不會導(dǎo)致網(wǎng)關(guān)發(fā)生 Crash。
在插件開發(fā)階段，Higress 基于 Proxy Wasm 生態(tài)提供了更容易上手的 C++ 和 Go 語言的 Wasm 插件 sdk，在 sdk 中封裝了插件路由和域名級生效的機(jī)制，開發(fā)者只需關(guān)心插件配置解析和運(yùn)行邏輯即可，在分發(fā)集成階段，Higress 定義了 Wasm 插件的 OCI 鏡像規(guī)范（ https://higress.io/zh-cn/docs/user/wasm-image-spec），將插件的 README 文檔，配置字段約束信息，以及 Wasm 文件等一起打包在一個 OCI 鏡像中，可以通過支持 OCI 格式的鏡像倉庫進(jìn)行存儲和拉取。并且可以通過 Higress 控制臺快速啟用插件：
Higress 的插件機(jī)制和傳統(tǒng)的基于 OpenResty Lua 擴(kuò)展的插件機(jī)制最本質(zhì)的區(qū)別，也是往往最容易被開發(fā)者忽略的是插件分發(fā)集成的環(huán)節(jié)。傳統(tǒng)的 Lua 插件擴(kuò)展機(jī)制，插件自身的版本生命周期是跟著網(wǎng)關(guān)的版本走，插件版本更新，以及自己開發(fā)插件都需要重新部署網(wǎng)關(guān)。而 Higress 依托于 OCI 鏡像進(jìn)行網(wǎng)關(guān)插件的版本管理和分發(fā)，實(shí)現(xiàn)了插件版本生命周期和網(wǎng)關(guān)版本的解耦，用戶只需調(diào)整一行插件 OCI 鏡像地址，即可完成插件的熱更新，整個過程網(wǎng)關(guān)連接不會發(fā)生斷開，流量完全無損。
基于此，在網(wǎng)關(guān)上的業(yè)務(wù)插件邏輯可以很方便地實(shí)現(xiàn)熱更新。Higress 也基于此能力提供了很多業(yè)務(wù)認(rèn)證和安全相關(guān)的官方插件，開箱即用。
標(biāo)準(zhǔn)化，降低改造綜合成本
因?yàn)?Envoy 是面向配置管理服務(wù)器設(shè)計(jì)的配置系統(tǒng)，對程序友好，對手寫配置并不友好。因此像 Istio 設(shè)計(jì)了 VirtualService/DestinationRule/AuthorizationPolicy 等等 CRD 抽象，來解決 Envoy 配置復(fù)雜的問題，Istio 的 CRD 本身是解決 ServiceMesh 下復(fù)雜的服務(wù)治理場景而設(shè)計(jì)，而對于網(wǎng)關(guān)路由場景，更多用戶需要的是 Ingress 這樣更簡單的 API 標(biāo)準(zhǔn)。
Higress 結(jié)合阿里內(nèi)部實(shí)踐以及阿里云產(chǎn)品沉淀，積累了基于 Ingress API 的豐富的路由策略擴(kuò)展能力，同時還兼容大部分 Nginx Ingress 能力，并且可以通過 Higress 提供的控制臺來創(chuàng)建路由，開箱即用：
Higress 控制臺目前對接的底層模型是 Ingress API，如果你對 Gateway API 有了解，會發(fā)現(xiàn) Higress 控制臺上的路由模型，也完全可以用 Gateway API 進(jìn)行描述：
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: 5678Gateway API 標(biāo)準(zhǔn)目前還處在 beta 階段，尚未完全定稿，生產(chǎn)使用我們更多還是建議用戶使用 Ingress API，避免后續(xù) Gateway API 標(biāo)準(zhǔn)改動帶來 Breaking Change。Higress 對 Gateway API 的支持正在開發(fā)中，可以看到基于上面的模型，借助 Higress 控制臺可以幫助用戶屏蔽底層 API 路由標(biāo)準(zhǔn)的代際差異，實(shí)現(xiàn)路由從 Ingress API 平滑遷移到 Gateway API，根治對技術(shù)標(biāo)準(zhǔn)追趕的焦慮。
K8s 帶來了云原生的路由標(biāo)準(zhǔn) Ingress/Gateway API，如同 POSIX 定義 Unix 可移植操作系統(tǒng)標(biāo)準(zhǔn)，歷時 35 年經(jīng)久不衰，云原生的路由標(biāo)準(zhǔn)的生命周期一定會遠(yuǎn)超過 K8s 本身。
熱更新，提升接入層穩(wěn)定性
Higress 基于 Envoy 引擎，為適應(yīng)現(xiàn)代應(yīng)用和微服務(wù)架構(gòu)的需求，對傳統(tǒng)流量網(wǎng)關(guān)（本文以 Nginx 為例）的不足之處進(jìn)行改進(jìn)，實(shí)現(xiàn)了真正的配置熱更新，并讓流量網(wǎng)關(guān)和微服務(wù)網(wǎng)關(guān)的融合成為可能。
Nginx 的配置變更 reload ，會導(dǎo)致 downstream 和 upstream 連接都斷開觸發(fā)重連，在高并發(fā)場景下，downstream 并發(fā)重連將導(dǎo)致 Nginx 的 CPU 飆升，最嚴(yán)重的還是 upstream 的并發(fā)重連，很可能打垮后端業(yè)務(wù)程序的線程池，造成雪崩。
而 Envoy 依托于精確的配置變更管理，做到了真正的熱更新。在 Envoy 中 downstream 對應(yīng) listener 配置，交由 LDS 實(shí)現(xiàn)配置發(fā)現(xiàn)；upstream 對應(yīng) cluster 配置，交由 CDS 實(shí)現(xiàn)配置發(fā)現(xiàn)。listener 配置更新重建，只會導(dǎo)致 downstream 連接斷開，不會影響 upstream 的連接；downstream 和 upstream 的配置可以獨(dú)立變更，互不影響。再進(jìn)一步，listener 下的證書 (cert)，過濾器插件 (filter)，路由 (router) 均可以實(shí)現(xiàn)配置獨(dú)立變更，這樣不論是證書 / 插件 / 路由配置變更都不再會引起 downstream 連接斷開。
4Higress 生產(chǎn)實(shí)踐最佳參考
可觀測
Higress 提供了自帶的 prometheus 和 grafana 可以開箱即用，同時也支持對接用戶自建的監(jiān)控系統(tǒng)，詳細(xì)請參考：《基于 Prometheus 實(shí)現(xiàn) Higress 流量觀測》： https://higress.io/zh-cn/docs/user/prometheus
安裝部署
可以使用 Helm 一鍵完成 Higress 的生產(chǎn)安裝部署
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 參數(shù) --set global.local=true 可以在本地 PC 環(huán)境基于 k3s/kind 等工具，進(jìn)行全功能測試和試用：
詳情可以參考：
《Higress Quickstart》：https://higress.io/zh-cn/docs/user/quickstart
《Higress 安裝部署》：https://higress.io/zh-cn/docs/ops/deploy-by-helm
微服務(wù)生態(tài)集成
不論 Dubbo/SpringCloud 服務(wù)是否部署在 K8s 集群內(nèi)， Higress 都可以實(shí)現(xiàn)對接。因此在 K8s 場景下，用戶可以將 Nginx Ingress 這類流量網(wǎng)關(guān)和 Spring Cloud Gateway 這類微服務(wù)網(wǎng)關(guān)合并，統(tǒng)一替換為 Higress。
《Higress 對接 Dubbo 服務(wù)》：https://cn.dubbo.Apache.org/zh-cn/overview/what/ecosystem/gateway/higress/
《Higress 對接 SpringCloud 服務(wù)》：https://higress.io/zh-cn/docs/user/spring-cloud
性能壓測數(shù)據(jù)
Higress 和 Nginx 對比，在 HTTP1 上會略遜一籌，但在現(xiàn)代化協(xié)議如 gRPC/HTTP2 上則比 Nginx 好很多。
《gRPC 吞吐是 Nginx 的 4 倍》：https://gist.Github.com/johnlanni/aac7480c17b0fde05fa64a20fc93b165
而如果你使用的是 K8s Nginx Ingress，因?yàn)槠?Lua 代碼性能較差，即使在 HTTP1 場景下，Higress 性能也更好，具體數(shù)據(jù)可以參考：
《K8s 網(wǎng)關(guān)選型初判》：h ttps://xie.infoq.cn/article/0a2c9ac4ed139bc28f881d7c3
企業(yè)用戶落地
Higress 自從 4 月份發(fā)布 1.0.0 RC 版本以來，在社區(qū)有大量用戶進(jìn)行安裝和測試，幫助 Higress 變得更成熟，并且適應(yīng)了更多系統(tǒng)和安裝環(huán)境。同時有多家企業(yè)完成了 Higress 技術(shù)的落地。
開源軟件的發(fā)展離不開社區(qū)用戶的實(shí)踐，用戶的參與和貢獻(xiàn)是推動開源項(xiàng)目成功的關(guān)鍵因素。在這里，我們歡迎更多的社區(qū)用戶加入 Higress 實(shí)踐落地的行列！歡迎到 Higress GitHub issue（ https://github.com/alibaba/higress/issues/1）登記信息，社區(qū)將邀請您加入 Higress 落地支持群，我們會為落地用戶提供指導(dǎo)和幫助。
5社區(qū)：回顧和展望
Higress 一路走來，保持一個月發(fā)布一個版本的頻率，一共完成了 183 個 PR 的合并，發(fā)布了 13 個 Release，完成了 5 個里程碑：
Higress 在 1.0 版本 GA 后，將繼續(xù)保持高投入，并快速迭代。社區(qū)未來三個大版本的核心功能規(guī)劃如下：
- 1.1 版本（6 月）
- 實(shí)現(xiàn) HTTP2RPC API
- 支持非 K8s 場景下使用
- 1.2 版本（7 月）
- 支持和 Skywalking 等更多可觀測生態(tài)集成
- 完整實(shí)現(xiàn) Gateway API
- 1.3 版本（8 月）
- 實(shí)現(xiàn) API 管理產(chǎn)品形態(tài)建設(shè)
- 推出獨(dú)立的 Wasm 插件集市項(xiàng)目
其中 Wasm 插件生態(tài)會作為 Higress 社區(qū)長期重點(diǎn)投入方向，目前在中科院開源之夏 /CCF 編程之夏 / 云原生編程挑戰(zhàn)賽等活動中均有 Higress Wasm 插件相關(guān)的項(xiàng)目推出，完成項(xiàng)目既能收獲項(xiàng)目獎金，還能收獲開源榮譽(yù)，歡迎有興趣的同學(xué)參與。
