?微服務(wù)分層架構(gòu)，之前聊得很多了，微服務(wù)離不開RPC框架，RPC框架的原理、實踐及細(xì)節(jié)，今天和大家聊一聊。

文章較長，1萬字左右，建議提前收藏。

?服務(wù)化有什么好處？

服務(wù)化的一個好處就是，不限定服務(wù)的提供方使用什么技術(shù)選型，能夠?qū)崿F(xiàn)大公司跨團隊的技術(shù)解耦，如下圖所示：

• 服務(wù)A：歐洲團隊維護，技術(shù)背景是Java；
• 服務(wù)B：美洲團隊維護，用C++實現(xiàn)；
• 服務(wù)C：中國團隊維護，技術(shù)棧是go；

服務(wù)的上游調(diào)用方，按照接口、協(xié)議即可完成對遠(yuǎn)端服務(wù)的調(diào)用。

但實際上，大部分互聯(lián)網(wǎng)公司，研發(fā)團隊規(guī)模有限，大都使用同一套技術(shù)體系來實現(xiàn)服務(wù)：

這樣的話，如果沒有統(tǒng)一的服務(wù)框架，各個團隊的服務(wù)提供方就需要各自實現(xiàn)一套序列化、反序列化、網(wǎng)絡(luò)框架、連接池、收發(fā)線程、超時處理、狀態(tài)機等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動，造成整體的低效。

因此，統(tǒng)一服務(wù)框架把上述“業(yè)務(wù)之外”的工作統(tǒng)一實現(xiàn)，是服務(wù)化首要解決的問題。

什么是RPC？

Remote Procedure Call Protocol，遠(yuǎn)程過程調(diào)用。

什么是“遠(yuǎn)程”，為什么“遠(yuǎn)”？

先來看下什么是“近”，即“本地函數(shù)調(diào)用”。

當(dāng)我們寫下：

int result = Add(1, 2);

這行代碼的時候，到底發(fā)生了什么？

• 傳遞兩個入?yún)ⅲ?/li>
• 調(diào)用了本地代碼段中的函數(shù)，執(zhí)行運算邏輯；
• 返回一個出參；

這三個動作，都發(fā)生在同一個進程空間里，這是本地函數(shù)調(diào)用。

那有沒有辦法，調(diào)用一個跨進程的函數(shù)呢？

典型的，這個進程部署在另一臺服務(wù)器上。

最容易想到的，兩個進程約定一個協(xié)議格式，使用Socket通信，來傳輸：

• 入?yún)ⅲ?/li>
• 調(diào)用哪個函數(shù)；
• 出參；如果能夠?qū)崿F(xiàn)，那這就是“遠(yuǎn)程”過程調(diào)用。

Socket通信只能傳遞連續(xù)的字節(jié)流，如何將入?yún)?、函?shù)都放到連續(xù)的字節(jié)流里呢？

假設(shè)，設(shè)計一個11字節(jié)的請求報文：

• 前3個字節(jié)填入函數(shù)名“add”；
• 中間4個字節(jié)填入第一個參數(shù)“1”；
• 末尾4個字節(jié)填入第二個參數(shù)“2”；

同理，可以設(shè)計一個4字節(jié)響應(yīng)報文：

4個字節(jié)填入處理結(jié)果“3”；

調(diào)用方的代碼可能變?yōu)椋?/p>

request = MakePacket(“add”, 1, 2);
SendRequest_ToService_B(request);
response = RecieveRespnse_FromService_B();
int result = unMakePacket(respnse);

這4個步驟是：

• 將傳入?yún)?shù)變?yōu)樽止?jié)流；
• 將字節(jié)流發(fā)給服務(wù)B；
• 從服務(wù)B接受返回字節(jié)流；
• 將返回字節(jié)流變?yōu)閭鞒鰠?shù)；

服務(wù)方的代碼可能變?yōu)椋?/p>

request = RecieveRequest();
args/function = unMakePacket(request);
result = Add(1, 2);
response = MakePacket(result);
SendResponse(response);

這個5個步驟也很好理解：

• 服務(wù)端收到字節(jié)流；
• 將字節(jié)流轉(zhuǎn)為函數(shù)名與參數(shù)；
• 本地調(diào)用函數(shù)得到結(jié)果；
• 將結(jié)果轉(zhuǎn)變?yōu)樽止?jié)流；
• 將字節(jié)流發(fā)送給調(diào)用方；

