《微服务架构设计模式》之外部API模式

导读

• 设计能够支持多种客户端的API挑战
• 使用API Gateway模式和后端访问模式
• 设计和实现API Gateway
• 使用响应式编程简化API组合

外部API设计

外部API：暴露给客户端的API接口

外部API客户端

JavaScript程序、移动APP应用、第三方应用

微服务架构下请求服务弊端

微服务架构下客户端直接请求各个微服务导致：安全性不高、用户体验不好、扩展性不高、前后端交互可能不友好

1. 多次请求

   • 效率低用户体验不佳：客户端多次和后端交互（并发请求、顺序请求）
   • 互联网（外网）通信延迟更高（移动网络更糟）
   • 移动端需要编写复杂的API组合逻辑（移动端核心任务时提供优质的用户体验）

2. 缺少封装：缺乏封装导致前端开发做出的代码修改影响后端

   • 后端无法对前端做到变更透明，后端变更API可能要求前端同步修改
   • 前后端耦合严重，紧耦合

3. 通信协议不友好

   服务可能使用对客户端而言不便或不能使用的进程间通信机制，尤其是防火墙外的客户端（XML、JSON、AMQP、WebSocket）

4. 对外客户端API不透明

   服务接口更新可能会修改API，但可能无法要求第三方同步更新

API Gateway功能

模式：API Gateway

• 实现一个服务，该服务时外部API客户端进入微服务应用程序的入口点

• 外观模式，一种服务

核心功能：

1. 请求路由（反向代理）

2. API组合：实现一组API操作

边缘功能：

1. 身份验证：验证请求客户端身份（如：登录验证）

2. 访问授权：验证客户端是否有权执行某次请求操作（如：每次请求鉴权）

3. 负载均衡：请求负载均衡到其他服务

4. 请求日志：记录请求历史

5. 限流：限制客户端每秒请求数

6. 指标收集：收集有关API的只用情况

7. 缓存：缓存以减少请求次数

8. 协议转换：外部请求为WebSocket，内部转发可以是RPC、HTTP等

API Gateway实现

集中式

API Gateway由独立团队开发和维护

弊端：

• 客户端调整需要协同API Gateway团队
• 与微服务提倡的松散耦合，团队自治理念背道而驰

所有者模式

API Gateway为每个客户端提供专用API（适合规模较大网关服务）

**好处：**客户端开发团队负责API Gateway的专用API开发和维护，变更方便

**弊端：**多个团队在同一个AG服务开发导致该服务业务职责不清晰（微服务架构：谁构建谁拥有）

后端前置模式

模式：后端前置

为每种类型的客户端实现单独的API Gateway

好处：

• API模块彼此隔离，提高了可靠性（如：部署、出现故障）
• 提高可观测性（不同进程的监控）
• 更高的可扩展性
• 提高可部署性

AG三种模式对比

	集中式	所有者模式	后端前置模式
隔离性	低	中	高
可观测性	低	中	高
可扩展性	低	中（内部模块化）	高（服务化）
可部署性	低（团队协调）	中（应实现自动化部署，不然需等AG团队发版）	高（独立部署）
松耦合	耦合大	团队自治，业务和团队绑定	谁构建谁拥有

使用AG前后对比

	无API Gateway	使用API Gateway
封装性	低（客户端可知后端服务结构）	高（内部服务结构客户端无法得知）
调用次数	多	少
边缘功能扩展	复杂、冗余大	统一实现（鉴权、身份验证、限流、埋点、负载均衡等）
性能瓶颈	各个微服务本身	API Gateway成为瓶颈，必须保证高可用

设计难题

1. 高性能和可扩展性

   • 承载的并发能力（并发连接数、线程数存在上限）
   • 必须高可用
   • 良好可扩展性

   使用NIO线程模型提高并发

   • netty
   • Spring Reactor
   • Vertx
   • JBoss Undertow
   • NodeJS

2. 使用响应式编程编写可维护代码

   AG服务中使用响应式方法，并发调用其他服务，以提高AG的响应速度。

   如：一个请求在AG里组合调用了其他四个服务，且为顺序调用，那么应该实现四个调用并发执行，在得到所有执行结果再进行组合最终结果返回。

   • Java8 CompletableFutures（CompletableFutures.all(…)）
   • Reactors Monos
   • Netflix创建的RxJava Observable
   • Scala Futures
   • 基于NodeJs使用JavaScript promises或RxJS

3. 处理局部故障

   • 重试机制：服务失败后的重试
   • 熔断器模式：下游服务一直未响应，AG可在一定时间后断开连接并开启熔断
   • 失败负载均衡：失败后自动负载到其他服务

4. 可观测性

   AG服务的运行状态等数据监控

实现API Gateway

云产品服务

• 阿里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是瓶颈点）
部署性	低	高（独立安装部署）	高（独立开发部署）

总结