3.3.1 網(wǎng)絡(luò)延遲

微服務(wù)之間的調(diào)用是相當(dāng)頻繁的，特別是一些高并發(fā)場(chǎng)景下更是如此。還有一些特定的服務(wù)需要反復(fù)調(diào)用鑒權(quán)類服務(wù)接口，這些都大大增加了網(wǎng)絡(luò)的延遲。傳統(tǒng)的基于REST風(fēng)格的RPC調(diào)用采用HTTP或者HTTPS協(xié)議，無形中又增加了整個(gè)鏈路的響應(yīng)延遲。

如果通信的過程安全以及數(shù)據(jù)安全方面的處理導(dǎo)致的延遲無法避免，那么可以考慮從傳輸鏈路及傳輸數(shù)據(jù)的角度來進(jìn)行處理了。

1.傳輸鏈路方面

傳輸鏈路的處理可以采取實(shí)時(shí)監(jiān)控+鏈路切換的方式來提升用戶體驗(yàn)。

圖3-9所示為傳輸鏈路切換流程圖，從圖中可以看出，在監(jiān)控系統(tǒng)根據(jù)業(yè)務(wù)情況設(shè)定訪問延遲報(bào)警的閾值之后，服務(wù)就會(huì)根據(jù)響應(yīng)延遲情況來決定本次訪問是否延遲。如果有延遲，則先進(jìn)入異常自動(dòng)應(yīng)急平臺(tái)處理，異常自動(dòng)應(yīng)急平臺(tái)根據(jù)日志及延遲情況自動(dòng)選擇是切換鏈路還是釋放（增加）資源。如果系統(tǒng)還不能恢復(fù)，則進(jìn)入人工介入階段。

圖3-9 傳輸鏈路切換流程圖

2.傳輸數(shù)據(jù)方面

以REST風(fēng)格為代表的HTTP請(qǐng)求，服務(wù)調(diào)用方與提供方交互的數(shù)據(jù)形式通常都是json格式。json格式的優(yōu)點(diǎn)顯而易見：友好；但是缺點(diǎn)也相當(dāng)明顯：明文傳輸，數(shù)據(jù)占據(jù)空間大，加大了傳輸過程的延遲。

MessagePack序列化后的數(shù)據(jù)所占空間比json格式要小，反序列化的延遲也比json格式小，在大量數(shù)據(jù)實(shí)時(shí)交互的場(chǎng)景中可以考慮替換json格式的數(shù)據(jù)。

Protobuf因?yàn)槭荊oogle力推的數(shù)據(jù)序列化格式也變得廣為流行，其對(duì)數(shù)據(jù)的壓縮率比MessagePack還要高，但是其反序列化速度比Messagepack要慢、比json格式要快，因此在批量傳輸場(chǎng)景中可以考慮使用。