Kong，Tyk，Apigee和替代方案的比較

為什么要使用API​網(wǎng)關(guān)?

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

企業(yè)集成中間件

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

打破整體

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

除微服務(wù)外，還有更小的計算單位，例如納米服務(wù)和無服務(wù)器計算。由于管理數(shù)百或數(shù)千個服務(wù)的復(fù)雜性以及為您的客戶端提供統(tǒng)一接口或合同的要求，API網(wǎng)關(guān)在使用微服務(wù)和無服務(wù)器計算的體系結(jié)構(gòu)中已變得司空見慣。

API網(wǎng)關(guān)的好處

無論您使用微服務(wù)或無服務(wù)器計算，還是內(nèi)部使用或公開訪問您的API，使用API​​網(wǎng)關(guān)都有許多好處：

• 解耦：如果您無法控制的客戶端直接與許多單獨的服務(wù)進行通信，則由于客戶端與基礎(chǔ)架構(gòu)和組織耦合，因此重命名或移動這些服務(wù)可能會面臨挑戰(zhàn)。API網(wǎng)關(guān)使您能夠基于路徑，主機名，標頭和其他關(guān)鍵信息進行路由，從而使面向公眾的API端點與基礎(chǔ)微服務(wù)體系結(jié)構(gòu)脫鉤。
• 減少往返次數(shù)：某些API端點可能需要跨多個服務(wù)連接數(shù)據(jù)。API網(wǎng)關(guān)可以執(zhí)行此聚合，因此客戶端不需要復(fù)雜的調(diào)用鏈，并減少了往返次數(shù)。
• 安全性：API網(wǎng)關(guān)提供集中式代理服務(wù)器，以管理速率限制，漫游器檢測，身份驗證，CORS等。許多API網(wǎng)關(guān)都允許設(shè)置數(shù)據(jù)存儲區(qū)(例如Redis)來存儲會話信息。
• 橫切關(guān)注點：日志記錄，緩存和其他橫切關(guān)注點可以在集中式設(shè)備中處理，而不是部署到每個微服務(wù)。實際上，Moesif為許多API網(wǎng)關(guān)(例如Kong和Tyk)提供了插件，因此您無需安裝任何SDK即可獲得現(xiàn)代的客戶和API分析。

API平臺的其他好處

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

使用API​​網(wǎng)關(guān)的其他好處是：

• 管理開發(fā)人員的API密鑰，包括提供一致的授權(quán)和身份驗證方法
• 速率限制和計費可以基于配額或使用情況。
• 為客戶和合作伙伴提供開發(fā)人員門戶，以創(chuàng)建API令牌，棄用令牌等。

什么是Moesif?

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

要比較的變量

(1) 部署復(fù)雜度

它是單節(jié)點設(shè)備還是網(wǎng)關(guān)需要運行多種類型的節(jié)點才能開始并設(shè)置數(shù)據(jù)庫?一些網(wǎng)關(guān)需要多種類型的數(shù)據(jù)庫。

(2) 開源與專有

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

(3) 在Premise vs Cloud托管

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

(4) 特征

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

(5) 社區(qū)

開發(fā)人員是否在網(wǎng)關(guān)之上構(gòu)建其他功能?就像Apache Tomcat和NGINX一樣，它們擁有大量的開放源碼。一些API網(wǎng)關(guān)擁有大量的開發(fā)人員社區(qū)，它們正在構(gòu)建腳本，在Stack Overflow上回答的問題等。

(6) 價格

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

API網(wǎng)關(guān)領(lǐng)域的主要參與者

(1) Kong

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

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

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

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

Kong有一個由社區(qū)開發(fā)的插件的龐大社區(qū)，他們于2018年啟動了 Kong Hub，它已經(jīng)有數(shù)十個插件。Moesif是那里的插件之一。

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

(2) Tyk

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

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

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

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

(3) Apigee

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

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

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

使用托管的API網(wǎng)關(guān)時，除非它與上游服務(wù)位于同一數(shù)據(jù)中心內(nèi)，否則可能會增加一點延遲。

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

(4) Amazon AWS API網(wǎng)關(guān)

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

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

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

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

(5) 其他

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

• Azure API網(wǎng)關(guān)與AWS的產(chǎn)品非常相似。當然，如果您使用的是Microsoft Azure并且對Azure功能具有良好的支持，則更合適。
• Express API Gateway是LunchBadger新建的條目，它是完全開源的，并基于非常流行的Node.js Express框架。他們的設(shè)計理念是保持最小化和聲明性。如果您要在Node.js上構(gòu)建大量核心基礎(chǔ)架構(gòu)，并且熟悉快速中間件，那么值得一看。
• KrakenD還是內(nèi)置在GoLang中的開源產(chǎn)品。

(6) 概括

以下是表格形式的調(diào)查結(jié)果的快速摘要：

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