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

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

为什么引入网关

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

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

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

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

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