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