作者回复: 你好，具体要不要分，还是要看业务和团队规模，对于像携程这样体量的公司(我之前工作过)，它们内部有超过十套以上面向不同端的网关，总网关集群规模超过百台。对大体量多团队的公司，网关如果分的不够，不同团队容易打架。微服务也是这个道理，服务分分多少多细，也主要看体量和团队规模，小团队不分也没事。另外，安全认证要求，对于不同部门可能不一样，比如支付部门要求更严格，所以可以独立定制部署。 另外，nginx偏运维，spring gateway对中国java程序员更友好。

作者回复: 你这个理解也有一定道理，网关主要给微服务/api用，偏向开发人员，反向代理主要面向传统静态web应用，偏向运维。未来趋势是DevOps+网关和反向代理再次融合。

作者回复: 在k8s中，和网关等价的概念叫Ingress，像kong/envoy/traefik这些可编程网关，都有支持对接Ingress。课程项目Staffjoy中的Faraday，即是反向代理也是网关，当把Staffjoy部署到K8s环境，Faraday也相当于Ingress功能。

作者回复: zuul是java开发，绝对性能比不过c/lua开发的nginx。但是网关性能考量只是一个方面，同时还要考虑开发和维护是否方便，使用是否简单灵活等其它方面因素。相对于nginx，zuul对开发人员(特别是java开发人员)更友好，使用门槛也更低。另外，网关一般无状态部署，可以支持水平扩容，如果性能容量不够，只要简单扩容即可。

作者回复: 你好，kong(https://github.com/Kong/kong)就是在openresty基础上扩展出来的云原生的网关，有api动态可编程，后面有一节专门讲主流网关概览会讲到kong。

作者回复: 这时候可以考虑引入前置硬件负载均衡，例如F5或者A10，然后nginx躲在硬件负载均衡器后面，做二级负载均衡，这时候nginx可以按需部署多台，分摊负载。

作者回复: stackoverflow上有讨论，网关和反向代理只是术语叫法不同，两者可以互补，也可以相互替代。 https://stackoverflow.com/questions/35756663/api-gateway-vs-reverse-proxy