作者 | Kislay Verma

編譯 | 崔皓

策劃 | 云昭

開篇

微服務(wù)架構(gòu)在當(dāng)今的軟件工程領(lǐng)域被廣泛采用。同時，采用分布式架構(gòu)的組織也發(fā)現(xiàn)需要考慮分布式故障的附加復(fù)雜性，而這種復(fù)雜性往往超出實際業(yè)務(wù)邏輯。

雖然分布式計算的謬誤是有據(jù)可查的，但對于組織而言并不是一件容易的事情。因此，構(gòu)建大規(guī)模、可靠的分布式系統(tǒng)架構(gòu)就成為一個難題。作為推論，當(dāng)我們將網(wǎng)絡(luò)交互的復(fù)雜性引入其中時，在原先非分布式系統(tǒng)中看起來很好的代碼就有可能成為一個大問題。

在生產(chǎn)代碼中摸爬滾打幾年后，遭遇了各種故障模式并且發(fā)現(xiàn)導(dǎo)致故障的根源之后，我逐漸能夠識別一些更常見的故障模式。由于不同公司以及使用不同的語言堆棧之間存在差異（取決于內(nèi)部基礎(chǔ)設(shè)施和工具的成熟度），但是可以從產(chǎn)生問題的原因中總結(jié)出一些具有共性的經(jīng)驗。

下面就是我從這些經(jīng)驗中總結(jié)出來的一些代碼審查指南，這個指南可以形成一份清單，并用來審查分布式環(huán)境中與系統(tǒng)間通信相關(guān)的代碼。雖然這份清單上提到的問題并不適用所有情況，但它們覆蓋了代碼審查的基本面，可以按照這個清單將問題走查一遍，在此過程中標記缺失的項目以供進一步討論，利用這種方式發(fā)現(xiàn)系統(tǒng)中的問題是非常行之有效的。從這個意義上來說，可以通過這個“無腦清單”來發(fā)現(xiàn)大多數(shù)問題。

如何調(diào)用遠程系統(tǒng)

1、當(dāng)遠程系統(tǒng)發(fā)生故障時會發(fā)生什么？

無論系統(tǒng)設(shè)計的多么謹慎，它都會出現(xiàn)故障 - 這是在生產(chǎn)中被印證的事實。故障的發(fā)生可能源于代碼錯誤，基礎(chǔ)設(shè)施問題，流量激增，系統(tǒng)疏于管理等，總之結(jié)果是引發(fā)故障。調(diào)用者如何處理故障將決定整個架構(gòu)的彈性和健壯性。

定義錯誤處理路徑：必須在代碼中明確錯誤處理路徑，而不是讓系統(tǒng)在最終用戶面前崩潰。這里需要向用戶明確指出錯誤，例如：設(shè)計良好的錯誤頁面、帶有錯誤信息的異常日志，以及帶有回退機制的斷路器等。

制定恢復(fù)計劃：考慮代碼中的每一次遠程交互，并弄清楚如何恢復(fù)被中斷的工作。思考如下價格問題：工作流程是否需要有狀態(tài)才能從故障點觸發(fā)？是否將所有失敗的有效請求發(fā)布到重試隊列/數(shù)據(jù)庫表，并在遠程系統(tǒng)恢復(fù)時重試請求？是否有腳本來比較兩個系統(tǒng)的數(shù)據(jù)庫并以某種方式使它們同步？在部署系統(tǒng)之前，是否有一個明確的系統(tǒng)的恢復(fù)計劃？

2、當(dāng)遠程系統(tǒng)變慢時會發(fā)生什么？

這種情況比徹底失敗更難辦，因為我們不知道遠程系統(tǒng)是否在工作。因此需要檢查以下事項從而處理這種情況。如果我們使用類似 Istio的服務(wù)網(wǎng)格技術(shù)，其中一些問題可以輕松搞定而不需要修改應(yīng)用程序代碼。即便如此，我們也應(yīng)該關(guān)注這些問題。

為遠程系統(tǒng)調(diào)用設(shè)置超時：這包括遠程 API 調(diào)用、事件發(fā)布和數(shù)據(jù)庫調(diào)用的超時時間。我在很多代碼中發(fā)現(xiàn)過這個問題，因此需要檢查遠程系統(tǒng)是否設(shè)置了合理的超時時間，從而避免該系統(tǒng)在無響應(yīng)時調(diào)用者因為等待而浪費資源的情況發(fā)生。

超時重試：網(wǎng)絡(luò)和系統(tǒng)并不是100%可靠的，重試對于系統(tǒng)恢復(fù)是非常必要的。重試機制會消除系統(tǒng)交互中的許多“問題”。如果可能，在重試中使用某種補償機制（固定的、指數(shù)的）。在重試機制中添加一點抖動（這里的抖動可以理解為隨機重試，例如設(shè)置隨機的重試時間3-5s重試一次，避免所有調(diào)用者一起地不斷地對被調(diào)用者進行重試，導(dǎo)致被調(diào)用者的負載增大），這樣做可以給被調(diào)用系統(tǒng)一些喘息的空間，通過能夠保證調(diào)用者在負載下獲得更好的調(diào)用成功率。重試的另一面是冪等性，我們將在本文后面介紹。

使用斷路器：一些應(yīng)用程序并沒有預(yù)先打包這個功能，但我看到公司內(nèi)部會編寫自己的包裝器。如果你有這個需求，一定要實現(xiàn)它，對斷路器的投入會讓你獲益。它會提供明確的框架來定義錯誤情況下的回退策略。

