CTO問(wèn)我，為什么需要API網(wǎng)關(guān)？
?最近看到了一篇 API 網(wǎng)關(guān)的文章，介紹了其三種角色：API 管理、集群入口控制、API 網(wǎng)關(guān)模式，最后還講了與服務(wù)網(wǎng)格的關(guān)系，通過(guò)此文可以更全面的理解 API 網(wǎng)關(guān)的作用。
圖片來(lái)自 Pexels
這些年來(lái)，API 網(wǎng)關(guān)正在經(jīng)歷一些有關(guān)他們是否真的起到作用的質(zhì)疑：
它們是否集中、共享了資源，從而促進(jìn)了 API 對(duì)于外部調(diào)用的管理？
它們是否集群入口（ingress）的控制器，從而可以嚴(yán)格管理用戶進(jìn)入或離開(kāi)集群?jiǎn)幔?/p>
或者它們是否某種 API 的鏈接器，從而讓 API 在指定的客戶端上更方便使用？
當(dāng)然，房間里的大象和最常見(jiàn)的問(wèn)題是：“服務(wù)網(wǎng)格會(huì)使 API 網(wǎng)關(guān)過(guò)時(shí)嗎？
房間里的大象：英語(yǔ)習(xí)語(yǔ)，指的是一些雖然顯而易見(jiàn)，但卻由于可能造成尷尬、爭(zhēng)執(zhí)、觸及敏感或禁忌等原因被人刻意忽視的事情。
一些背景
隨著技術(shù)發(fā)展日新月異，整個(gè)行業(yè)通過(guò)技術(shù)和架構(gòu)模式的推陳出新進(jìn)行快速洗牌，如果你說(shuō)“所有這些都使我頭大”，也可以理解。
在本文中，我希望總結(jié)出“API 網(wǎng)關(guān)”的不同身份，闡明日常使用中，哪些群體可以使用 API 網(wǎng)關(guān)（或許一部人正碰到并在嘗試解決這個(gè)問(wèn)題），并再次強(qiáng)調(diào)那些基本原則。
理想情況下，在本文結(jié)束時(shí)，您將更好地了解 API 基礎(chǔ)架構(gòu)在不同層級(jí)、對(duì)不同對(duì)象的作用，同時(shí)明白如何從每個(gè)層級(jí)獲得最大價(jià)值。
在深入探討之前，讓我們先明確 API 一詞的含義。
我對(duì) API 的定義：一個(gè)有著明確定義并且最終目的清晰的接口，通過(guò)網(wǎng)絡(luò)調(diào)用，使軟件開(kāi)發(fā)人員能夠方便安全的對(duì)目標(biāo)數(shù)據(jù)和功能進(jìn)行程序訪問(wèn)。
這些接口抽象了實(shí)現(xiàn)它們的技術(shù)架構(gòu)細(xì)節(jié)。對(duì)于這些設(shè)計(jì)好了的網(wǎng)絡(luò)節(jié)點(diǎn)，我們希望獲得一定程度的使用指引、以及成熟的向下兼容性。
相反，如果僅僅是可以通過(guò)網(wǎng)絡(luò)與另一軟件進(jìn)行交互，并不一定意味著那些遠(yuǎn)程節(jié)點(diǎn)就是符合此定義的 API。
許多系統(tǒng)相互交互，但是這些交互比較隨意，并且因?yàn)橄到y(tǒng)之間耦合性和其他一些因素的關(guān)系，往往在即時(shí)性方面會(huì)受到影響。
我們創(chuàng)建 API 來(lái)為業(yè)務(wù)的各個(gè)部分提供完善的抽象服務(wù)，以實(shí)現(xiàn)新的業(yè)務(wù)功能以及偶然發(fā)現(xiàn)一兩個(gè)創(chuàng)新之舉。
在談?wù)?API 網(wǎng)關(guān)時(shí)，首先要提到的是 API 管理。
API 管理
許多人從 API 管理的角度考慮 API 網(wǎng)關(guān)。這是合理的。但是，讓我們先快速看一下此類(lèi)網(wǎng)關(guān)的功能。
通過(guò) API 管理，我們嘗試去解決“如何控制給其他人使用當(dāng)前有的 API”的問(wèn)題。
例如，如何跟蹤誰(shuí)在使用這些 API、對(duì)誰(shuí)能使用這些 API 進(jìn)行權(quán)限控制、建立一套完善的管理措施進(jìn)行使用授權(quán)和認(rèn)證，同時(shí)創(chuàng)建一個(gè)服務(wù)目錄，可以在設(shè)計(jì)時(shí)使用，提升對(duì) API 的理解并為以后的有效治理奠定基礎(chǔ)。
我們想解決“我們有一些優(yōu)秀的 API，并且我們希望別人來(lái)使用這些 API，但是希望他們按照我們的規(guī)則去使用”的問(wèn)題。
API 管理當(dāng)然也起到一些很好的用處，例如，它允許用戶（潛在的 API 使用者）進(jìn)行自助服務(wù)，簽署不同的 API 使用計(jì)劃（請(qǐng)考慮：在給定時(shí)間范圍內(nèi)，在指定價(jià)格點(diǎn)上，每個(gè)端點(diǎn)每個(gè)用戶的調(diào)用次數(shù)）。
有能力完成這些管理功能的基礎(chǔ)架構(gòu)就是網(wǎng)關(guān)（API 流量所經(jīng)過(guò)的）。在網(wǎng)關(guān)層，我們可以執(zhí)行身份驗(yàn)證，速率限制，指標(biāo)收集，其它策略執(zhí)行等一系列操作。
API Management Gateway
基于 API 網(wǎng)關(guān)的 API 管理軟件示例：
Google Cloud Apigee
Red Hat 3Scale
Mulesoft
Kong
在這個(gè)層級(jí)，我們考慮的是 API（如上定義）是如何最好地管理和允許對(duì)其進(jìn)行訪問(wèn)。
我們沒(méi)有考慮其他角度，例如服務(wù)器、主機(jī)、端口、容器甚至服務(wù)（這是另一個(gè)很難定義清楚的詞）。
API 管理（以及它們相應(yīng)的網(wǎng)關(guān)），通常會(huì)被嚴(yán)格把控，并作為一種“平臺(tái)組件”、“一體化組件”和 API 的其他基礎(chǔ)組件一起生效。
需要注意的一件事：我們要小心千萬(wàn)別讓任何業(yè)務(wù)邏輯進(jìn)入這一層。
如前一段所述，API 管理是共享的基礎(chǔ)架構(gòu)，但是由于我們的 API 流量經(jīng)過(guò)了它，因此它傾向于重新創(chuàng)建“大包大攬的全能型”（認(rèn)為是企業(yè)服務(wù)總線）網(wǎng)關(guān)，這會(huì)導(dǎo)致我們必須與之協(xié)調(diào)來(lái)更改我們的服務(wù)。
從理論上講，這聽(tīng)起來(lái)不錯(cuò)。實(shí)際上，這最終可能成為組織的瓶頸。
有關(guān)更多信息，請(qǐng)參見(jiàn)這篇文章：具有 ESB，API 管理和 Now…Service Mesh 的應(yīng)用程序網(wǎng)絡(luò)功能？
https://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/
集群入口
為了構(gòu)建和實(shí)現(xiàn) API，我們將重點(diǎn)放在代碼、數(shù)據(jù)、生產(chǎn)力框架等方面。
但是，要想使這些事情中的任何一個(gè)產(chǎn)生價(jià)值，就必須對(duì)其進(jìn)行測(cè)試，部署到生產(chǎn)中并進(jìn)行監(jiān)控。
當(dāng)我們開(kāi)始部署到云平臺(tái)時(shí)，我們開(kāi)始考慮部署、容器、服務(wù)、主機(jī)、端口等，并構(gòu)建可在此環(huán)境中運(yùn)行的應(yīng)用程序。
我們可能正在設(shè)計(jì)工作流（CI）和管道（CD），以利用云平臺(tái)快速遷移、更改的特點(diǎn)，將其快速展示在客戶面前等等。
在這種環(huán)境中，我們可能會(huì)構(gòu)建和維護(hù)多個(gè)集群來(lái)承載我們的應(yīng)用程序，并且需要某種方式直接來(lái)訪問(wèn)這些集群中的應(yīng)用程序和服務(wù)。
以 Kubernetes 為例思考。我們可能會(huì)通過(guò)一個(gè) Kubernetes 入口控制器來(lái)訪問(wèn) Kubernetes 集群（集群中的其它所有內(nèi)容都無(wú)法從外部訪問(wèn)）。
這樣，我們就可以通過(guò)定義明確的規(guī)則（例如域/虛擬主機(jī)、端口、協(xié)議等），嚴(yán)格控制哪些內(nèi)容可以進(jìn)入（甚至離開(kāi)）我們的集群。
在這個(gè)層級(jí)，我們可能希望某種“入口網(wǎng)關(guān)”成為允許請(qǐng)求和消息進(jìn)入集群的流量監(jiān)控人。
在這個(gè)層級(jí)，思考更多的是“我的集群中有此服務(wù)，我需要集群外的人能夠調(diào)用它”。
這可能是服務(wù)（公開(kāi) API）、現(xiàn)有的整體組件、gRPC 服務(wù)，緩存、消息隊(duì)列、數(shù)據(jù)庫(kù)等。
有些人選擇將其稱(chēng)為 API 網(wǎng)關(guān)，而且實(shí)際上可能會(huì)做比控制流量進(jìn)/出而言更多的事情，但重點(diǎn)是這個(gè)層級(jí)的問(wèn)題是屬于集群操作級(jí)別的。
Cluster Ingress Gateway
這些類(lèi)型的入口實(shí)現(xiàn)的示例包括如下：
Envoy Proxy 及其基礎(chǔ)上的項(xiàng)目包括：
Datawire Ambassador
Solo.io Gloo
Heptio Contour
基于其他反向代理/負(fù)載均衡器構(gòu)建的其它組件：
HAProxy
OpenShift’s Router
Nginx
Traefik
Kong
此層級(jí)的集群入口控制器由平臺(tái)組件操作，但是，這部分基礎(chǔ)架構(gòu)通常與更加分布式、自助服務(wù)的工作流相關(guān)聯(lián)（正如您對(duì)云平臺(tái)所期望的那樣）。
參見(jiàn) The “GitOps” workflow as described by the good folks at Weaveworks：
https://www.weave.works/blog/gitops-operations-by-pull-request
API 網(wǎng)關(guān)模式
關(guān)于“ API 網(wǎng)關(guān)”一詞的另一種擴(kuò)展是我在聽(tīng)到該術(shù)語(yǔ)時(shí)通常想到的，它是與 API 網(wǎng)關(guān)模式最相似的。
Chris Richardson 在其“微服務(wù)模式”一書(shū)第 8 章很好地介紹了這種用法。簡(jiǎn)而言之，API 網(wǎng)關(guān)模式是針對(duì)不同類(lèi)別的使用者來(lái)優(yōu)化 API 的使用。
這個(gè)優(yōu)化涉及一個(gè) API 間接訪問(wèn)。您可能會(huì)聽(tīng)到另一個(gè)代表 API 網(wǎng)關(guān)模式的術(shù)語(yǔ)是“前端的后端”，其中“前端”可以是字符終端（UI）、移動(dòng)客戶端、IoT 客戶端甚至其他服務(wù)/應(yīng)用程序開(kāi)發(fā)人員。
在 API 網(wǎng)關(guān)模式中，我們明顯簡(jiǎn)化了對(duì)一組 API 的調(diào)用，以模擬針對(duì)特定用戶、客戶端或使用者的“應(yīng)用程序”內(nèi)聚 API。
回想一下，當(dāng)我們使用微服務(wù)構(gòu)建系統(tǒng)時(shí)，“應(yīng)用程序”的概念就消失了。API 網(wǎng)關(guān)模式有助于恢復(fù)此概念。
這里的關(guān)鍵是 API 網(wǎng)關(guān)，一旦實(shí)現(xiàn)，它將成為客戶端和應(yīng)用程序的 API，并負(fù)責(zé)與任何后端 API 和其他應(yīng)用程序網(wǎng)絡(luò)節(jié)點(diǎn)（不滿足上述 API 定義的節(jié)點(diǎn)）進(jìn)行通信交互。
與上一節(jié)中的入口控制器不同，此 API 網(wǎng)關(guān)更接近開(kāi)發(fā)人員的視角，而較少關(guān)注哪些端口或服務(wù)會(huì)公開(kāi)以供集群外使用。
此“ API 網(wǎng)關(guān)”也不同于我們管理現(xiàn)有 API 的 API 管理視角。此 API 網(wǎng)關(guān)將對(duì)后端的調(diào)用聚合在一起。
這可能會(huì)公開(kāi) API，但也可能會(huì)涉及到一些 API 描述較少的東西，例如對(duì)舊系統(tǒng)的 RPC 調(diào)用，使用不符合“REST”的協(xié)議的調(diào)用（如通過(guò) HTTP 但不使用JSON），gRPC，SOAP，GraphQL、WebSockets 和消息隊(duì)列。
這種類(lèi)型的網(wǎng)關(guān)也可用來(lái)進(jìn)行消息級(jí)轉(zhuǎn)換、復(fù)雜的路由、網(wǎng)絡(luò)彈性/回退以及響應(yīng)的聚合。
如果您熟悉 REST API 的 Richardson Maturity 模型，就會(huì)發(fā)現(xiàn)相比 Level 1–3，實(shí)現(xiàn)了 API 網(wǎng)關(guān)模式的 API 網(wǎng)關(guān)集成了更多的 Level 0 請(qǐng)求（及其之間的所有內(nèi)容）。
這些類(lèi)型的網(wǎng)關(guān)實(shí)現(xiàn)仍需要解決速率限制、身份驗(yàn)證/授權(quán)、電路斷路、度量收集、流量路由等問(wèn)題。
這些類(lèi)型的網(wǎng)關(guān)可以在集群邊緣用作集群入口控制器，也可以在集群內(nèi)部用作應(yīng)用程序網(wǎng)關(guān)。
API Gateway Pattern
此類(lèi) API 網(wǎng)關(guān)的示例包括：
Spring Cloud Gateway
Netflix Zuul
IBM-Strongloop Loopback/Microgateway
也可以使用更通用的編程或集成語(yǔ)言/框架，例如：
Apache Camel
Spring Integration
Ballerina.io
Eclipse Vert.x
NodeJS
由于這種類(lèi)型的 API 網(wǎng)關(guān)與應(yīng)用和服務(wù)的開(kāi)發(fā)緊密相關(guān)，因此我們希望開(kāi)發(fā)人員能夠參與幫助指定 API 網(wǎng)關(guān)公開(kāi)的 API，了解所涉及的任何聚合邏輯以及能夠快速測(cè)試和更改此 API 基礎(chǔ)架構(gòu)的能力。
我們還希望運(yùn)維人員或工程師對(duì) API 網(wǎng)關(guān)的安全性、彈性和可觀察性配置有一些想法。
這種層級(jí)的基礎(chǔ)架構(gòu)還必須適應(yīng)不斷發(fā)展的、按需的、自主服務(wù)開(kāi)發(fā)人員的工作流?？梢酝ㄟ^(guò)查看 GitOps 模型獲取更多這方面信息。
進(jìn)入服務(wù)網(wǎng)格（Service Mesh）
在云基礎(chǔ)架構(gòu)上運(yùn)行服務(wù)架構(gòu)的一部分難點(diǎn)是，如何在網(wǎng)絡(luò)中構(gòu)建正確級(jí)別的可觀察性和控制。
在解決此問(wèn)題的先前迭代中，我們使用了應(yīng)用程序庫(kù)和一些專(zhuān)業(yè)的開(kāi)發(fā)人員治理來(lái)實(shí)現(xiàn)此目的。
但是，在大規(guī)模和多種開(kāi)發(fā)語(yǔ)言環(huán)境下，服務(wù)網(wǎng)格技術(shù)的出現(xiàn)提供了更好的解決方案。
服務(wù)網(wǎng)格通過(guò)透明地實(shí)現(xiàn)為平臺(tái)及其組成服務(wù)帶來(lái)以下功能：
服務(wù)到服務(wù)（即東西向流量）的彈性。
安全性包括最終用戶身份驗(yàn)證、相互 TLS、服務(wù)到服務(wù) RBAC/ABAC。
黑盒服務(wù)的可觀察性（專(zhuān)注于網(wǎng)絡(luò)通信），例如請(qǐng)求/秒、請(qǐng)求延遲、請(qǐng)求失敗、熔斷事件、分布式跟蹤等。
服務(wù)到服務(wù)速率限制，配額執(zhí)行等。
精明的讀者會(huì)認(rèn)識(shí)到，API 網(wǎng)關(guān)和服務(wù)網(wǎng)格在功能上似乎有所重疊。服務(wù)網(wǎng)格的目的是通過(guò)在 L7 透明地解決所有服務(wù)/應(yīng)用程序的這些問(wèn)題。
換句話說(shuō)，服務(wù)網(wǎng)格希望融合到服務(wù)中（實(shí)際上它的代碼并沒(méi)有嵌入到服務(wù)中）。
另一方面，API 網(wǎng)關(guān)位于服務(wù)網(wǎng)格之上，和應(yīng)用程序一起（L8？）。服務(wù)網(wǎng)格為服務(wù)、主機(jī)、端口、協(xié)議等（東西向流量）之間的請(qǐng)求流帶來(lái)了價(jià)值。
它們還可以提供基本的集群入口功能，以將某些此功能引入南北向。但是，這不應(yīng)與 API 網(wǎng)關(guān)可以帶來(lái)北/南流量的功能相混淆。（一個(gè)在集群的南北向和一個(gè)是在一組應(yīng)用程序的南北向）
服務(wù)網(wǎng)格和 API 網(wǎng)關(guān)在某些方面在功能上重疊，但是在它們?cè)诓煌瑢用婊パa(bǔ)，分別負(fù)責(zé)解決不同的問(wèn)題。
理想的解決方案是將每個(gè)組件（API 管理、API 網(wǎng)關(guān)、服務(wù)網(wǎng)格）合適的安置到您的解決方案中，并根據(jù)需要在各組件間建立良好的邊界（或在不需要時(shí)排除它們）。
同樣重要的是找到適合的辦法去分布式的處理這些組件，給到相應(yīng)的開(kāi)發(fā)人員和運(yùn)營(yíng)工作流。
即使這些不同組件的術(shù)語(yǔ)和標(biāo)識(shí)存在混淆，我們也應(yīng)該依靠基本原理，并了解這些組件在我們的體系結(jié)構(gòu)中帶來(lái)的價(jià)值，從而來(lái)確定它們?nèi)绾为?dú)立存在和互補(bǔ)并存。
