概述
由于服务粒度的不同以及数据包装因端而异的差异需求，我们在之前章节中引入了 BFF 层，调用端可以直接调用 BFF 层，由 BFF 层再将请求分发至不同微服务，进行数据组装。由于很多子服务都需要用户验证、权限验证、流量控制等，真的要在每个子服务中重复编写用户验证的逻辑吗？本章节就带你走近网关，在网关层统一处理这些共性需求。
为什么要引入网关
如果没有网关的情况下，服务调用面临的几个直接问题：
- 每个服务都需要独立的认证，增加不必要的重复度
- 客户端直接与服务对接，后端服务一旦变动，前端也要跟着变动，独立性缺失
- 将后端服务直接暴露在外，服务的安全性保障是一个挑战
- 某些公共的操作，如日志记录等，需要在每个子服务都实现一次，造成不必要的重复劳动
现有系统的调用结构如下图所示：
直接由前端发起调用，服务间的调用可以由服务注册中心调配，但前端调用起来就没这么简单了，特别是后端服务以多实例的形态出现时。由于各个子服务都有各自的服务名、端口号等，加之某些共性的东西（如鉴权、日志、服务控制等）重复在各子模块实现，造成不必要的成本浪费。此时，就亟需一个网关，将所有子服务包装后，对外统一提供服务，并在网关层针对所有共性的功能作统一处理，大大提高服务的可维护性、健壮性。
引入网关后，请求的调用结构演变成如下图：
最后
以上就是尊敬母鸡为你收集整理的服务压力大系统响应慢如何破——网关流量控制的全部内容，希望文章能够帮你解决服务压力大系统响应慢如何破——网关流量控制所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。
发表评论 取消回复