对于web架构优化我们的最终方向有两点
1：提高系统的吞吐量
2：提高系统的处理逻辑能力。
大体的流程图如下
解释下这个张流程图
1：netty是维护客户端连接负责把请求的内容拿到(是不能阻塞的)
2：disouptor是用来堆放netty放过来的请求与把任务向下放（它只要把请求给到逻辑层处理），可以理解成任务。
3：前面两部都是去堆放大量请求与任务，而第三步的逻辑处理层处理正真的逻辑，第一步到第二步到第三步，都是一个异步的过程，第三步把数据处理好了，存放到一个结果池，然后结果池把数据推给netty，netty然后返回给对应的客户端。
说下传统单体架构的理解
1：普通我们的单体架构项目能容纳的吞吐量很有限，其实在tomcat中也是有一个连接池，然后不停堆任务然后创建线程执行。这样的话，每一个请求我们都需要一个线程去执行。这样至上而下的话，我的线程数量越多cpu压力越大，不停的切换上下文，这样很容易达到硬件所能处理的瓶颈，线程数越多栈的占用量就越大。这样我们系统能容纳喝提供吞吐量并不多传统项目也是采用的bio。
2：这样的架构适合用于controller层支撑收集大量请求，service处理具体业务耗时。然后再利用mq把结果返回给controller层。其实并没让处理请求耗时变短，只是让一个单体的controller层，变得能容纳更多得请求了。
3：针对单体架构而言可以做到逻辑资源不需要考虑锁。
4:针对微服务架构可以这样设计
netty+disouptor （流量层）rpc给到->service（逻辑层）->结果体（可以使用mq）->流量层。这样改变了以前普通的调用过程。现在变成了一个环形执行链，每个部位都是异步的过程。也对cpu与线程用到了极致。
微服务的调用链路图
