概述
我们知道soul网关支持多种协议的,其中http协议应该是最基本也是平时使用最多的协议。
开始实践之前,我们可以梳理一下网关的基本功能,需要考虑什么问题呢?
先梳理一下加入网关后的调用流程:
客户端http请求->网关->后端服务。
- 可以看到,网关是一个服务器,可以接受请求和转发请求。
- 经过网关的请求,需要对url进行解析,判断其是否满足转发到后端服务的条件
- 如果后端服务有多个,需要考虑负责均衡策略。
- 网关调用后端服务,那么必定要知道后端服务的地址,有两种方式
- 将后端地址配置在网关服务中(如spring cloud gateway)
- 网关服务主动去获取后端地址(soul网关的决策)
- 网关调用后端接口服务采用的方式,及RPC的方式。
带着以上思考,我们开始正式的实践操作吧。
实战练习
启动soul-admin和soul-bootstrap项目
上一篇我们了解了soul的架构,知道了admin和bootstrap的关系。
我们知道了网关服务(bootstrap)都是通过admin服务与后端服务交互信息的,这里admin服务起到一个配置信息中转的角色。后端服务通过向admin注册的方式,将自身的网关路由规则注册到admin,然后admin实时同步给soul网关,soul网关缓存下来。这样网关不需要配置后端服务的信息,也可以做到带有请求规则的转发。
启动soul-examples-http项目
- 配置soul-admin的地址,以及需要注册的信息。
soul:
http:
adminUrl: http://localhost:9095 #admin的后台地址
port: 8188 #端口号
contextPath: /http #这里可以理解为本应用在网关的一个入口地址
appName: http
full: false #false自定义流量,需要配置规则,true为全流量。
- 查看pom引用,特殊的可以看到引用了一个soul的mvc客户端。
<dependency>
<groupId>org.dromara</groupId>
<artifactId>soul-spring-boot-starter-client-springmvc</artifactId>
<version>${soul.version}</version>
</dependency>
这样我们可以在项目中通过在接口上添加注解的方式,将接口注册到admin服务中去。
我们可以猜测@SoulSpringMvcClient注解的作用就是定义网关的规则,并注册到admin的配置中去。
@PostMapping("/save")
@SoulSpringMvcClient(path = "/save" , desc = "Save order")
public OrderDTO save(@RequestBody final OrderDTO orderDTO) {
orderDTO.setName("hello world save order");
return orderDTO;
}
-
启动SoulTestHttpApplication项目,我们可以在控制台中看到以下日志信息:
-
登录admin控制台的插件列表,选择divide,可以查看刚刚SoulTestHttpApplication应用注册上来的信息。
通过比对可以发现,选择器的配置信息对应了我们SoulTestHttpApplication项目里application.yaml中的配置信息,而右边的规则列表则是由添加了 @SoulSpringMvcClient注解的接口生成注册的。
左边部分选择器列表,右边部分选择器规则列表,可以看到选择器和规则的是一对多的对应关系。
这里引出了我们插件最重要的两个核心概念:选择器和规则。
选择器
字段详解:
- 名称:为你的选择器起一个容易分辨的名字
- 类型:custom 是自定义流量,full 是全流量。自定义流量就是请求会走你下面的匹配方式与条件。全流量则不走。
- 匹配方式:and 或者or 是指下面多个条件是按照and 还是or的方式来组合。
- 条件:
- uri:是指你根据uri的方式来筛选流量,match的方式支持模糊匹配(/**)
- header:是指根据请求头里面的字段来筛选流量。
- query: 是指根据uri的查询条件来进行筛选流量。
- ip:是指根据你请求的真实ip,来筛选流量。
- host:是指根据你请求的真实host,来筛选流量。
- post:建议不要使用。
- 条件匹配:
- match : 模糊匹配,建议和uri条件搭配,支持 restful风格的匹配。(/test/**)
- = : 前后值相等,才能匹配。
- regEx : 正则匹配,表示前面一个值去匹配后面的正则表达式。
- like :字符串模糊匹配。
- 是否开启:打开才会生效
- 打印日志:打开的时候,当匹配上的时候,会打印匹配日志。
- 执行顺序:当多个选择器的时候,执行顺序小的优先执行。
- 选择器建议 : 可以
uri
条件,match
前缀 (/contextPath),进行第一道流量筛选。
规则
- 当流量经过选择器匹配成功之后,会进入规则来进行最终的流量匹配。
- 规则是对流量最终执行逻辑的确认。
- 规则详解:
- 名称:为你的规则起一个容易分辨的名字
- 匹配方式:and 或者or 是指下面多个条件是按照and 还是or。
- 条件:
- uri:是指你根据uri的方式来筛选流量,match的方式支持模糊匹配(/**)
- header:是指根据请求头里面的字段来筛选流量。
- query: 是指根据uri的查询条件来进行筛选流量。
- ip:是指根据你请求的真实ip,来筛选流量。
- host:是指根据你请求的真实host,来筛选流量。
- post:建议不要使用。
- 条件匹配:
- match : 模糊匹配,建议和uri条件搭配,支持 restful风格的匹配。(/test/**)
- = : 前后值相等,才能匹配。
- regEx : 正则匹配,表示前面一个值去匹配后面的正则表达式。
- like :字符串模糊匹配。
- 是否开启:打开才会生效。
- 打印日志:打开的时候,当匹配上的时候,会打印匹配日志。
- 执行顺序:当多个选择器的时候,执行顺序小的优先执行。
- 处理:每个插件的规则处理不一样,具体的差有具体的处理,具体请查看每个对应插件的处理。
- 上图表示:当
uri
等于/http/order/save
的时候该规则被匹配,就会执行该规则中,负载策略是random
- 联合选择器,我们来表述一下 :当一个 请求的
uri
为/http/order/save
, 会通过random
的方式,转发到1.1.1.1:8080
。 - 规则建议: 可以
uri
条件,match
最真实的uri路径
,进行流量的最终筛选 。
条件详解
- uri 匹配 (推荐)
- uri匹配是根据你请求路径中的uri来进行匹配,在接入网关的时候,前端几乎不用做任何更改。
- 当使用
match
方式匹配时候,同springmvc
模糊匹配原理相同。 - 在选择器中,推荐使用uri中的前缀来进行匹配,而在规则中,则使用具体路径来进行匹配。
- 该匹配方式的时候,在匹配字段名称可以任意填写,匹配字段值需要正确填写。
- header 匹配
- header是根据你的
http
请求头中的字段值来匹配。
- header是根据你的
- query 匹配
- 这个是根据你的uri中的查询参数来进行匹配,比如 /test?a=1&&b=2 ,那么可以选择该匹配方式。
- 上述就可以新增一个条件,选取 query方式 , a = 1 。
- ip匹配
- 这个是根据 http调用方的 ip来进行匹配。
- 尤其是在waf插件里面,如果发现一个ip地址有攻击,可以新增一条匹配条件,填上该ip,拒绝该ip的访问。
- 如果在soul前面使用了nginx代理,为了获取正确的ip,你可能要参考 dev-iphost
- host匹配
- 这个是根据 http调用方的host来进行匹配。
- 尤其是在waf插件里面,如果发现一个host地址有攻击,可以新增一条匹配条件,填上该host,拒绝该host的访问。
- 如果在soul前面使用了nginx代理,为了获取正确的host,你可能要参考 dev-iphost
- post匹配
- 不推荐使用。
使用Postman调用soul网关进行转发
-
打开postman测试后端http服务是否能正常调用。
-
通过调用soul网关来访问后端http服务,如果结果如上图所示说明访问成功。
以上通过soul网关进行单机版的http服务转发已经实现了,继续添加一个http后端服务,测试soul的负载均衡功能。 -
添加第二个http后端服务
如下图,本地复制一个SoulTestHttpApplication应用,修改端口号8189,启动服务。
server: port: 8189 address: 0.0.0.0 soul: http: adminUrl: http://localhost:9095 port: 8189 contextPath: /http appName: http full: false
打开admin编辑插件——选择器/http,可以看到选择器/http中多处了一行配置,这个是端口号为8189的服务配置。
修改weight参数,通过postman请求soul网关服务,观察负载的概率分布是否与weight的参数比符合。
这里需要将soul网关的服务的日志改为debug级别,才能观察。
logging:
level:
root: info
org.springframework.boot: info
org.apache.ibatis: info
org.dromara.soul.bonuspoint: info
org.dromara.soul.lottery: info
org.dromara.soul: debug
实践结论
以上,通过实践我们可以验证我们之前思考的问题。
-
可以看到,网关是一个服务器,可以接受请求和转发请求。
soul网关是一个基于netty的服务器,决定了它的高性能。
-
经过网关的请求,需要对url进行解析,判断其是否满足转发到后端服务的条件
-
选择器(例子中的/http)决定了我们访问那个后端应用,从而把我们的流量限制在具体的某个后端服务。
-
规则决定了我们更为细致的判断条件,并且可以从多个维度url、header、query等来限制请求,从而更近一步限制了流量。
-
-
如果后端服务有多个,需要考虑负责均衡策略。
针对每个接口我们都可以控制其开关及负载均衡策略,这个在规则中可以配置。
-
网关调用后端服务,那么必定要知道后端服务的地址,有两种方式
- 将后端地址配置在网关服务中(如spring cloud gateway)
- 网关服务主动去获取后端地址(soul网关的决策)
这部分在后面的章节再分析。
-
网关调用后端接口服务采用的方式,及RPC的方式。
Soul网关既然是插件式的,那么这个rpc方式肯定是可以变化的,这里是采用http的方式,通过动态代理来与后端交互的。
思考总结
和Spring Cloud Gateway网关的思路差不多,**网关所做的事情主要就是服务的转发,但是并不是所有的请求都可以被服务的,必定要满足后端服务规则的请求才能被转发给后端服务。**因此如何设计判断规则是网关的重点。
Soul网关采用选择器+规则的方式,来组织请求的判断的规则,一个选择器对应多个规则,一个规则又对应多个条件。这个模型就好比一个后端服务有多个服务接口,一个接口有多个限制条件。如下图所示:
这样,在我们的微服务架构中,我们可以为每个服务配置一个选择器,分别为每个接口(对应的是rule)配置其具体限制条件(condition)。
以上这一切在soul网关中不需要我们手动配置,只需要在我们的服务中通过在接口上添加注解的方式来实现。