有了Nginx后为什么还要网关，你知道吗？

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

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

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

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

图片

公司的新业务上线，运营人员线上需要部署C服务，完成部署服务C后，运维人员还要在Nginx中配置请求转发的配置，如下图所示：

为了让Nginx中的配置生效，往往还需要重新地启动Nginx服务。

（2）Nginx中通用业务逻辑维护麻烦

在实际的业务中，通常都需要用户鉴权、日志记录和黑白名单的功能，这些通用的功能一般都不会放在具体的微服务中而是单独抽取出来，然后请求到达微服务上的时候先执行这些通用的功能，如下所示：

图片

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

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

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

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

图片

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

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

图片

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