怎么為您的平臺選擇正確的API網關

本篇內容主要講解“怎么為您的平臺選擇正確的API網關”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么為您的平臺選擇正確的API網關”吧!

為什么要使用API網關?

API是各種大小應用程序背后的推動力。無論您是發布公共API還是建立新的集成市場，API都將成為開展業務的方式。就像網絡時代有HTTP服務器在生產中為那些網站提供服務一樣，API也有API網關以便在生產中為API提供服務?？梢岳肁PI網關來幫助您為客戶和合作伙伴提供具有高可用性的API。它們是代理服務器的一種，位于API的前面，并執行諸如身份驗證，速率限制，將公共可訪問的端點路由到適當的微服務，跨多個內部服務進行負載平衡等功能。

企業集成中間件

從歷史上看，對API網關的需求源于集成方面的挑戰。在使用REST和GraphQL  API之前，公司正在構建基于SOAP和XML的API，這些API包含結構化或非結構化數據。API網關可以提供統一的接口，并將多個舊版應用程序鏈接在一起。在這樣的用例中，API網關可以采用舊版SOAP服務，將數據轉換應用于API，例如從SOAP轉換為REST，從JSON轉換為XML)。這些類型的轉換通常不是自動的。例如，RESTful  API與SOAP的核心主體非常不同，因此它不像將XML轉換為JSON那樣簡單。

打破整體

微服務架構是構建和部署獨立服務以組成更大的應用程序的策略。微服務與單片架構的優缺點不在本文討論范圍之內。從高層次來看，微服務架構正在成為構建API的方法。它使多個獨立團隊可以在大型應用程序上工作，而不會互相干擾或處理很長的部署時間。

除微服務外，還有更小的計算單位，例如納米服務和無服務器計算。由于管理數百或數千個服務的復雜性以及為您的客戶端提供統一接口或合同的要求，API網關在使用微服務和無服務器計算的體系結構中已變得司空見慣。

API網關的好處

無論您使用微服務或無服務器計算，還是內部使用或公開訪問您的API，使用API網關都有許多好處：

• 解耦：如果您無法控制的客戶端直接與許多單獨的服務進行通信，則由于客戶端與基礎架構和組織耦合，因此重命名或移動這些服務可能會面臨挑戰。API網關使您能夠基于路徑，主機名，標頭和其他關鍵信息進行路由，從而使面向公眾的API端點與基礎微服務體系結構脫鉤。

• 減少往返次數：某些API端點可能需要跨多個服務連接數據。API網關可以執行此聚合，因此客戶端不需要復雜的調用鏈，并減少了往返次數。

• 安全性：API網關提供集中式代理服務器，以管理速率限制，漫游器檢測，身份驗證，CORS等。許多API網關都允許設置數據存儲區(例如Redis)來存儲會話信息。

• 橫切關注點：日志記錄，緩存和其他橫切關注點可以在集中式設備中處理，而不是部署到每個微服務。實際上，Moesif為許多API網關(例如Kong和Tyk)提供了插件，因此您無需安裝任何SDK即可獲得現代的客戶和API分析。

API平臺的其他好處

除了上面列出的好處外，為正在為客戶和合作伙伴構建可公開訪問的API的公司還有其他好處。這樣的API平臺是由諸如Stripe或Twilio的API首先公司以及具有開發平臺(如Github或Twitter)的公司構建的。如今，隨著客戶和合作伙伴要求更多的自定義和集成，對于B2B公司過渡到平臺而言，它變得越來越重要。

使用API網關的其他好處是：

• 管理開發人員的API密鑰，包括提供一致的授權和身份驗證方法

• 速率限制和計費可以基于配額或使用情況。

• 為客戶和合作伙伴提供開發人員門戶，以創建API令牌，棄用令牌等。

什么是Moesif?

Moesif是成千上萬的平臺使用的最先進的API分析平臺，用于了解您最忠實的客戶對您的API所做的事情，他們如何訪問它們以及從何處訪問它們。Moesif有流行的API網關，如插件香港，TYK和更多。

要比較的變量

(1) 部署復雜度

它是單節點設備還是網關需要運行多種類型的節點才能開始并設置數據庫?一些網關需要多種類型的數據庫。

(2) 開源與專有

當您想使用其他功能擴展網關時，會發生什么情況。有插件嗎?如果是這樣，那么插件是開源的嗎?

