微服務(wù)架構(gòu)的分布式容錯(cuò)

『看看論文』是一系列分析計(jì)算機(jī)和軟件工程領(lǐng)域論文的文章，我們?cè)谶@個(gè)系列的每一篇文章中都會(huì)閱讀一篇來自 OSDI、SOSP 等頂會(huì)中的論文，這里不會(huì)事無巨細(xì)地介紹所有的細(xì)節(jié)，而是會(huì)篩選論文中的關(guān)鍵內(nèi)容，如果你對(duì)相關(guān)的論文非常感興趣，可以直接點(diǎn)擊鏈接閱讀原文。

本文要介紹的是 2019 年 SOSP 期刊中的論文 —— Aegean: Replication beyond the client-server model[^1]，這篇論文實(shí)現(xiàn)的 Aegean 并不是復(fù)雜的系統(tǒng)，它更像是一個(gè)工具或者框架，能夠在今天復(fù)雜的微服務(wù)架構(gòu)中保證請(qǐng)求處理的正確性。經(jīng)典的復(fù)制協(xié)議（Replication Protocol），例如：主從復(fù)制、Paxos 和 PBFT 能夠很好地適用于常見的客戶端 / 服務(wù)端模型（Client-Server Model），但是它們卻很難在多服務(wù)的設(shè)置中保證正確性。

在傳統(tǒng)的客戶端 / 服務(wù)端模型中，客戶端的請(qǐng)求往往都是由如下圖所示的一組相同服務(wù)器副本處理的，不同的部分會(huì)運(yùn)行相同的代碼，只是它們的角色可能有所不同，這些副本在處理請(qǐng)求時(shí)也基本不會(huì)依賴其他的服務(wù)；但是在微服務(wù)架構(gòu)中，接收用戶請(qǐng)求的服務(wù)往往只是 HTTP 入口，它會(huì)調(diào)用系統(tǒng)中的其他服務(wù)完成用戶期望的功能：

微服務(wù)架構(gòu)的復(fù)雜性來源于服務(wù)之間的大量交互以及網(wǎng)絡(luò)請(qǐng)求的不確定性，調(diào)用路徑上的任何服務(wù)超時(shí)或者宕機(jī)都可能影響用戶請(qǐng)求的處理，服務(wù)的宕機(jī)也可能會(huì)造成用戶無法感知請(qǐng)求的結(jié)果、系統(tǒng)處于異常狀態(tài)并無法回滾等問題。

該論文主要做了四部分工作，分別是陳述并定義微服務(wù)架構(gòu)中的現(xiàn)有問題、提出三種用于解決上述問題的技術(shù)、在解決問題的基礎(chǔ)上優(yōu)化系統(tǒng)的性能以及實(shí)現(xiàn) Aegean 框架在 TPC-W 基準(zhǔn)測(cè)試[^2]下評(píng)估 Aegean 的性能，我們?cè)谶@篇文章中更關(guān)注論文的前兩部分工作：?jiǎn)栴}陳述以及解決方案。

問題陳述

在這里，我們會(huì)設(shè)定一些簡(jiǎn)單的前提條件來展示微服務(wù)架構(gòu)中的問題，如下圖所示，客戶端會(huì)向服務(wù)端發(fā)送一組請(qǐng)求，這些請(qǐng)求會(huì)由服務(wù)端的一組中間服務(wù)（Middle Service）副本處理，中間服務(wù)在處理請(qǐng)求的過程中會(huì)調(diào)用后端服務(wù)（Backend Service）的接口，接收請(qǐng)求的中間服務(wù)會(huì)包含多個(gè)，而后端服務(wù)只會(huì)包含一個(gè)：

如果客戶端發(fā)起了下單請(qǐng)求，那么中間服務(wù)是處理結(jié)賬請(qǐng)求的服務(wù)，而后端服務(wù)是處理轉(zhuǎn)賬請(qǐng)求的服務(wù)。現(xiàn)實(shí)世界中微服務(wù)之間的交互遠(yuǎn)遠(yuǎn)比上圖展示的復(fù)雜得多，但是這個(gè)簡(jiǎn)單的模型已經(jīng)可以足夠說明微服務(wù)架構(gòu)中服務(wù)交互對(duì)保證正確性帶來的影響了。

