作者回复: 你好，你的问题回答如下：1），是原生zuul的简化定制版，不是spring cloud zuul。2)，当企业业务和团队到一定规模，zuul网关是要按场景(h5,无线,第三方开放平台等)分集群的，我之前和现在的公司都是这种管理模式，当然管理成本会大一点，一般需要研发一套统一网关治理系统。如果你业务和团队规模小，则没必要分那么细。3）我们做法是存数据库集中管理，zuul网关节点定期到数据库拉取(zuul节点本地有缓存和比对机制)。4)，我们在生产实践中发现，不启用AsyncServerlet，当访问量大时候连接数有限制（拒绝额外请求）；启用AsyncServerlet后，可以接受的连接数明显增加，当然这个只是前端异步，后端处理和请求还是由容器线程池同步处理的，总体吞吐量没有增加，只是可接受连接数增加了，所以我说优化了连接数。

作者回复: 你好，看得出你们已经花费很多功夫去禁用某个filter，实际生产中，我们还是需要评估成本和可靠性，首先，生产上禁用某个filter一般不会频繁发生(毕竟我们没有Netflix那么大规模)，所以需要评估这个成本是否值得，大部分情况下，能用apollo配置中心动态控制filter启停就足够了(我们之前就是这么干的)，没必要完全内存删除；其次，删除filter可能有潜在内存问题，是否会引入不可靠性？所以还是需要评估下是否一定要这样做，anyway，你已经深入研究了这个问题，也完全理解了这种机制的利弊，相信你已经有自己的答案了，也谢谢你提供的方案思路！

作者回复: 对的，netflix原生zuul这块还不完善，主要在filter本地加载那块，笨办法只能先删除本地filter临时目录，再重启zuul。或者需自己修复filter加载逻辑，下线的filter本地和内存都要删除。或者也可以用apollo开关控制filter的启用或禁用。groovy应该不在spring容器管理范围内，估计不能用注入。

作者回复: 总体是基于zuul源码，做了少量简化和调整，主要变化：过滤器管理数据访问层从cassandra改为mysql，增加CAT埋点，增加AsyncServlet支持

作者回复: 建议阅读一下这篇文章<理解AsyncServlet>： https://ijunc2.github.io/2018/02/01/seventh.html AsyncServlet把线程的角色一分为二，分为主要处理连接和I/O的Servlet线程和处理业务逻辑的Worker线程。这个优化对提升服务其处理效率还是有不小的帮助的，Servlet线程处理完IO就可以被回收到线程池，这样就可以处理更多的连接。如果不分的化，Servlet线程要同时处理I/O连接和处理业务逻辑，容易阻塞消耗更多资源。 就像一个由AB两个步骤组成的任务原来只有一个人干，B阻塞的时候这个人只能等着，现在把步骤拆分为二，有两个人分别专注干A和B，B阻塞的时候，第一个人可以继续可以干下一个A。

作者回复: 如果讲绝对性能，zuul应该比不过nginx，但是网关无状态，可以水平扩，适当优化，zuul组成的网关性能完全是ok的(携程每日百亿API请求通过zuul网关，netflix比携程的量应该还要大)，而且zuul基于java，对开发人员扩展比较友好。相比nginx比较偏运维，开发人员能直接扩展nginx的不多。

作者回复: 请确保网络良好，可以正常连接并下载官方maven仓库中的依赖jar包。

作者回复: 请确保网络良好，可以正常连接并下载官方maven仓库中的依赖jar包。

作者回复: 源码就是定制版s2g-zuul和lab05中的项目 https://github.com/spring2go/s2g-zuul

作者回复: 理论上讲，Zuul能做的， Nginx都能做到，相反，Nginx能做的，Zuul也能做到(可以扩展)。实际上，Nginx是一种通用高性能的反向代理，常常作为网站的前置反向代理和负载均衡器用；而zuul则一般用在API网关场景。很多公司同时用Nginx + Zuul。