(3) 在Premise vs Cloud托管

本地部署可能會增加額外的時間來計劃部署和維護。但是，由于額外的躍點，云托管解決方案可能會增加一點延遲，并且如果供應商宕機，則會降低服務的可用性。

(4) 特征

某些網關更像是為服務API而修改的裸機HTTP服務器。其他則包括整個軟件包，包括開發人員門戶，安全性等。如果網關包含此類功能，則開發人員門戶等功能具有良好的用戶體驗和設計，或者使您能夠調整設計以滿足自己的需求。

(5) 社區

開發人員是否在網關之上構建其他功能?就像Apache  Tomcat和NGINX一樣，它們擁有大量的開放源碼。一些API網關擁有大量的開發人員社區，它們正在構建腳本，在Stack  Overflow上回答的問題等。

(6) 價格

如果您是一家小型公司，那么他們是否有不錯的免費套餐或開源版本?而如果您是老牌企業，則該公司是否有您需要的支持。

API網關領域的主要參與者

(1) Kong

Kong是一個基于(NGINX。)的開源API網關，NGNNX是一種非常流行的開源HTTP代理服務器。即使Kong是開源的，KongHQ仍為大型企業提供維護和支持許可證。開源版本具有基本功能，但某些功能(例如Admin  UI，安全性和開發人員門戶)僅在企業許可證中可用。

部署：Kong的最大優勢之一是其廣泛的安裝選項，并帶有Docker和Vagrant等預制容器，因此您可以使部署快速運行。  NGINX是繼Apache和IIS之后最受歡迎的HTTP服務器，并且即使在高請求率下也具有很高的性能。  NGINX擁有龐大的Lua腳本和擴展社區，因此在尋求某些自定義設置時不會被遺忘。在部署方面，Kong具有中等復雜性。它確實需要運行Cassandra或Postgres。一些插件(例如限速插件)可選地需要其他數據存儲(例如Redis)。但是，生產部署并不像Apigee那樣復雜。

功能完備性：開箱即用地提供了API管理的許多預期功能，例如創建API密鑰，路由到多個微服務等。它沒有太多的轉換層(主要是基于HTTP的轉換，沒有SOAP或XML)  。但是，如果您沒有很多舊版應用程序，那么您可能根本不需要額外的數據轉換層權重。即使它帶有速率限制，也沒有計費集成?？梢酝ㄟ^CLI或curl命令對REST  API執行管理和管理任務，從而使管理更易于集成到現有devops劇本中。

Kong具有服務，路由和使用者的概念，在處理構成您的API的數百種微服務以及調用您的API的不同類型的使用者時，它們提供了很大的靈活性。這使插件和轉換可以附加到特定路線甚至單個使用者。

Kong有一個由社區開發的插件的龐大社區，他們于2018年啟動了 Kong Hub，它已經有數十個插件。Moesif是那里的插件之一。

Kong是我們強烈推薦的API網關之一。如果您不需要傳統的行李，而是想要一個流行的開源API網關，那么Kong絕對不會出錯。它是現代的，旨在管理現代微服務，而不僅僅是在原有的整體架構上添加轉換外觀，并且擁有一個快速增長的插件社區，從Moesif之類的API分析到緩存層以及JWT(JSON  Web令牌)驗證。

(2) Tyk

與Kong一樣，Tyk也是開源的，但是它受MPL許可證的約束，該許可證不如Kong的Apache  2.0許可證允許。同時，Tyk的企業用戶使用與社區用戶完全相同的網關。您不必為某些企業功能支付額外費用。  Tyk不再依賴于額外的插件和Lua腳本，而更像是包含了API Gateway的電池。開箱即用地支持OIDC，OAuth3，Bearer Token，Basic  Auth，Mutual TLS，HMAC等身份驗證方案，而無需插件。它還支持XML-> JSON，JSON-> XML，JSON模式驗證。

Tyk基于GoLang構建，GoLang作為一種系統語言，旨在實現高吞吐量和并行性。Tyk.io是其背后的公司，提供云托管版本和專業支持許可證。與Kong  /  NGINX的Lua不同，有些人可能會發現Golang更現代，并且更容易編程。除Golang外，Tyk還具有解釋器，可用于運行其他語言(如Javascript和Lua)的插件。請記住，與可以與內部服務部署在同一vnet上的本地版本不同，云版本將需要直接將某些服務公開到Internet。