不要把超時當(dāng)作請求失敗來處理——超時不是失敗，而是一種不確定的場景，應(yīng)該通過一種處理方式來應(yīng)對這種不確定性。因此需要建立明確的處理機制，允許系統(tǒng)在發(fā)生超時的情況下進行同步。處理機制可以是簡單的協(xié)調(diào)腳本，也可以是有狀態(tài)的工作流，或者是通過死信隊列（消息被拒絕、消息TTL過期、隊列達到最大長度）實現(xiàn)。

不要在事務(wù)中調(diào)用遠程系統(tǒng)——當(dāng)遠程系統(tǒng)訪問速度變慢時，依舊會長時間保持數(shù)據(jù)庫連接，如果訪問持續(xù)而因為速度的問題一直無法完成系統(tǒng)的訪問，會導(dǎo)致數(shù)據(jù)庫的連接也無法釋放，也就將數(shù)據(jù)庫連接用完，最終造成系統(tǒng)中斷的后果。

使用智能批處理：如果處理大量數(shù)據(jù)請求，可以逐個進行批量遠程調(diào)用（API 調(diào)用、數(shù)據(jù)庫讀?。亩W(wǎng)絡(luò)開銷。每個批量處理的量越大，整體延遲就會越大，可能失敗的工作單元也會越多。因此需要針對性能和容錯性優(yōu)化批量大小。

如何面對調(diào)用方請求

所有 API 必須保證冪等性：冪等性是為了實現(xiàn)調(diào)用方API的超時重試功能。只有API 能夠支持安全重試且不會有副作用時，調(diào)用者才能安心使用重試功能。這里的API 是指同步 API 和任何消息傳遞接口——調(diào)用者可能會發(fā)布兩次相同的消息（或者代理可能會發(fā)送兩次）給到該API。

明確定義響應(yīng)時間和吞吐量 SLA 以及遵守定義的規(guī)則：在分布式系統(tǒng)中，快速失敗比讓調(diào)用者等待要好得多。誠然，吞吐量 SLA 很難實現(xiàn)（分布式速率限制一個難題），但我們需要確保SLA在主動呼叫失敗時做好準備。另一個重要方面是了解下游系統(tǒng)的響應(yīng)時間，以確定系統(tǒng)最快的速度。

定義和限制批處理 API：如果公開批處理 API，則應(yīng)明確定義最大批處理的數(shù)量，這個數(shù)量需要受到SLA的 限制，也就是需要遵守 SLA的規(guī)則定義。

預(yù)先考慮可觀察性：可觀察性意味著能夠分析系統(tǒng)的行為，而無需通過查看API或組件的內(nèi)部來實現(xiàn)。預(yù)先考慮你關(guān)心的系統(tǒng)指標以及需要收集的數(shù)據(jù)，幫助你回答以前未提出的問題。再對系統(tǒng)進行檢測并獲得這些數(shù)據(jù)。執(zhí)行此操作的一個強大機制是識別系統(tǒng)的域模型，當(dāng)域中發(fā)生某個事件時進行發(fā)布事件的操作。（例如收到請求 id 123，返回請求 123 的響應(yīng)——注意如何使用這兩個“域”事件會導(dǎo)出一個稱為“響應(yīng)時間”的新指標。將原始數(shù)據(jù)轉(zhuǎn)換到預(yù)先確定的聚合中）。

一般性原則

盡量使用緩存：網(wǎng)絡(luò)變化無常，因此盡可能多地使用緩存，并不斷講最新的數(shù)據(jù)保存其中。當(dāng)然，有可能會使用遠程緩存機制（例如，Redis 服務(wù)器運行在單獨的服務(wù)器上），但至少通過緩存的方式可以將數(shù)據(jù)帶入控制域并減少系統(tǒng)的負載。

考慮單元故障：如果一個 API 或一條消息代表多個工作單元（批處理），那么需要思考單元故障意味著什么？如果有效載荷都失敗一次意味著什么？又或者單個單元獨立成功或失敗意味著什么？部分成功呢，API 是否響應(yīng)成功或失敗代碼？

這里的意思是一個API調(diào)用多個工作單元，這里的工作單元可以是一個組件或者是一個API。有可能在調(diào)用多個工作單元的時候，其中一個工作單元失敗了，或者有的工作單元成功了，這個時候作為最外層調(diào)用這些工作單元的API來說要考慮好是成功還是失敗，如果失敗如何返回失敗信息。

在系統(tǒng)邊緣隔離外部域?qū)ο螅?/strong>不允許以重用的名義在系統(tǒng)中使用其他系統(tǒng)的域?qū)ο?。這將會加劇我們的系統(tǒng)與其他系統(tǒng)的實體建模的耦合，在其他系統(tǒng)發(fā)生更改時，我們的系統(tǒng)都會進行大量重構(gòu)。我們應(yīng)該始終構(gòu)建自己的實體表示并將外部有效負載轉(zhuǎn)換為此我們系統(tǒng)內(nèi)的模式，然后我們的系統(tǒng)中使用它。

安全性

在每個邊緣清理輸入：在分布式環(huán)境中，系統(tǒng)的任何部分都可能受到損害（從安全角度來看）。因此，在系統(tǒng)邊界處會對進入系統(tǒng)的數(shù)據(jù)進行“消毒”處理，這里有一個假設(shè)就是這些進入系統(tǒng)的數(shù)據(jù)有可能不是干凈或安全的。

永遠不要提交憑證（Credentials）：永遠不要將憑證（數(shù)據(jù)庫用戶名/密碼或 API 密鑰）提交到代碼庫。雖然提交憑證到代碼庫對于某些人來說是常規(guī)操作，但我們需要摒棄這種陋習(xí)。始終遵守“憑證必須始終從外部（有安全存儲保證）加載到系統(tǒng)”的規(guī)則。

譯者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗，10年分布式架構(gòu)經(jīng)驗。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過60萬?！斗植际郊軜?gòu)原理與實踐》作者。