应用场景
1、南北向流量
需要流量网关和微服务网关配合使用，将内部的微服务能力，以统一的 HTTP 接入点对外提供服务。
流量网管主要是接入流量进行负载均衡，上游的微服务网关地址和数量变化不大，对服务发现要求不高。
微服务网关则把外部请求映射到内部的微服务上，微服务的节点地址和数量会经常变化，路由规则变化基本稳定，微服务网关很方便的解决了服务发现。
2、东西向流量
在同一业务域内的微服务通信走的是服务发现机制，通过robbin和Feign即可很好解决上游节点的负载均衡，不需要微服务网关再来提供集中式的服务。
在一些业务量比较大的系统中，可能会按照业务域隔离出一系列的微服务，比如支付和交易两个大的业务域服务，各自可以拆分出来很多的细粒度的微服务，在跨业务域访问的时候希望能够统一提供服务，可以走南北向访问也可以走东西向模式访问，在走东西向的时候则可以借助借助于微服务网关。
比较与未来
springcloud gateway的功能弱爆了，只支持代码和配置文件来配置路由规则，不支持动态配置路由规则（需要自行来实现），实用性不够。
类似apisix这些网关随便拿一个出来都可以干爆springcloud gateway，动态定义路由规则配置不需要重启即可生效，打通Eureka服务发现也早就实现。
上kubenetes后直接就用service来做服务发现了，别说是gateway了，连Eureka都不需要了。
长期看所有的应用上k8s是必然，springcloud gateway必然没落。