主從復(fù)制、類 Paxos 協(xié)議以及預(yù)測(cè)執(zhí)行是在分布式系統(tǒng)中保證系統(tǒng)正確性最常見的三種技術(shù)，但是這三種技術(shù)在服務(wù)交互的場(chǎng)景下卻不能很好地工作，這里簡(jiǎn)單介紹下幾種技術(shù)的缺陷。

主從復(fù)制

在常見的主從復(fù)制算法中，主節(jié)點(diǎn)會(huì)負(fù)責(zé)處理所有的請(qǐng)求并將狀態(tài)更新的結(jié)果同步到從節(jié)點(diǎn)，當(dāng)從節(jié)點(diǎn)確認(rèn)了狀態(tài)的更新后，主節(jié)點(diǎn)才會(huì)將結(jié)果返回給客戶端。如果我們?cè)谥鲝膹?fù)制的模型中引入了中間服務(wù)，就會(huì)出現(xiàn)如下所示的情況：

1. 當(dāng)主節(jié)點(diǎn)向后端服務(wù)發(fā)送嵌套請(qǐng)求后宕機(jī)，后端服務(wù)會(huì)接收并處理該請(qǐng)求；
2. 作為后端服務(wù)的觀察者，主節(jié)點(diǎn)并沒有來得及將消息復(fù)制給從節(jié)點(diǎn)就發(fā)生了宕機(jī)；
3. 從節(jié)點(diǎn)超時(shí)并成為主節(jié)點(diǎn)后會(huì)丟失該請(qǐng)求相關(guān)的信息；

在這種情況下，原有的從節(jié)點(diǎn)不知道主節(jié)點(diǎn)處理了什么請(qǐng)求，它可能會(huì)重新執(zhí)行嵌套請(qǐng)求、稍有不同的請(qǐng)求甚至可能會(huì)向客戶端發(fā)送『商品已經(jīng)售罄』的錯(cuò)誤消息，然而該用戶的轉(zhuǎn)賬請(qǐng)求已經(jīng)被后端服務(wù)處理了。

這里出現(xiàn)的最根本問題是，主節(jié)點(diǎn)在向后端發(fā)送嵌套請(qǐng)求實(shí)際上是通知外部服務(wù)提交變更，然而在發(fā)出請(qǐng)求之前，它卻沒有將自己的狀態(tài)同步到從節(jié)點(diǎn)，防止在故障時(shí)發(fā)生狀態(tài)的丟失。

類 Paxos 算法

Paxos 算法和它的變種是目前使用最廣泛的復(fù)制協(xié)議，這些協(xié)議會(huì)使用主動(dòng)復(fù)制機(jī)制，也就是先確定請(qǐng)求的順序，然后按照順序執(zhí)行客戶端發(fā)出的所有請(qǐng)求。然而 Paxos 以及變種算法會(huì)遇到很多問題，首先，主動(dòng)復(fù)制機(jī)制意味著所有的中間服務(wù)都會(huì)收到并處理請(qǐng)求，后端服務(wù)會(huì)收到并執(zhí)行多份相同的嵌套請(qǐng)求：

檢測(cè)重復(fù)請(qǐng)求并不能解決全部的問題，后端服務(wù)還需要引入響應(yīng)緩存（Reply Cache）保證相同請(qǐng)求可以得到相同的響應(yīng)，也就是冪等性；很多交易相關(guān)的服務(wù)都會(huì)使用唯一標(biāo)識(shí)符來去重并防止重入。

正確性不是 Paxos 算法帶來的唯一問題，在微服務(wù)的架構(gòu)中，線性執(zhí)行請(qǐng)求會(huì)對(duì)性能造成非常嚴(yán)重地影響，能夠明顯地降低服務(wù)的吞吐量以及服務(wù)的可擴(kuò)展性。

預(yù)測(cè)執(zhí)行

