破解服务中共性问题的繁琐处理方式——接入 API 网关

由于服务粒度的不同以及数据包装因端而异的差异需求,我们在之前章节中引入了 BFF 层,调用端可以直接调用 BFF 层,由 BFF 层再将请求分发至不同微服务,进行数据组装。由于很多子服务都需要用户验证、权限验证、流量控制等,真的要在每个子服务中重复编写用户验证的逻辑吗?本章节就带你走近网关,在网关层统一处理这些共性需求。

为什么引入网关

如果没有网关的情况下,服务调用面临的几个直接问题:

  1. 每个服务都需要独立的认证,增加不必要的重复度
  2. 客户端直接与服务对接,后端服务一旦变动,前端也要跟着变动,独立性缺失
  3. 将后端服务直接暴露在外,服务的安全性保障是一个挑战
  4. 某些公共的操作,如日志记录等,需要在每个子服务都实现一次,造成不必要的重复劳动

现有系统的调用结构如下图所示:

直接由前端发起调用,服务间的调用可以 由服务注册中心调配,但前端调用起来就没这么简单了,特别是后端服务以多实例的形态出现时。由于各个子服务都有各自的服务名、端口号等,加之某些共性的东西(如鉴权、日志、服务控制等)重复在各子模块实现,造成不必要的成本浪费。此时,就亟需一个网关,将所有子服务包装后,对外统一提供服务,并在网关层针对所有共性的功能作统一处理,大大提高服务的可维护性、健壮性。

引入网关后,请求的调用结构演变成如下图:

评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符 “速评一下”
©️2020 CSDN 皮肤主题: 精致技术 设计师:CSDN官方博客 返回首页
实付 39.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值