作者 | Kislay Verma

編譯 | 崔皓

策劃 | 云昭

開篇

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

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

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

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

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

1、當(dāng)遠(yuǎn)程系統(tǒng)發(fā)生故障時(shí)會(huì)發(fā)生什么？

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

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

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

2、當(dāng)遠(yuǎn)程系統(tǒng)變慢時(shí)會(huì)發(fā)生什么？

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

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

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

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

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

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

使用智能批處理：如果處理大量數(shù)據(jù)請(qǐng)求，可以逐個(gè)進(jìn)行批量遠(yuǎn)程調(diào)用（API 調(diào)用、數(shù)據(jù)庫(kù)讀取）從而消除網(wǎng)絡(luò)開銷。每個(gè)批量處理的量越大，整體延遲就會(huì)越大，可能失敗的工作單元也會(huì)越多。因此需要針對(duì)性能和容錯(cuò)性優(yōu)化批量大小。

如何面對(duì)調(diào)用方請(qǐng)求

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

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

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

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

一般性原則

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

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

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

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

安全性

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

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

譯者介紹

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