預(yù)測(cè)執(zhí)行（Speculative execution）是高并發(fā)提高性能的一種重要工具，使用預(yù)測(cè)執(zhí)行的復(fù)制協(xié)議會(huì)在一組副本對(duì)執(zhí)行順序達(dá)成一致之前向下游發(fā)出請(qǐng)求。預(yù)測(cè)執(zhí)行在微服務(wù)復(fù)雜的架構(gòu)可能會(huì)影響系統(tǒng)的正確性，因?yàn)樵诳蛻舳朔?wù)器模型中，預(yù)測(cè)執(zhí)行需要系統(tǒng)向客戶端能夠隱藏錯(cuò)誤預(yù)測(cè)帶來的不一致狀態(tài)，服務(wù)端也需要支持狀態(tài)的回滾：

而在微服務(wù)架構(gòu)中，預(yù)測(cè)執(zhí)行會(huì)導(dǎo)致問題變得更加復(fù)雜，當(dāng)客戶端通過預(yù)測(cè)執(zhí)行調(diào)用中間服務(wù)時(shí)，中間服務(wù)會(huì)調(diào)用后端服務(wù)，客戶端在這時(shí)如果突然發(fā)現(xiàn)預(yù)測(cè)發(fā)生了錯(cuò)誤，我們需要級(jí)聯(lián)回滾來恢復(fù)狀態(tài)，這不僅需要回滾中間服務(wù)，還需要回滾后端服務(wù)。

小結(jié)

三種不同的復(fù)制協(xié)議都不能直接適用于包含服務(wù)交互的微服務(wù)架構(gòu)，在對(duì)三種復(fù)制協(xié)議的研究中，論文提出了微服務(wù)架構(gòu)帶來的三大挑戰(zhàn)：

• 復(fù)制客戶端（Replicated client）— 在客戶端服務(wù)器模型中，客戶端是唯一一個(gè)向服務(wù)端發(fā)送請(qǐng)求的機(jī)器，然而在微服務(wù)架構(gòu)中，一組復(fù)制的中間服務(wù)可能向其他服務(wù)發(fā)送請(qǐng)求，這些服務(wù)副本發(fā)送的不同請(qǐng)求應(yīng)該在邏輯上被看做單個(gè)請(qǐng)求；
• 嵌套響應(yīng)的持久化（Durability of nested responses）— 當(dāng)中間服務(wù)接收到其他服務(wù)返回的響應(yīng)時(shí)，它應(yīng)該先保證該響應(yīng)被足夠的副本確認(rèn)，這樣才能在宕機(jī)時(shí)保證其他副本能夠正確返回響應(yīng)；
• 預(yù)測(cè)執(zhí)行（Speculative execution）— 在預(yù)測(cè)狀態(tài)下，中間服務(wù)不能發(fā)出任何的嵌套請(qǐng)求，這可能會(huì)導(dǎo)致后端服務(wù)提交未經(jīng)確認(rèn)的狀態(tài)；

這些都是微服務(wù)架構(gòu)中常見的問題，對(duì)服務(wù)端開發(fā)稍微有經(jīng)驗(yàn)的讀者應(yīng)該對(duì)上述三大挑戰(zhàn)非常熟悉，這篇論文只是使用了更加正式的模型進(jìn)行了歸納和總結(jié)。

解決方案

為了解決微服務(wù)架構(gòu)中最常見的三個(gè)挑戰(zhàn)，論文中引入了服務(wù)器墊片（Server Shim）、響應(yīng)持久化（Response Durability）和改良預(yù)測(cè)（Taming Speculation）三種技術(shù)分別解決復(fù)制客戶端、嵌套響應(yīng)的持久化和預(yù)測(cè)執(zhí)行幾個(gè)問題。

服務(wù)器墊片

當(dāng)中間服務(wù)使用主動(dòng)的復(fù)制協(xié)議時(shí)，后端服務(wù)會(huì)收到大量的重復(fù)請(qǐng)求，為了較少冗余請(qǐng)求的處理并保證所有的請(qǐng)求都得到相同的響應(yīng)，我們可能需要對(duì)后端服務(wù)進(jìn)行修改；然而修改所有的后端服務(wù)是比較大的工程，我們更希望對(duì)現(xiàn)有的架構(gòu)造成較小的影響，所以論文提出了如下所示的簡(jiǎn)單抽象：

