KONG正在成为API网关之王
思维导图
API网关：快速变化的环境
特性 | 企业服务总线 (ESB) | API 网关 |
|---|---|---|
定义 | 实现SOA中软件应用间的通信系统。 | 充当API前端，调度API请求并执行各种策略。 |
作用 | 作为企业中整合应用程序的中央平台。 | 管理API请求，执行流量策略、安全策略，并收集流量分析数据。 |
架构 | 通常被视为通过共同通信总线进行通信的架构，包括提供者和服务使用者间的点对点连接。 | 主要用于协调转换引擎，在运行时修改请求/响应。 |
使用场景 | 适用于面向服务的架构中，用于应用程序之间的集成。 | 适用于管理外部客户端与服务之间的通信。 |
主要功能 | 服务集成，简化了不同应用程序之间的交互。 | 提供流量控制、安全措施、流量分析等功能，优化API使用体验。 |
区别 | 面向内部服务集成。 | 面向外部客户端，处理与服务之间的接口通信。 |
应用服务器的出现使得通过HTTP服务器作为反向代理来提供Web应用程序或Servlet成为可能。虽然这些应用程序在当时非常好用，但它们变得过于复杂，无法与其他应用程序/服务在面向服务的架构（SOA）中进行集成，于是企业服务总线（ESB）应运而生。
ESB实现了SOA中相互交互的软件应用之间的通信系统。作为一种架构，可以将ESB看作是在企业中整合应用程序的中央平台。它也可以看作是一种通过共同通信总线进行通信的架构，该总线包括提供者和服务使用者之间的各种点对点连接。
API网关充当API前端，调度API请求、执行流量策略（如限流、缓存）、安全策略（如授权、认证）、收集流量分析数据，并协调转换引擎以在运行时修改请求/响应。
服务网格的目的是实现内部服务之间的通信并强制执行策略，而API网关主要用于外部客户端与服务之间的通信。
API网关
OpenResty并不是Nginx的分支，而是一组库和模块，以扩展Nginx的能力。这个基础使得Kong能够通过可插拔的架构与Lua脚本（称为“插件”）进行扩展
Kong最初是在Mashape构建的，用于为其API市场提供安全性、管理性和扩展性，该市场每月为200,000多名开发人员生成数十亿次请求。如今，Kong在关键任务中被广泛使用。
Kong特点总结
特点 | 描述 |
|---|---|
可扩展 | Kong通过添加更多机器实现水平扩展，可以处理几乎任何负载，同时保持低延迟。 |
模块化 | 可通过添加新插件扩展Kong，这些插件可以通过RESTful管理API轻松配置。 |
适用于任何基础架构 | 可在云上或本地环境部署Kong，包括单个或多个数据中心设置，适用于公有、私有或邀请-only的API。 |
架构
几行脚本成功为插件实现了一个有用的缓存系统。
Kong可以做的事
功能类别 | 描述 |
|---|---|
代理 | Kong 作为代理，将请求传递给后端服务。 |
中间件 | Kong 作为中间件，通过转换、限流等功能来扩展服务。 |
资源管理器 | Kong 作为资源管理器，可以管理服务的用户并通过认证层保护服务。 |
docker-compose up --scale users=2操作步骤
- 创建upstreams（多个target）
- 创建services（对应后面的upstreams）
- 添加api（route）关联后面的services
健康检查
类型 | 描述 |
|---|---|
Active HC | 定期请求特定的HTTP端点，使用响应来检查服务的健康状况。与负载均衡器结合使用，以自动启用和禁用目标。 |
Passive HC | 监视每个服务的持续流量，确定流量的健康响应。使用管理API来通知目标的健康状态，以启用目标。 |
版本管理
API版本使用三个标识符：主要（major）.次要（minor）.补丁（patch）
- 主要：不兼容
- 次要：向后兼容
- 补丁：修复一些错误（也是向后兼容）
版本类型 | 描述 | 兼容性 | 例子 |
|---|---|---|---|
主要 | 不兼容的重大更新，可能会引入破坏性变化。 | 不向后兼容 | 2.0.0 |
次要 | 向后兼容的功能更新，添加新功能但不会影响现有功能的使用。 | 向后兼容 | 1.1.0 |
补丁 | 修复错误的小更新，不会更改软件的功能或添加新功能。 | 向后兼容 | 1.0.1 |