前言

網(wǎng)關(guān)是流量請求的入口，在微服務(wù)架構(gòu)中承擔(dān)了非常重要的角色，網(wǎng)關(guān)高可用的重要性不言而喻。在使用網(wǎng)關(guān)的過程中，為了滿足業(yè)務(wù)訴求，經(jīng)常需要變更配置，比如流控規(guī)則、路由規(guī)則等等。因此，網(wǎng)關(guān)動(dòng)態(tài)配置是保障網(wǎng)關(guān)高可用的重要因素。那么，Soul 網(wǎng)關(guān)又是如何支持動(dòng)態(tài)配置的呢?

[[284791]]

使用過 Soul 的同學(xué)都知道，Soul 的插件全都是熱插拔的，并且所有插件的選擇器、規(guī)則都是動(dòng)態(tài)配置，立即生效，不需要重啟服務(wù)。但是我們在使用 Soul 網(wǎng)關(guān)過程中，用戶也反饋了不少問題

• 依賴 zookeeper，這讓使用 etcd、consul、nacos 注冊中心的用戶很是困擾
• 依賴 redis、influxdb，我還沒有使用限流插件、監(jiān)控插件，為什么需要這些

因此，我們對 Soul 進(jìn)行了局部重構(gòu)，歷時(shí)兩個(gè)月的版本迭代，我們發(fā)布了 2.0 版本

• 數(shù)據(jù)同步方式移除了對 zookeeper 的強(qiáng)依賴，新增 http 長輪詢 以及 websocket
• 限流插件與監(jiān)控插件實(shí)現(xiàn)真正的動(dòng)態(tài)配置，由之前的 yml 配置，改為 admin 后臺用戶動(dòng)態(tài)配置

1.可能有人會問我，配置同步為什么不使用配置中心呢?

答：首先，引入配置中心，會增加很多額外的成本，不管是運(yùn)維，而且會讓 Soul 變得很重;另外，使用配置中心，數(shù)據(jù)格式不可控，不便于 soul-admin 進(jìn)行配置管理。

2.可能還有人會問?動(dòng)態(tài)配置更新?每次我查數(shù)據(jù)庫，或者redis不就行了嗎?拿到的就是最新的，哪里那么多事情呢?

答：soul作為網(wǎng)關(guān)，為了提供更高的響應(yīng)速度，所有的配置都緩存在JVM的Map中，每次請求都走的本地緩存，速度非?？?。所以本文也可以理解為分布式環(huán)境中，內(nèi)存同步的三種方式。

原理分析

先來張高清無碼圖，下圖展示了 Soul 數(shù)據(jù)同步的流程，Soul 網(wǎng)關(guān)在啟動(dòng)時(shí)，會從從配置服務(wù)同步配置數(shù)據(jù)，并且支持推拉模式獲取配置變更信息，并且更新本地緩存。而管理員在管理后臺，變更用戶、規(guī)則、插件、流量配置，通過推拉模式將變更信息同步給 Soul 網(wǎng)關(guān)，具體是 push 模式，還是 pull 模式取決于配置。關(guān)于配置同步模塊，其實(shí)是一個(gè)簡版的配置中心。

在 1.x 版本中，配置服務(wù)依賴 zookeeper 實(shí)現(xiàn)，管理后臺將變更信息 push 給網(wǎng)關(guān)。而 2.x 版本支持 webosocket、http、zookeeper，通過 soul.sync.strategy 指定對應(yīng)的同步策略，默認(rèn)使用 http 長輪詢同步策略，可以做到秒級數(shù)據(jù)同步。但是，有一點(diǎn)需要注意的是，soul-web 和 soul-admin 必須使用相同的同步機(jī)制。

• 如下圖所示，soul-admin 在用戶發(fā)生配置變更之后，會通過 EventPublisher 發(fā)出配置變更通知，由 EventDispatcher 處理該變更通知，然后根據(jù)配置的同步策略(http、weboscket、zookeeper)，將配置發(fā)送給對應(yīng)的事件處理器
• 如果是 websocket 同步策略，則將變更后的數(shù)據(jù)主動(dòng)推送給 soul-web，并且在網(wǎng)關(guān)層，會有對應(yīng)的 WebsocketCacheHandler 處理器處理來處 admin 的數(shù)據(jù)推送
• 如果是 zookeeper 同步策略，將變更數(shù)據(jù)更新到 zookeeper，而 ZookeeperSyncCache 會監(jiān)聽到 zookeeper 的數(shù)據(jù)變更，并予以處理

