一、問題背景

設(shè)想，打開一個(gè) APP，我們會(huì)看到什么？答案是： 內(nèi)容信息 。

例如當(dāng)我們打開轉(zhuǎn)轉(zhuǎn) APP 時(shí)，目光所及的首頁、商品列表頁、商品詳情頁...以上我們簡稱為信息聚合場景。在電商 APP 中，此類信息聚合場景往往需要 聚合 多種數(shù)據(jù)源才能完成最終渲染，這也意味著在微服務(wù)架構(gòu)中，服務(wù)端響應(yīng)一次用戶請求需要聚合 N 個(gè)內(nèi)部 RPC 請求響應(yīng)的數(shù)據(jù)才能完成最終響應(yīng)。

而為了盡快響應(yīng)用戶請求，往往需要通過某些方式異步發(fā)起多個(gè) RPC 請求來獲取結(jié)果數(shù)據(jù)，我們把這樣的過程稱為并發(fā)場景。

二、復(fù)雜并發(fā)場景釋義

2.1 簡單并發(fā)場景

較為 簡單 的信息聚合場景，一次信息聚合過程只需要 N 個(gè) 相互獨(dú)立 的 RPC 結(jié)果即可。如下圖所示：

2.2 復(fù)雜并發(fā)場景

較為 復(fù)雜 ，但卻常見的重要信息聚合場景。通常意味著響應(yīng)一次用戶請求的過程：1，需要聚合多個(gè) RPC 響應(yīng)結(jié)果；2，內(nèi)部多個(gè) RPC 請求之間 存在相互依賴關(guān)系 ，如下圖所示：D 的 request 依賴 A、B 的 response；E 的 request 依賴 C、D 的 response；...

三、分組并發(fā)調(diào)度模型演進(jìn)

3.1 簡單異步并發(fā)調(diào)度

為了盡量提升服務(wù)端的請求響應(yīng)速度，我們可以有一些簡單的方式，如：

基于 Future 等基礎(chǔ)能力，在一次用戶請求的處理過程中，異步執(zhí)行沒有前后依賴關(guān)系的 RPC 過程。

這種方式通常更 適用于簡單并發(fā)場景 ，而復(fù)雜并發(fā)場景下怎么辦呢？

自然而然，我們很容易想到一個(gè)方式：分組并發(fā)調(diào)度。

3.2 分組并發(fā)調(diào)度

分組并發(fā)調(diào)度主要適用于一次用戶請求處理過程需要聚合多個(gè)存在前后依賴關(guān)系的 RPC 查詢結(jié)果的復(fù)雜并發(fā)場景中，通常我們會(huì)使用如下方案：

1， 分組 ：將所有 RPC 查詢過程按照依賴關(guān)系分組。如：沒有前置依賴的 RPC 過程認(rèn)為是第一組；依賴第一組的 RPC 過程認(rèn)為是第二組；依此類推...

2， 調(diào)度 ：基于 CompleteFuture、Future 等基礎(chǔ)能力，依次從第一組開始并發(fā)執(zhí)行組內(nèi)的 RPC 過程。即：組間同步、組內(nèi)異步。

為了提升開發(fā)效率，我們可以基于 Future 等基礎(chǔ)能力重新封裝自己的分組并發(fā)調(diào)度工具，甚至集成并發(fā)治理等方面的能力，如：細(xì)粒度的超時(shí)調(diào)控、熔斷降級機(jī)制，以大幅度降低治理工作成本。

四、自驅(qū)動(dòng)并發(fā)調(diào)度模型演進(jìn)

4.1 一個(gè)優(yōu)化耗時(shí)的小目標(biāo)及其實(shí)現(xiàn)

在 2020 年 Q2，轉(zhuǎn)轉(zhuǎn)基礎(chǔ)生態(tài)有這么一個(gè) OKR：實(shí)現(xiàn)全平臺(tái)核心接口平均耗時(shí)穩(wěn)定降低到 90ms 以下。不可忽略的背景是彼時(shí)接口耗時(shí)在 120ms 上下，且受下游服務(wù)方影響，每周呈現(xiàn) 10ms 的上漲趨勢。為了完成這個(gè)不太可能的目標(biāo)，我們做了 這些事情 ：

1.分析接口單位貢獻(xiàn)值 ：主要根據(jù)接口 QPS，分別分析單接口每降低 10ms 的響應(yīng)時(shí)間對全局響應(yīng)的貢獻(xiàn)值，確定優(yōu)化方向。

2.理解每一毫秒的耗時(shí) ：假設(shè)從監(jiān)控平臺(tái)我們可以看到某個(gè)接口耗時(shí)為 200ms，但具體耗時(shí)在哪是不明確的。為此，我們在每個(gè)接口的內(nèi)部執(zhí)行邏輯，從代碼行的維度監(jiān)測耗時(shí)，嘗試去完全理解每一毫秒。

