Soul高可用网关配置缓存的三大同步策略详解

网络 通信技术
网关是流量请求的入口,在微服务架构中承担了非常重要的角色,网关高可用的重要性不言而喻。在使用网关的过程中,为了满足业务诉求,经常需要变更配置,比如流控规则、路由规则等等。

 前言

网关是流量请求的入口,在微服务架构中承担了非常重要的角色,网关高可用的重要性不言而喻。在使用网关的过程中,为了满足业务诉求,经常需要变更配置,比如流控规则、路由规则等等。因此,网关动态配置是保障网关高可用的重要因素。那么,Soul 网关又是如何支持动态配置的呢?

[[284791]]

使用过 Soul 的同学都知道,Soul 的插件全都是热插拔的,并且所有插件的选择器、规则都是动态配置,立即生效,不需要重启服务。但是我们在使用 Soul 网关过程中,用户也反馈了不少问题

  • 依赖 zookeeper,这让使用 etcd、consul、nacos 注册中心的用户很是困扰
  • 依赖 redis、influxdb,我还没有使用限流插件、监控插件,为什么需要这些

因此,我们对 Soul 进行了局部重构,历时两个月的版本迭代,我们发布了 2.0 版本

  • 数据同步方式移除了对 zookeeper 的强依赖,新增 http 长轮询 以及 websocket
  • 限流插件与监控插件实现真正的动态配置,由之前的 yml 配置,改为 admin 后台用户动态配置

1.可能有人会问我,配置同步为什么不使用配置中心呢?

答:首先,引入配置中心,会增加很多额外的成本,不管是运维,而且会让 Soul 变得很重;另外,使用配置中心,数据格式不可控,不便于 soul-admin 进行配置管理。

2.可能还有人会问?动态配置更新?每次我查数据库,或者redis不就行了吗?拿到的就是最新的,哪里那么多事情呢?

答:soul作为网关,为了提供更高的响应速度,所有的配置都缓存在JVM的Map中,每次请求都走的本地缓存,速度非常快。所以本文也可以理解为分布式环境中,内存同步的三种方式。

原理分析

先来张高清无码图,下图展示了 Soul 数据同步的流程,Soul 网关在启动时,会从从配置服务同步配置数据,并且支持推拉模式获取配置变更信息,并且更新本地缓存。而管理员在管理后台,变更用户、规则、插件、流量配置,通过推拉模式将变更信息同步给 Soul 网关,具体是 push 模式,还是 pull 模式取决于配置。关于配置同步模块,其实是一个简版的配置中心。

 

Soul高可用网关配置缓存的三大同步策略详解

 

在 1.x 版本中,配置服务依赖 zookeeper 实现,管理后台将变更信息 push 给网关。而 2.x 版本支持 webosocket、http、zookeeper,通过 soul.sync.strategy 指定对应的同步策略,默认使用 http 长轮询同步策略,可以做到秒级数据同步。但是,有一点需要注意的是,soul-web 和 soul-admin 必须使用相同的同步机制。

  • 如下图所示,soul-admin 在用户发生配置变更之后,会通过 EventPublisher 发出配置变更通知,由 EventDispatcher 处理该变更通知,然后根据配置的同步策略(http、weboscket、zookeeper),将配置发送给对应的事件处理器
  • 如果是 websocket 同步策略,则将变更后的数据主动推送给 soul-web,并且在网关层,会有对应的 WebsocketCacheHandler 处理器处理来处 admin 的数据推送
  • 如果是 zookeeper 同步策略,将变更数据更新到 zookeeper,而 ZookeeperSyncCache 会监听到 zookeeper 的数据变更,并予以处理

如果是 http 同步策略,soul-web 主动发起长轮询请求,默认有 90s 超时时间,如果 soul-admin 没有数据变更,则会阻塞 http 请求,如果有数据发生变更则响应变更的数据信息,如果超过 60s 仍然没有数据变更则响应空数据,网关层接到响应后,继续发起 http 请求,反复同样的请求

 

Soul高可用网关配置缓存的三大同步策略详解

 

zookeeper同步