這個過程用一張圖描述如下：

調(diào)用方與服務(wù)方的處理步驟都是非常清晰。

這個過程存在最大的問題是什么呢？

調(diào)用方太麻煩了，每次都要關(guān)注很多底層細(xì)節(jié)：

• 入?yún)⒌阶止?jié)流的轉(zhuǎn)化，即序列化應(yīng)用層協(xié)議細(xì)節(jié)；
• socket發(fā)送，即網(wǎng)絡(luò)傳輸協(xié)議細(xì)節(jié)；
• socket接收；
• 字節(jié)流到出參的轉(zhuǎn)化，即反序列化應(yīng)用層協(xié)議細(xì)節(jié)；

能不能調(diào)用層不關(guān)注這個細(xì)節(jié)？

可以，RPC框架就是解決這個問題的，它能夠讓調(diào)用方“像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端的函數(shù)（服務(wù)）”。

講到這里，是不是對RPC，對序列化范序列化有點感覺了？往下看，有更多的底層細(xì)節(jié)。

RPC框架的職責(zé)是什么？

RPC框架，要向調(diào)用方屏蔽各種復(fù)雜性，要向服務(wù)提供方也屏蔽各類復(fù)雜性：

• 服務(wù)調(diào)用方client感覺就像調(diào)用本地函數(shù)一樣，來調(diào)用服務(wù)；
• 服務(wù)提供方server感覺就像實現(xiàn)一個本地函數(shù)一樣，來實現(xiàn)服務(wù)；

所以整個RPC框架又分為client部分與server部分，實現(xiàn)上面的目標(biāo)，把復(fù)雜性屏蔽，就是RPC框架的職責(zé)。

如上圖所示，業(yè)務(wù)方的職責(zé)是：

• 調(diào)用方A，傳入?yún)?shù)，執(zhí)行調(diào)用，拿到結(jié)果；
• 服務(wù)方B，收到參數(shù)，執(zhí)行邏輯，返回結(jié)果；

RPC框架的職責(zé)是，中間大藍(lán)框的部分：

• client端：序列化、反序列化、連接池管理、負(fù)載均衡、故障轉(zhuǎn)移、隊列管理，超時管理、異步管理等等；
• server端：服務(wù)端組件、服務(wù)端收發(fā)包隊列、io線程、工作線程、序列化反序列化等；

server端的技術(shù)大家了解的比較多，接下來重點講講client端的技術(shù)細(xì)節(jié)。

先來看看RPC-client部分的“序列化反序列化”部分。

為什么要進行序列化？

工程師通常使用“對象”來進行數(shù)據(jù)的操縱：

class User{
         std::String user_name;
         uint64_t user_id;
         uint32_t user_age;
}; 

User u = new User(“shenjian”);
u.setUid(123);
u.setAge(35);

但當(dāng)需要對數(shù)據(jù)進行存儲或者傳輸時，“對象”就不這么好用了，往往需要把數(shù)據(jù)轉(zhuǎn)化成連續(xù)空間的“二進制字節(jié)流”，一些典型的場景是：

• 數(shù)據(jù)庫索引的磁盤存儲：數(shù)據(jù)庫的索引在內(nèi)存里是b+樹，但這個格式是不能夠直接存儲到磁盤上的，所以需要把b+樹轉(zhuǎn)化為連續(xù)空間的二進制字節(jié)流，才能存儲到磁盤上；
• 緩存的KV存儲：redis/memcache是KV類型的緩存，緩存存儲的value必須是連續(xù)空間的二進制字節(jié)流，而不能夠是User對象；
• 數(shù)據(jù)的網(wǎng)絡(luò)傳輸：socket發(fā)送的數(shù)據(jù)必須是連續(xù)空間的二進制字節(jié)流，也不能是對象；

所謂序列化（Serialization），就是將“對象”形態(tài)的數(shù)據(jù)轉(zhuǎn)化為“連續(xù)空間二進制字節(jié)流”形態(tài)數(shù)據(jù)的過程。這個過程的逆過程叫做反序列化。

怎么進行序列化？

