作者：褚杏娟
前言：
雲幾乎給每項基礎設施都帶來了衝擊，網關也不例外。近期，雲原生網關概念也越來越被大家熱議。那麼，究竟雲原生網關需要具備哪些特點？主流網關產品如何適應雲原生？網關標準統一是否必要？雲原生網關未來如何發展？
此前，Higress 發起人、阿里雲微服務引擎負責人李豔林（彥林）受邀與企業用戶代表一起聊聊網關的演進歷程。
本文根據李豔林（彥林）回答摘取整理而成。
如何應對業務需求？
首先，請針對 UU 跑腿的一個場景來提出自己的解決方案。
UU 跑腿已經是雲原生架構了，但作爲一家配送平臺，UU 跑腿有大量的客戶需要通過網關接入平臺，同時也有大量的後端服務需要接入網關，因此確保網關的穩定性和可靠性是非常重要的，這樣才能保障業務的持續性和客戶的滿意度。在這樣的需求背景下，Higress 會用怎樣的方式來幫助企業達成目標呢？
李豔林（彥林）： 我瞭解到 UU 跑腿業務是線上線下結合的。因此，相比於一般的純線上業務，對於穩定性的要求會更高一些，這是可以理解的。隨着整個業務逐漸上雲，行業對可靠性的要求會越來越高，特別是網關作爲整個公司的入口，如果出現問題就會帶來非常大的損失。我們在做 Higress 的過程中也是更加關注穩定性。我想分享一些想法。
首先，我們的架構和內核使用了 Envoy 和 Istio，它們的好處是將數據面和控制面解 耦 。 這意味着，如果控制面出現問題，數據面不會受到影響。這種分離有效地避免了控制面的安全和穩定性問題對數據面的影響。在內核上，我們使用了一種稱爲 WASM 的沙箱擴展機制。如果擴展邏輯代碼出現問題，WASM 沙箱會做很好的隔離，不會影響整個網關的主業務。這種設計可以在一定程度上控制整個系統的爆炸半徑。
其次，關於 UU 跑腿和阿里巴巴的 IoT 設備，因爲在線上線下結合的過程中，這些設備對穩定性有更高的要求，特別是在多端情況下。如果在一般情況下去更新規則、路由或證書插件，連接可能會發生抖動。但由於 Higress 採用了 Envoy 內核，所有規則變更都是熱更新的，因此對長連接都是非常友好的，不會抖動。這將顯著提高在線業務的連續性和穩定性。
最後，簡單介紹一下 Higress。雖然我們在 2022 年 7 月的雲棲大會上開源了它，但在阿里雲內部，我們已經孵化雲原生網關大概三到四年了。最初，它是爲了解決阿里電商和螞蟻之間的互通問題，讓 RPC 可以直接調用並使用 gRPC 協議。經過幾年的驗證，包括在雙十一等大促場景和成千上萬家企業的驗證，它現在非常穩定。在這些基礎上，Higress 主要關注一些推空保護和其他細節方面的功能。
企業需要怎樣的網關？
除了剛纔提到的，現在企業對網關產品還有哪些要求？現在網關產品已經解決了哪些問題？還有哪些需求未被滿足？
李豔林（彥林）： 這個話題很有意思，它實際上關乎人們對整個網關未來的定位和趨勢判斷。從阿里雲的角度來看，我們認爲客戶最關注的是網關的安全問題。事實上，阿里巴巴最初開發網關也是爲了解決安全問題，因爲我們希望能夠通過一個統一的入口來解決安全問題。
以前我在外部也遇到很多客戶的應用因爲一些問題而被攻擊，導致整個風險極大。因此，網關的第一個重要作用就是建立統一的安全防線。Higress 在這方面提供了一些 WAF 插件、認證插件，以及黑白名單機制，可以爲企業數字化升級過程中保駕護航。
我認爲，無論是國內還是海外，安全都是網關的首要問題。雖然國內許多人關注高可用性，但海外很多人更加註重安全性，它們都在某些公有云上運行，並且非常注重應用安全和基礎設施安全。
其次，我想談談高可用和穩定性。其實，大家最關心的問題可能是我們的網關穩定性如何、能否幫助我們解決高可用問題。在這方面，Higress 做了一個深度集成，使用阿里雲的 Sentinel，在入口提供整體的降級防護能力，以防止業務雪崩。
今年我們搞了很多次大促、海外業務等爆發性增長，當流量達到峯值時，建立防護線以防止異常流量打垮整個系統非常重要。特別是對於像 UU 跑腿這樣有高峯值場景的業務，保障業務的整體意義更加重大。
過去兩年，我在做海外網關競品分析時發現，最早的架構可能是 SLB+ECS（單體應用架構），包括雲服務都是這樣的架構。隨着微服務的興起，人們開始使用 API 網關等工具來管理微服務，並將其集成到服務網格體系中。在 Serverless 時代，每個領域都有獨立的入口，並且運營數據是獨立統計的。這種架構演進也帶來了問題。例如，我們今年做了一個標杆客戶，需要掛三層網關，相當於在單體到微服務、再到 Kubernetes 的過程中添加了網關層，導致整個訪問鏈路多層網關，最終影響 RT 和運維效率。
我看到 UU 跑腿之前也在處理協議的轉換，將 HTTP 轉換爲 Dubbo，需要加一個網關，這樣代價太大了。因此，Higress 定位是支持多種後端服務負載模式的統一，包括單體微服務、Kubernetes 和整個服務器的負載均衡。我們將後端的能力暴露到北向，進行服務發現，並將整個微服務網關、流量網關和安全網關三合一，以便高效地解決業務問題。這樣，用戶的業務和運維成本，以及資源成本都會大幅降低。我們發現客戶非常認可這種做法。
在網關的標準方面，我最近在研究時發現，有三個標準，分別是協議標準（HTTP 加 RESTFUL），文檔標準（Swagger），以及路由標準（Kubernetes Ingress / Gateway API）。Kubernetes 推出了路由標準，並通過 Higress 逐漸將路由標準統一起來，這是非常好的事情。
此外，開源社區正在推動 Gateway API 的完善，這將進一步統一路由標準。我們希望通過開源標準的建立來推進整個產業的發展。類似於 Linux 標準、MySQL 標準等，網關標準的建立對於未來雲計算的發展是至關重要的。未來，我們相信這些需求，包括 API 管理的更多能力，能夠更好地跨越雲、混合雲和多雲。 這是我思考的一些問題，希望對大家有幫助。
你眼中的雲原生網關
對於未來 1 年在雲原生網關的規劃是什麼樣的？
李豔林（彥林）： 我們一直參與阿里容器化的架構演進。這個過程中，我們發現雲原生網關應該具備四個特點：標準化、高集成、熱更新和易擴展。爲什麼呢？
首先，我們期望代碼可以跨雲、混合雲、私有云和公有云運行，而不受廠商的限制。比如，採用某個廠商的實現時，如果需要切換到另一個廠商，不會因爲廠商差異而出現問題。因此，標準化非常重要，它解除了廠商的綁定。Ingress 標準、Gateway API 標準和容器標準等構成了雲原生的基礎。
在此基礎之上，我們強調雲原生網關應該具備高集成特點。作爲一家以公有云爲主的廠商，我們的思路與專有云爲主的廠商有所不同。我們提到高集成，是因爲我們發現在傳統架構中，通常有三層：前端安全網關 WAF、中間流量網關 Nginx 、後端微服務網關 Spring Cloud Gateway。例如，我曾遇到一位客戶在面對超時問題時需要拉三撥人去查，判斷到底是 WAF 超時，還是 Nginx 或 SpringCloud Gateway 超時，這樣的部署資源成本很高，而且排查鏈路效率非常低。
我們認爲“合久必分，久必合”。爲什麼有這個想法？因爲我們是從第一性原理出發，阿里內部並沒有那麼多網關，爲什麼今天會有三個？其實是爲了簡化架構，更好地拆分模塊和職能，但實際上這不符合用戶的利益。用戶的實際利益在於成本，包括運維成本和部署成本。因此，我們認爲大部分客戶可能都需要高集成，包括像阿里、快手、抖音和騰訊等頭部廠商。這些大廠也需要拆分，拆分邏輯包括四層和七層，上層使用 SRB，下層可能使用原生網關，上層承擔流量，下層負責路由轉發。但對於大部分中小客戶，一層就足夠了。例如，我們的客戶已經有數百萬連接和幾百萬 TPS 的數據，但只需要一層就足以應對。這顯然降低了整個運維和部署成本。
第三個是熱更新。 實際上，我們認爲 Kubernetes 帶來的一個核心變化是業務頻繁調度。如果調度頻繁，後端發佈和規則變更需要快速聯動，尤其是在存在長連接和 IOT 設備的情況下，連接的抖動是不可接受的。因此，熱更新在確保連接穩定性方面非常必要。隨着基礎設施和使用場景的不斷變化，包括線上線下結合、IoT 設備等，熱更新的重要性會越來越突出。
第四個，易擴展性也是重要的一點。我們發現許多客戶在網關上都進行了定製，主要包括安全和路由方面的定製，甚至包括存儲方面的定製，這是因爲不同公司在安全定製方面的策略不同。因此，易擴展性非常重要。我們採用了多語言熱更新等機制，使得我們的網關可以更好地支持定製需求。
因此，我們認爲在未來，這四個能力：易用性、高集成、熱更新和易擴展性，將是雲原生網關必備的。
在今天的雲原生網關定位和發展過程中，我們圍繞着四個關鍵點展開，以差異化能力爲目標。大家都知道，像 APISIX 和 NGINX 這樣的巨頭擁有非常強的護城河，所以我們需要構建差異化能力，圍繞着這四個關鍵點進行。目前，我們已經完成了整個雲原生網關的佈局，接下來會在易用性和 Gateway API 的標準化上繼續探索。
我發現雲原生網關與 API 網關的區別在於雲原生網關多了一個 API 的層次。這是非常重要的，因爲有了 API，我們可以利用其自動化測試、調用和安全審計的能力，這對於未來結合人工智能非常重要。我們意識到，如果只做底層的原生網關和基本的路由能力，就無法獲取服務和 API 的元數據，這將限制我們在增加更多功能時的擴展能力。因此，我們最近在內部探索一種可能的演進方向。
我們已經完成了阿里巴巴的 Nacos 和 Dubbo 生態的整合，包括在灰度發佈方面集成了 Kubernetes OpenKruise，這爲我們打造更多的生態擴展奠定了基礎。儘管我們目前的插件相對於 NGINX 或 APISIX 來說較少，但我們採用的是整個服務網格的架構，可以複用一套擴展機制來快速構建統一控制東西南北流量的能力。
我們正在不斷積累這些能力。我們相信通過插件市場，可以一起擴展整個上下游，包括 API 管理和安全等能力，這樣就能爲客戶提供一站式的網關解決方案，而不需要過多地研究其他技術。
雲原生網關演化思路
產品提供方都是如何進行自己的產品演化的？社區推動與企業推動，哪個更重要？
李豔林（彥林）： 這個話題很有趣。我之前看到一篇文章，講的是《開源與商業的關係》。我認爲，今天的開源與商業關係正處在一個非常重要的階段，就像中國的軟件市場一樣。例如，你的手機裏有多少款軟件是付費的呢？這反映了中國人民對軟件付費的態度。如果沒有人爲軟件付費，軟件的持續發展就會受到威脅。因此，開源與商業之間的關係非常重要，就像如今社區與企業之間的關係一樣。
有點像之前的 360 互聯網模式，其中大部分人免費使用，只有 1% 的人付費。這種模式可以使開源與商業相互促進，從而實現持續的發展。如果沒有這個正循環，一些項目就很難維持下去，例如早期的 Dubbo 以及現在的 Spring Cloud Netflix，每公司都有自己的 KPI，如果項目沒有持續發展，就會面臨失敗的風險。今天我們能夠在這裏交流，說明我們背後有一個力量在支持着我們。但是如果沒有這個力量，這些事情就會變得更加困難。
我們需要不斷地加強社區投入，促進生態建設。 我們都知道，在數字化時代、雲時代，開源就是標準。我們通過開源軟件構建了整個開源標準，然後藉助衆人的力量推動它的使用場景和通用性，然後達到最佳狀態，這樣我們才能把整個領域做大、擴大這個蓄水池。這其實是一種互聯網經營模式，當這個蓄水池足夠大之後，我們才能繼續生存下去。只有這樣，我們才能更好地回饋社區。
不過，如今開源的訴求與商業的要求還是有所區別：開源更關注易用性、生態；商業版本則更關心產品的穩定性、安全性、高可用性和兜底服務能力。
阿里巴巴是開源、商業和內部三位一體。 我們通過開源軟件打磨產品的易用性和生態、和擴展性，而商業上更關注企業級特性，如穩定性和安全性，我們在阿里內部的場景打磨高可用性和高性能。這幾個方面是相輔相成的，大家都明白開源到商業、社區到企業的閉環非常重要，這也是我們能夠生存下去的關鍵。
雲原生網關可以在企業數字化升級中發揮什麼樣的作用？
李豔林（彥林）： 大家對數字化的理解大概是這樣的：首先有一個網站，其次有一個大盤。不知道大家是否看過在朋友圈中轉發的“靈隱寺的大盤”，一般來說，傳統公司對數字化的需求可能就是有一個網站和一個大盤；對於已經進行了數字化升級的公司來說，它們需要從傳統架構過渡到雲原生架構。
第一類用戶需要快速構建企業級、高可用、安全的入口，我們可以幫助他們實現這個目標。第二類客戶，也是我們目前關注的重點客戶，因爲他們通常是傳統架構，希望升級到微服務和雲原生架構。最簡單的方法是在前面加一個網關。有了網關，傳統的應用可以繼續使用傳統的負載方式，而微服務可以使用微服務負載方式，這樣就能快速進入雲原生時代。
那麼，如何實現新老系統之間的互聯互通呢？雲原生網關充當了統一的控制中心，可以控制流量和管理新舊系統之間的互動。 舉個例子，可以實現上雲和下雲之間的互通，不同業務域之間的跨域互通，通過網關來快速解決新老系統之間的連接和升級。這樣一來，新的 IDC 和老的 IDC 之間可以快速連接和升級，從而加快整個數字化升級和創新的速度。
因爲大家都知道，當一個 IT 系統變得越來越複雜時，採用微服務架構可以釋放出更大的研發效率紅利，尤其在海外更爲明顯。這也是爲什麼海外要推崇 Serverless 架構，從微服務走向 Serverless，因爲人力成本是最高的，所以要儘可能降低運維和開發成本。所以，對我們來說，這意味着我們可以加快企業的創新速度。
另外一個我最近研究的課題是關於上雲和數字化過程的。實際上，它可以分爲兩個部分：業務數字化和業務智能化。在第一個階段，我們的雲原生網關可以幫助用戶快速將單體應用、微服務應用以及整個 Kubernetes 等多種負載快速地將後端服務能力輸送到客戶端，這是我們的第一個價值所在。
第二個價值在於如何快速將後端的數據能力和 AI 能力輸送到客戶端。這個問題也非常重要，包括之前提到的 GraphQL 等。在研究中，我發現通過低代碼和快速的方式將後端的數據能力快速輸出到客戶端非常有意義。從業務智能化的升級過程來看，我們的網關可以快速將後端的 AI 能力輸送到手機端，這樣就可以幫助企業快速將後端能力輸出到客戶端和生態系統。
提到 API 領域，通過服務的貨幣化將調用、生態全部整合起來，也具有很大的意義。在海外，這種做法已經得到了很好的發展，而我相信國內未來也會成爲趨勢。爲什麼這樣判斷？因爲國外的人力成本較高，所以他們更傾向於使用別人的服務而不是自己開發，而國內則相對較少。但隨着中國數字化水平的提升，程序員的工資持續上漲，API 化仍然是未來的趨勢，這是第二個可能性，即我們能夠幫助企業快速將後端能力輸出到客戶端。
第三個價值在於網關本身。雲原生網關在入口處建立安全和高可用的防線非常重要，因爲近年來行業內出現了數據泄漏和穩定性問題，網關作爲一個關鍵位置具有致命的意義。
網關會被取代嗎？
當前的網關行業處於什麼階段？爲什麼？對於想要進入這個市場的開發者來說還有哪些機會？
李豔林(彥林)： 我的判斷是這樣的，現在正是傳統網關向雲原生網關迅速發展的爆發期。首先，我們可以看到容器已經成爲基礎設施的主要架構，而 Kubernetes 通過網關構建了一個標準，這實際上是行業發展的基礎。第二點是，從 CNCF 報告和整個行業動態來看，雲原生網關和 API 網關在過去三年裏增長了一倍以上，每年都在持續增加，增長速度非常快。我最近做分享時仔細數了一下，在 CNCF 裏大約有二三十個項目涉及這個領域。在這個領域有這麼多的參與者，說明這是一個機會，吸引了許多人涉足。
在這個領域中，我進行了一些分析。大約有 40%的項目是基於 NGINX 內核構建的，而 35% 的項目是基於 Envoy 內核構建的。可以說，Envoy 與 NGINX 佔據了 75% 的網關實現市場份額，這確實是兩個主要的主流力量。
統一標準，重要嗎？
當前，網關行業的發展面臨着哪些問題？如何保證網關生態的長期健康發展？
李豔林（彥林）： 從整個行業的角度來看，現在的標準正在逐漸建立，但還沒有完全穩定下來。目前實踐方面相對來說已經比較集中，大約佔了 75% 的份額，但還有 35% 是比較分散的長尾部分。我們希望行業標準能夠統一，讓大家都能達成共識。
比如，MySQL、PostgreSQL、Oracle 等數據庫在市場上佔有較大份額，加上其他一些常見的網關產品，可能佔據了 90% 左右的市場份額，這種收斂的趨勢對整個產業會有積極的影響。我們需要共同推動這些標準的發展，加快標準的形成。
未來，我認爲網關在安全和 Serverless 領域都有巨大的挑戰和機遇。 首先，對於開發者而言，他們在軟件開發過程中首先關注的是研發效率，其次是擴展性，然後是穩定性，最後纔是安全性。但實際上，隨着數字資產的增大，我們會發現各種攻擊和防禦正在不斷增加。這些安全威脅的加大將帶來巨大的變數和機遇。例如，能否利用人工智能自動進行攻擊和防禦，這都是攻防之間的問題。誰能夠利用人工智能和算力快速構建防護壁壘？包括阿里雲自身在內也在進行相關探索。
其次，將網關發展到極致，實現服務化也是一個有趣的方向。 當前的四層網關和雲廠商的第二層網關基本上都是基於特定內核構建的。而對於我們的七層網關來說，原生網關應該具備流量付費和彈性調整能力，以適應資源需求的變化。將網關無服務化將會是一個有意義的發展方向。我們一直在對網絡進行抽象，從四層到七層再到網關實質上是網絡一層層向上抽象，對開發者越來越易用。未來，能否實現網關的無服務化和極致彈性是一個重要的挑戰。
目前看來，網關行業處於一個非常有前景的階段，市場需求強勁，各家企業都在爭相進入，並通過共同努力來推動行業的發展。
雲原生網關的未來
最後，請總結下未來雲原生網關的發展趨勢？
李豔林（彥林）： 這塊我可以給大家一些建議。首先，未來雲原生網關的發展趨勢應該朝着標準化、高集成、易擴展和熱更新的方向不斷加強。 我們推測，Ingress 和 Gateway API 可能會成爲 API 路由的標準，這個標準可能不會受個人主觀意願的影響。
第二個趨勢是，對於一些小中型客戶來說，Higress 對於一些簡單的 4 層路由和 7 層簡單路由可能足夠了，但對於一些中大型客戶來說，他們可能對於複雜的 API 管理和路由有更多需求，未來可能會朝這個方向發展。我注意到在羣裏也有人提問，當 API 變得複雜並且規模擴大時，如何進行 API 管理和治理，我們可以在以後討論這個問題。
第三個趨勢是統一東西南北流量。我們採用 Envoy 內核，可以看到東西南北流量的統一加速趨勢。無論是從北向進來的流量，還是跨安全域、跨業務域、跨區域的東西向流量，包括 sidecar 之間的流量，因爲採用 Envoy 內核，我們在統一東西南北流量方面具有一些優勢。當然，我也看到一些嘗試將 NGINX 用作 sidecar 內核的設計，包括 APISIX 也在進行這方面的嘗試。我認爲大家的思路都很好，核心本質是大家都認爲統一東西南北流量控制是一個重要的方向。
第四個趨勢可能是關於 AI 領域的探索，AI 的入口到底是誰？包括在阿里內部以及與其他合作伙伴進行的一些嘗試。未來的 AI 能力和大模型能力都是基於容器作爲基礎設施進行輸出的，對於連接的穩定性、高可用性以及流量防護也有較高的要求。所以，我相信在未來的 AI 探索領域中，探索 AI 的入口將是值得的。
最後，根據 CNCF 的數據，我認爲以 NGINX、Envoy 爲內核可能是未來原生網關的關鍵實現。我也相信 Higress 在未來一年會有爆發性增長，加速推動原生網關的認知建立，這只是我大致的判斷。