【翻譯】對於API網關的一些質疑和思考

翻譯：Eolinker——國內流行的高效API網關
來源：Medium
這些年來，API網關正在經歷一些有關他們是否真的起到做用的質疑。
• 它們是否集中、共享了資源，從而促進了API對於外部調用的管理？
• 它們是否集羣入口（ingress）的控制器，從而能夠嚴格管理用戶進入或離開集羣嗎？
• 或者它們是否某種API的連接器，從而讓API在指定的客戶端上更方便使用？

# 背景
隨着技術發展突飛猛進，整個行業經過技術和架構模式的推陳出新進行快速洗牌，若是你說「全部這些都使我頭大」，也能夠理解。在本文中，我但願總結出「 API網關」的不一樣身份，闡明平常使用中，哪些羣體可使用API網關（或許一部人正碰到並在嘗試解決這個問題），並再次強調那些基本原則。

在深刻探討以前，讓咱們先明確API一詞的含義。
我對API的定義：
一個有着明肯定義而且最終目的清晰的接口，經過網絡調用，使軟件開發人員可以方便安全的對目標數據和功能進行程序訪問。
這些接口抽象了實現它們的技術架構細節。對於這些設計好了的網絡節點，咱們但願得到必定程度的使用指引、以及成熟的向下兼容性。
相反，若是僅僅是能夠經過網絡與另外一軟件進行交互，並不必定意味着那些遠程節點就是符合此定義的API。許多系統相互交互，可是這些交互比較隨意，而且由於系統之間耦合性和其餘一些因素的關係，每每在即時性方面會受到影響。
咱們建立API來爲業務的各個部分提供完善的抽象服務，以實現新的業務功能以及偶然發現一兩個創新之舉。
在談論API網關時，首先要提到的是API管理。

# API管理
許多人從API管理的角度考慮API網關。這是合理的。可是，讓咱們先快速看一下此類網關的功能。
經過API 管理，咱們嘗試去解決「如何控制給其餘人使用當前有的API」的問題，例如，如何跟蹤誰在使用這些API、對誰能使用這些API進行權限控制、創建一套完善的管理措施進行使用受權和認證，同時建立一個服務目錄，能夠在設計時使用，提高對API的理解併爲之後的有效治理奠基基礎。
咱們想解決「咱們有一些優秀的API，而且咱們但願別人來使用這些API，可是但願他們按照咱們的規則去使用」的問題。
API管理固然也起到一些很好的用處，例如，它容許用戶（潛在的API使用者）進行自助服務，簽署不一樣的API使用計劃（請考慮：在給定時間範圍內，在指訂價格點上，每一個端點每一個用戶的調用次數）。有能力完成這些管理功能的基礎架構就是網關（API流量所通過的）。在網關層，咱們能夠執行身份驗證，速率限制，指標收集，其它策略執行等一系列操做。

在這個層級，咱們考慮的是API（如上定義）是如何最好地管理和容許對其進行訪問。咱們沒有考慮其餘角度，例如服務器、主機、端口、容器甚至服務（這是另外一個很難定義清楚的詞！）。
API管理（以及它們相應的網關），一般會被嚴格把控，並做爲一種「平臺組件」、「一體化組件」和API的其餘基礎組件一塊兒生效。
須要注意的一件事：咱們要當心千萬別讓任何業務邏輯進入這一層。
如前一段所述，API管理是共享的基礎架構，可是因爲咱們的API流量通過了它，所以它傾向於從新建立「大包大攬的全能型」（認爲是企業服務總線）網關，這會致使咱們必須與之協調來更改咱們的服務。從理論上講，這聽起來不錯。實際上，這最終可能成爲組織的瓶頸。

# 集羣入口
爲了構建和實現API，咱們將重點放在代碼、數據、生產力框架等方面。可是，要想使這些事情中的任何一個產生價值，就必須對其進行測試，部署到生產中並進行監控。當咱們開始部署到雲平臺時，咱們開始考慮部署、容器、服務、主機、端口等，並構建可在此環境中運行的應用程序。咱們可能正在設計工做流（CI）和管道（CD），以利用雲平臺快速遷移、更改的特色，將其快速展現在客戶面前等等。
在這種環境中，咱們可能會構建和維護多個集羣來承載咱們的應用程序，而且須要某種方式直接來訪問這些集羣中的應用程序和服務。以Kubernetes爲例思考。咱們可能會經過一個Kubernetes 入口控制器來訪問Kubernetes集羣（集羣中的其它全部內容都沒法從外部訪問）。這樣，咱們就能夠經過定義明確的規則（例如域/虛擬主機、端口、協議等），嚴格控制哪些內容能夠進入（甚至離開）咱們的集羣。
在這個層級，咱們可能但願某種「入口網關」成爲容許請求和消息進入集羣的流量監控人。在這個層級，思考更多的是「個人集羣中有此服務，我須要集羣外的人可以調用它」。這多是服務（公開API）、現有的總體組件、gRPC服務，緩存、消息隊列、數據庫等。有些人選擇將其稱爲API網關，並且實際上可能會作比控制流量進/出而言更多的事情，但重點是這個層級的問題是屬於集羣操做級別的。