這是一個非常細(xì)節(jié)的問題，要是讓你來把“對象”轉(zhuǎn)化為字節(jié)流，你會怎么做？很容易想到的一個方法是xml（或者json）這類具有自描述特性的標(biāo)記性語言：

<class name=”User”>

<element name=”user_name” type=”std::String” value=”shenjian” />

<element name=”user_id” type=”uint64_t” value=”123” />

<element name=”user_age” type=”uint32_t” value=”35” />

</class>

規(guī)定好轉(zhuǎn)換規(guī)則，發(fā)送方很容易把User類的一個對象序列化為xml，服務(wù)方收到xml二進制流之后，也很容易將其范序列化為User對象。

畫外音：語言支持反射時，這個工作很容易。

第二個方法是自己實現(xiàn)二進制協(xié)議來進行序列化，還是以上面的User對象為例，可以設(shè)計一個這樣的通用協(xié)議：

• 頭4個字節(jié)表示序號；
• 序號后面的4個字節(jié)表示key的長度m；
• 接下來的m個字節(jié)表示key的值；
• 接下來的4個字節(jié)表示value的長度n；
• 接下來的n個字節(jié)表示value的值；
• 像xml一樣遞歸下去，直到描述完整個對象；

上面的User對象，用這個協(xié)議描述出來可能是這樣的：

• 第一行：序號4個字節(jié)（設(shè)0表示類名），類名長度4個字節(jié)（長度為4），接下來4個字節(jié)是類名（”User”），共12字節(jié)；
• 第二行：序號4個字節(jié)（1表示第一個屬性），屬性長度4個字節(jié)（長度為9），接下來9個字節(jié)是屬性名（”user_name”），屬性值長度4個字節(jié)（長度為8），屬性值8個字節(jié)（值為”shenjian”），共29字節(jié)；
• 第三行：序號4個字節(jié)（2表示第二個屬性），屬性長度4個字節(jié)（長度為7），接下來7個字節(jié)是屬性名（”user_id”），屬性值長度4個字節(jié)（長度為8），屬性值8個字節(jié)（值為123），共27字節(jié)；
• 第四行：序號4個字節(jié)（3表示第三個屬性），屬性長度4個字節(jié)（長度為8），接下來8個字節(jié)是屬性名（”user_name”），屬性值長度4個字節(jié)（長度為4），屬性值4個字節(jié)（值為35），共24字節(jié)；

整個二進制字節(jié)流共12+29+27+24=92字節(jié)。

實際的序列化協(xié)議要考慮的細(xì)節(jié)遠(yuǎn)比這個多，例如：強類型的語言不僅要還原屬性名，屬性值，還要還原屬性類型；復(fù)雜的對象不僅要考慮普通類型，還要考慮對象嵌套類型等。無論如何，序列化的思路都是類似的。

序列化協(xié)議要考慮什么因素？

不管使用成熟協(xié)議xml/json，還是自定義二進制協(xié)議來序列化對象，序列化協(xié)議設(shè)計時都需要考慮以下這些因素：

• 解析效率：這個應(yīng)該是序列化協(xié)議應(yīng)該首要考慮的因素，像xml/json解析起來比較耗時，需要解析doom樹，二進制自定義協(xié)議解析起來效率就很高；
• 壓縮率，傳輸有效性：同樣一個對象，xml/json傳輸起來有大量的xml標(biāo)簽，信息有效性低，二進制自定義協(xié)議占用的空間相對來說就小多了；
• 擴展性與兼容性：是否能夠方便的增加字段，增加字段后舊版客戶端是否需要強制升級，都是需要考慮的問題，xml/json和上面的二進制協(xié)議都能夠方便的擴展；
• 可讀性與可調(diào)試性：這個很好理解，xml/json的可讀性就比二進制協(xié)議好很多；
• 跨語言：上面的兩個協(xié)議都是跨語言的，有些序列化協(xié)議是與開發(fā)語言緊密相關(guān)的，例如dubbo的序列化協(xié)議就只能支持Java的RPC調(diào)用；
• 通用性：xml/json非常通用，都有很好的第三方解析庫，各個語言解析起來都十分方便，上面自定義的二進制協(xié)議雖然能夠跨語言，但每個語言都要寫一個簡易的協(xié)議客戶端；

有哪些常見的序列化方式？

