谈谈微服务设计中的 API 网关模式
proginn468312
共 3432字,需浏览 7分钟
·
2020-09-10 01:26
每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。 通过自治的跨职能团队进行敏捷开发和敏捷部署。 运用技术时具备灵活性和可扩展性
客户端到微服务的连接
在考虑客户端与每个已部署的微服务 直接通信 的问题时,应考虑以下挑战:
如果微服务向客户端公开了细粒度的 API,则客户端应向每个微服务发出请求。在典型的单页中,可能需要进行 多次服务器往返,才能满足请求。对于较差的网络条件下运行的设备(例如移动设备),这可能会更糟。
微服务中存在的 多种通信协议(例如 gRpc、thrift、REST、AMQP 等)使客户端很难轻松采用所有这些协议。
必须在每个微服务中实现 通用网关功能(例如身份验证、授权、日志记录)。
在不中断客户端连接的情况下,很难在微服务中进行更改。例如,在合并或划分微服务时,可能需要重新编写客户端部分代码。
API 网关
为了解决上述挑战,人们引入了一个附加层,该附加层位于客户端和服务器之间,充当从客户端到服务器的反向代理路由请求。与面向对象设计的模式相似,它为封装底层系统架构的 API 提供了一个单一的入口,称为 API 网关。
简而言之,它的行为就像 API 管理员一样,但重要的是不要将 API 管理与 API Gateway 混为一谈。
API 网关的功能
路由
认证和授权 服务发现集成 缓存响应结果 重试策略、熔断器、QoS 限速和节流 负载均衡 log 日志、链路追踪、关联 Header、query 字符串 以及 claims 转义 IP 白名单 IAM 集中式日志管理(服务之间的 transaction ID、错误日志等) 身份的提供方,验证与授权 后端服务前端模式(BFF Backend for Frontend)
著名的 API 网关
Apigee API Gateway MuleSoft Tyk.io Akana SwaggerHub Azure API Gateway Express API Gateway Karken D
API 组合与聚合
负载均衡 服务发现 健康检查 安全性
可能产生的单点故障或者瓶颈 由于通过 API 网关进行了额外的网络跳转以及复杂性风险,响应时间增长了。
评论