前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >推荐一个微服务网关,支持 Dubbo、Spring Cloud、Spring Boot !

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

作者头像
芋道源码
发布2019-05-13 15:45:55
9.9K0
发布2019-05-13 15:45:55
举报
文章被收录于专栏:芋道源码1024芋道源码1024

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 头设置:
  1. module :必填,指请求的系统模块,建议:所有插件的选择器中应该根据此字段来匹配
  2. method :必填,请求的方法,指真实请求的方法,如果是http/springcloud,那么指请求的方法路径。如果是dubbo,那就是请求的真实方法. 建议:所有插件规则应该根据此字段来匹配过滤请求
    1. rpcType: 请求的类型,填写http 则会使用divide插件,填写dubbo则会使用dubbo插件,填写springcloud则会使用springcloud插件。
    2. 这里我只有列举了比较简单的几个字段,还有几个字段未写,可以在这里看:请求参数设置

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

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

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

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

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

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

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

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

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

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

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

  1. module字段值设置了 test,
  2. 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依赖
代码语言:javascript
复制
  <dependency>
         <groupId>org.dromara</groupId>
         <artifactId>soul-spring-boot-starter</artifactId>
         <version>1.0.5-RELEASE</version>
  </dependency>

or

代码语言:javascript
复制
  <dependency>
          <groupId>org.dromara</groupId>
          <artifactId>soul-web</artifactId>
          <version>1.0.5-RELEASE</version>
   </dependency>
  • 在你的新建项目组引入spring-webflux所需要的依赖包。
  • 具体可以参考 以下项目:soul-bootstrap soul-demo

soul未来展望

  • 我觉得soul 做为纯java来开发网关,其低成本,易用性,随着微服务的流行,肯定会有各种各样的新需求,希望广大技术朋友参与进来,提供优秀的代码与建议。
  • 有人说java语言做网关不如lua,Python等,这个是匪夷所思的。
  • 现在soul是依赖了webflux,个人觉得,后续或者直接使用netty,性能或许会更高。
  • 现在soul依赖于zookeeper,来做配置数据之间的同步,可能会有些重,未来可能会采用http长轮询的方案来同步更新 具体的讨论在:issues

Soul的具体使用文档:

  • 官网文档 :https://dromara.org/website/zh-cn/docs/soul/index.html
  • github地址: https://github.com/Dromara/soul
  • gitee 地址:https://gitee.com/shuaiqiyu/soul


本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-04-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 芋道源码 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Soul网关由来?
  • 当时我们面对什么问题呢?
  • 当时我们怎么解决的呢?
  • 首先我们来看一张soul的架构图,有利于加深它的运行原理
  • 我们来看一下soul实现的功能
  • 请求soul网关
  • 这里就有一个大体的印象,我是用http访问了soul网关,只不过在http header里面新增了几个soul需要的几个字段而已。
  • 当然如果你比较熟悉soul的话,这里是非常宽泛的,用户完全可以自己传递字段,然后在admin后来,根据字段来匹配就好了,相当灵活便利
  • 接下来我们来熟悉下:插件 选择器 规则
  • 接下来我们来熟悉下 soul-admin
  • 然后访问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
  • dubbo 用户使用soul
  • soul 扩展
  • soul自定义开发
  • soul未来展望
  • Soul的具体使用文档:
相关产品与服务
消息队列 TDMQ
消息队列 TDMQ (Tencent Distributed Message Queue)是腾讯基于 Apache Pulsar 自研的一个云原生消息中间件系列,其中包含兼容Pulsar、RabbitMQ、RocketMQ 等协议的消息队列子产品,得益于其底层计算与存储分离的架构,TDMQ 具备良好的弹性伸缩以及故障恢复能力。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档