Soul网关由来？

Soul网关是我在任职某大型电商公司中间件技术部的时候所开发的。开源以后，针对不同的用户需求，进行了功能的升级，比如支持了springcloud websocket restful风格 get请求，插件可以定制化开发等等,感谢开源。

当时我们面对什么问题呢？

首先公司有很多语言，java，net，php，Python等等，相互之间的交互只能通过http,调用很不统一，尤其是java为主以后，php等语言要调用dubbo服务，dubbo服务者必须提供http服务出来，增加了java后端人员的工作量。
接口鉴权，限流，代理等等很多基本的需求，如果由每个业务系统开发人员开发，增加了成本，风险不可控。
所有的配置没有统一化的管理页面，不利于管理。
接口的性能没有监控，不利于横向扩展。
业务系统进行灰度发布，需要运维进行nginx负载，增加了运维的工作量。
等等很多很多的因素，我们需要一个可配置的，可视化，高性能的API网关，做为公司的公用服务。

当时我们怎么解决的呢？

首先我们调研了市场上的一些API网关 zuul kong sc-gateway

zuul 是一个中间件产品，完全可以由业务系统自己去引入，性能没达到我们的预期，没有动态化的配置，不利于管理，和我们中间件技术部好像没啥关系。
kong kong确实是好，好到它的某些功能是收费的，而且它是lua语言开发，维护成本太高（其实就是hold不住lua）
sc-gateway 这个是基于webflux的，底层也是基于netty，性能可以，其缺点就是，没有动态化的配置，而且也只是sc-cloud体系的，其他的业务系统怎么接入? 怎么做成公用服务？每次新上接口怎么办？动态调整接口的限流速率怎么办？等等很多问题。

so 基于以上问题，我们综合考虑，决定自己干一个。我在做的时候，参考了kong的插件思想，sc-gateway的webflux思想，再结合公司的定制需求写出了soul网关.

首先我们来看一张soul的架构图，有利于加深它的运行原理

首先别被这张图吓着，我来详细的讲解下，绿色的部分，客户端就是代表用户,它按照网关要求的数据格式来请求网关服务。
soul服务其实就是个http服务，底层用了webflux，所以它如果部署集群的话，可以开启一个nginx集群，来反向代理soul服务
soul-admin 就是整个soul的整个管理后台，它配置所有的规则选择器，然后再把数据写到zookeeper。
soul服务在启动的时候，会拉取zookeeper的数据，写到本地JVM，然后继续监听 zookeeper，来动态更新JVM中的数据，这一块可以参考 zookeeper-node 设计。
后面就是soul的执行流程了，基本上就是插件责任链模式，具体的插件执行具体的事情. 每个插件它是根据用户请求网关的数据，与admin后台配置的规则，来执行具体的逻辑。所以这有个很重要的东西，用户访问soul的数据请求格式是什么？

我们来看一下soul实现的功能

自带插件: 防火墙，签名，监控，限流，代理，dubbo，springcloud
所有的插件，选择器，规则，热插拔，动态配置。
无缝对接http，restful，websocket，dubbo，springcloud 等协议
支持集群部署，支持灰度发布。
当然你熟了以后，还有很多其他的功能，比如查找定位问题，A/B test 等等

请求soul网关

这里我假设你已经部署好了soul-admin 以及 soul-web 为localhost:8080
你使用 http工具类，或者postman ，post请求访问 localhost:8080
http header 头设置：

module ：必填,指请求的系统模块，建议：所有插件的选择器中应该根据此字段来匹配
method ：必填,请求的方法，指真实请求的方法，如果是http/springcloud，那么指请求的方法路径。如果是dubbo，那就是请求的真实方法. 建议：所有插件规则应该根据此字段来匹配过滤请求

rpcType: 请求的类型，填写http 则会使用divide插件，填写dubbo则会使用dubbo插件，填写springcloud则会使用springcloud插件。
这里我只有列举了比较简单的几个字段，还有几个字段未写，可以在这里看:请求参数设置

这里就有一个大体的印象，我是用http访问了soul网关，只不过在http header里面新增了几个soul需要的几个字段而已。

当然如果你比较熟悉soul的话，这里是非常宽泛的，用户完全可以自己传递字段，然后在admin后来，根据字段来匹配就好了，相当灵活便利

接下来我们来熟悉下：插件选择器规则

话不多说，首先来一张uml 图来表示他们之间的关系。

推荐一个微服务网关，支持 Dubbo、Spring Cloud、Spring Boot ！

一个插件对应多个选择器，一个选择器对应多个规则。
一个选择器对应多个匹配条件，一个规则对应多个匹配条件。
每个规则在对应插件下，不同的处理表现为handle字段，这个一个不同处理的json字符串。具体的可以在admin使用过程中进行查看。

接下来我们来熟悉下 soul-admin

话多说几句:因为篇幅问题，我这里只是举一个列子。

我们在divide插件的选择器配置以上规则，注意 条件：module=test
我们的http配置就是真实服务的路径:http://10.10.10.4:8088 可以配置多个，然后设置负载方式与权重

我们再来看一下，这个选择器下面的规则配置：

同样我们注意下匹配条件 header 匹配 method = test/putPathBody

如果你是一直看下来的话：我相信你就有了印象，如果我们在http header ：

module字段值设置了 test,
method 字段值设置了 test/putPathBody

然后访问soul，那么soul就会匹配到你的设置最终调用http服务为 : http://10.10.10.4:8088/test/putPathBody

发起代理调用，最终返回数据给你，这样你就完成了一个网关的调用。我们来回想一下，我们做了什么？

我们访问网关是 `localhost:8080` 然后设置了http header ,最后真实调用为:http://10.10.10.4:8088/test/putPathBody

soul 支持websocket

首先我们来看ws访问soul网关路径 ws://localhost:8080/? module=ws&method=/bbex/websocket/buyAndSell&rpcType=websocket

参数详解:
1.localhost:8080 是soul启动的ip和端口。
2.module（必填）:值是你用来匹配selector的关键
3.method （参数）: 你的 websocket路径，同时也用做匹配rule
4.rpcType ：websocket 必填，且必须为websocket

这里websocket 就不能通过header传了，就要用参数方式了。

dubbo 用户使用soul

这里少说两句了

如果是dubbo集成，那么rpcType的值为dubbo
dubbo参数设置在http body里面，具体的请查看 dubbo插件

soul 扩展

方式一：如果你只想使用soul插件的责任链模式，那么只需要实现 org.dromara.soul.web.plugin.SoulPlugin
方式二：如果你想自定义插件,使用soul的选择器，规则设置，那么需要继承org.dromara.soul.web.plugin.AbstractSoulPlugin
篇幅原因请参考：soul扩展

soul自定义开发

其实我更推荐你们自己新建项目来集成soul服务，admin后台就不需要了。
首先引入soul依赖

  <dependency>
         <groupId>org.dromara</groupId>
         <artifactId>soul-spring-boot-starter</artifactId>
         <version>1.0.5-RELEASE</version>
  </dependency>

  <dependency>
          <groupId>org.dromara</groupId>
          <artifactId>soul-web</artifactId>
          <version>1.0.5-RELEASE</version>
   </dependency>

在你的新建项目组引入spring-webflux所需要的依赖包。
具体可以参考以下项目:soul-bootstrap soul-demo