如果是 http 同步策略，soul-web 主動(dòng)發(fā)起長輪詢請求，默認(rèn)有 90s 超時(shí)時(shí)間，如果 soul-admin 沒有數(shù)據(jù)變更，則會阻塞 http 請求，如果有數(shù)據(jù)發(fā)生變更則響應(yīng)變更的數(shù)據(jù)信息，如果超過 60s 仍然沒有數(shù)據(jù)變更則響應(yīng)空數(shù)據(jù)，網(wǎng)關(guān)層接到響應(yīng)后，繼續(xù)發(fā)起 http 請求，反復(fù)同樣的請求

zookeeper同步

基于 zookeeper 的同步原理很簡單，主要是依賴 zookeeper 的 watch 機(jī)制，soul-web 會監(jiān)聽配置的節(jié)點(diǎn)，soul-admin 在啟動(dòng)的時(shí)候，會將數(shù)據(jù)全量寫入 zookeeper，后續(xù)數(shù)據(jù)發(fā)生變更時(shí)，會增量更新 zookeeper 的節(jié)點(diǎn)，與此同時(shí)，soul-web 會監(jiān)聽配置信息的節(jié)點(diǎn)，一旦有信息變更時(shí)，會更新本地緩存。

soul 將配置信息寫到zookeeper節(jié)點(diǎn)，是通過精細(xì)設(shè)計(jì)的。

websocket同步

websocket 和 zookeeper 機(jī)制有點(diǎn)類似，將網(wǎng)關(guān)與 admin 建立好 websocket 連接時(shí)，admin 會推送一次全量數(shù)據(jù)，后續(xù)如果配置數(shù)據(jù)發(fā)生變更，則將增量數(shù)據(jù)通過 websocket 主動(dòng)推送給 soul-web

使用websocket同步的時(shí)候，特別要注意斷線重連，也叫保持心跳。soul使用java-websocket 這個(gè)第三方庫來進(jìn)行websocket連接。

public class WebsocketSyncCache extends WebsocketCacheHandler { 
 /** 
 * The Client. 
 */ 
 private WebSocketClient client; 
 public WebsocketSyncCache(final SoulConfig.WebsocketConfig websocketConfig) { 
 ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(1, 
 SoulThreadFactory.create("websocket-connect", true)); 
 client = new WebSocketClient(new URI(websocketConfig.getUrl())) { 
 @Override 
 public void onOpen(final ServerHandshake serverHandshake) { 
 //.... 
 } 
 @Override 
 public void onMessage(final String result) { 
 //.... 
 }  
 }; 
 //進(jìn)行連接 
 client.connectBlocking(); 
 //使用調(diào)度線程池進(jìn)行斷線重連，30秒進(jìn)行一次 
 executor.scheduleAtFixedRate(() -> { 
 if (client != null && client.isClosed()) { 
 client.reconnectBlocking(); 
 } 
 }, 10, 30, TimeUnit.SECONDS); 
 } 

http長輪詢

zookeeper、websocket 數(shù)據(jù)同步的機(jī)制比較簡單，而 http 同步會相對復(fù)雜一些。Soul 借鑒了 Apollo、Nacos 的設(shè)計(jì)思想，取決精華，自己實(shí)現(xiàn)了 http 長輪詢數(shù)據(jù)同步功能。注意，這里并非傳統(tǒng)的 ajax 長輪詢!

http 長輪詢機(jī)制如上所示，soul-web 網(wǎng)關(guān)請求 admin 的配置服務(wù)，讀取超時(shí)時(shí)間為 90s，意味著網(wǎng)關(guān)層請求配置服務(wù)最多會等待 90s，這樣便于 admin 配置服務(wù)及時(shí)響應(yīng)變更數(shù)據(jù)，從而實(shí)現(xiàn)準(zhǔn)實(shí)時(shí)推送。

http 請求到達(dá) sou-admin 之后，并非立馬響應(yīng)數(shù)據(jù)，而是利用 Servlet3.0 的異步機(jī)制，異步響應(yīng)數(shù)據(jù)。首先，將長輪詢請求任務(wù) LongPollingClient 扔到 BlocingQueue 中，并且開啟調(diào)度任務(wù)，60s 后執(zhí)行，這樣做的目的是 60s 后將該長輪詢請求移除隊(duì)列，即便是這段時(shí)間內(nèi)沒有發(fā)生配置數(shù)據(jù)變更。因?yàn)榧幢闶菦]有配置變更，也得讓網(wǎng)關(guān)知道，總不能讓其干等吧，而且網(wǎng)關(guān)請求配置服務(wù)時(shí)，也有 90s 的超時(shí)時(shí)間。

