作者回复: 网关主要是请求路由转发,开销有一点,但是一般不是很大,我们观察生产一般网关损耗只有大约10ms左右;另外网关上需要做好限流熔断,防止后端慢服务影响网关。具体部署多少个zuul实例,要看你的访问量规模,我之前公司有部署上百个的,也有10~20个的,你需要自己评估,做好监控和容量规划。
作者回复: 能做和该不该它做是两码事,网关适合做反向路由,负载均衡,安全,监控,和限流熔断这些基础功能。
分布式事务一般和业务相关,建议不要耦合在网关上。分布式锁简单的采用DB锁或者复杂点的采用Zookeeper做,一般不要放在网关上。
作者回复: 你好,你的问题很长很多,这里回复不全,建议参考我的文章《BFF和网关是如何演化出来》https://blog.csdn.net/yang75108/article/details/86987404,应该能够找到答案,如果还有疑问,可以直接在群里向我提问。
作者回复: zuul可以做细粒度权限控制,可开发定制过滤器filter,权限逻辑根据业务需求灵活定制实现。jwt带权限往后传可以,userid往后传再到集中服务验权也可以,两种架构风格,各有利弊。
作者回复: 我之前公司实践,Edge Service依赖Base Service走内部nginx代理,Edge Service之间或Base Service之间如有依然(网状结构有时也合理)也走内部nginx代理。内部服务(Edge或Base Service)对外暴露时才走zuul网关。当然,内部服务用rpc直连,不走内部nginx代理,也是可以,是另一种架构风格。
作者回复: 两种做法都可以,是两种架构风格,静态资源可以躲在网关zuul后面,这样就没有跨域问题;也可以前面加nginx,做动静分别转发,动态api转网关zuul,静态转资源服务器,这种方式需要考虑跨域问题。我们目前用第二种,但是在考虑简化采用第一种,但是zuul网关需要优化改造,改造成同时适合处理api和静态资源。
作者回复: 我只用过zuul,spring cloud gateway还没用,不好做建议,你需要自己调研测试。总体我认为zuul比较成熟,在netflix有大规模落地,但是同步模型(zuul2是异步),spring cloud gateway比较新,实际落地案例还不多,你用的话要实测下。