SpringClould-Gateway和nginx网关的区别

---

想学习架构师构建流程请跳转：Java架构师系统架构设计

1 SpringClould-Gateway和nginx

有一天又有人问到我这个,当时没有想过,就说了个软硬件和路由问题其实再想一些业务的话,简单的说gateway 是前端工程 到 后台服务器之间的一个 对内网关,nginx是用户到 前端工程 的网关，对外网关,使其还可以细说没有研究到那么深比如原理性的东西

2 Zuul和Spring Cloud Gateway

两者均是web网关，处理的是http请求
gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件，而zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等
gateway很好的支持异步，而zuul仅支持同步，那么理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定
从框架设计的角度看，gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的
编码上看，zuul更加简洁易懂，注释规范清晰，而gateway作为Spring家族的一份子，竟然几乎不注释…
总的来说，在微服务架构，如果使用了Spring Cloud生态的基础组件，则Spring Cloud Gateway相比而言更加具备优势，单从流式编程+支持异步上就足以让开发者选择它了。

而对于小型微服务架构或是复杂架构（不仅包括微服务应用还有其他非Spring Cloud服务节点），zuul也是一个不错的选择，当然，这种场景下一般会选择nginx，因为nginx从各个方面都会表现的更好…

3 Nginx在微服务中的地位

最后简单聊一下nginx，在过去几年微服务架构还没有流行的日子里，nginx已经得到了广大开发者的认可，其性能高、扩展性强、可以灵活利用lua脚本构建插件的特点让人没有抵抗力。

有一个能满足我所有需求还很方便我扩展的东西，还免费，凭啥不用？？
但是，如今很多微服务架构的项目中不会选择nginx，我认为原因有以下几点：
微服务框架一般来说是配套的，集成起来更容易
如今微服务架构中，仅有很少的公司会面对无法解决的性能瓶颈，而他们也不会因此使用nginx，而是选择开发一套适合自己的微服务框架
spring boot对于一些模板引擎如FreeMarker、themleaf的支持是非常好的，很多应用还没有达到动、静态文件分离的地步，对nginx的需求程度并不大。
无论如何，nginx作为一个好用的组件，最终使不使用它都是由业务来驱动的，只要它能为我们方便的解决问题，那用它又有何不可呢？

4 小结

实际在使用中两者是都可以实现对api接口的拦截，负载均衡、反向代理、请求过滤等功能。
不同点：编写的语言是不一样的，Nginx采用C语言编写，而Gateway采用Java编写的，能够更好对微服务实现拓展功能，而Nginx想要实现拓展功能需要结合Lua语言等。
还有一点是Nginx实现负载均衡原理是属于服务器端负载均衡器，而Gateway则是采用本地负载均衡的形式。
在项目中同时使用到这两者的情况时候，可以这么理解，用户请求进来是先过Nginx网关，这里的Nginx就相当于一个流量网关，是属于用户访问的一个入口。 然后在进入到getway网关中，这里的getway网关属于一个业务网关，通过对应的属性配置将请求传递到每一个业务微服务中去。

通过总结发现，在微服务架构中网关上的选择，最好的方式是使用现在比较成熟的Spring Cloud套件，其提供了Spring Cloud Gateway网关，或是结合公司情况来开发一套适合自己的微服务套件，至少从网关上可以看出来其内部实现并不难，同时也比较期待开源项目Nacos、Spring Cloud Alibaba 建设情况，期待它能构建一个高活跃社区的、稳定的、适合中国特色（大流量、高并发）的微服务基础架构。
竞争是发展的催化剂。在这个网关服务层出不穷的年代，各公司都铆足力气打造自己的网关产品，尽量让自己的产品成为用户的第一选择。而广大开发者也在享受这样的红利，使用高性能的网关来开发自己的应用。作为广大开发者的一员，我们欣然接受这样良性竞争的出现，并且也乐于尝试市面上出现的任何新产品，谁也说不准某一个产品以后就会成为优选的代名词。虽然从现在网关的性能差距看来，后发优势明显，但在可预见的将来，各网关迟早会到达性能瓶颈，在性能差距不大并且产品稳定之后，就会有各种差异化特性出现。而等到网关产品进入百舸争流的时代之后，用户就可以不再根据性能，而是根据自己的需求选择适合的网关服务了。