作者回复: 视频ppt中观点只是我个人基于实战经验之后的建议,仅供参考,你作为架构师需要根据企业实际上下文自己独立思考和选型。spring cloud zuul虽封装得对开发较友好,但有点过度封装,很多学员反应比较绕,出问题不容易定位和深入源码,这些是封装的成本。建议在较大流量生产上使用的话,还是需要深入zuul/ribbon/hystrix源码,根据企业实际情况作定制,这点我认为原生zuul的代码相对简单更容易切入。当然spring cloud的产品一直在迭代完善中,相信后面会越做越好。anyway,感兴谢你提出来的问题,架构师需要这种批判性思考态度!
作者回复: 你的想法很多,可以加我微信(bulldog2015)交流,我有一个极客时间群,大家可以一起讨论学习成长。这个样例是让大家上手spring cloud zuul的,理解它和原生zuul的主要差别,毕竟现在很多公司直接用spring cloud zuul的,并不是说会用spring cloud zuul就是架构师了。如果有架构师来我这里面试,我会让他解释原生zuul架构和内核原理,也会问原生zuul和spring cloud zuu的差别,以及他的实战经验。
作者回复: zuul主要用做针对API的网关,Web应用或者静态页面,建议放在nginx这类反向代理之后,nginx处理静态页面性能会更好。 当然zuul和nginx没有本质区别,都是反向代理,zuul也可以反向代理Web应用或者静态资源,zuul其实也不关心请求/响应是xml/json还是html页面。具体配置你可以看Spring Cloud Zuul的官方文档即可,如果有问题,可以简单debug一下,看看是不是有filter截获了请求做了重定向,zuul的代码不复杂。
作者回复: https://stackoverflow.com/questions/48584013/ribbon-retry-properties-not-respected 你试试这个帖子里头讲的设置一个全局ribbon retry是否管用: ribbon: OkToRetryOnAllOperations: false
作者回复: 谢支持🌹
作者回复: spring cloud可能也能实现动态filter加载,但需扩展对接定制的filter存储,拉取等管理机制,这些netflix原生zuul已有支持。建议大规模流量网端考虑netflix原生zuul,动态filter机制更灵活,中小规模流量网端用spring cloud zuul也ok,静态filter也有利,调试更友好。
作者回复: 嗯,原生zuul代码不复杂,本质就是个servlet,建议拉下代码研读下,会更有收获。