《微服务架构设计模式》之外部API模式
作者:互联网
文章目录
导读
- 设计能够支持多种客户端的API挑战
- 使用API Gateway模式和后端访问模式
- 设计和实现API Gateway
- 使用响应式编程简化API组合
外部API设计
外部API:暴露给客户端的API接口
外部API客户端
JavaScript程序、移动APP应用、第三方应用
微服务架构下请求服务弊端
微服务架构下客户端直接请求各个微服务导致:安全性不高、用户体验不好、扩展性不高、前后端交互可能不友好
-
多次请求
效率低
用户体验不佳
:客户端多次和后端交互(并发请求、顺序请求)- 互联网(外网)通信
延迟更高
(移动网络更糟) - 移动端需要编写复杂的
API组合逻辑
(移动端核心任务时提供优质的用户体验)
-
缺少封装:缺乏封装导致前端开发做出的代码修改影响后端
- 后端无法对前端做到变更透明,后端变更API可能要求前端同步修改
- 前后端耦合严重,
紧耦合
-
通信协议不友好
服务可能使用对客户端而言不便或不能使用的进程间通信机制,尤其是防火墙外的客户端(XML、JSON、AMQP、WebSocket)
-
对外客户端API不透明
服务接口更新可能会修改API,但可能无法要求第三方同步更新
API Gateway功能
模式:API Gateway
实现一个服务,该服务时外部API客户端进入微服务应用程序的入口点
外观模式
,一种服务
核心功能:
-
请求路由
(反向代理) -
API组合
:实现一组API操作
边缘功能:
-
身份验证
:验证请求客户端身份(如:登录验证) -
访问授权
:验证客户端是否有权执行某次请求操作(如:每次请求鉴权) -
负载均衡
:请求负载均衡到其他服务 -
请求日志
:记录请求历史 -
限流
:限制客户端每秒请求数 -
指标收集
:收集有关API的只用情况 -
缓存
:缓存以减少请求次数 -
协议转换
:外部请求为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成为瓶颈,必须保证高可用 |
设计难题
-
高性能和可扩展性
- 承载的并发能力(并发连接数、线程数存在上限)
- 必须高可用
- 良好可扩展性
使用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服务的运行状态等数据监控
实现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是瓶颈点) |
部署性 | 低 | 高(独立安装部署) | 高(独立开发部署) |
总结
标签:架构设计,服务,请求,AG,模式,API,Gateway,客户端 来源: https://blog.csdn.net/cn_hhaip/article/details/120546981