本文主要講解 bootstrap 端啟動后數(shù)據(jù)的同步和更新時的同步流程。上文講解到 admin 端啟動時主要的幾個步驟，那么 bootstrap 端再啟動后，admin 端又做了哪些操作呢？

啟動 bootstrap

從上文的日志文件中，可以看到 bootstrap 啟動時做了幾件事情:

• 配置了 http long pull 的同步方式
• 請求配置: requst config
• 清除所有緩存: clear all XX cache
• 獲取最新的配置信息

代碼出發(fā)

第一步映入眼簾的便是 : HttpSyncDataConfiguration, 在該 方法中，注冊了 HttpSyncDataService 的 Bean。 進入到 HttpSyncDataService 的構造方法中, 調(diào)用了 start() 方法

  private void start() {
        // It could be initialized multiple times, so you need to control that.
       // 這里有個疑問：為什么會有 cas 的操作， start 直接注冊到 bean 。 
        if (RUNNING.compareAndSet(false, true)) {
            // 同步所有設置
            this.fetchGroupConfig(ConfigGroupEnum.values());
            // 下面都是申請資源
            ... 
        } else {
            log.info("soul http long polling was started, executor=[{}]", executor);
        }
    }

進入 fetchGroup 中，核心的方法 doFetchGroupConfig， 將所有的配置組合成一個參數(shù)傳遞到 Admin 端，請求接口為
"/configs/fetch?" ，進入 admin 跟蹤這個鏈路。

在 ConfigController#fetchConfigs 方法中，映射了 "/configs/fetch" 這個路徑， 跟蹤到 fetchConfig 時，主要是從之前 admin 端啟動后緩存到內(nèi)存中的數(shù)據(jù)。

public ConfigData<?> fetchConfig(final ConfigGroupEnum groupKey) {
        ConfigDataCache config = CACHE.get(groupKey.name());
        switch (groupKey) {
            case APP_AUTH:
                List<AppAuthData> appAuthList = GsonUtils.getGson().fromJson(config.getJson(), new TypeToken<List<AppAuthData>>() {
                }.getType());
                return new ConfigData<>(config.getMd5(), config.getLastModifyTime(), appAuthList);
         }
        ...
    }

回到 bootstrap 中，繼續(xù)往下走, 執(zhí)行到： this.executor.execute(new HttpLongPollingTask(server))); 中時，會有長輪詢的任務開始執(zhí)行。進入 run 中，主要方式是 doLongPolling(), 進入 doLongPolling() 。 有發(fā)送 Post 的 ”/configs/listener", 但是這是并沒有立即返回，而是在差不多一分鐘左右返回。

2021-01-30 07:14:31.876  INFO 43588 --- [-long-polling-1] o.d.s.s.data.http.HttpSyncDataService    : request listener configs: [http://localhost:9095/configs/listener]
...
2021-01-30 07:15:40.015  INFO 43588 --- [-long-polling-1] o.d.s.s.data.http.HttpSyncDataService    : listener result: [{"code":200,"message":"success","data":[]}

這時又得進入 admin 端一探究竟。進入 HttpLongPollingDataChangedListener 中， doLongPolling 為主要核心邏輯。

public void doLongPolling(final HttpServletRequest request, final HttpServletResponse response) {

       // 比較 md5 是否一致
        List<ConfigGroupEnum> changedGroup = compareChangedGroup(request);
        String clientIp = getRemoteIp(request);

        // 有變化立即返回
        if (CollectionUtils.isNotEmpty(changedGroup)) {
            this.generateResponse(response, changedGroup);
            log.info("send response with the changed group, ip={}, group={}", clientIp, changedGroup);
            return;
        }

        // 啟動異步返回
        final AsyncContext asyncContext = request.startAsync();

        // AsyncContext.settimeout() does not timeout properly, so you have to control it yourself
        asyncContext.setTimeout(0L);

        // SERVER_MAX_HOLD_TIMEOUT = 60s,  60s 后返回。
        scheduler.execute(new LongPollingClient(asyncContext, clientIp, HttpConstants.SERVER_MAX_HOLD_TIMEOUT));
    }

class LongPollingClient implements Runnable {
    ...
        @Override
        public void run() {
            this.asyncTimeoutFuture = scheduler.schedule(() -> {
                clients.remove(LongPollingClient.this);
                List<ConfigGroupEnum> changedGroups = compareChangedGroup((HttpServletRequest) asyncContext.getRequest());
                sendResponse(changedGroups);
            }, timeoutTime, TimeUnit.MILLISECONDS);
            clients.add(this);
        }
...
}

接著又回到 bootstrap 端，這里需要將 HttpSyncDataService#doLongPolling 中日志 debug 更改成 info，

log.debug("request listener configs: [{}]", listenerUrl)  => log.info("request listener configs: [{}]", listenerUrl);
log.debug("listener result: [{}]", json) =>  blog.info("listener result: [{}]", json);

便能得到以下日志：

image.png

總結(jié)

1. 正常流程已經(jīng)斷斷續(xù)續(xù)的更完了，那異常流程還沒有。正常流程的流程圖：

大致流程圖

2. 多個 admin 實例的情況該怎么做。接下來會繼續(xù)更新。