• 一些背景
• 我對API的定義：
• API管理
• 集群入口
• API網(wǎng)關模式
• 進入服務網(wǎng)格(Service Mesh)

翻譯一篇API網(wǎng)關的文章，介紹了其三種角色：API管理、集群ingress網(wǎng)關、API網(wǎng)關模式，最后還講了與service mesh的關系，通過此文可以更全面的理解API網(wǎng)關的作用。

原文：API Gateways are going through an identity crisis

這些年來，API網(wǎng)關正在經(jīng)歷一些身份危機。

• 它們是否是集中的、共享的資源，從而促進了API對外部實體的暴露與治理？
• 它們是集群入口（ingress）哨兵，從而可以嚴格控制哪些用戶流量進入或離開集群嗎？
• 或者它們根據(jù)自己擁有的客戶端類型，使用某種API結合膠水來更簡潔地表達API？
• 當然，房間里的大象和我經(jīng)常聽到的一個問題：“服務網(wǎng)格會使API網(wǎng)關過時嗎？

房間里的大象：英語習語，指的是一些雖然顯而易見，但卻由于可能造成尷尬、爭執(zhí)、觸及敏感或禁忌等原因被人刻意忽視的事情。

一些背景

隨著技術發(fā)展日新月異，整個行業(yè)通過技術和架構模式進行快速洗牌，如果你說“所有這些都使我頭大”，也可以理解。在本文中，我希望總結出“ API網(wǎng)關”的不同身份，闡明公司中的哪些群體可以使用API網(wǎng)關（他們正在嘗試解決的問題），并重新關注這些首要原則。理想情況下，在本文結束時，您將更好地了解API基礎架構在不同層級、對不同團隊的作用，同時明白如何從每個層級獲得最大價值。

在深入探討之前，讓我們先明確API一詞的含義。

我對API的定義：

一個明確定義和目的型接口，通過網(wǎng)絡調(diào)用，使軟件開發(fā)人員能夠以受控且方便的方式，對組織內(nèi)的數(shù)據(jù)和功能進行編程訪問。

這些接口抽象了實現(xiàn)它們的技術架構細節(jié)。對于這些設計的網(wǎng)絡端點，我們希望獲得一定程度的文檔、使用指南、穩(wěn)定性和向后兼容性。

相反，僅僅因為我們可以通過網(wǎng)絡與另一軟件進行通信，并不一定意味著遠程端點就是符合此定義的API。許多系統(tǒng)相互通信，但是通信發(fā)生更加隨意，并在與耦合和其他因素之間進行權衡。

我們創(chuàng)建API來為業(yè)務的各個部分提供周全的抽象，以實現(xiàn)新的業(yè)務功能以及偶然的創(chuàng)新。

在談論API網(wǎng)關時，首先要提到的是API管理。

API管理

許多人從API管理的角度考慮API網(wǎng)關。這是公平的。但是，讓我們快速看一下此類網(wǎng)關的功能。

通過API Management，我們試圖解決“何時公開現(xiàn)有的API供他人使用”的問題，如何跟蹤誰使用這些API，實施關于允許誰使用它們的政策，建立安全流程來進行身份驗證和授權許可，同時創(chuàng)建一個服務目錄（該目錄可在設計時使用以促進API使用，并為有效治理奠定基礎）。

我們想解決“我們擁有要與他人共享，但要按我們的條款共享這些現(xiàn)有的、經(jīng)過精心設計的API ”的問題。

API管理也做得很好，它允許用戶（潛在的API使用者）進行自助服務，簽署不同的API使用計劃（請考慮：在給定時間范圍內(nèi)，在指定價格點上，每個端點每個用戶的調(diào)用次數(shù)）。有能力完成這些管理功能的基礎架構就是網(wǎng)關（API流量所經(jīng)過的）。在網(wǎng)關層，我們可以執(zhí)行身份驗證，速率限制，指標收集，其它策略執(zhí)行等操作。

API Management Gateway

基于API網(wǎng)關的API管理軟件示例：

• Google Cloud Apigee
• Red Hat 3Scale
• Mulesoft
• Kong

在這個級別上，我們考慮的是API（如上定義）是如何最好地管理和允許對其進行訪問。我們不是在考慮服務器，主機、端口、容器甚至服務（另一個定義不明確的詞）。

API管理（以及它們相應的網(wǎng)關）通常被作為由“平臺團隊”、“集成團隊”或其它API基礎架構團隊所擁有的、嚴格控制的共享基礎架構。

