微服務為什麼要用到 API 閘道器？

本文介紹了 API 閘道器日誌的價值，並以知名閘道器 Apache APISIX 為例，展示如何整合 API 閘道器日誌。

作者程小蘭，API7.ai 技術工程師，Apache APISIX Contributor。

原文連結

什麼是微服務

微服務架構（通常簡稱為微服務）是指開發應用所用的一種架構形式。通過微服務，可將大型應用分解成多個獨立的元件，其中每個元件都有各自的責任領域。在處理一個使用者請求時，基於微服務的應用可能會呼叫許多內部微服務來共同生成其響應。微服務是網際網路業務發展的結果，網際網路業務的飛速發展導致系統的架構也在不斷地發生變化，總體來說，系統的架構大致經歷了：單體應用架構—> SOA 架構—>微服務架構的演變，具體發展歷程和各自的優缺點如下表所示。

架構型別	簡介	優點	缺點
單體應用架構	將所有的功能程式碼打包成一個服務。	1. 架構簡單，專案開發和維護成本低。	所有模組耦合在一起，比較有利於小型專案的開發和維護；但是，對於大型專案來說卻存在問題，比如：<br/> 1. 專案各模組之間過於耦合，一個模組的效能問題可能導致整個專案的不可用；<br/> 2. 專案的擴充套件性差。
SOA 架構	中文意思為 “面向服務的架構”，通常包含多個服務，<br/>一個服務通常以獨立的形式存在於作業系統程序中，服務之間通過相互依賴或者通過通訊機制來完成通訊的，<br/>最終提供一系列的功能。	1. 系統整合：站在系統的角度，解決企業系統間的通訊問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構；<br/> 2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再<br/> 3. 業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務。	1. 服務的中心化，各服務之間存在依賴關係，如果某個服務出現故障可能會造成服務的雪崩；<br/> 2. 服務之間的依賴與呼叫關係複雜，測試部署的困難比較大。
微服務架構	微服務是在 SOA 上做的昇華。微服務架構重點強調的一個是"業務需要徹底的元件化和服務化"，<br/>原有的單個業務系統會拆分為多個可以獨立開發、設計、<br/>執行的小應用。各個小應用之間，相互去協作通訊，來完成一個互動和整合，這就是微服務架構。	1. 去中心化；<br/> 2. 通過服務實現元件化；<br/> 3. 按業務能力來劃分服務和開發團隊；<br/> 4. 基礎設施自動化（ Devops、自動化部署）。	1. 開發的成本比較高；<br/> 2. 會引發服務的容錯性問題；<br/> 3. 會引發資料的一致性問題；<br/> 4. 會涉及分散式事務。

因此，微服務是網際網路發展的必然結果，很多傳統公司的系統架構也在逐步微服務化。但是，隨著網際網路業務的發展，API 的數量也在劇增，使用閘道器對API統一管理也將面臨挑戰，選擇一個更強大的 API 閘道器，可以有效地增強系統的監控、容災、鑑權和限流等能力。

什麼是 API 閘道器

API 閘道器為客戶與服務系統之間的互動提供了統一的介面，也是管理請求和響應的中心點，選擇一個適合的 API 閘道器，可以有效地簡化開發並提高系統的運維與管理效率。 API 閘道器在微服務架構中是系統設計的一個解決方案，用來整合各個不同模組的微服務，統一協調服務。API 閘道器作為一個系統訪問的切面，對外提供統一的入口供客戶端訪問，隱藏系統架構實現的細節，讓微服務使用更為友好；並集成了一些通用特性（如鑑權、限流、熔斷），避免每個微服務單獨開發，提升效率，使系統更加標準化，比如身份驗證、監控、負載均衡、限流、降級與應用檢測等功能。

為什麼微服務需要 API 閘道器

如上圖所示，API 閘道器作為客戶端和微服務的中間層，它可以將微服務以統一的地址對外提供服務，將外部訪問這個地址的流量，根據適當的規則路由到內部叢集中正確的服務節點之上，如果沒有 API 閘道器，流量的出入口則不統一，客戶端就需要知道所有服務的訪問資訊，微服務的意義將不復存在，所以，微服務閘道器在微服務系統架構中的存在是必要的。此外，API 閘道器在系統的可觀測性、身份鑑權認證、穩定性和服務發現等方面也會發揮重要作用。

微服務遇到的挑戰

微服務閘道器應該首先要具備 API 路由能力，微服務數量變多，API 數量急劇增加，閘道器還可以根據具體的場景作為流量過濾器來使用，以提供某些額外可選功能，因此對微服務 API Gateway 提出了更高要求，比如：

• 可觀測性：在以往的單體應用中，排查問題往往通過檢視日誌定位錯誤資訊和異常堆疊；但是在微服務架構中服務繁多，出現問題時的問題定位變得非常困難；因此，如何監控微服務的執行狀況、當出現異常時能快速給出報警，這給開發人員帶來很大挑戰。
• 鑑權認證：而微服務架構下，一個應用會被拆分成若干個微應用，每個微應用都需要對訪問進行鑑權，每個微應用都需要明確當前訪問使用者以及其許可權。尤其當訪問來源不只是瀏覽器，還包括其它服務的呼叫時，單體應用架構下的鑑權方式就不是特別合適了。在微服務架構下，要考慮外部應用接入的場景、使用者 - 服務的鑑權、服務 - 服務的鑑權等多種鑑權場景。
• 系統穩定性：若大量請求超過微服務的處理能力時，可能會將服務打垮，甚至產生雪崩效應、影響系統的整體穩定性。
• 服務發現：微服務的分散管理，讓微服務的負載均衡的實現也更具有挑戰性。

