Zuul 1.x 优劣势和使用场景
-
zuul 1.x servlet阻塞多线程模式，一个请求一个线程来处理，会阻塞
优势 劣势 编程模型简单 线程上下文切换有开销，耗CPU内存资源 开发调试运维简单 连接数有限制 debug调试线程不断好跟踪 延迟阻塞可能会耗尽链接资源造成不稳定，抖动甚至崩溃 -
适用于计算密集型(CPU bound 场景)， IO轻的场景
Zuul 2.x 优劣势和使用场景
-
zuul 2.0非阻塞异步模式,引入事件、总线、队列机制，事件环处理，一个core上一个线程，线程开销少
优势 劣势 线程开销少，每个core上只有一个 编程模型复杂，没有清晰的线程执行流，线程切换来切换去 连接数数量大，易扩展 开发调试运维复杂 null 简单机制的ThredLocak机制不work null cat等全链路监控依赖ThredLocak不容易集成 null Zuul中的requestContext 本身也是ThredLocak处理复杂，因为Zuul2.0本身没有线程局部的概念 -
适用于IO密集型(IO bound) 场景
-
zuul 2.0功能亮点
协议 弹性 运维 hhtp/2 自适应重试 request Passport 方便调试，跟踪请求生命周期 mutusl TLS 源并发保护 status categories 状态码方便调试 null null request Attempts 请求重试监控 方便调试
zuul 2.0性能提示不到20%
生产建议选用 zuul 1.x
-
同步模型简单，大部分公司的量级没必要用这个异步，开发容易调试简单
-
容易监控埋点（cat）
-
稳定成熟 超过7年以上落地经验， 国内携程等公司在用
-
大部分公司量级OK,Netflix 每天千亿级所有要使用2.0
-
可以集成Hystrix熔断，主动熔断防止同步阻塞，可以使用AsyncServlet servlet3.0支持异步请求，不是全程异步，只是前端异步可以支持很多连接数，但是后端保持单线程优点