部署：Tyk提供云托管的SaaS解決方案或在內部部署。您可以在Heroku或AWS上部署實例。他們的網站提供了有關如何操作的教程。開源版本的部署相對簡單，只需要Redis，而Kong則需要同時運行Cassandra或Postgres集群。

Tyk具有諸如密鑰管理，配額，速率限制，API版本，訪問控制之類的功能，但沒有集成的計費功能。Tyk同時具有REST  API和Web儀表板來執行管理任務。盡管他們確實有一個擴展列表，但Tyk所擁有的社區或插件集線器并不像Kong那樣大。但是，他們確實對網關進行了精心設計，并嘗試使其保持精簡。

(3) Apigee

Apigee是本文中列出的最古老的API網關。它成立于2004年，并于2016年被Google收購。它不是開源的，并且基于企業Java構建。他們最初是從XML  / SOA應用程序開始的，但后來轉向了API管理領域。Apigee旨在將遺留的整體組件轉換為可供第三方使用的API。他們較少關注微服務和內部API。

因為Apigee具有復雜的多節點體系結構，所以與開源API網關相比，部署的復雜性要高得多。Apigee  Edge要求在本地至少運行9個節點，并且包括運行Cassandra，Zookeeper和Postgres，這迫使集中式基礎架構團隊花費數月的部署時間來計劃部署。

雖然大多數Apigee客戶使用本地版本，但加入Google后，他們推出了Cloud托管解決方案。但是，它更接近IaaS，必須部署到特定的Google  Cloud數據中心，而不是純粹的SaaS。與其他托管版本一樣，托管代理版本會增加延遲，并且需要保護您自己的服務。

使用托管的API網關時，除非它與上游服務位于同一數據中心內，否則可能會增加一點延遲。

與其他服務不同，Apigee支持端到端集成計費，可直接通過您的API獲利。管理門戶建立在Drupal之上。根據您的觀點，Apigee可能顯得功能feature腫，或者是完整的解決方案。同時，它是專有的，沒有龐大的開發者社區來貢獻插件或擴展。

(4) Amazon AWS API網關

作為最大的云供應商，Amazon AWS還具有AWS API Gateway。這是僅云選項。如果您已經在使用AWS  Lambda或EC2，則可以在與上游服務相同的數據中心區域中部署AWS API網關，從而減少了延遲。AWS API  Gateway受到完全管理，只需單擊幾下即可在AWS門戶中進行部署。

與AWS Lambda結合使用時，AWS API  Gateway為無服務器API提供了很好的解決方案。無服務器就像類固醇上的微服務一樣，需要對API端點進行無懈可擊的管理，才能將傳入的API調用路由到適當的無服務器功能。

除AWS Lambda之外，AWS API Gateway還擁有最佳的一鍵式解決方案，可將傳入的API調用路由到其他AWS服務，例如Amazon  Kinesis和Amazon DynamoDB。另外，您可以使用現有的IAM基礎結構來提供對API的身份驗證，而不會產生太多開銷。

從功能上講，它可與Kong媲美。但是，AWS API Gateway沒有龐大的開發人員社區來編寫擴展程序或插件。使用AWS API  Gateway的最大問題之一是供應商鎖定。

(5) 其他

上面的清單并不詳盡，下面是其他清單的快速摘要：

• Azure API網關與AWS的產品非常相似。當然，如果您使用的是Microsoft Azure并且對Azure功能具有良好的支持，則更合適。

• Express API Gateway是LunchBadger新建的條目，它是完全開源的，并基于非常流行的Node.js  Express框架。他們的設計理念是保持最小化和聲明性。如果您要在Node.js上構建大量核心基礎架構，并且熟悉快速中間件，那么值得一看。

• KrakenD還是內置在GoLang中的開源產品。

(6) 概括

以下是表格形式的調查結果的快速摘要：

API網關的使用只會隨著越來越多的公司部署更復雜的mciroservice和無服務器架構而增加。此外，看到Twilio，Salesforce和Stripe等公司的早期成功之后，越來越多的公司正在啟動自己的開發人員計劃。我們非常高興看到API經濟和開發者平臺如何發展，并為它做出貢獻感到高興。

到此，相信大家對“怎么為您的平臺選擇正確的API網關”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！