解決方案

API 閘道器作為客戶端和服務端的中間橋樑，為微服務系統提供統一的管理機制：除了基礎的請求分發、API 管理和條件路由等功能，還包括身份驗證、監控報警、呼叫鏈追蹤、負載均衡、限流隔離和熔斷降級。 身份認證：下圖表示的是微服務聯合 API 閘道器如何進行身份認證的，由圖可見所有請求都通過閘道器，從而有效地隱藏了微服務。

監控報警/呼叫鏈追蹤：API 作為客戶端和服務端的中間橋樑，是微服務監控的最好載體，API 閘道器監控功能的主要職責是及時發現閘道器以及後端伺服器的連線異常，在 API 的監控平臺上面使用者可以隨時檢視日誌資訊，監控資訊，呼叫鏈等等，並且主機發生的任何異常都會自動報警到控制檯。有些閘道器甚至可以做到給客戶端和服務端雙向報警。

限流隔離/熔斷降級：隨著網際網路業務規模的增加，系統的併發度增高，多個服務之間相互呼叫鏈路，一條核心鏈路往往可能呼叫十個服務。如果在鏈路中，某個服務的 rt（響應時間）急劇上升，上游服務不斷請求，造成惡性迴圈，上游等待結果執行緒數越多，使得更上游服務阻塞最終整條鏈路無法使用，從而導致服務雪崩，所以對入口流量進行整治管理是很有必要的，下圖表示微服務系統是如何結合 API 閘道器進行限流隔離和熔斷降級的。

主流閘道器選擇

在微服務領域，有許多開源閘道器實現，有 NGINX、Kong、Apache APISIX 和 Envoy 等，Java 技術棧的有 Netfilx Zuul、Spring Cloud Gateway、Soul 等。或許你會問“有了 NGINX 和 Kong，為什麼還需要 Apache APISIX ？” ，下面做個簡單對比。

閘道器	痛點	優勢
NGINX	1. 修改配置需要 Reload 才能生效，跟不上雲原生的發展。	1. 老牌應用；<br/> 2. 穩定可靠，久經考驗；<br/> 3. 高效能。
Apache APISIX	1. 文件不夠豐富和清晰，需要待改進。	1. Apache 基金會頂級專案；<br/> 2. 技術架構更貼合雲原生； 3. 效能表現優秀；<br/> 4. 生態豐富； 5. 除了支援 Lua 開發外掛外，還支援 Java、Go、Python、Node 等語言外掛。
Kong	1. 預設使用 PostgreSQL 或 Cassandra 資料庫，使得整個架構非常臃腫，並且會帶來高可用的問題；<br/> 2. 路由使用的是遍歷查詢，當閘道器內有超過上千個路由時，它的效能就會出現比較急劇的下降；<br/> 3. 一些重要功能是需要付費的。	1. 開源 API 閘道器的鼻祖，使用者數眾多；<br/> 2. 效能滿足大部分使用者的需求；<br/> 3. 生態豐富；<br/> 4. 支援 Lua 和 Go 開發外掛。
Envoy	1. 使用 C++，二次開發難度大；<br/> 2. 除了 C++ 開發 filter 外，還支援 WASM 和 Lua。	1. CNCF 畢業專案 更適合服務網格場景多語言架構部署。
Spring Cloud Gateway	1. 雖然 Spring 社群成熟，但是 Gateway 資源缺乏。	1. 內建了非常多的開箱即用功能，並且都可以通過 SpringBoot 配置或者手工編碼鏈式呼叫來使用； <br/> 2. Spring 系列可擴充套件性強，易配置，可維護性好； <br/> 3. Spring 社群成熟； <br/> 4. 簡單易用；<br/> 5. 對於 Java 技術棧來說方便。

總結

隨著網際網路的發展，網際網路企業的業務也在不斷的飛速發展，進而導致系統的架構也在不斷的發生著變化，微服務架構已經在眾多公司得到廣泛應用。隨著微服務的資料越來越多，API 的數量也越來越多，對於大流量的治理，選擇一個優秀的 API 閘道器是至關重要的。本文列舉了常見閘道器，並進行對比，列出各自的優缺點，如果你正在做 API 閘道器的技術選型，或者你的微服務系統出現了效能問題，再或者你想搭建一個高效穩定的微服務系統，希望本文可以帶給你一定的啟發。

關於 API7.ai 與 APISIX

API7.ai 是一家提供 API 處理和分析的開源基礎軟體公司，於 2019 年開源了新一代雲原生 API 閘道器 -- APISIX 並捐贈給 Apache 軟體基金會。此後，API7.ai 一直積極投入支援 Apache APISIX 的開發、維護和社群運營。與千萬貢獻者、使用者、支持者一起做出世界級的開源專案，是 API7.ai 努力的目標。