• xml/json：解析效率，壓縮率都較差，擴展性、可讀性、通用性較好；
• thrift；
• protobuf：Google出品，必屬精品，各方面都不錯，強烈推薦，屬于二進制協(xié)議，可讀性差了點，但也有類似的to-string協(xié)議幫助調(diào)試問題；
• Avro；
• CORBA；
• mc_pack：懂的同學(xué)就懂，不懂的就不懂了，09年用過，傳說各方面都超越protobuf，懂行的同學(xué)可以說一下現(xiàn)狀；
• …

RPC-client除了序列化反序列化的部分（上圖中的1、4），還包含發(fā)送字節(jié)流與接收字節(jié)流的部分（上圖中的2、3）這一部分，又分為同步調(diào)用與異步調(diào)用兩種方式，下面一一來進行介紹。

畫外音：搞通透RPC-client確實不容易。

同步調(diào)用的代碼片段為：

Result = Add(Obj1, Obj2);// 得到Result之前處于阻塞狀態(tài)

異步調(diào)用的代碼片段為：

Add(Obj1, Obj2, callback);// 調(diào)用后直接返回，不等結(jié)果

處理結(jié)果通過回調(diào)為：

callback(Result){// 得到處理結(jié)果后會調(diào)用這個回調(diào)函數(shù)
         …
}

這兩類調(diào)用，在RPC-client里，實現(xiàn)方式完全不一樣。

RPC-client同步調(diào)用架構(gòu)如何？

所謂同步調(diào)用，在得到結(jié)果之前，一直處于阻塞狀態(tài)，會一直占用一個工作線程，上圖簡單的說明了一下組件、交互、流程步驟：

• 左邊大框，代表了調(diào)用方的一個工作線程
• 左邊粉色中框，代表了RPC-client組件
• 右邊橙色框，代表了RPC-server
• 藍(lán)色兩個小框，代表了同步RPC-client兩個核心組件，序列化組件與連接池組件
• 白色的流程小框，以及箭頭序號1-10，代表整個工作線程的串行執(zhí)行步驟：

1）業(yè)務(wù)代碼發(fā)起RPC調(diào)用：

Result=Add(Obj1,Obj2)

2）序列化組件，將對象調(diào)用序列化成二進制字節(jié)流，可理解為一個待發(fā)送的包packet1；

3）通過連接池組件拿到一個可用的連接connection；

4）通過連接connection將包packet1發(fā)送給RPC-server；

5）發(fā)送包在網(wǎng)絡(luò)傳輸，發(fā)給RPC-server；

6）響應(yīng)包在網(wǎng)絡(luò)傳輸，發(fā)回給RPC-client；

7）通過連接connection從RPC-server收取響應(yīng)包packet2；

8）通過連接池組件，將conneciont放回連接池；

9）序列化組件，將packet2范序列化為Result對象返回給調(diào)用方；

10）業(yè)務(wù)代碼獲取Result結(jié)果，工作線程繼續(xù)往下走；

畫外音：請對照架構(gòu)圖中的1-10步驟閱讀。

連接池組件有什么作用？

RPC框架鎖支持的負(fù)載均衡、故障轉(zhuǎn)移、發(fā)送超時等特性，都是通過連接池組件去實現(xiàn)的。

典型連接池組件對外提供的接口為：

int ConnectionPool::init(…);

Connection ConnectionPool::getConnection();

int ConnectionPool::putConnection(Connection t);

init做了些什么？

和下游RPC-server（一般是一個集群），建立N個tcp長連接，即所謂的連接“池”。

getConnection做了些什么？

從連接“池”中拿一個連接，加鎖（置一個標(biāo)志位），返回給調(diào)用方。

putConnection做了些什么？

將一個分配出去的連接放回連接“池”中，解鎖（也是置一個標(biāo)志位）。

如何實現(xiàn)負(fù)載均衡？

連接池中建立了與一個RPC-server集群的連接，連接池在返回連接的時候，需要具備隨機性。

如何實現(xiàn)故障轉(zhuǎn)移？

連接池中建立了與一個RPC-server集群的連接，當(dāng)連接池發(fā)現(xiàn)某一個機器的連接異常后，需要將這個機器的連接排除掉，返回正常的連接，在機器恢復(fù)后，再將連接加回來。

如何實現(xiàn)發(fā)送超時？

