微服务和API(应用程序编程接口的缩写)在可持续的现代应用程序开发中几乎变得司空见惯。API 驱动微服务(一种将应用程序构建为小型、独立且可管理的服务/片段的架构设计),它们定义了(API 的)消费者如何与底层服务交互和使用。
对于企业和其他组织而言,API 已成为数字化转型战略的核心。API 使用的增长增加了开发人员对 API 管理解决方案的使用,以将他们的 API 发布给公众或外部开发人员、内部开发人员以及其他合作伙伴。
API 管理工具可以帮助您:
将微服务公开为托管 API。
组合多个微服务以作为 API 公开。
将安全应用于内部和外部微服务。
将遗留服务公开为现代 API。
从微服务和 API 的使用等方面获取业务洞察力。
您正在为您的公司寻找开源 API 管理解决方案吗?那么本指南专为您制作,请继续阅读。
下面,我们分享了您可以在 IT 基础架构中使用的 10 个顶级开源 API 网关和 API 管理解决方案。请注意,以下列表未按特定顺序组织。
1.Kong(OSS)
Kong Gateway (OSS)是一种流行的、开源的、先进的云原生 API 网关,专为通用部署而构建:它可以在任何平台上运行。 它用Lua 编程语言编写,支持混合和多云基础设施,并针对微服务和分布式架构进行了优化。
Kong的核心是为高性能、可扩展性和可移植性而构建的。Kong还轻巧、快速且可扩展。它支持没有数据库的声明式配置,仅使用内存存储和原生 Kubernative CRD。
Kong具有负载平衡(使用不同的算法)、日志记录、身份验证(支持OAuth2.0)、速率限制、转换、实时监控、服务发现、缓存、故障检测和恢复、集群等等。重要的是,Kong支持节点集群和无服务器功能。
它支持为您的服务配置代理,并通过 SSL 或使用WebSockets为它们提供服务。它可以通过上游服务的副本对流量进行负载平衡,监控服务的可用性,并相应地调整其负载平衡。
此外,Kong附带一个命令行界面,允许您从命令行管理Kong集群。此外,Kong使用插件和不同类型的集成是高度可扩展的。它可以通过其 RESTful API 进行管理,以获得最大的灵活性。
2.Apinto
Apinto是一款高性能、可扩展、易维护的云原生API网关。
Apinto网关基于GO语言模块化开发,5分钟极速部署,配置简单、易于维护,支持集群与动态扩容,并且提供几十款网关插件和实用的企业级插件,让用户开箱即用。Apinto网关可以作为业务流量的入口,可以对业务流量进行处理,如动态路由、负载均衡、服务发现、熔断降级、身份认证、监控与告警等。 Apinto网关不受云平台限制,也能在Kubernetes运行。
3.KrakenD
KrakenD也是用 Go 编写的,并且在构建时考虑到了性能,它是一种高性能的开源、简单且可插入的 API 网关,采用无状态架构设计。它可以在任何地方运行并且不需要数据库来运行。它具有简单的配置并支持无限的端点和后端。
KrakenD具有监控、缓存、用户配额、速率限制、服务质量(并发调用、断路器和粒度超时)转换、聚合(合并源)、过滤(白名单和黑名单)和解码等功能。它提供代理功能,例如负载平衡、协议转换和 Oauth;和安全功能,例如 SSL 和安全策略。
您可以手动或使用 KrakenDesigner 配置 API 网关行为, KrakenDesigner是一种 GUI,可让您从头开始直观地设计 API 或恢复现有 API。此外,KrakenD 的可扩展架构允许添加额外的功能、插件、嵌入式脚本和中间件,而无需修改其源代码。
4.Gravitee.io API Platform
Gravitee.io是一个开源、基于 Java 且易于使用的 API 管理平台,可帮助组织保护、发布、分析和记录其 API。它带有三个主要模块,它们是:
API 管理 (APIM):一种开源、简单但功能强大、灵活、轻量级且速度极快的 API 管理 ( APIM ) 解决方案,旨在让您的组织完全控制访问您的 API 的人员、时间和方式。
访问管理 (AM):一种灵活、轻量级、多功能且易于使用的开源身份和访问管理解决方案。它基于 OAuth2/OpenID Connect 协议并充当身份提供者代理。它具有集中式身份验证和授权服务,可保护您的应用程序和 API。
警报引擎 (AE):一个允许用户配置警报和接收通知以轻松有效地监控其 API 平台的模块。它支持多渠道通知和可疑行为检测等。
此外,Gravitee.io附带了 Cockpit,该工具可帮助您设计 API 并在所有环境中发布它们,并提供全功能的多租户支持。它使您能够从平台本身扩展您的Gravitee.io部署。还有graviteeio-cli,一个用于管理 Gravitee.io 生态系统的简单命令行工具。
5.Gloo Edge
Gloo Edge也是开源和基于 Go 的,它是一个功能丰富的 Kubernetes 原生入口控制器(构建在Envoy Proxy之上)和支持遗留应用程序、微服务以及无服务器的下一代云原生 API 网关. 并且它与您的环境相集成,允许您选择自己喜欢的工具来进行调度、持久性和安全性。
它提供强大的功能级路由(允许集成遗留应用程序、微服务和无服务器),旨在支持使用在不同云上运行的不同类型的技术、架构和协议构建的混合应用程序。
Gloo Edge支持限速、熔断、重试、缓存、外部认证、授权等 API 网关特性。它还支持转换、服务网格集成、全自动发现和安全性。
Gloo Edge采用 GraphQL、gRPC、OpenTracing、NATS 等顶级开源项目来提供高质量的功能。此外,它还支持集成未来可能出现的开源项目。
6.Goku API Gateway
Goku API Gateway是一个开源微服务网关,具有使用 Go 构建的云原生架构。它作为微服务架构的API网关;作为统一认证、流量控制、安全防护的平台;作为内部 OPEN API 开发平台;并作为第三方 API 的统一平台。
它具有高性能 HTTP 转发和动态路由、服务编排、多租户管理、API 访问控制等功能。它支持集群部署和动态服务注册、后端负载均衡、API 健康检查、API 断开和重新连接功能、热更新(持续更新配置而无需重启节点)。
Goku还带有一个内置的仪表板,使配置更容易,一个强大的插件系统来扩展其功能,以及一个用于通过命令行启动\停止\重新加载 Goku 的 CLI。
7.WSO2 API Microgateway
WSO2 API Microgateway是一个用于微服务的开源云原生、以开发人员为中心和去中心化的 API 网关。它主要使用Java构建,简化了在分布式微服务架构中创建、部署和保护 API 的过程。
WSO2 API Microgateway是一个轻量级的无状态容器,具有低内存占用,支持通过单个 API 组合多个微服务,还支持运行时服务发现。它允许将遗留 API 格式(包括请求和响应)转换为现代格式,以将它们公开给现代消费者应用程序。
由于WSO2 API Microgateway使用OpenAPI Specification ( OAS ),这使开发人员能够协作创建 API,然后独立测试它们。此外,它具有高度可扩展性,因为它可以独立运行而不依赖于其他组件。
它具有速率限制、服务发现、请求和响应转换、负载平衡、故障转移和熔断、无缝 Docker 和 Kubernetes 集成等功能。它提供基于 OAuth2.0、API 密钥、Basic Auth 和双向 TLS 的身份验证和授权。
8.Fusio
Fusio是一种开源的、基于 PHP 的 API 管理解决方案,用于构建和管理 REST API。从某种意义上说,它是一个 API 管理平台,它允许您开发可以从数据库请求和转换数据的 API 端点。它提供了所有必要的工具,不仅可以从不同的数据源快速构建 API,还可以创建完全自定义的响应。
它用于公开业务功能、微服务、Javascript 应用程序和移动应用程序,提供诸如速率限制、授权、RPC 支持、验证、分析和用户管理等功能。
此外,Fusio支持 OpenAPI 生成、SDK 生成,并带有一个订阅层来帮助您为您的 API 构建一个发布/订阅,以及一个简单的支付系统来对特定路由收费。
Fusio包含一个命令行客户端,允许您直接与 API 交互并部署特定的 YAML 配置文件。Fusio-CLI自动包含在每个Fusio安装中,但您也可以独立运行 CLI 客户端。Fusio 生态系统中还有其他几种工具。
9.Apiman
Apiman是一种开源的、基于 Java 的 API 管理工具,它带有丰富的 API 设计和配置层以及极快的运行时间。它是一个独立的系统,既可以作为单独的系统运行,也可以嵌入到现有的框架和平台中。
它的主要特性是 API 的灵活性和基于策略的运行时治理、丰富的管理层及其完全异步。它支持节流和配额、集中安全、计费和指标,以及许多其他功能。
10. API Umbrella
API Umbrella是一个主要使用Ruby构建的开源 API 管理解决方案。它是一个位于 API 前面的代理,使您能够为所有 API 和微服务创建一个单一的公共入口点,而不管它们位于何处。它提供 API 密钥、速率限制、分析和缓存等功能。
它支持多租户并附带一个管理员来管理 API Umbrella 的所有方面,例如 API 路由配置、用户管理、查看分析等。在 API Umbrella 下,所有管理功能也可通过 REST API 获得。
就这样吧!在本文中,我们回顾了 10 个开源 API 网关和管理解决方案,您可以在您的基础架构中的 Linux 服务器上使用这些解决方案。如果您遇到但我们在本文中遗漏的任何其他解决方案,请随时告诉我们。