目录
背景介绍
soul源码阅读（六）Spring Cloud应用示例运行续
soul源码阅读（七）Spring Cloud应用示例运行续2
前面三篇文章，我们通过以下两个问题：
一：{"code":-107,"message":"Can not find selector, please check your configuration!","data":null}
二：{"code":-106,"message":"Can not find url, please check your configuration!","data":null}
基本将插件的启动工作流程，客户端请求的工作流程给debug调试了一遍，包括各个插件的加载，请求初始化流程，真实url封装流程，后台服务请求处理流程，后台服务响应处理流程。前文是基于问题的形式，不断猜想然后往前追溯源码找原因，一步步来搞清楚源码然后解决问题的，本文我们就通过画一些简要流程图的方式将插件的整个工作流程再给梳理一下。
网关启动插件的工作流程
从以上流程图可以看出，我们run SoulBootstrapApplication后，会先去注册各个插件，包括GlobalPlugin，DividePlugin，SpringCloud Plugin，WebClientPlugin等等插件到spring容器。插件列表如上图所示。所有插件都注册成功后，一个核心类，负责所有插件调度处理的SoulWebHandler就要登场了，它在网关启动-》插件注册到spring容器后，会将自己先注册到spring容器，同时将容器中的插件集合进行排序，排序的作用主要是请求到网关后，有些插件是负责初始化工作，有些是构造参数的作用，有些是真实请求后台服务的作用，有些是处理请求响应的工作，所以需要保证顺序。启动流程介绍完毕，接下来介绍下网关收到请求后的插件工作流程。
客户端请求网关后各插件的处理流程
同样，用一个流程图咱们做下描述梳理。一个客户端请求过来，会先进入到org.dromara.soul.web.handler.SoulWebHandler#handle()方法，这个方法是soul网关收到请求后的统一处理入口。该方法会调用org.dromara.soul.web.handler.SoulWebHandler.DefaultSoulPluginChain#execute()方法，该方法将会循环处理各个插件，执行的顺序就是启动网关的时候排好序的，基本大的来看是先global插件，然后再divide，springcloud插件，webclient插件，webclientresponse插件等，几个插件介绍如下，中间过程有一些插件暂未研究，下篇文章分享。
- GlobalPlugin:获取元数据，初始化PRC类型等参数
- SpringCloudPlugin：处理封装后台服务信息，负载均衡处理，生成真实请求URL和TIME_OUT
- WebClientPlugin：处理封装后台服务信息，获取上下文对象的url信息，请求处理
- WebClientResponsePlugin：服务响应处理
基本参照流程找对应流程的源码，去debug一遍看过程参数是不是符合预期，不符合预期的参数是哪一个，直到定位到源头，找到最根本原因，问题也就解决了。
总结
本篇文章篇幅不多，但需要梳理出这么个东西来，所耗费的精力却不见的少，希望有清晰的描述到整个插件的工作流程，有助于我们一起来梳理源码以及定位问题，包括在清晰流程的基础上后可以自定义一个插件的工作流程，把它集成到大的流程中去工作。这里推荐一个大佬的自定义插件博客：Soul网关源码阅读（十）自定义简单插件编写。