需要注意的一件事：我們要小心，別讓任何業(yè)務邏輯進入這一層。如前一段所述，API管理是共享的基礎結構，但是由于我們的API流量經(jīng)過了它，因此它傾向于重新創(chuàng)建“大包大攬的全能型”（認為是企業(yè)服務總線）網(wǎng)關，這會導致我們必須與之協(xié)調(diào)來更改我們的服務。從理論上講，這聽起來不錯。實際上，這最終可能成為組織的瓶頸。有關更多信息，請參見這篇文章：具有ESB，API管理和Now…Service Mesh的應用程序網(wǎng)絡功能？

集群入口

為了構建和實現(xiàn)API，我們將重點放在代碼、數(shù)據(jù)、生產(chǎn)力框架等方面。但是，要想使這些事情中的任何一個產(chǎn)生價值，就必須對其進行測試，部署到生產(chǎn)中并進行監(jiān)控。當我們開始部署到云原生平臺時，我們開始考慮部署、容器、服務、主機、端口等，并構建可在此環(huán)境中運行的應用程序。我們可能正在設計工作流（CI）和管道（CD），以利用云平臺快速遷移、更改、將其展示在客戶面前等等。

在這種環(huán)境中，我們可能會構建和維護多個集群來承載我們的應用程序，并且需要某種方式來訪問這些群集中的應用程序和服務。以Kubernetes為例思考。我們可能會通過Kubernetes Ingress來訪問Kubernetes集群（集群中的其它所有內(nèi)容都無法從外部訪問）。這樣，我們就可以通過定義明確的入口點（例如域/虛擬主機、端口、協(xié)議等），嚴格控制哪些流量可以進入（甚至離開）我們的集群。

在這個級別上，我們可能希望某種“ingress網(wǎng)關”成為允許請求和消息進入群集的流量哨兵。在這個級別上，您的思考更多是“我的集群中有此服務，我需要集群外的人能夠調(diào)用它”。這可能是服務（公開API）、現(xiàn)有的整體組件、gRPC服務，緩存、消息隊列、數(shù)據(jù)庫等。有些人選擇將其稱為API網(wǎng)關，而且實際上可能會做比流量的入口/出口更多的事情，但重點是這個層級的問題是屬于集群操作級別的。

Cluster Ingress Gateway

這些類型的ingress實現(xiàn)的示例包括：Envoy Proxy 及其基礎上的項目包括：

• Datawire Ambassador
• Solo.io Gloo
• Heptio Contour

基于其他反向代理/負載均衡器構建的其它組件：

• HAProxy
• OpenShift’s Router (based on HAProxy)
• NGINX
• Traefik
• Kong

此層級的集群入口控制器由平臺團隊操作，但是，這部分基礎架構通常與更加去中心化的、自助服務工作流相關聯(lián)（正如您對云原生平臺所期望的那樣）。參見The “GitOps” workflow as described by the good folks at Weaveworks

API網(wǎng)關模式

關于“ API網(wǎng)關”一詞的另一種擴展是我在聽到該術語時通常想到的，它是與API網(wǎng)關模式最相似的。Chris Richardson在其“微服務模式”一書第8章很好地介紹了這種用法。我強烈建議您將此書用于此模式和其他微服務模式學習資料?？稍谒膍icroservices.io網(wǎng)站API Gatway Pattern可以進行快速瀏覽。簡而言之，API網(wǎng)關模式是針對不同類別的消費者來優(yōu)化API的使用。這個優(yōu)化涉及一個API間接訪問。您可能會聽到另一個代表API網(wǎng)關模式的術語是“前端的后端”，其中“前端”可以是字符終端（UI）、移動客戶端、IoT客戶端甚至其它服務/應用程序開發(fā)人員。

在API網(wǎng)關模式中，我們明顯簡化了一組API的調(diào)用，以模擬針對特定用戶、客戶端或使用者的“應用程序”內(nèi)聚API?；叵胍幌?，當我們使用微服務構建系統(tǒng)時，“應用程序”的概念就消失了。API網(wǎng)關模式有助于恢復此概念。這里的關鍵是API網(wǎng)關，一旦實現(xiàn)，它將成為客戶端和應用程序的API，并負責與任何后端API和其他應用程序網(wǎng)絡端點（不滿足上述API定義的端點）進行通信。

