目录
问题描述
服务拆分之后，会面临两大问题：
- 服务地址过多，其将来可能还会变化，导致前端不知道该请求哪个服务。
- 每个服务可能都需要登录用户信息，如果各自去做登录校验，不仅麻烦，而且还会有密钥泄漏的风险
解决方案-网关
右边的小区可以看出一个微服务集群，小区里的每个住户可以看成一个个微服务，而看门大爷可以看作网关：
路由转发
如上图所示，以后，前端只需要知道网关的地址即可，前端所有的请求都去请求8080端口，就会到达网关，网关再根据前端的请求去判断应该由哪个微服务来处理这个请求，比如判断出该请求是在查商品，那么自然就会知道该请求应该由商品微服务处理，而这个判断的过程，就是请求的路由。
路由之后，判断出了该请求应该由哪个微服务处理，那么接下来网关就会把该请求转发到具体的微服务。这个过程就是路由转发。
负载均衡
微服务在线上部署时，可能不是单节点部署，而是有很多的实例形成集群，这时，网关要将请求路由转发到微服务，还需要在多实例之间，利用负载均衡的算法来挑选一个具体的实例。
服务拉取
所有的微服务一启动，都会把自己的信息注册到注册中心，而网关其实也是一个微服务，它启动了之后，也可以去注册中心拉取所有的服务地址，这样一来，网关就可以清楚地知道所有微服务的地址了，而且将来如果微服务地址有变更，注册中心也会推送给网关。
身份校验
在网关做路由转发之前，还需要对请求的用户身份进行校验，如果某个业务要求必须登录，而访问时没有登录，那肯定需要进行拦截，如果登录了，那么网关就可以解析用户的jwt,从而得到登录用户的信息，然后再把该用户信息向后传递，即：在路由转发的过程中，把它传递给下游的这些微服务。这样一来，我们就不需要在每个微服务中进行校验了。
网关的作用
有了网关以后，微服务的地址就再也不用暴露给前端了，要暴露给前端的，仅仅是网关地址，这对微服务来说，也是一种保护。
对前端来说，由于它只知道网关地址，因此，整个微服务对它来讲是隐藏的，即一个黑盒：
在前端看来，后端跟原来的单体架构没有什么区别，这样开发体验也是一致的。
所以，网关的作用非常大，它已经成为现在微服务开发必不可少的组件了。
网关的实现的选择
网关的这些功能实现起来还是比较复杂的，所以SpringCloud为我们提供了成熟的网关组件，我们只需要引入，就可以非常方便地实现网关功能了
经过测试，响应式编程的吞吐能力比阻塞式编程要强很多，所以Spring Cloud Gateway也成为了现在更主流的一个网关技术。并且Netfilx Zuul现在也不怎么维护了。
所以选择Spring Cloud Gateway更好。