作者：耿蕾蕾（如葑）
唯一不變的是變化，在現代複雜的商業環境中，企業的業務形態與規模往往處於不斷變化和擴大之中。這種動態發展對企業的資訊系統提出了更高的要求，特別是在軟體架構方面。為了應對不斷變化的市場需求和業務擴充套件，軟體架構必須進行相應的演進和最佳化。閘道器作為網際網路流量的入口，其形態也在跟隨軟體架構持續演進迭代中。我們下面就聊一聊閘道器的演進歷程以及在時下火熱的 AI 浪潮下，閘道器又會迸發怎樣新的形態。
閘道器演進形態概覽
軟體架構的演進是一個不斷適應技術發展和業務需求變化的過程，伴隨著軟體架構的演進閘道器的形態也在隨之持續迭代，在不同軟體架構階段中閘道器也呈現其不同的形態。
軟體架構的演進是技術發展和業務需求不斷推動的結果，從早期的簡單設計到如今複雜的多層次架構，體現了軟體系統在可擴充套件性、維護性和效能方面的不斷追求。
- 單體架構： 在軟體工程的初期，單體架構是最常見的形式。所有的功能模組都整合在一個整體應用中。這種架構的優點是初期開發和部署比較簡單，但隨著系統功能的擴充套件和複雜性增加，維護和升級變得越來越困難，單點故障的風險也越來越高。
- 垂直架構： 為了解決單體架構帶來的維護問題，逐漸發展出垂直架構。不同的業務功能被拆分成不同的模組，每個模組獨立開發和部署。雖然這種架構在一定程度上提升了效率，但模組之間的依賴關係依然緊密，擴充套件和協作問題仍然存在。
- SOA 架構（面向服務的架構）： SOA 架構透過服務松耦合來解決垂直架構中的依賴問題。系統被設計成一組相互協作的微服務，每個服務透過定義明確的介面進行通訊。這種方式提高了系統的靈活性和可擴充套件性，但管理和運維複雜度增加，需要採用成熟的服務治理框架。
- 微服務架構： 微服務架構是 SOA 架構的發展和細化，它將應用進一步拆分成更小的服務單元，每個單元可以獨立開發、部署和擴充套件。微服務架構強調容錯和自動化運維，適合大規模、高複雜度的系統。但其實施也需要更復雜的測試、監控和管理工具支援。
- 雲原生架構： 雲原生架構進一步解放了開發者，允許他們專注於程式碼邏輯，而不需要關心底層的基礎設施。透過統一的 K8s 運維底座，系統的擴充套件和縮減可以更加靈活地自動進行。雲原生架構帶來了更高的彈性和資源利用率，同時也要求開發者適應新的開發和運維模式。
- AI 原生架構： 隨著人工智慧和機器學習技術的發展，AI 原生架構應運而生。這種架構將大規模語言模型整合到應用系統中，提供自然語言處理、智慧推薦等功能。AI 原生架構不僅改變了傳統應用的互動方式，還帶來了更智慧的業務決策支援。但這種架構也對計算資源和資料隱私提出了更高的要求。
總體來看，軟體架構演進的每一步都在尋求解決當前架構的瓶頸和不足，透過技術創新和最佳實踐，使得軟體系統能夠更好地應對不斷變化的業務需求和技術環境。
閘道器演進之流量閘道器
流量閘道器作為網路架構中的關鍵元件，主要負責管理和最佳化資料流量，以提升業務的可伸縮性和高可用性。Nginx 作為流量閘道器的代表性軟體，以其高效的效能和靈活的配置廣受歡迎。流量閘道器的核心目的是解決多業務節點的流量負載均衡問題， 透過智慧排程將客戶請求分配到不同的伺服器上，從而均勻分攤負載，避免單點故障，確保服務的穩定性和連續性。
閘道器演進之 ESB
企業服務匯流排（ESB）閘道器是一個專為企業設計的關鍵整合解決方案，旨在標準化和簡化不同系統和服務之間的通訊與訊息傳送。作為核心通訊基礎設施，ESB 閘道器可以減少系統間的耦合性，提高互操作性和靈活性，確保資料和服務的無縫整合。遵循服務導向型架構（SOA）原則，ESB 透過集中管理訊息路由、轉換和安全，實現服務的快速部署和高效運作。它支援不同協議和資料格式，提升了系統的擴充套件性和可維護性，幫助企業在不斷變化的業務環境中保持競爭力與創新。
閘道器演進之微服務閘道器
微服務閘道器是微服務架構中的關鍵元件，負責集中管理微服務的路由規則，增強系統安全性，提供效能監控，並簡化訪問流程，從而提高整個系統的可靠性。微服務閘道器可以實現負載均衡、限流、熔斷、身份驗證等功能，透過統一入口管理和最佳化各微服務間的互動。此舉不僅簡化了客戶端與微服務的通訊複雜性，還為系統安全提供了額外的保護，Spring Cloud Gateway 是一個廣泛應用的微服務閘道器，它基於 Spring 生態系統，易於與 Spring Boot 專案整合，因其靈活、高效和可擴充套件性受到了開發者的青睞。
閘道器演進之雲原生閘道器
雲原生閘道器是伴隨 K8s 的廣泛應用而誕生的一種創新閘道器，K8s 叢集內外網路天然隔離的特性要求透過閘道器來將外部請求轉發給叢集內部服務，K8s 採用 Ingress/Gateway API 來統一閘道器的配置方式，同時 K8s 提供了彈性擴縮容來幫助使用者解決應用容量排程問題，基於此使用者對閘道器產生了新的訴求：期望閘道器既能有流量閘道器的特性來處理海量請求，又具備微服務閘道器的特性來做服務發現與服務治理，同時要求閘道器也具備彈性擴縮容能力解決容量排程問題，能夠讓開發者能夠專注於業務邏輯的實現，而無需擔心底層架構的容量、維護和管理。
閘道器演進的下一站：AI 閘道器
AI 閘道器是專為處理 AI 流量設計的關鍵元件，具備長連線、大頻寬、高延時的特性，能夠高效管理和最佳化資料傳輸。在 AI 應用、AI 平臺和大型語言模型（LLM）中，不同的場景對 AI 閘道器的效能和功能有著多樣化的需求。為更好地滿足這些需求，AI 閘道器提供了豐富的 AI 外掛集，開發者可以透過低程式碼方式輕鬆整合和構建複雜的 AI 應用。這不僅大幅降低了開發難度，還顯著提高了效率，使得 AI 技術在各類應用和平臺中更加易用和普及。AI 閘道器因此成為推動 AI 創新和應用落地的核心推動力。
API 閘道器去哪了？
讀到這裡的同學可能會有這麼一個問題：API 閘道器去哪了？我們耳熟能詳的 API 閘道器為什麼沒有提到呢？回答這個問題之前我們可以先問自己一個問題：API 是什麼？API 包含什麼？
在流量閘道器中我們配置的路由本身也是一種 API，只是沒有定義規範的請求/響應標準而已，通常我們稱為 HTTP API，在 AWS API Gateway 中的 HTTP API 指的就是這個，目前 HTTP API 使用最簡單、應用最廣；REST API 相信大家基本都或多或少聽說過，它採用 JSON 格式來規範請求/響應，在微服務閘道器中應用較廣；Websocket/gRPC/Dubbo API 這些相信大家同樣不會陌生，因此可以說支援 API 訪問的都是 API 閘道器，API 閘道器是貫穿軟體架構演進的各個階段。時間來到了當下，在 AI 浪潮下 API 閘道器又會迸發出怎樣新的特性呢？
Higress：AI 原生的 API 閘道器
Higress 源自阿里巴巴內部電商、交易等核心生產場景的實踐沉澱，遵循 Ingress/Gateway API 標準，將流量閘道器、微服務閘道器、安全閘道器三合一，並在此基礎上擴充套件了服務管理外掛、安全類外掛和自定義外掛，高度整合 K8s 和微服務生態，包括 Nacos 註冊和配置、Sentinel 限流降級等能力，並支援規則變更毫秒級生效等熱更新能力。
在 AI 浪潮下，Higress 面向 AI Native 場景提供原生擴充套件能力以滿足複雜的 AI 應用需求。它不僅支援常見的 API 管理、流量控制和安全策略，還具備與 AI 模型無縫整合的特性。Higress 透過靈活的外掛機制，允許開發者輕鬆新增自定義功能，提升擴充套件性和適應不同應用場景的能力。藉助高效能的處理能力和智慧流量排程，Higress 閘道器可以顯著減少延遲，提升 AI 服務的響應速度。此外，Higress 強大的監控和日誌功能，幫助開發者快速定位和解決問題，使 AI 應用的開發和運維變得更加高效和可靠。
本文整理自《統一多層閘道器架構影片課程》的第一期影片。
關注「阿里云云原生」公眾號，後臺回覆：1105即可下載課程 PPT。
點選此處，檢視直播回放。