來源 | https://urlify.cn/ZfyyIv
最近看到一篇翻譯一篇API網關的正用文章，介紹了其三種角色：API管理、的作集群入口控制、網關API網關模式，正用最后還講了與服務網格的的作關系，通過此文可以更全面的網關理解API網關的作用。
原文 API Gateways are going through an identity crisis
(地址如下：https://medium.com/solo-io/api-gateways-are-going-through-an-identity-crisis-d1d833a313d7)
這些年來，正用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 Management Gateway
基于API網關的API管理軟件示例：
- Google Cloud Apigee(https://links.jianshu.com/go?to=https%3A%2F%2Fapigee.com%2Fapi-management%2F%23%2Fhomepage)
- Red Hat 3Scale(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.3scale.net%2F)
- Mulesoft(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.mulesoft.com%2F)
- Kong(https://links.jianshu.com/go?to=https%3A%2F%2Fkonghq.com%2F)
在這個層級，我們考慮的是API（如上定義）是如何最好地管理和允許對其進行訪問。我們沒有考慮其他角度，例如服務器、主機、端口、容器甚至服務（這是另一個很難定義清楚的詞！）。
API管理（以及它們相應的網關），通常會被嚴格把控，并作為一種“平臺組件”、“一體化組件”和API的其他基礎組件一起生效。
需要注意的一件事：我們要小心千萬別讓任何業務邏輯進入這一層。如前一段所述，API管理是共享的基礎架構，但是由于我們的API流量經過了它，因此它傾向于重新創建“大包大攬的全能型”（認為是企業服務總線）網關，這會導致我們必須與之協調來更改我們的服務。從理論上講，這聽起來不錯。實際上，這最終可能成為組織的瓶頸。有關更多信息，請參見這篇文章：具有ESB，API管理和Now…Service Mesh的應用程序網絡功能？(https://links.jianshu.com/go?to=http%3A%2F%2Fblog.christianposta.com%2Fmicroservices%2Fapplication-network-functions-with-esbs-api-management-and-now-service-mesh%2F)
集群入口
為了構建和實現API，我們將重點放在代碼、數據、生產力框架等方面。但是，要想使這些事情中的任何一個產生價值，就必須對其進行測試，部署到生產中并進行監控。當我們開始部署到云平臺時，我們開始考慮部署、容器、服務、主機、端口等，并構建可在此環境中運行的應用程序。我們可能正在設計工作流（CI）和管道（CD），以利用云平臺快速遷移、更改的特點，將其快速展示在客戶面前等等。
在這種環境中，我們可能會構建和維護多個集群來承載我們的應用程序，并且需要某種方式直接來訪問這些集群中的應用程序和服務。以Kubernetes為例思考。我們可能會通過一個Kubernetes 入口控制器來訪問Kubernetes集群（集群中的其它所有內容都無法從外部訪問）。這樣，我們就可以通過定義明確的規則（例如域/虛擬主機、端口、協議等），嚴格控制哪些內容可以進入（甚至離開）我們的集群。
在這個層級，我們可能希望某種“入口網關”成為允許請求和消息進入集群的流量監控人。在這個層級，思考更多的是“我的集群中有此服務，我需要集群外的人能夠調用它”。這可能是服務（公開API）、現有的整體組件、gRPC服務，緩存、消息隊列、數據庫等。有些人選擇將其稱為API網關，而且實際上可能會做比控制流量進/出而言更多的事情，但重點是這個層級的問題是屬于集群操作級別的。
Cluster Ingress Gateway
這些類型的入口實現的示例包括：Envoy Proxy 及其基礎上的項目包括：
- Datawire Ambassador(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.getambassador.io%2F)
- Solo.io Gloo(https://links.jianshu.com/go?to=https%3A%2F%2Fgloo.solo.io%2F)
- Heptio Contour(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fheptio%2Fcontour)
基于其他反向代理/負載均衡器構建的其它組件：
- HAProxy(https://links.jianshu.com/go?to=http%3A%2F%2Fwww.haproxy.org%2F)
- OpenShift’s Router (based on HAProxy)(https://links.jianshu.com/go?to=https%3A%2F%2Fdocs.openshift.com%2Fcontainer-platform%2F3.9%2Finstall_config%2Frouter%2Findex.html)
- NGINX(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fingress-nginx)
- Traefik(https://links.jianshu.com/go?to=https%3A%2F%2Ftraefik.io%2F)
- Kong(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2FKong%2Fkubernetes-ingress-controller)
此層級的集群入口控制器由平臺組件操作，但是，這部分基礎架構通常與更加分布式、自助服務的工作流相關聯（正如您對云平臺所期望的那樣）。參見The “GitOps” workflow as described by the good folks at Weaveworks(https://links.jianshu.com/go?to=https%3A%2F%2Fwww.weave.works%2Fblog%2Fgitops-operations-by-pull-request)
API網關模式
關于“ API網關”一詞的另一種擴展是我在聽到該術語時通常想到的，它是與API網關模式最相似的。Chris Richardson在其“微服務模式”一書第8章很好地介紹了這種用法。我強烈建議您將此書用于此模式和其他微服務模式學習資料。可在他的microservices.io網站進行快速瀏覽，API Gatway Pattern(https://links.jianshu.com/go?to=https%3A%2F%2Fmicroservices.io%2Fpatterns%2Fapigateway.html)。簡而言之，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請求（及其之間的所有內容）。
https://martinfowler.com/articles/richardsonMaturityModel.html
這些類型的網關實現仍需要解決速率限制、身份驗證/授權、電路斷路、度量收集、流量路由等問題。這些類型的網關可以在集群邊緣用作集群入口控制器，也可以在集群內部用作應用程序網關。
API Gateway Pattern
此類API網關的示例包括：
- Spring Cloud Gateway(https://links.jianshu.com/go?to=http%3A%2F%2Fspring.io%2Fprojects%2Fspring-cloud-gateway)
- Solo.io Gloo(https://links.jianshu.com/go?to=https%3A%2F%2Fgloo.solo.io%2F)
- Netflix Zuul(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2FNetflix%2Fzuul)
- IBM-Strongloop Loopback/Microgateway(https://links.jianshu.com/go?to=https%3A%2F%2Fstrongloop.com%2F)
也可以使用更通用的編程或集成語言/框架（例如：
- Apache Camel(https://links.jianshu.com/go?to=https%3A%2F%2Fgithub.com%2Fapache%2Fcamel)
- Spring Integration(https://links.jianshu.com/go?to=https%3A%2F%2Fspring.io%2Fprojects%2Fspring-integration)
- Ballerina.io(https://links.jianshu.com/go?to=https%3A%2F%2Fballerina.io%2F)
- Eclipse Vert.x(https://links.jianshu.com/go?to=https%3A%2F%2Fvertx.io%2F)
- NodeJS(https://links.jianshu.com/go?to=https%3A%2F%2Fnodejs.org%2Fen%2F)
由于這種類型的API網關與應用和服務的開發緊密相關，因此我們希望開發人員能夠參與幫助指定API網關公開的API，了解所涉及的任何聚合邏輯以及能夠快速測試和更改此API基礎架構的能力。我們還希望運維人員或工程師對API網關的安全性、彈性和可觀察性配置有一些想法。這種層級的基礎架構還必須適應不斷發展的、按需的、自主服務開發人員的工作流。可以通過查看GitOps模型獲取更多這方面信息。
進入服務網格(Service Mesh)
在云基礎架構上運行服務架構的一部分難點是，如何在網絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中，我們使用了應用程序庫和一些專業的開發人員治理來實現此目的。但是，在大規模和多種開發語言環境下，服務網格技術的出現提供了更好的解決方案。服務網格通過透明地實現為平臺及其組成服務帶來以下功能：
- 服務到服務（即東西向流量）的彈性
- 安全性包括最終用戶身份驗證、相互TLS、服務到服務RBAC / ABAC
- 黑盒服務的可觀察性（專注于網絡通信），例如請求/秒、請求延遲、請求失敗、熔斷事件、分布式跟蹤等
- 服務到服務速率限制，配額執行等
精明的讀者會認識到，API網關和服務網格在功能上似乎有所重疊。服務網格的目的是通過在L7透明地解決所有服務/應用程序的這些問題。換句話說，服務網格希望融合到服務中（實際上它的代碼并沒有嵌入到服務中）。另一方面，API網關位于服務網格之上，和應用程序一起（L8？）。服務網格為服務、主機、端口、協議等（東西向流量）之間的請求流帶來了價值。它們還可以提供基本的集群入口功能，以將某些此功能引入南北向。但是，這不應與API網關可以帶來北/南流量的功能相混淆。（一個在集群的南北向和一個是在一組應用程序的南北向）
服務網格和API網關在某些方面在功能上重疊，但是在它們在不同層面互補，分別負責解決不同的問題。理想的解決方案是將每個組件（API管理、API網關、服務網格）合適的安置到您的解決方案中，并根據需要在各組件間建立良好的邊界（或在不需要時排除它們）。同樣重要的是找到適合的辦法去分布式的處理這些組件，給到相應的開發人員和運營工作流。即使這些不同組件的術語和標識存在混淆，我們也應該依靠基本原理，并了解這些組件在我們的體系結構中帶來的價值，從而來確定它們如何獨立存在和互補并存。
免責聲明：本文內容由21ic獲得授權后發布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
