标签：流程 png 需要 逻辑 控制 线程 就会 设置 tom
蓝色和粉色是它的后台实现，几乎可以忽略不计，这是它的底层实现。
所以对于我们来说重要的是这一部分
Zuul Servlet会截断我们所有的http请求。
第二步是ZuulFilter Runner。Zuul的核心其实是Filter，Zuul几乎没有任何可供你们实现的表现层、逻辑层、业务层等，几乎很少有这种情况。Zuul就是servlet+Filter构建的的完整的一套体系，所以它其实是很薄的一层，这很薄的一层里面集成了很多的Filter，因为肯定会有一些定制性的开发，Filter的总控制器就是Runner。也就是说所有的请求进来Runner来判断进那个Filter
filter分了三大类，前置、处理中路由中、路由后期
只要是servlet本身就是线程非安全的，所以它理论上会串数据，第二是当我们用servlet去处理filter的时候，我们就有一个很麻烦的问题是，我们在flter里面怎么才能区分出每一次请求之间的不同呢，这个时候它给我们封装了一个安全的对象RequestContext，没一个请求都会封一个RequestContext这样一个对象，这个里面封装你在Request里，Response里以及中间过程处理所需要的所有的数据都封装在这里边了。所以虽然我们的filter是线程非安全的，servlet是非安全的，runner是非安全的，可是我们这里有个RequestContext是线程安全的，这个RequestContext很重要，也是我们在zuul servlet里面玩出各种花样的根基。
所以以上变相的告诉我们两件事情，一是Zuul是由很多很多filter构成的，第二步是filter分为三大类，前置、路由中和后置 ，
第三点：还因为servlet和filter本身是线程非安全的，同时数据会有安全性问题。所以这种情况下，Zuul很人性化的封装了一个对象叫做RequestContext 。
虽然servlet和filter都是线程非安全的，但是RequestContext是线程安全的
都处理完成后，就会返回一个Http Response。说白了这个流程大致就是这样一个流程。
这是官方给我们提供的图，
origin Server就是我们真实的服务器。它代表的就是我们film的微服务
有一个关键的核心点在这，真正调用服务是这里，routing filters。也就是说pre filters是在我们调用真实的服务之前要做的事情。
而post filters就是在我们调用真实服务返回之后要去做的事情，
除了以上，还变相的给了我们两个，一个是cumstom Filter 一个是 error Filters
cumstom Filter ：更多的是一些用户管理行为的东西
error Filters：是真实存在的，它是用来帮我们做容错管理的，
以上的图就标识出来我们所有的filter的位置和大概是做什么用的了。
pre filters:做鉴权、解包、解码、验签一些的东西，也就是说我们可以处理一些真实数据触发我们的真实业务之前的一些前置内容，
postFilter：一般都是做一些数据增强，比如说我们的数据在返回前端时候，我们需要签名，postFilter就可以做这些事情。第二有可能我们返回的数据是写杂乱无章的数据，那我的postFilter可以对数据做整理、编排然后紧着做返回，或者我们可以去设置返回值的内容的 context-type等。
标签：流程 png 需要 逻辑 控制 线程 就会 设置 tom
原文地址：https://www.cnblogs.com/wangjunwei/p/12856588.html
