- 导读
- 外部API设计
- 微服务架构下请求服务弊端
- API Gateway功能
- API Gateway实现
- 集中式
- 所有者模式
- 后端前置模式
- 设计难题
- 实现API Gateway
- 云产品服务
- 已有成熟产品
- 自主开发
- 总结
- 设计能够支持多种客户端的API挑战
- 使用API Gateway模式和后端访问模式
- 设计和实现API Gateway
- 使用响应式编程简化API组合
外部API：暴露给客户端的API接口
外部API客户端
Javascript程序、移动APP应用、第三方应用
微服务架构下客户端直接请求各个微服务导致：安全性不高、用户体验不好、扩展性不高、前后端交互可能不友好
-
多次请求
- 效率低用户体验不佳：客户端多次和后端交互（并发请求、顺序请求）
- 互联网（外网）通信延迟更高（移动网络更糟）
- 移动端需要编写复杂的API组合逻辑（移动端核心任务时提供优质的用户体验）
-
缺少封装：缺乏封装导致前端开发做出的代码修改影响后端
- 后端无法对前端做到变更透明，后端变更API可能要求前端同步修改
- 前后端耦合严重，紧耦合
-
通信协议不友好
服务可能使用对客户端而言不便或不能使用的进程间通信机制，尤其是防火墙外的客户端（XML、JSON、AMQP、WebSocket）
-
对外客户端API不透明
服务接口更新可能会修改API，但可能无法要求第三方同步更新
模式：API Gateway
实现一个服务，该服务时外部API客户端进入微服务应用程序的入口点
外观模式，一种服务
核心功能：
-
请求路由（反向代理）
-
API组合：实现一组API操作
边缘功能：
-
身份验证：验证请求客户端身份（如：登录验证）
-
访问授权：验证客户端是否有权执行某次请求操作（如：每次请求鉴权）
-
负载均衡：请求负载均衡到其他服务
-
请求日志：记录请求历史
-
限流：限制客户端每秒请求数
-
指标收集：收集有关API的只用情况
-
缓存：缓存以减少请求次数
-
协议转换：外部请求为WebSocket，内部转发可以是RPC、HTTP等
API Gateway由独立团队开发和维护
弊端：
- 客户端调整需要协同API Gateway团队
- 与微服务提倡的松散耦合，团队自治理念背道而驰
API Gateway为每个客户端提供专用API（适合规模较大网关服务）
**好处：**客户端开发团队负责API Gateway的专用API开发和维护，变更方便
**弊端：**多个团队在同一个AG服务开发导致该服务业务职责不清晰（微服务架构：谁构建谁拥有）
后端前置模式模式：后端前置
为每种类型的客户端实现单独的API Gateway
好处：
- API模块彼此隔离，提高了可靠性（如：部署、出现故障）
- 提高可观测性（不同进程的监控）
- 更高的可扩展性
- 提高可部署性
AG三种模式对比
| 集中式 | 所有者模式 | 后端前置模式 | |
|---|---|---|---|
| 隔离性 | 低 | 中 | 高 |
| 可观测性 | 低 | 中 | 高 |
| 可扩展性 | 低 | 中（内部模块化） | 高（服务化） |
| 可部署性 | 低（团队协调） | 中（应实现自动化部署，不然需等AG团队发版） | 高（独立部署） |
| 松耦合 | 耦合大 | 团队自治，业务和团队绑定 | 谁构建谁拥有 |
使用AG前后对比
| 无API Gateway | 使用API Gateway | |
|---|---|---|
| 封装性 | 低（客户端可知后端服务结构） | 高（内部服务结构客户端无法得知） |
| 调用次数 | 多 | 少 |
| 边缘功能扩展 | 复杂、冗余大 | 统一实现（鉴权、身份验证、限流、埋点、负载均衡等） |
| 性能瓶颈 | 各个微服务本身 | API Gateway成为瓶颈，必须保证高可用 |
-
高性能和可扩展性
- 承载的并发能力（并发连接数、线程数存在上限）
- 必须高可用
- 良好可扩展性
使用NIO线程模型提高并发
- netty
- Spring Reactor
- Vertx
- JBoss Undertow
- NodeJS
-
使用响应式编程编写可维护代码
AG服务中使用响应式方法，并发调用其他服务，以提高AG的响应速度。
如：一个请求在AG里组合调用了其他四个服务，且为顺序调用，那么应该实现四个调用并发执行，在得到所有执行结果再进行组合最终结果返回。
- Java8 CompletableFutures（CompletableFutures.all(…)）
- Reactors Monos
- Netflix创建的RxJava Observable
- Scala Futures
- 基于NodeJs使用Javascript promises或RxJS
-
处理局部故障
- 重试机制：服务失败后的重试
- 熔断器模式：下游服务一直未响应，AG可在一定时间后断开连接并开启熔断
- 失败负载均衡：失败后自动负载到其他服务
-
可观测性
AG服务的运行状态等数据监控
- 阿里SLB（简单负载均衡）
- AWS Application LoadBalancer（简单负载均衡，支持HTTP、WS、HTTP2、HTTPS）
- AWS API Gateway
-
定制化产品Kong（基于Nginx），实现了身份验证、鉴权、可埋点、路由规则动态配置、负载均衡，需要独立运维和配置
-
Traefik（Golang编写），类似Kong并支持服务注册发现（基于K8S）
-
APISIX，支持动态负载平衡、身份验证、限流限速，国产云原生、高性能、可扩展的微服务 API 网关，定制插件开发。
- Netfix ZUUL：ZUUL1传统IO模型，ZUUL2底层基于Netty，实现了响应式，NIO线程模型
- SpringCloud Gateway：底层基于Netty，实现了响应式，NIO线程模型
- Alibaba Nacos
| 云产品服务 | 已有成熟产品 | 自主开发 | |
|---|---|---|---|
| 灵活性 | 低 | 中（不同产品有差异） | 高，可定制化（动态路由、指标收集、缓存、限流） |
| 开发难度 | 低 | 中（配置即用） | 高 |
| 维护难度 | 低 | 高 | 高 |
| 并发性 | 高 | 高 | 中（NIO模型较好） |
| 高可用 | 高 | 高 | 中（维护集群，且API Gateway是瓶颈点） |
| 部署性 | 低 | 高（独立安装部署） | 高（独立开发部署） |