服務(wù)器墊片會(huì)與后端服務(wù)一起執(zhí)行，中間服務(wù)發(fā)出的所有請(qǐng)求會(huì)先經(jīng)過服務(wù)器墊片再到后端服務(wù)，墊片主要會(huì)負(fù)責(zé)以下兩大功能：

• 接收請(qǐng)求：服務(wù)器墊片會(huì)認(rèn)證其他服務(wù)發(fā)送的請(qǐng)求并確認(rèn)發(fā)送方的身份，在收到請(qǐng)求時(shí)也不會(huì)立刻交給下游的后端服務(wù)處理，而是會(huì)等待一組（quorum）來自副本客戶端的相同請(qǐng)求，收到足夠的請(qǐng)求后會(huì)將請(qǐng)求轉(zhuǎn)發(fā)給后端并忽略剩余副本的請(qǐng)求；
• 返回響應(yīng)：當(dāng)后端服務(wù)生成響應(yīng)之后，服務(wù)器墊片會(huì)負(fù)責(zé)將響應(yīng)廣播給正在等待的一組客戶端，同時(shí)為了防止消息的丟失，墊片還會(huì)為每個(gè)客戶端持久化響應(yīng)緩存；

響應(yīng)持久化

在客戶端服務(wù)器模型中，副本服務(wù)的輸入僅僅來源于客戶端的輸入，而在微服務(wù)的架構(gòu)中，嵌套請(qǐng)求的響應(yīng)也是中間服務(wù)的輸入；因?yàn)閭鹘y(tǒng)的復(fù)制協(xié)議需要所有的輸入都必須持久化地存儲(chǔ)到日志中，所以在多服務(wù)的設(shè)置中，我們需要保證來自客戶端的輸入和嵌套響應(yīng)都存儲(chǔ)在日志中，只有在持久化日志之后，我們才可以向客戶端或者后端服務(wù)提交變更。

改良預(yù)測(cè)

在多服務(wù)的設(shè)置中，如果一組中間服務(wù) A、B 和 C 在達(dá)成一致之前，A 服務(wù)就進(jìn)行了預(yù)測(cè)執(zhí)行調(diào)用下游服務(wù)提交變更，那么當(dāng) B 和 C 發(fā)現(xiàn)當(dāng)前請(qǐng)求無效要求回滾時(shí)，我們就在系統(tǒng)中引入了不一致的狀態(tài)。為了解決預(yù)測(cè)可能帶來的不確定性問題，我們會(huì)在請(qǐng)求執(zhí)行的不同階段引入屏障來對(duì)齊多個(gè)線程或者副本之間的狀態(tài)：

當(dāng)請(qǐng)求執(zhí)行遇到屏障時(shí)，它會(huì)等待其他副本直到它們的狀態(tài)發(fā)生收斂，只有在狀態(tài)達(dá)成一致之后，它們才會(huì)執(zhí)行具有副作用的任務(wù)，例如：調(diào)用下游服務(wù)或者返回響應(yīng)。

總結(jié)

作為 SOSP 中的論文，Aegean: Replication beyond the client-server model 中介紹的問題與我們?cè)诠こ躺嫌龅降姆浅Ｏ嗨疲m然它提出了一些解決方案，但是作者認(rèn)為這些解決方案太過于正式和學(xué)術(shù)。

我們?cè)诠こ躺贤鶗?huì)使用更加粗糙和容易實(shí)現(xiàn)的方式解決服務(wù)的重入、冪等以及錯(cuò)誤恢復(fù)的問題，例如：利用唯一標(biāo)識(shí)符去重、通過 MySQL 或者 Redis 存儲(chǔ)請(qǐng)求的響應(yīng)、在后臺(tái)啟動(dòng)線程重試失敗的任務(wù)，這些方法雖然不能保證強(qiáng)一致性，但是它們?cè)诙鄶?shù)場(chǎng)景下都是夠用的，只有當(dāng)一致性和正確性成為較強(qiáng)的需求時(shí)，再考慮文中的幾種稍微復(fù)雜的技術(shù)也是可以的。