作者：褚杏娟
前言：
雲幾乎給每項基礎設施都帶來了衝擊，閘道器也不例外。近期，雲原生閘道器概念也越來越被大家熱議。那麼，究竟雲原生閘道器需要具備哪些特點？主流閘道器產品如何適應雲原生？閘道器標準統一是否必要？雲原生閘道器未來如何發展？
此前，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 在未來一年會有爆發性增長，加速推動原生閘道器的認知建立，這只是我大致的判斷。