API网关：Kong、Gravitee、Tyk、HAProxy大PK

随着微服务的兴起，网关已成为最重要的一个部分。众多的 Api 网关的产生，使不少人面临着 2 个比较尖锐的问题。一个是增加了面试的难度，另外一个是选择一个最适合自己的网关并非易事。

基于此，我简单的比较了 4 种 API 网关：Kong，Gravitee，Tyk和HAProxy。希望能对大家有所帮助！

Kong

Kong 是自 2017 年以来由 Kong Inc 用 Lua 和 Perl 编码的开源 API 网关。开源解决方案是 Kong API Gateway，而企业版 Kong Enterprise 在网关周围收集了更多工具，例如仪表板或监视工具。

Kong 只需要一个 PostgreSQL 来保存其配置，就可以安装在许多环境和 OS 中。

从架构蓝图可以看出，Kong 包含了一个插件部分。Kong Inc 及其社区目前拥有非常多的插件，包括：身份验证，日志，监控，速率限制等。Kong 的社区活跃且发展迅速。此外，Kong 易于理解和部署：大多初学者只需要 1 小时，便可掌握，而自定义安装脚本只需几分钟。

Kong 还非常的轻量级，大概只需要不到 300MB 的内存就可以运行。它需要CPU，增加 CPU 数量将提高其性能。Kong 可以水平扩展：API 网关是无状态的，数据库是唯一的。这意味着我们进行更改时，水平缩放将会变得非常的简单。

Gravitee

Gravitee 是 Gravitee Source 自 2015 年 1 月以来使用 Java 开发的开源 API 网关。该系统比 Kong 更复杂：它依赖于 3 个应用程序。前两个是 Management 块的一部分：门户是 Angular Front，它与 Management API 交互以管理网关的所有配置。它的配置保存在 MongoDB中。

Gravitee 的优点之一是仪表板：它清晰，易于开发人员理解，并且我们可以使用 Gravitee 进行的所有操作（路由，身份验证，警报等）。Gravitee 提供的功能少于 Kong，但如果您没有特殊需求，它将令人满意。

对于 Gravitee，痛苦的是安装和文档。因为我们安装它时，至少要安装 3 个组件和一个 MongoDB，并且可能需要 ElasticSearch。相关的学习文档也比较少，并且社区不大。

Gravitee 对内存要求较高，学习成本也比 Kong 高，因此我一般不建议大家使用它。

Tyk

Tyk.io 是自 2014 年以来由 Tyk Technologie 用 Go 编写的开源 API 网关。Tyk 也比较麻烦，它需要 Redis 和 MongoDB。

Tyk 的优点是仪表盘，文档也比较丰富。Tyk 不需要太多的内存，但是会占用大量CPU。Tyk 的性能也不占据优势，社区活跃度也不如 Kong。

HAProxy

HAProxy 是用 Lua 和 C 开发的开源解决方案。HAProxy 与其他解决方案有很大不同，因为它的首次使用是作为负载均衡器而不是 API Gateway。它的体系结构很简单：只有一个启动过程，启动时会读取配置文件。

由于 HAProxy 并不是 API 网关的主要用途，因此它缺少了用于管理API网关功能的完整接口。但是，HAProxy 优势是性能。它可以使用更少的资源（CPU 和内存）就可以获得比较好的性能。另外一个优势是，如果你用它做了负载均衡，那么把它扩展成网关就显得非常的简单。

实际上，API 网关还有很多，我就不在列举了，看下面的图，基本上列举的比较全了。

以上，只作为大家技术选型的参考，不构成使用建议！

： » API网关：Kong、Gravitee、Tyk、HAProxy大PK