怎么为您的平台选择正确的API网关

本篇内容主要讲解“怎么为您的平台选择正确的API网关”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“怎么为您的平台选择正确的API网关”吧!

为什么要使用API网关?

API是各种大小应用程序背后的推动力。无论您是发布公共API还是建立新的集成市场，API都将成为开展业务的方式。就像网络时代有HTTP服务器在生产中为那些网站提供服务一样，API也有API网关以便在生产中为API提供服务。可以利用API网关来帮助您为客户和合作伙伴提供具有高可用性的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网关”有了更深的了解，不妨来实际操作一番吧！这里是编程笔记网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！