此層級的集羣入口控制器由平臺組件操做，可是，這部分基礎架構一般與更加分佈式、自助服務的工做流相關聯（正如您對雲平臺所指望的那樣）。

# API網關模式
關於「 API網關」一詞的另外一種擴展是我在聽到該術語時一般想到的，它是與API網關模式最類似的。簡而言之，API網關模式是針對不一樣類別的使用者來優化API的使用。這個優化涉及一個API間接訪問。您可能會聽到另外一個表明API網關模式的術語是「前端的後端」，其中「前端」能夠是字符終端（UI）、移動客戶端、IoT客戶端甚至其它服務/應用程序開發人員。
在API網關模式中，咱們明顯簡化了對一組API的調用，以模擬針對特定用戶、客戶端或使用者的「應用程序」內聚API。回想一下，當咱們使用微服務構建系統時，「應用程序」的概念就消失了。API網關模式有助於恢復此概念。這裏的關鍵是API網關，一旦實現，它將成爲客戶端和應用程序的API，並負責與任何後端API和其餘應用程序網絡節點（不知足上述API定義的節點）進行通訊交互。
與上一節中的入口控制器不一樣，此API網關更接近開發人員的視角，而較少關注哪些端口或服務會公開以供集羣外使用。此「 API網關」也不一樣於咱們管理現有API的API管理視角。此API網關將對後端的調用聚合在一塊兒，這可能會公開API，但也可能會涉及到一些API描述較少的東西，例如對舊系統的RPC調用，使用不符合「 REST」的協議的調用（如經過HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息隊列。這種類型的網關也可用來進行消息級轉換、複雜的路由、網絡彈性/回退以及響應的聚合。
若是您熟悉REST API的Richardson Maturity模型，就會發現相比Level 1–3，實現了API網關模式的API網關集成了更多的Level 0請求（及其之間的全部內容）。

這些類型的網關實現仍須要解決速率限制、身份驗證/受權、電路斷路、度量收集、流量路由等問題。這些類型的網關能夠在集羣邊緣用做集羣入口控制器，也能夠在集羣內部用做應用程序網關。

因爲這種類型的API網關與應用和服務的開發緊密相關，所以咱們但願開發人員可以參與幫助指定API網關公開的API，瞭解所涉及的任何聚合邏輯以及可以快速測試和更改此API基礎架構的能力。咱們還但願運維人員或工程師對API網關的安全性、彈性和可觀察性配置有一些想法。這種層級的基礎架構還必須適應不斷髮展的、按需的、自主服務開發人員的工做流。能夠經過查看GitOps模型獲取更多這方面信息。

# 進入服務網格(Service Mesh)
在雲基礎架構上運行服務架構的一部分難點是，如何在網絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中，咱們使用了應用程序庫和一些專業的開發人員治理來實現此目的。可是，在大規模和多種開發語言環境下，服務網格技術的出現提供了更好的解決方案。服務網格經過透明地實現爲平臺及其組成服務帶來如下功能：
• 服務到服務（即東西向流量）的彈性
• 安全性包括最終用戶身份驗證、相互TLS、服務到服務RBAC / ABAC
• 黑盒服務的可觀察性（專一於網絡通訊），例如請求/秒、請求延遲、請求失敗、熔斷事件、分佈式跟蹤等
• 服務到服務速率限制，配額執行等
精明的讀者會認識到，API網關和服務網格在功能上彷佛有所重疊。服務網格的目的是經過在L7透明地解決全部服務/應用程序的這些問題。換句話說，服務網格但願融合到服務中（實際上它的代碼並無嵌入到服務中）。另外一方面，API網關位於服務網格之上，和應用程序一塊兒（L8？）。服務網格爲服務、主機、端口、協議等（東西向流量）之間的請求流帶來了價值。它們還能夠提供基本的集羣入口功能，以將某些此功能引入南北向。可是，這不該與API網關能夠帶來北/南流量的功能相混淆。（一個在集羣的南北向和一個是在一組應用程序的南北向）
服務網格和API網關在某些方面在功能上重疊，可是在它們在不一樣層面互補，分別負責解決不一樣的問題。理想的解決方案是將每一個組件（API管理、API網關、服務網格）合適的安置到您的解決方案中，並根據須要在各組件間創建良好的邊界（或在不須要時排除它們）。一樣重要的是找到適合的辦法去分佈式的處理這些組件，給到相應的開發人員和運營工做流。即便這些不一樣組件的術語和標識存在混淆，咱們也應該依靠基本原理，並瞭解這些組件在咱們的體系結構中帶來的價值，從而來肯定它們如何獨立存在和互補並存。