因為是同步阻塞調(diào)用，拿到一個連接后，使用帶超時的send/recv即可實現(xiàn)帶超時的發(fā)送和接收。

總的來說，同步的RPC-client的實現(xiàn)是相對比較容易的，序列化組件、連接池組件配合多工作線程數(shù)，就能夠?qū)崿F(xiàn)。

RPC-client異步回調(diào)架構(gòu)如何？

所謂異步回調(diào)，在得到結(jié)果之前，不會處于阻塞狀態(tài)，理論上任何時間都沒有任何線程處于阻塞狀態(tài)，因此異步回調(diào)的模型，理論上只需要很少的工作線程與服務(wù)連接就能夠達(dá)到很高的吞吐量，如上圖所示：

• 左邊的框框，是少量工作線程（少數(shù)幾個就行了）進行調(diào)用與回調(diào)
• 中間粉色的框框，代表了RPC-client組件
• 右邊橙色框，代表了RPC-server
• 藍(lán)色六個小框，代表了異步RPC-client六個核心組件：上下文管理器，超時管理器，序列化組件，下游收發(fā)隊列，下游收發(fā)線程，連接池組件
• 白色的流程小框，以及箭頭序號1-17，代表整個工作線程的串行執(zhí)行步驟：

1）業(yè)務(wù)代碼發(fā)起異步RPC調(diào)用；

Add(Obj1,Obj2, callback)

2）上下文管理器，將請求，回調(diào)，上下文存儲起來；

3）序列化組件，將對象調(diào)用序列化成二進制字節(jié)流，可理解為一個待發(fā)送的包packet1；

4）下游收發(fā)隊列，將報文放入“待發(fā)送隊列”，此時調(diào)用返回，不會阻塞工作線程；

5）下游收發(fā)線程，將報文從“待發(fā)送隊列”中取出，通過連接池組件拿到一個可用的連接connection；

6）通過連接connection將包packet1發(fā)送給RPC-server；

7）發(fā)送包在網(wǎng)絡(luò)傳輸，發(fā)給RPC-server；

8）響應(yīng)包在網(wǎng)絡(luò)傳輸，發(fā)回給RPC-client；

9）通過連接connection從RPC-server收取響應(yīng)包packet2；

10）下游收發(fā)線程，將報文放入“已接受隊列”，通過連接池組件，將conneciont放回連接池；

11）下游收發(fā)隊列里，報文被取出，此時回調(diào)將要開始，不會阻塞工作線程；

12）序列化組件，將packet2范序列化為Result對象；

13）上下文管理器，將結(jié)果，回調(diào)，上下文取出；

14）通過callback回調(diào)業(yè)務(wù)代碼，返回Result結(jié)果，工作線程繼續(xù)往下走；

如果請求長時間不返回，處理流程是：

15）上下文管理器，請求長時間沒有返回；

16）超時管理器拿到超時的上下文；

17）通過timeout_cb回調(diào)業(yè)務(wù)代碼，工作線程繼續(xù)往下走；

畫外音：請配合架構(gòu)圖仔細(xì)看幾遍這個流程。

序列化組件和連接池組件上文已經(jīng)介紹過，收發(fā)隊列與收發(fā)線程比較容易理解。下面重點介紹上下文管理器與超時管理器這兩個總的組件。

為什么需要上下文管理器？

由于請求包的發(fā)送，響應(yīng)包的回調(diào)都是異步的，甚至不在同一個工作線程中完成，需要一個組件來記錄一個請求的上下文，把請求-響應(yīng)-回調(diào)等一些信息匹配起來。

如何將請求-響應(yīng)-回調(diào)這些信息匹配起來？

這是一個很有意思的問題，通過一條連接往下游服務(wù)發(fā)送了a，b，c三個請求包，異步的收到了x，y，z三個響應(yīng)包：

怎么知道哪個請求包與哪個響應(yīng)包對應(yīng)？怎么知道哪個響應(yīng)包與哪個回調(diào)函數(shù)對應(yīng)？

可以通過“請求id”來實現(xiàn)請求-響應(yīng)-回調(diào)的串聯(lián)。

整個處理流程如上，通過請求id，上下文管理器來對應(yīng)請求-響應(yīng)-callback之間的映射關(guān)系：

1）生成請求id；

2）生成請求上下文context，上下文中包含發(fā)送時間time，回調(diào)函數(shù)callback等信息；