基于 zookeeper 的同步原理很简单,主要是依赖 zookeeper 的 watch 机制,soul-web 会监听配置的节点,soul-admin 在启动的时候,会将数据全量写入 zookeeper,后续数据发生变更时,会增量更新 zookeeper 的节点,与此同时,soul-web 会监听配置信息的节点,一旦有信息变更时,会更新本地缓存。

 

Soul高可用网关配置缓存的三大同步策略详解

 

soul 将配置信息写到zookeeper节点,是通过精细设计的。

websocket同步

websocket 和 zookeeper 机制有点类似,将网关与 admin 建立好 websocket 连接时,admin 会推送一次全量数据,后续如果配置数据发生变更,则将增量数据通过 websocket 主动推送给 soul-web

使用websocket同步的时候,特别要注意断线重连,也叫保持心跳。soul使用java-websocket 这个第三方库来进行websocket连接。

  1. public class WebsocketSyncCache extends WebsocketCacheHandler { 
  2.  /** 
  3.  * The Client. 
  4.  */ 
  5.  private WebSocketClient client; 
  6.  public WebsocketSyncCache(final SoulConfig.WebsocketConfig websocketConfig) { 
  7.  ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(1, 
  8.  SoulThreadFactory.create("websocket-connect"true)); 
  9.  client = new WebSocketClient(new URI(websocketConfig.getUrl())) { 
  10.  @Override 
  11.  public void onOpen(final ServerHandshake serverHandshake) { 
  12.  //.... 
  13.  } 
  14.  @Override 
  15.  public void onMessage(final String result) { 
  16.  //.... 
  17.  }  
  18.  }; 
  19.  //进行连接 
  20.  client.connectBlocking(); 
  21.  //使用调度线程池进行断线重连,30秒进行一次 
  22.  executor.scheduleAtFixedRate(() -> { 
  23.  if (client != null && client.isClosed()) { 
  24.  client.reconnectBlocking(); 
  25.  } 
  26.  }, 10, 30, TimeUnit.SECONDS); 
  27.  } 

http长轮询

zookeeper、websocket 数据同步的机制比较简单,而 http 同步会相对复杂一些。Soul 借鉴了 Apollo、Nacos 的设计思想,取决精华,自己实现了 http 长轮询数据同步功能。注意,这里并非传统的 ajax 长轮询!

 

Soul高可用网关配置缓存的三大同步策略详解

 

http 长轮询机制如上所示,soul-web 网关请求 admin 的配置服务,读取超时时间为 90s,意味着网关层请求配置服务最多会等待 90s,这样便于 admin 配置服务及时响应变更数据,从而实现准实时推送。

http 请求到达 sou-admin 之后,并非立马响应数据,而是利用 Servlet3.0 的异步机制,异步响应数据。首先,将长轮询请求任务 LongPollingClient 扔到 BlocingQueue 中,并且开启调度任务,60s 后执行,这样做的目的是 60s 后将该长轮询请求移除队列,即便是这段时间内没有发生配置数据变更。因为即便是没有配置变更,也得让网关知道,总不能让其干等吧,而且网关请求配置服务时,也有 90s 的超时时间。

  1. public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) { 
  2.  // 因为soul-web可能未收到某个配置变更的通知,因此MD5值可能不一致,则立即响应 
  3.  List<ConfigGroupEnum> changedGroup = compareMD5(request); 
  4.  String clientIp = getRemoteIp(request); 
  5.  if (CollectionUtils.isNotEmpty(changedGroup)) { 
  6.  this.generateResponse(response, changedGroup); 
  7.  return
  8.  } 
  9.  // Servlet3.0异步响应http请求 
  10.  final AsyncContext asyncContext = request.startAsync(); 
  11.  asyncContext.setTimeout(0L); 
  12.  scheduler.execute(new LongPollingClient(asyncContext, clientIp, 60)); 
  13. class LongPollingClient implements Runnable { 
  14.  LongPollingClient(final AsyncContext ac, final String ip, final long timeoutTime) { 
  15.  // 省略...... 
  16.  } 
  17.  @Override 
  18.  public void run() { 
  19.  // 加入定时任务,如果60s之内没有配置变更,则60s后执行,响应http请求 
  20.  this.asyncTimeoutFuture = scheduler.schedule(() -> { 
  21.  // clients是阻塞队列,保存了来处soul-web的请求信息 
  22.  clients.remove(LongPollingClient.this); 
  23.  List<ConfigGroupEnum> changedGroups = HttpLongPollingDataChangedListener.compareMD5((HttpServletRequest) asyncContext.getRequest()); 
  24.  sendResponse(changedGroups); 
  25.  }, timeoutTime, TimeUnit.MILLISECONDS); 
  26.  //  
  27.  clients.add(this); 
  28.  } 

如果这段时间内,管理员变更了配置数据,此时,会挨个移除队列中的长轮询请求,并响应数据,告知是哪个 Group 的数据发生了变更(我们将插件、规则、流量配置、用户配置数据分成不同的组)。网关收到响应信息之后,只知道是哪个 Group 发生了配置变更,还需要再次请求该 Group 的配置数据。有人会问,为什么不是直接将变更的数据写出?我们在开发的时候,也深入讨论过该问题,因为 http 长轮询机制只能保证准实时,如果在网关层处理不及时,或者管理员频繁更新配置,很有可能便错过了某个配置变更的推送,安全起见,我们只告知某个 Group 信息发生了变更。

  1. // soul-admin发生了配置变更,挨个将队列中的请求移除,并予以响应 
  2. class DataChangeTask implements Runnable { 
  3.  DataChangeTask(final ConfigGroupEnum groupKey) { 
  4.  this.groupKey = groupKey; 
  5.  } 
  6.  @Override 
  7.  public void run() { 
  8.  for (Iterator<LongPollingClient> iter = clients.iterator(); iter.hasNext(); ) { 
  9.  LongPollingClient client = iter.next(); 
  10.  iter.remove(); 
  11.  client.sendResponse(Collections.singletonList(groupKey)); 
  12.  } 
  13.  } 

当 soul-web 网关层接收到 http 响应信息之后,拉取变更信息(如果有变更的话),然后再次请求 soul-admin 的配置服务,如此反复循环。

快速使用

  • get soul-admin.jar
  1. > wget https://yu199195.github.io/jar/soul-admin.jar 
  • start soul-admin.jar
  1. java -jar soul-admin.jar -Dspring.datasource.url="your mysql url"  
  2. -Dspring.datasource.username='you username' -Dspring.datasource.password='you password' 
  • visit : http://localhost:8887/index.html username:admin password :123456
  • get soul-bootstrap.jar
  1. > wget https://yu199195.github.io/jar/soul-bootstrap.jar 
  • start soul-bootstrap.jar
  1. java -jar soul-bootstrap.jar 

仓库地址

github: https://github.com/Dromara/soul

gitee: https://gitee.com/shuaiqiyu/soul

 

责任编辑:武晓燕 来源: 今日头条
相关推荐

2023-04-27 07:52:56

Redis集群模式

2012-11-07 09:41:31

IBMdw

2020-08-27 08:17:05

缓存高并发系统

2021-03-29 11:51:07

缓存储存数据

2019-03-20 09:11:50

Web缓存策略

2019-10-09 16:18:36

缓存架构雪崩

2020-08-30 16:27:30

多云云计算

2018-05-15 10:54:33

NginxRedisEhcache

2019-10-17 09:05:21

MySQL数据库高可用

2010-03-15 09:16:49

高可用虚拟机

2017-03-15 16:15:35

2018-10-23 10:47:03

高并发系统缓存

2018-06-19 08:29:00

2019-08-30 13:00:12

MySQL高可用数据库

2024-03-14 08:57:04

高并发缓存更新

2010-09-17 16:14:22

Java内存分配

2020-08-03 07:00:00

Snowflake数据库性能调优

2022-07-22 20:00:01

高可用路由

2018-04-03 12:35:48

API高可用网关

2015-09-23 09:28:24

点赞
收藏

51CTO技术栈公众号