工作幾年了,API 網關還不懂?

點擊關注公衆號,Java乾貨及時送達

譯者:蚊子squirrel
來源:www.jianshu.com/p/9fab0982c6bb

翻譯一篇API網關的文章,介紹了其三種角色:API管理、集羣ingress網關、API網關模式,最後還講了與service mesh的關係,通過此文可以更全面的理解API網關的作用。

原文:https://medium.com/solo-io/api-gateways-are-going-through-an-identity-crisis-d1d833a313d7
這些年來,API網關正在經歷一些身份危機。
房間裏的大象:英語習語,指的是一些雖然顯而易見,但卻由於可能造成尷尬、爭執、觸及敏感或禁忌等原因被人刻意忽視的事情。

一些背景

隨着技術發展日新月異,整個行業通過技術和架構模式進行快速洗牌,如果你說“所有這些都使我頭大”,也可以理解。
在本文中,我希望總結出“ API網關”的不同身份,闡明公司中的哪些羣體可以使用API網關(他們正在嘗試解決的問題),並重新關注這些首要原則。
理想情況下,在本文結束時,您將更好地瞭解API基礎架構在不同層級、對不同團隊的作用,同時明白如何從每個層級獲得最大價值。
在深入探討之前,讓我們先明確API一詞的含義。另外,關注公衆號Java技術棧,在後臺回覆:面試,可以獲取我整理的分佈式面試題和答案。

我對API的定義:

一個明確定義和目的型接口,通過網絡調用,使軟件開發人員能夠以受控且方便的方式,對組織內的數據和功能進行編程訪問。
這些接口抽象了實現它們的技術架構細節。對於這些設計的網絡端點,我們希望獲得一定程度的文檔、使用指南、穩定性和向後兼容性。
相反,僅僅因爲我們可以通過網絡與另一軟件進行通信,並不一定意味着遠程端點就是符合此定義的API。許多系統相互通信,但是通信發生更加隨意,並在與耦合和其他因素之間進行權衡。
我們創建API來爲業務的各個部分提供周全的抽象,以實現新的業務功能以及偶然的創新。
在談論API網關時,首先要提到的是API管理。

API管理

許多人從API管理的角度考慮API網關。這是公平的。但是,讓我們快速看一下此類網關的功能。
通過API Management,我們試圖解決“何時公開現有的API供他人使用”的問題,如何跟蹤誰使用這些API,實施關於允許誰使用它們的政策,建立安全流程來進行身份驗證和授權許可,同時創建一個服務目錄(該目錄可在設計時使用以促進API使用,併爲有效治理奠定基礎)。
我們想解決“我們擁有要與他人共享,但要按我們的條款共享這些現有的、經過精心設計的API ”的問題。
API管理也做得很好,它允許用戶(潛在的API使用者)進行自助服務,簽署不同的API使用計劃(請考慮:在給定時間範圍內,在指定價格點上,每個端點每個用戶的調用次數)。有能力完成這些管理功能的基礎架構就是網關(API流量所經過的)。在網關層,我們可以執行身份驗證,速率限制,指標收集,其它策略執行等操作。

API Management Gateway
基於API網關的API管理軟件示例:
  • Google Cloud Apigee

  • Red Hat 3Scale

  • Mulesoft

  • Kong

在這個級別上,我們考慮的是API(如上定義)是如何最好地管理和允許對其進行訪問。我們不是在考慮服務器,主機、端口、容器甚至服務(另一個定義不明確的詞)。
API管理(以及它們相應的網關)通常被作爲由“平臺團隊”、“集成團隊”或其它API基礎架構團隊所擁有的、嚴格控制的共享基礎架構。
需要注意的一件事:我們要小心,別讓任何業務邏輯進入這一層。如前一段所述,API管理是共享的基礎結構,但是由於我們的API流量經過了它,因此它傾向於重新創建“大包大攬的全能型”(認爲是企業服務總線)網關,這會導致我們必須與之協調來更改我們的服務。
從理論上講,這聽起來不錯。實際上,這最終可能成爲組織的瓶頸。有關更多信息,請參見這篇文章:
http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/

集羣入口

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

Cluster Ingress Gateway
這些類型的ingress實現的示例包括:
Envoy Proxy 及其基礎上的項目包括:
  • Datawire Ambassador

  • Solo.io Gloo

  • Heptio Contour

