应用场景

1、南北向流量

需要流量网关和微服务网关配合使用，将内部的微服务能力，以统一的 HTTP 接入点对外提供服务。

流量网管主要是接入流量进行负载均衡，上游的微服务网关地址和数量变化不大，对服务发现要求不高。

微服务网关则把外部请求映射到内部的微服务上，微服务的节点地址和数量会经常变化，路由规则变化基本稳定，微服务网关很方便的解决了服务发现。

2、东西向流量

在同一业务域内的微服务通信走的是服务发现机制，通过robbin和Feign即可很好解决上游节点的负载均衡，不需要微服务网关再来提供集中式的服务。

在一些业务量比较大的系统中，可能会按照业务域隔离出一系列的微服务，比如支付和交易两个大的业务域服务，各自可以拆分出来很多的细粒度的微服务，在跨业务域访问的时候希望能够统一提供服务，可以走南北向访问也可以走东西向模式访问，在走东西向的时候则可以借助借助于微服务网关。

比较与未来

springcloud gateway的功能弱爆了，只支持代码和配置文件来配置路由规则，不支持动态配置路由规则（需要自行来实现），实用性不够。

类似apisix这些网关随便拿一个出来都可以干爆springcloud gateway，动态定义路由规则配置不需要重启即可生效，打通Eureka服务发现也早就实现。

上kubenetes后直接就用service来做服务发现了，别说是gateway了，连Eureka都不需要了。

长期看所有的应用上k8s是必然，springcloud gateway必然没落。