與上一節(jié)中的Ingress控制器不同，此API網(wǎng)關更接近開發(fā)人員的視角，而較少關注哪些端口或服務暴露以供集群外使用的方面。此“ API網(wǎng)關”也不同于我們管理現(xiàn)有API的API管理視角。此API網(wǎng)關將對后端的調(diào)用聚合在一起，這可能會公開API，但也可能是與API描述較少的東西，例如對舊系統(tǒng)的RPC調(diào)用，使用不符合“ REST”的協(xié)議的調(diào)用（如通過HTTP但不使用JSON），gRPC，SOAP，GraphQL、websockets和消息隊列。這種類型的網(wǎng)關也可用來進行消息級轉(zhuǎn)換、復雜的路由、網(wǎng)絡彈性/回退以及響應的聚合。

如果您熟悉REST API的Richardson Maturity模型，就會發(fā)現(xiàn)相比Level 1–3，實現(xiàn)了API網(wǎng)關模式的API網(wǎng)關來集成了更多的Level 0請求（及其之間的所有內(nèi)容）。

https://martinfowler.com/articles/richardsonMaturityModel.html

這些類型的網(wǎng)關實現(xiàn)仍需要解決速率限制、身份驗證/授權、斷路、度量收集、流量路由等問題。這些類型的網(wǎng)關可以在集群邊緣用作集群入口控制器，也可以在集群內(nèi)部用作應用程序網(wǎng)關。

API Gateway Pattern

此類API網(wǎng)關的示例包括：

• Spring Cloud Gateway
• Solo.io Gloo
• Netflix Zuul
• IBM-Strongloop Loopback/Microgateway

也可以使用更通用的編程或集成語言/框架（例如：

• Apache Camel
• Spring Integration
• Ballerina.io
• Eclipse Vert.x
• NodeJS

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

進入服務網(wǎng)格(Service Mesh)

在云基礎架構上運行服務架構的一部分難點是，如何在網(wǎng)絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中，我們使用了應用程序庫和希望的開發(fā)人員治理來實現(xiàn)此目的。但是，在大規(guī)模和多種開發(fā)語言環(huán)境下，服務網(wǎng)格技術的出現(xiàn)提供了更好的解決方案。服務網(wǎng)格通過透明地實現(xiàn)為平臺及其組成服務帶來以下功能：

• 服務到服務（即東西向流量）的彈性
• 安全性包括最終用戶身份驗證、相互TLS、服務到服務RBAC / ABAC
• 黑盒服務的可觀察性（專注于網(wǎng)絡通信），例如請求/秒、請求延遲、請求失敗、熔斷事件、分布式跟蹤等
• 服務到服務速率限制，配額執(zhí)行等

精明的讀者會認識到，API網(wǎng)關和服務網(wǎng)格在功能上似乎有所重疊。服務網(wǎng)格的目的是通過在L7透明地解決所有服務/應用程序的這些問題。換句話說，服務網(wǎng)格希望融合到服務中（實際上它的代碼并沒有嵌入到服務中）。另一方面，API網(wǎng)關位于服務網(wǎng)格以及應用程序之上（L8？）。服務網(wǎng)格為服務、主機、端口、協(xié)議等（東西向流量）之間的請求流帶來了價值。它們還可以提供基本的集群入口功能，以將某些此功能引入南北向。但是，這不應與API網(wǎng)關可以帶來北/南流量的功能相混淆。（一個在集群的南北向和一個是在一組應用程序的南北向）

Service Mesh和API網(wǎng)關在某些方面在功能上重疊，但是在它們在不同層面互補，分別負責解決不同的問題。理想的解決方案是將每個組件（API管理、API網(wǎng)關、服務網(wǎng)格）合適的安置到您的解決方案中，并根據(jù)需要在各組件間建立良好的邊界（或在不需要時排除它們）。同樣重要的是找到適合去中心化開發(fā)人員和運營工作流程的這些工具實現(xiàn)。即使這些不同組件的術語和標識存在混淆，我們也應該依靠基本原理，并了解這些組件在我們的體系結構中帶來的價值，從而來確定它們?nèi)绾为毩⒋嬖诤突パa并存。

 關注：Java后端編程，回復下面關鍵字 

要Java學習完整路線，回復  路線 

缺Java入門視頻，回復： 視頻 

要Java面試經(jīng)驗，回復  面試 

缺Java項目，回復： 項目 

進Java粉絲群： 加群