基於其他反向代理/負載均衡器構建的其它組件:
  • HAProxy

  • OpenShift’s Router (based on HAProxy)

  • NGINX

  • Traefik

  • Kong

此層級的集羣入口控制器由平臺團隊操作,但是,這部分基礎架構通常與更加去中心化的、自助服務工作流相關聯(正如您對雲原生平臺所期望的那樣)。
參見:https://www.weave.works/blog/gitops-operations-by-pull-request

API網關模式

關於“ API網關”一詞的另一種擴展是我在聽到該術語時通常想到的,它是與API網關模式最相似的。Chris Richardson在其“微服務模式”一書第8章很好地介紹了這種用法。
我強烈建議您將此書用於此模式和其他微服務模式學習資料。可在他的microservices.io網站API Gatway Pattern可以進行快速瀏覽。簡而言之,API網關模式是針對不同類別的消費者來優化API的使用。
這個優化涉及一個API間接訪問。您可能會聽到另一個代表API網關模式的術語是“前端的後端”,其中“前端”可以是字符終端(UI)、移動客戶端、IoT客戶端甚至其它服務/應用程序開發人員。
在API網關模式中,我們明顯簡化了一組API的調用,以模擬針對特定用戶、客戶端或使用者的“應用程序”內聚API。回想一下,當我們使用微服務構建系統時,“應用程序”的概念就消失了。API網關模式有助於恢復此概念。這裏的關鍵是API網關,一旦實現,它將成爲客戶端和應用程序的API,並負責與任何後端API和其他應用程序網絡端點(不滿足上述API定義的端點)進行通信。
與上一節中的Ingress控制器不同,此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請求(及其之間的所有內容)。

https://martinfowler.com/articles/richardsonMaturityModel.html
這些類型的網關實現仍需要解決速率限制、身份驗證/授權、斷路、度量收集、流量路由等問題。這些類型的網關可以在集羣邊緣用作集羣入口控制器,也可以在集羣內部用作應用程序網關。

API Gateway Pattern
此類API網關的示例包括:
  • Spring Cloud Gateway

  • Solo.io Gloo

  • Netflix Zuul

  • IBM-Strongloop Loopback/Microgateway

也可以使用更通用的編程或集成語言/框架(例如:
  • Apache Camel

  • Spring Integration

  • Ballerina.io

  • Eclipse Vert.x

  • NodeJS

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

進入服務網格(Service Mesh)

在雲基礎架構上運行服務架構的一部分難點是,如何在網絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中,我們使用了應用程序庫和希望的開發人員治理來實現此目的。
但是,在大規模和多種開發語言環境下,服務網格技術的出現提供了更好的解決方案。服務網格通過透明地實現爲平臺及其組成服務帶來以下功能:
  • 服務到服務(即東西向流量)的彈性

  • 安全性包括最終用戶身份驗證、相互TLS、服務到服務RBAC / ABAC

  • 黑盒服務的可觀察性(專注於網絡通信),例如請求/秒、請求延遲、請求失敗、熔斷事件、分佈式跟蹤等

  • 服務到服務速率限制,配額執行等

精明的讀者會認識到,API網關和服務網格在功能上似乎有所重疊。服務網格的目的是通過在L7透明地解決所有服務/應用程序的這些問題。換句話說,服務網格希望融合到服務中(實際上它的代碼並沒有嵌入到服務中)。
另一方面,API網關位於服務網格以及應用程序之上(L8?)。服務網格爲服務、主機、端口、協議等(東西向流量)之間的請求流帶來了價值。它們還可以提供基本的集羣入口功能,以將某些此功能引入南北向。但是,這不應與API網關可以帶來北/南流量的功能相混淆。(一個在集羣的南北向和一個是在一組應用程序的南北向)
Service Mesh和API網關在某些方面在功能上重疊,但是在它們在不同層面互補,分別負責解決不同的問題。理想的解決方案是將每個組件(API管理、API網關、服務網格)合適的安置到您的解決方案中,並根據需要在各組件間建立良好的邊界(或在不需要時排除它們)。
同樣重要的是找到適合去中心化開發人員和運營工作流程的這些工具實現。即使這些不同組件的術語和標識存在混淆,我們也應該依靠基本原理,並瞭解這些組件在我們的體系結構中帶來的價值,從而來確定它們如何獨立存在和互補並存。






關注Java技術棧看更多幹貨



獲取 Spring Boot 實戰筆記!

本文分享自微信公衆號 - Java技術棧(javastack)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章