3.并發(fā)調(diào)度調(diào)整 ：基于上述準(zhǔn)備，進(jìn)行接口耗時(shí)優(yōu)化。期間我們發(fā)現(xiàn)嚴(yán)格的分組并發(fā)調(diào)度模型并不能達(dá)到最佳調(diào)度，為此我們又破壞了原本的分組模型，將一些沒有前后依賴的長耗時(shí) RPC 過程單獨(dú)提取出來做全局異步調(diào)度。

在 Q2 結(jié)束，全平臺(tái)核心接口平均耗時(shí)降低到 85ms，超額完成了既定目標(biāo)。

4.2 下一步的疑惑

隨著耗時(shí)優(yōu)化目標(biāo)的完成，我們產(chǎn)生了一些這樣的疑惑：

1.開發(fā)維護(hù)工作依舊 繁瑣 ：復(fù)雜并發(fā)場景中，隨著業(yè)務(wù)迭代，代碼腐化嚴(yán)重。一個(gè)小需求的迭代可能需要太多的前置熟悉代碼的時(shí)間。

2.接口耗時(shí)優(yōu)化工作 周而復(fù)始 ：回想過去，每到一定的時(shí)間（例如一兩周、一兩個(gè)月），需要花費(fèi)時(shí)間去調(diào)整并發(fā)模型，優(yōu)化組織分組邏輯以盡可能消除業(yè)務(wù)迭代帶來的影響。

3.分組并發(fā)調(diào)度模型的 折中 ：結(jié)合上述目標(biāo)的完成過程，我們?yōu)榱诵阅芏鴳?yīng)用分組并發(fā)調(diào)度模型后又為了性能破壞既定模型。

信息聚合場景的接口耗時(shí)優(yōu)化，

下一步該怎么做？

4.3 對問題的重新思考以及自驅(qū)動(dòng)并發(fā)調(diào)度模型的誕生

4.3.1 重新思考

回想以往，我們做的是什么？不外乎：編織一幅圖。

上圖示意一次用戶請求（如商品列表頁搜索）的內(nèi)部 RPC 聚合過程，一個(gè)最簡單的聚合節(jié)點(diǎn)等同于一次 RPC 請求過程。

回首我們的開發(fā)工作，會(huì)發(fā)現(xiàn)做的事情其實(shí)是：

1. 畫點(diǎn) ：例如商列需要展示活動(dòng)信息，此時(shí)就會(huì)新增一個(gè)查詢活動(dòng)信息的 RPC 聚合節(jié)點(diǎn)。

2.連線 ：我們依據(jù)依賴關(guān)系將可以同時(shí)并發(fā)查詢的節(jié)點(diǎn)放置于同一組。

3.畫圖 ：組織各組的并發(fā)調(diào)度、數(shù)據(jù)同步、并串行驅(qū)動(dòng)下一組。

整個(gè)過程概括起來就是： 點(diǎn)動(dòng)成線，線動(dòng)成面 。 可能這正是對復(fù)雜并發(fā)場景下一系列表面問題背后的 更深層

的一種描述。

4.3.2 自驅(qū)動(dòng)并發(fā)調(diào)度模型

基于以上思考，可以發(fā)現(xiàn)在業(yè)務(wù)開發(fā)中：

1.業(yè)務(wù)邏輯強(qiáng)相關(guān)的增量邏輯在于 “點(diǎn)” 。

2.業(yè)務(wù)邏輯弱相關(guān)的重復(fù)工作成本在于 “連線” 、在于 “圖的編織” 。

那么，有沒有一種可能：開發(fā)者僅僅關(guān)心“點(diǎn)”，由額外的框架能力來處理“線”與“圖”？

即是“點(diǎn)動(dòng)成線，線動(dòng)成面”中 “動(dòng)”的工作由框架能力自動(dòng)化支持。

于是，自驅(qū)動(dòng)并發(fā)調(diào)度模型基于此愿景而誕生，整體設(shè)計(jì)方向如下：

1.開發(fā)模式的聚焦：實(shí)現(xiàn)面向節(jié)點(diǎn)行為的開發(fā)方式

2.框架能力的聚焦：框架聚焦于任意兩點(diǎn)之間的自動(dòng)化連線能力，從而實(shí)現(xiàn)全圖的自動(dòng)編織。

五、結(jié)語

本文的講述側(cè)重于并發(fā)調(diào)度模型演進(jìn)的思考過程，講述了基于對問題的理解再理解的探索過程去尋找當(dāng)前最佳解決方案的思路，也是轉(zhuǎn)轉(zhuǎn)公司復(fù)仇者聯(lián)盟技術(shù)生態(tài)系列之奧創(chuàng)組件的由來。