有了Nginx后为什么还要网关

    在微服务架构普及的当下，即使项目中已经使用了Nginx，通常还需要网关，Nginx和网关并非替代关系，而是‌互补协作‌的关系，这就是有了Nginx后为什么还要网关的原因。

    Nginx是一款很强大的高性能Web和反向代理服务，它是用C语言开发的，其核心优势占有内存少，并发能力强，非常适合应用在高并发场景、静态资源托管和请求的负载均衡等等。Nginx在流量的最外层，可以能帮应用系统扛住海量的tcp的连接。Nginx虽然很强大，但是其在实际的项目中有存在一些缺点：

（1）Nginx的配置缺乏灵活性

    假设现在公司的系统中有服务A、服务B和服务C，通过Nginx配置实现请求的负载均衡，如下图所示：

    Nginx可以实现上述的功能，但是比较麻烦，需要使用Lua脚本，对于使用Java的业务团队来说，一方面上手慢，另一方面一旦逻辑复杂维护成本很高。

    此时我们就引入了网关，我们将Java开发出来的通用的功能（用户鉴权、日志记录和黑白名单等等），然后将这些通用的功能放在Nginx和业务服务之间，如下图所示：

    在Java当中，目前主流的网关是SpringCloud Gateway，它对java开发比较友好，并且能够与注册中心Nacos无缝连接。SpringCloud Gateway不需要去手动的配置IP列表，能自动的感知服务的上线和下线，当微服务需要扩容或缩容时，网关的路由表是动态刷新的。

    假设现在又的用户请求来了，我们可以通过SpringCloud Gateway中通过编写Predicate和过滤器实现复杂的业务逻辑（典型应用是识别用户是否VIP，然后转发不同的服务上），如下图所示：

这种基于上下文的精细化流量治理，正是应用网关的核心竞争力所在。

    在实际的架构中，Nginx和网关是组合在一起的使用的，如下图所示的架构：

    请求到达的第一层是Nginx，它作为流量的入口，就像小区的大门一样，负责一些日常的安全的把控（如处理DOSS攻击、处理静态资源）和流量的限流，经过Nginx过滤后的请求发送到网关上处理。

    网关上主要负责治理工作（如进行统一的鉴权、限流熔断和服务的路由，日志的记录等等），经过网关处理后的用户的请求最后由网关转发到具体的微服务的集群当中处理业务逻辑。

总结：

（1）Nginx主要负责一些安全的把控和抗住大流量的对应用系统的冲击，然后将有效的请求转发到网关上。

（2）网关负责精细化流量治理，然后将请求转发到具体的服务上处理业务逻辑。