3）上下文管理器記錄req-id與上下文context的映射關(guān)系；

4）將req-id打在請求包里發(fā)給RPC-server；

5）RPC-server將req-id打在響應(yīng)包里返回；

6）由響應(yīng)包中的req-id，通過上下文管理器找到原來的上下文context；

7）從上下文context中拿到回調(diào)函數(shù)callback；

8）callback將Result帶回，推動業(yè)務(wù)的進一步執(zhí)行；

如何實現(xiàn)負(fù)載均衡，故障轉(zhuǎn)移？

與同步的連接池思路類似，不同之處在于：

• 同步連接池使用阻塞方式收發(fā)，需要與一個服務(wù)的一個ip建立多條連接；
• 異步收發(fā)，一個服務(wù)的一個ip只需要建立少量的連接（例如，一條tcp連接）；

如何實現(xiàn)超時發(fā)送與接收？

超時收發(fā)，與同步阻塞收發(fā)的實現(xiàn)就不一樣了：

• 同步阻塞超時，可以直接使用帶超時的send/recv來實現(xiàn)；
• 異步非阻塞的nio的網(wǎng)絡(luò)報文收發(fā)，由于連接不會一直等待回包，超時是由超時管理器實現(xiàn)的；

超時管理器如何實現(xiàn)超時管理？

超時管理器，用于實現(xiàn)請求回包超時回調(diào)處理。

每一個請求發(fā)送給下游RPC-server，會在上下文管理器中保存req-id與上下文的信息，上下文中保存了請求很多相關(guān)信息，例如req-id，回包回調(diào)，超時回調(diào)，發(fā)送時間等。

超時管理器啟動timer對上下文管理器中的context進行掃描，看上下文中請求發(fā)送時間是否過長，如果過長，就不再等待回包，直接超時回調(diào)，推動業(yè)務(wù)流程繼續(xù)往下走，并將上下文刪除掉。

如果超時回調(diào)執(zhí)行后，正常的回包又到達(dá)，通過req-id在上下文管理器里找不到上下文，就直接將請求丟棄。

畫外音：因為已經(jīng)超時處理了，無法恢復(fù)上下文。

無論如何，異步回調(diào)和同步回調(diào)相比，除了序列化組件和連接池組件，會多出上下文管理器，超時管理器，下游收發(fā)隊列，下游收發(fā)線程等組件，并且對調(diào)用方的調(diào)用習(xí)慣有影響。

畫外音：編程習(xí)慣，由同步變?yōu)榱嘶卣{(diào)。

異步回調(diào)能提高系統(tǒng)整體的吞吐量，具體使用哪種方式實現(xiàn)RPC-client，可以結(jié)合業(yè)務(wù)場景來選取。

總結(jié)

(1) 什么是RPC調(diào)用？

像調(diào)用本地函數(shù)一樣，調(diào)用一個遠(yuǎn)端服務(wù)。

(2) 為什么需要RPC框架？

RPC框架用于屏蔽RPC調(diào)用過程中的序列化，網(wǎng)絡(luò)傳輸?shù)燃夹g(shù)細(xì)節(jié)。讓調(diào)用方只專注于調(diào)用，服務(wù)方只專注于實現(xiàn)調(diào)用。

(3) 什么是序列化？為什么需要序列化？

把對象轉(zhuǎn)化為連續(xù)二進制流的過程，叫做序列化。磁盤存儲，緩存存儲，網(wǎng)絡(luò)傳輸只能操作于二進制流，所以必須序列化。

(4) 同步RPC-client的核心組件是什么？

同步RPC-client的核心組件是序列化組件、連接池組件。它通過連接池來實現(xiàn)負(fù)載均衡與故障轉(zhuǎn)移，通過阻塞的收發(fā)來實現(xiàn)超時處理。

(5) 異步RPC-client的核心組件是什么？

異步RPC-client的核心組件是序列化組件、連接池組件、收發(fā)隊列、收發(fā)線程、上下文管理器、超時管理器。它通過“請求id”來關(guān)聯(lián)請求包-響應(yīng)包-回調(diào)函數(shù)，用上下文管理器來管理上下文，用超時管理器中的timer觸發(fā)超時回調(diào)，推進業(yè)務(wù)流程的超時處理。

思路比結(jié)論重要。?