public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) { 
 // 因?yàn)閟oul-web可能未收到某個(gè)配置變更的通知，因此MD5值可能不一致，則立即響應(yīng) 
 List<ConfigGroupEnum> changedGroup = compareMD5(request); 
 String clientIp = getRemoteIp(request); 
 if (CollectionUtils.isNotEmpty(changedGroup)) { 
 this.generateResponse(response, changedGroup); 
 return; 
 } 
 // Servlet3.0異步響應(yīng)http請求 
 final AsyncContext asyncContext = request.startAsync(); 
 asyncContext.setTimeout(0L); 
 scheduler.execute(new LongPollingClient(asyncContext, clientIp, 60)); 
} 
class LongPollingClient implements Runnable { 
 LongPollingClient(final AsyncContext ac, final String ip, final long timeoutTime) { 
 // 省略...... 
 } 
 @Override 
 public void run() { 
 // 加入定時(shí)任務(wù)，如果60s之內(nèi)沒有配置變更，則60s后執(zhí)行，響應(yīng)http請求 
 this.asyncTimeoutFuture = scheduler.schedule(() -> { 
 // clients是阻塞隊(duì)列，保存了來處soul-web的請求信息 
 clients.remove(LongPollingClient.this); 
 List<ConfigGroupEnum> changedGroups = HttpLongPollingDataChangedListener.compareMD5((HttpServletRequest) asyncContext.getRequest()); 
 sendResponse(changedGroups); 
 }, timeoutTime, TimeUnit.MILLISECONDS); 
 //  
 clients.add(this); 
 } 
} 

如果這段時(shí)間內(nèi)，管理員變更了配置數(shù)據(jù)，此時(shí)，會挨個(gè)移除隊(duì)列中的長輪詢請求，并響應(yīng)數(shù)據(jù)，告知是哪個(gè) Group 的數(shù)據(jù)發(fā)生了變更(我們將插件、規(guī)則、流量配置、用戶配置數(shù)據(jù)分成不同的組)。網(wǎng)關(guān)收到響應(yīng)信息之后，只知道是哪個(gè) Group 發(fā)生了配置變更，還需要再次請求該 Group 的配置數(shù)據(jù)。有人會問，為什么不是直接將變更的數(shù)據(jù)寫出?我們在開發(fā)的時(shí)候，也深入討論過該問題，因?yàn)?http 長輪詢機(jī)制只能保證準(zhǔn)實(shí)時(shí)，如果在網(wǎng)關(guān)層處理不及時(shí)，或者管理員頻繁更新配置，很有可能便錯(cuò)過了某個(gè)配置變更的推送，安全起見，我們只告知某個(gè) Group 信息發(fā)生了變更。

// soul-admin發(fā)生了配置變更，挨個(gè)將隊(duì)列中的請求移除，并予以響應(yīng) 
class DataChangeTask implements Runnable { 
 DataChangeTask(final ConfigGroupEnum groupKey) { 
 this.groupKey = groupKey; 
 } 
 @Override 
 public void run() { 
 for (Iterator<LongPollingClient> iter = clients.iterator(); iter.hasNext(); ) { 
 LongPollingClient client = iter.next(); 
 iter.remove(); 
 client.sendResponse(Collections.singletonList(groupKey)); 
 } 
 } 
} 

當(dāng) soul-web 網(wǎng)關(guān)層接收到 http 響應(yīng)信息之后，拉取變更信息(如果有變更的話)，然后再次請求 soul-admin 的配置服務(wù)，如此反復(fù)循環(huán)。

快速使用

• get soul-admin.jar

> wget https://yu199195.github.io/jar/soul-admin.jar 

• start soul-admin.jar

java -jar soul-admin.jar -Dspring.datasource.url="your mysql url"  
-Dspring.datasource.username='you username' -Dspring.datasource.password='you password' 

• visit : http://localhost:8887/index.html username:admin password :123456
• get soul-bootstrap.jar

> wget https://yu199195.github.io/jar/soul-bootstrap.jar 

• start soul-bootstrap.jar

java -jar soul-bootstrap.jar 

倉庫地址

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

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