淺談“完美無(wú)瑕”的分布式系統(tǒng)
2019-08-29 來(lái)源：raincent
本文最初發(fā)布于 Lena Hall 個(gè)人博客，譯者：劉志勇 來(lái)源：InfoQ
導(dǎo)讀： 本文基于 Lena Hall 的 O’Reilly Velocity 2019 主題演講，進(jìn)行了解讀。分布式系統(tǒng)是建立在網(wǎng)絡(luò)之上的軟件系統(tǒng)。正是因?yàn)檐浖奶匦�，所以分布式系統(tǒng)具有高度的內(nèi)聚性和透明性。因此，網(wǎng)絡(luò)和分布式系統(tǒng)之間的區(qū)別更多的在于高層軟件(特別是操作系統(tǒng))，而不是硬件。內(nèi)聚性是指每一個(gè)數(shù)據(jù)庫(kù)分布節(jié)點(diǎn)高度自治，有本地的數(shù)據(jù)庫(kù)管理系統(tǒng)。透明性是指每一個(gè)數(shù)據(jù)庫(kù)分布節(jié)點(diǎn)對(duì)用戶的應(yīng)用來(lái)說(shuō)都是透明的，看不出是本地還是遠(yuǎn)程。在分布式數(shù)據(jù)庫(kù)系統(tǒng)中，用戶感覺(jué)不到數(shù)據(jù)是分布的，即用戶不須知道關(guān)系是否分割、有無(wú)副本、數(shù)據(jù)存于哪個(gè)站點(diǎn)以及事務(wù)在哪個(gè)站點(diǎn)上執(zhí)行等。說(shuō)了這么多，但實(shí)際上，分布式系統(tǒng)一點(diǎn)都不復(fù)雜，簡(jiǎn)單的說(shuō)就是：將整個(gè)個(gè)軟件視為一個(gè)系統(tǒng)(不管它有多復(fù)雜)，然后將整個(gè)系統(tǒng)分割為一系列的進(jìn)程，每個(gè)進(jìn)程完成一定的功能。再將這些進(jìn)程分散到不同的機(jī)器上，分散后，選擇若干種通信協(xié)議將它們連接起來(lái)。這就完成了分布式系統(tǒng)的構(gòu)建。人們常常把分布式系統(tǒng)自然而然的和并行計(jì)算聯(lián)系起來(lái)。然而這并不正確。實(shí)際上，分布式系統(tǒng)并不一定是并行的。Lena Hall 給我們?cè)敿?xì)闡述了“完美無(wú)瑕”的分布式系統(tǒng)應(yīng)該是什么樣的，以及我們應(yīng)該如何朝著這一目標(biāo)做哪些工作。
本文闡述了我們所做工作帶來(lái)的影響，我們所面臨的復(fù)雜性和障礙，以及對(duì)于構(gòu)建更好的分布式系統(tǒng)的重要因素，尤其是當(dāng)其他關(guān)鍵領(lǐng)域依賴并建立我們所創(chuàng)造的基礎(chǔ)之上時(shí)。
目前可用的系統(tǒng)已經(jīng)提供了許多解決方案，封裝了許多分布式算法，實(shí)現(xiàn)了自動(dòng)化并抽象出一些復(fù)雜性。使用這些系統(tǒng)的工程師并不一定非要擁有開(kāi)發(fā)它們所需的大量知識(shí)不可。盡管對(duì)于工程師新手來(lái)說(shuō)，了解這些系統(tǒng)所依賴的基礎(chǔ)知識(shí)越來(lái)越?jīng)]有什么必要了，但在某些情況下，了解幕后工作對(duì)于做出正確的決策并解決出現(xiàn)的困難問(wèn)題還是必不可少的。
基礎(chǔ)知識(shí)仍然很重要嗎?
為什么說(shuō)重視基礎(chǔ)知識(shí)很重要?今天，我們正處于這樣的一個(gè)階段，分布式系統(tǒng)在醫(yī)療系統(tǒng)、自主設(shè)備、傳輸自動(dòng)化和其他生命攸關(guān)系統(tǒng)中的應(yīng)用越來(lái)越廣泛，在這些場(chǎng)景中，錯(cuò)誤的代價(jià)越來(lái)越高，而正確性變得日益重要起來(lái)。
錯(cuò)誤的代價(jià)并不是指你的系統(tǒng)今天不可用的時(shí)間長(zhǎng)短。它是關(guān)于你的系統(tǒng)發(fā)生宕機(jī)或故障時(shí)，給用戶或他們的用戶帶來(lái)的代價(jià)。我們應(yīng)該負(fù)起責(zé)任，并永遠(yuǎn)記住我們?yōu)槭裁催@樣做，我們真正要解決的問(wèn)題是什么。
每個(gè)行業(yè)都希望通過(guò)結(jié)合他們和我們的研究和解決方案來(lái)取得更大的進(jìn)步。而我們的工作能夠幫助其他領(lǐng)域更好地實(shí)現(xiàn)他們的目標(biāo)。對(duì)我們來(lái)說(shuō)，了解如何放寬某些限制或者微調(diào)某些權(quán)衡也是非常有用的。
了解核心的內(nèi)容，是一個(gè)強(qiáng)大的工具，可以讓我們從容駕馭不斷變化的選項(xiàng)和工具的復(fù)雜性，并幫助我們構(gòu)建正確的解決方案，以改進(jìn)我們現(xiàn)有的選項(xiàng)。
但事實(shí)證明，要做到這一點(diǎn)并不是那么容易。在我們前進(jìn)的道路上，荊棘載途，艱難險(xiǎn)阻。
理論和實(shí)踐存在巨大的差距
理解“正確”對(duì)我們的系統(tǒng)意味著什么，對(duì)我們來(lái)說(shuō)，不啻為一個(gè)挑戰(zhàn)。大多數(shù)理論材料都很不“接地氣”，眾所周知，它們很難被理解并掌握。不止如此，它往往還不包括那些將這一理論付諸實(shí)踐所需的信息。要想應(yīng)用到生產(chǎn)系統(tǒng)中，就必須修改理論算法，并對(duì)它們進(jìn)行調(diào)整以適應(yīng)實(shí)際環(huán)境。其中許多并沒(méi)有透露對(duì)實(shí)際解決方案很重要的具體細(xì)節(jié)。甚至對(duì)協(xié)議細(xì)節(jié)稍有誤解，也會(huì)破壞協(xié)議的正確性。因此，我們需要做更多的額外工作，以保證實(shí)踐時(shí)，協(xié)議仍然是正確的。
正確性難以驗(yàn)證和維持
在實(shí)際環(huán)境中驗(yàn)證并維持分布式系統(tǒng)的正確性，是一項(xiàng)具有挑戰(zhàn)性的工作。它可能聽(tīng)上去很完美，但在實(shí)踐中，卻可能是低效的、或者難以實(shí)現(xiàn)的。這在理論上聽(tīng)起來(lái)不切實(shí)際，但在實(shí)踐中卻是完全可以接受的。須知在算法邏輯及其實(shí)現(xiàn)中，很多地方都有可能出錯(cuò)，而且還難以檢測(cè)。
正確性并不總是優(yōu)先考慮的事
另一方面，正確性并不總是優(yōu)先考慮的事。還有截止期限、競(jìng)爭(zhēng)和客戶都需要更快的解決方案。終端系統(tǒng)還可能會(huì)出現(xiàn)倉(cāng)促而不能正確修復(fù)的情況。這意味著團(tuán)隊(duì)可能沒(méi)有足夠的時(shí)間來(lái)做這件事：正確地討論并系統(tǒng)地解決罕見(jiàn)的“間歇性”錯(cuò)誤背后的真正原因，這些錯(cuò)誤在未來(lái)還會(huì)再次發(fā)生，導(dǎo)致出現(xiàn)更多的錯(cuò)誤。
我們?cè)撊绾胃倪M(jìn)?
我們可以從多個(gè)方面改進(jìn)。其中之一就是：強(qiáng)調(diào)并集中精力提高正確性，以確保我們能夠構(gòu)建并維護(hù)系統(tǒng)，使其始終按照我們所希望的那樣運(yùn)行。
另一個(gè)就是，提高對(duì)它們?nèi)绾喂ぷ鞯睦斫猓驗(yàn)檫@有助于我們減少?gòu)?fù)雜性和可能出現(xiàn)的錯(cuò)誤，并使我們更有準(zhǔn)備迎接即將到來(lái)的挑戰(zhàn)。
當(dāng)我們不直接實(shí)現(xiàn)分布式算法和概念時(shí)，我們肯定會(huì)依賴基于那些構(gòu)建的系統(tǒng)。在我們構(gòu)建的內(nèi)容與其他領(lǐng)域相互交叉時(shí)，理解基本概念和權(quán)衡就變得極為重要了。
如果向你承諾了一些性能和一致性，那么你該如何確保這些承諾就是在你需要的確切水平上提供的呢?
簡(jiǎn)單問(wèn)題復(fù)雜化
當(dāng)幾臺(tái)計(jì)算機(jī)相互通信時(shí)，瑣碎的問(wèn)題就變成了棘手的問(wèn)題，而且它們還會(huì)累積起來(lái)。分布式系統(tǒng)難以理解，也難以實(shí)現(xiàn)，而且在實(shí)踐中很難保持它們的正確性。
我認(rèn)為有很多方法可以說(shuō)明其原因。最近，我有機(jī)會(huì)為生物信息學(xué)領(lǐng)域的人解釋，他們想知道為什么需要在分布式環(huán)境中的重要屬性之間進(jìn)行權(quán)衡。
排序
我想到的第一件事就是對(duì)事件進(jìn)行排序。在一臺(tái)機(jī)器上進(jìn)行排序很容易，但當(dāng)消息通過(guò)網(wǎng)絡(luò)發(fā)送時(shí)，就變得很難了!我們不能依賴物理時(shí)間戳，因?yàn)椴煌瑱C(jī)器上的物理時(shí)鐘往往有所偏移。對(duì)于分布式系統(tǒng)中的排序，我們經(jīng)常應(yīng)用邏輯時(shí)鐘，或者簡(jiǎn)單地說(shuō)，在節(jié)點(diǎn)之間傳遞的計(jì)數(shù)器。
由于分布式系統(tǒng)的異步特性，我們并不能很容易地為所有事件建立競(jìng)爭(zhēng)順序，因?yàn)槠渲幸恍┦录遣l(fā)的!我們所能做的就是找出哪些事件是并發(fā)的，哪些事件在彼此之前發(fā)生。即使是這樣一個(gè)簡(jiǎn)單的任務(wù)，我們也需要做出一些決定。
例如，如果系統(tǒng)告訴我們事件是有序的，但實(shí)際上它們是并發(fā)的，那么，這種情況我們是否可以接受呢?
或者，我們是否需要確切地知道，當(dāng)我們可以對(duì)事件進(jìn)行排序時(shí)，事件真的不是同時(shí)發(fā)生的嗎?
協(xié)議
我們不能簡(jiǎn)單地對(duì)并發(fā)事件進(jìn)行排序，有時(shí)候，我們?nèi)匀恍枰獩Q定操作的順序、值、值序列或其他任何東西。
事實(shí)證明，讓幾臺(tái)機(jī)器選擇相同的東西是另一種情況。在這種情況下，我們必須要問(wèn)自己的問(wèn)題，并決定什么對(duì)我們是合適的。
例如，二階段提交(Two Phase Commit)的是一種解決方案，在這種解決方案中，我們的節(jié)點(diǎn)可以就某些方面達(dá)成一致。
譯注：在計(jì)算機(jī)網(wǎng)絡(luò)以及數(shù)據(jù)庫(kù)領(lǐng)域內(nèi)，二階段提交(Two-phase Commit)是指，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點(diǎn)在進(jìn)行事務(wù)提交時(shí)保持一致性而設(shè)計(jì)的一種算法。通常，二階段提交也被稱為是一種協(xié)議。在分布式系統(tǒng)中，每個(gè)節(jié)點(diǎn)雖然可以知曉自己的操作時(shí)成功或者失敗，卻無(wú)法知道其他節(jié)點(diǎn)的操作的成功或失敗。當(dāng)一個(gè)事務(wù)跨越多個(gè)節(jié)點(diǎn)時(shí)，為了保持事務(wù)的 ACID 特性，需要引入一個(gè)作為協(xié)調(diào)者的組件來(lái)統(tǒng)一掌控所有節(jié)點(diǎn)(稱作參與者) 的操作結(jié)果并最終指示這些節(jié)點(diǎn)是否要把操作結(jié)果進(jìn)行真正的提交(比如將更新后的數(shù)據(jù)寫(xiě)入磁盤(pán)等等)。因此，二階段提交的算法思路可以概括為： 參與者將操作成敗通知協(xié)調(diào)者，再由協(xié)調(diào)者根據(jù)所有參與者的反饋情報(bào)決定各參與者是否要提交操作還是中止操作。
只要我們的節(jié)點(diǎn)不出故障，它就可以進(jìn)行工作。
如果一些節(jié)點(diǎn)發(fā)生崩潰，為了防止出現(xiàn)數(shù)據(jù)不一致的可能性，系統(tǒng)就會(huì)阻塞，直到崩潰的節(jié)點(diǎn)返回，這種情況也有可能永遠(yuǎn)不會(huì)發(fā)生;或者需要非常、非常長(zhǎng)的時(shí)間。
所以，這個(gè)算法是安全的，但它不是實(shí)時(shí)的。
如果這還不是我們所能接受的，那么我們是不是真的需要一個(gè)系統(tǒng)來(lái)回應(yīng)呢?
在這種情況下，我們可能有另一種潛在的解決方案：三階段提交(Three Phase Commit)，當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)，它就不會(huì)發(fā)生阻塞。
譯注： 三階段提交(Three-phase commit)，是在計(jì)算機(jī)網(wǎng)絡(luò)及數(shù)據(jù)庫(kù)的范疇下，使得一個(gè)分布式系統(tǒng)內(nèi)的所有節(jié)點(diǎn)能夠執(zhí)行事務(wù)的提交的一種分布式算法。三階段提交是為解決兩階段提交協(xié)議的缺點(diǎn)而設(shè)計(jì)的。與二階段提交不同的是，三階段提交是 “非阻塞” 協(xié)議。三階段提交在二階段提交的第一階段與第二階段之間插入了一個(gè)準(zhǔn)備階段，使得原先在二階段提交中，參與者在投票之后，由于協(xié)調(diào)者發(fā)生崩潰或錯(cuò)誤，而導(dǎo)致參與者處于無(wú)法知曉是否提交或者中止的 “不確定狀態(tài)” 所產(chǎn)生的可能相當(dāng)長(zhǎng)的延時(shí)的問(wèn)題得以解決。
但是，當(dāng)有網(wǎng)絡(luò)分區(qū)時(shí)，情況又會(huì)怎么樣呢?
網(wǎng)絡(luò)的兩個(gè)相互隔離的分區(qū)在超時(shí)后可能會(huì)做出兩個(gè)不同的決定，系統(tǒng)最終將會(huì)處于不一致的狀態(tài)。
所以，這時(shí)候我們得到的是相反的結(jié)果：系統(tǒng)是實(shí)時(shí)響應(yīng)的，但并不安全，因?yàn)椴煌墓?jié)點(diǎn)可以決定不同的值。
如果我們對(duì)這兩個(gè)選項(xiàng)中的任何一個(gè)都能接受，那就太好了!
如果我們希望數(shù)據(jù)始終保持一致性，并且系統(tǒng)還要能夠響應(yīng)，那么我們應(yīng)該做什么呢?
不可能結(jié)果
不可能結(jié)果 證明，實(shí)際上，在完全異步的環(huán)境中，總是終止并最終作出決定的確定性算法是不存在的，甚至可能出現(xiàn)一次故障。
譯注： 不可能結(jié)果(Impossibility result)是分布式領(lǐng)域的專業(yè)術(shù)語(yǔ)，在一個(gè)完全異步的消息傳遞分布式系統(tǒng)中，如果一個(gè)進(jìn)程有故障，那么一致性問(wèn)題是無(wú)法得到解決的。簡(jiǎn)單來(lái)說(shuō)，就是在一定的限制條件下問(wèn)題能否被解決，那么任務(wù)的不可能結(jié)果就只有兩種情況：能和不能。
從這個(gè)結(jié)果中，我們可以學(xué)到的主要內(nèi)容是：如果我們想在實(shí)踐中解決協(xié)議，我們就必須重新考慮我們的假設(shè)，以反映更為現(xiàn)實(shí)的期望!例如，我們可以設(shè)定最大消息延遲的上限，并確定系統(tǒng)可接受的失敗次數(shù)。
如果我們改變假設(shè)，那么我們就可以用多種方式來(lái)解決分布式協(xié)議!
Paxos 算法
最著名的解決方案是 Paxos 算法，眾所周知，這個(gè)算法晦澀難懂，而且難以正確實(shí)施。
它實(shí)際上是可行的，但只有在大多數(shù)節(jié)點(diǎn)都必須啟動(dòng)，且最大消息延遲是有限的情況下才可行。
在 Paxos 中，任何節(jié)點(diǎn)都可以提出一個(gè)值，在經(jīng)過(guò)“準(zhǔn)備”和“建議”階段后，所有節(jié)點(diǎn)都應(yīng)該就相同的值達(dá)成一致。
大多數(shù)節(jié)點(diǎn)都需要啟動(dòng)，因?yàn)槿绻诿總�(gè)階段中 Quorums 相交，總有有至少一個(gè)節(jié)點(diǎn)記得最近的建議是什么，這就阻止了對(duì)舊值達(dá)成一致。
為了提高算法的效率，在實(shí)際應(yīng)用中，對(duì)出事算法進(jìn)行了許多優(yōu)化�；谒鼈兯x擇的權(quán)衡，共識(shí)算法也有許多可能的變體。
例如，Leader 完成了多少工作。擁有一個(gè)強(qiáng)大的 Leader 可能是好事，但也有可能是壞事。這要取決于失敗的頻率和重新選舉的難度。另一種權(quán)衡是，我們可以容忍多少節(jié)點(diǎn)出故障，以及 Quorum 數(shù)量應(yīng)該有多少。
有些被低估的標(biāo)準(zhǔn)是算法在實(shí)踐中的可理解性和可實(shí)施性。Raft 之所以廣受歡迎，是因?yàn)樗菀桌斫猓F(xiàn)在已經(jīng)應(yīng)用于許多廣泛使用的項(xiàng)目中。
譯注： Paxos 算法是 Leslie Lamport(就是 LaTeX 中的 “La”，此人現(xiàn)在在微軟研究院)于 1990 年提出的一種基于消息傳遞的一致性算法。這個(gè)算法被認(rèn)為是類似算法中最有效的。Paxos 算法解決的問(wèn)題是一個(gè)分布式系統(tǒng)如何就某個(gè)值(決議)達(dá)成一致。一個(gè)典型的場(chǎng)景是，在一個(gè)分布式數(shù)據(jù)庫(kù)系統(tǒng)中，如果各節(jié)點(diǎn)的初始狀態(tài)一致，每個(gè)節(jié)點(diǎn)執(zhí)行相同的操作序列，那么他們最后能得到一個(gè)一致的狀態(tài)。為保證每個(gè)節(jié)點(diǎn)執(zhí)行相同的命令序列，需要在每一條指令上執(zhí)行一個(gè) “一致性算法” 以保證每個(gè)節(jié)點(diǎn)看到的指令一致。
新的權(quán)衡仍在不斷發(fā)現(xiàn)
但更有趣的是，盡管共識(shí)和協(xié)議的話題并不新鮮，但我們?nèi)匀话l(fā)現(xiàn)了許多新的優(yōu)化和權(quán)衡。
在經(jīng)典的 Paxos 算法中，大多數(shù)節(jié)點(diǎn)都需要啟動(dòng)以確保所有的 Quorum 相交。但事實(shí)證明，我們可以重新考慮并簡(jiǎn)化大多數(shù) Quorum 要求。事實(shí)證明，只有準(zhǔn)備階段和建議階段的 Quorum 相交就足矣，這為我們提供了更多的靈活性來(lái)對(duì)每個(gè)階段的 Quorum 大小和性能進(jìn)行實(shí)驗(yàn)!
重點(diǎn)是，揭示迄今為止的新性能和可用性權(quán)衡，有助于我們?cè)趯?shí)踐中擴(kuò)大選擇范圍。共識(shí)只是一個(gè)構(gòu)件塊，但它可以用來(lái)解決許多常見(jiàn)問(wèn)題，如原子廣播(atomic broadcast)、分布式鎖(distributed locks)、強(qiáng)一致性復(fù)制等等。
請(qǐng)查看 Heidi Howard 博士的論文 “Distributed Consensus Revised”，該篇論文是這方面最好的論文之一。
一致性復(fù)制?
復(fù)制(Replication)是當(dāng)今任何分布式系統(tǒng)的重要組成部分。
我們實(shí)際上可以用共識(shí)來(lái)實(shí)現(xiàn)強(qiáng)一致性復(fù)制，但它的缺點(diǎn)之一就是性能。另一方面當(dāng)然是一致性復(fù)制，這種復(fù)制速度非�？�，但在客戶端卻可以看到不一致的數(shù)據(jù)。在實(shí)踐中，我們通常會(huì)希望獲得更好的性能，同時(shí)還要保持更強(qiáng)的一致性，這可能有些棘手。
因此，在某些情況下，我們可以提出比共識(shí)更快的解決方案，而且比最終的一致性更加一致。
其中一個(gè)有趣的例子是 Aurora，它避免了對(duì) I/O 和其他一些操作達(dá)成共識(shí)。它們使用 Quorum 進(jìn)行寫(xiě)入，但不用它們來(lái)閱讀。實(shí)際上，副本可能會(huì)存儲(chǔ)不同的值，但當(dāng)客戶端執(zhí)行讀取操作時(shí)，由于數(shù)據(jù)庫(kù)維護(hù)一致性點(diǎn)，因此它可以直接查看已知數(shù)據(jù)一致的節(jié)點(diǎn)，并將正確的數(shù)據(jù)返回給客戶端。
無(wú)沖突可復(fù)制數(shù)據(jù)類型
另一個(gè)有趣的例子是無(wú)沖突可復(fù)制數(shù)據(jù)類型(Conflict Free Replicated Data Type，CRDT)。它們可以提供強(qiáng)大的最終一致性：快速讀寫(xiě)操作，甚至在網(wǎng)絡(luò)分區(qū)期間仍然保持可用，而無(wú)需使用共識(shí)或同步。然而，只有在我們能夠有解決任何并發(fā)沖突的規(guī)則時(shí)才有可能。
換句話說(shuō)，如果可以使用某些函數(shù)合并并發(fā)更新，這些可以按任意順序應(yīng)用它們，并且還可以按照我們想要的任意次數(shù)應(yīng)用它們，而不會(huì)破壞結(jié)果，那么我們就只能使用這種技術(shù)。
這是一個(gè)完全可以接受的示例，其中所有更新都是附加的，因此它們完全滿足這一要求。
另一方面，這一點(diǎn)并不明顯，因?yàn)槲覀儧](méi)有明確的規(guī)則來(lái)解決這種同時(shí)更新的沖突。
Azure Cosmos DB 使用 CRDT 在并發(fā)多主多區(qū)域?qū)懭氲暮笈_(tái)來(lái)解決沖突。Redis 和 Riak 也使用 CRDT。
故障檢測(cè)
如果我們?cè)诜植际较到y(tǒng)中進(jìn)入另一個(gè)主題，我們總會(huì)發(fā)現(xiàn)需要進(jìn)行更多的權(quán)衡。
故障檢測(cè)器 是分布式系統(tǒng)中發(fā)現(xiàn)節(jié)點(diǎn)崩潰的關(guān)鍵技術(shù)之一。它們可以應(yīng)用于協(xié)議問(wèn)題、Leader 選舉、組員協(xié)議和其他領(lǐng)域。
我們可以通過(guò)故障檢測(cè)器的“完備性”、“正確度”來(lái)衡量它們的效率。
完備性顯示了系統(tǒng)中的一些或所有節(jié)點(diǎn)是否發(fā)現(xiàn)所有故障。正確度度量故障檢測(cè)器在懷疑另一個(gè)節(jié)點(diǎn)故障可能出現(xiàn)的錯(cuò)誤級(jí)別。
事實(shí)證明，即使是不可靠的故障檢測(cè)器在實(shí)際系統(tǒng)中也是非常有用的，因?yàn)槲覀兛梢酝ㄟ^(guò)添加一種故障知識(shí)傳播到所有節(jié)點(diǎn)的“八卦”機(jī)制，來(lái)提高它們的完備性。
為什么所有這一切都很重要?
權(quán)衡可能是多種多樣的，如果我們知道如何使用它們，知道在哪里尋找它們，那么我們就可以變得非常靈活。
許多產(chǎn)品都是圍繞算法和權(quán)衡而構(gòu)建的。這些產(chǎn)品為我們做出了某些選擇，我們通過(guò)使用某些產(chǎn)品來(lái)做出選擇。未受教育的選擇可能會(huì)導(dǎo)致延遲和數(shù)據(jù)丟失。對(duì)于某些系統(tǒng)來(lái)說(shuō)，這點(diǎn)可能會(huì)導(dǎo)致客戶流失和巨額資金。對(duì)于其他系統(tǒng)來(lái)說(shuō)，它可能導(dǎo)致反應(yīng)緩慢，或者操作順序錯(cuò)誤，從而構(gòu)成了實(shí)際的生命威脅。理解你的權(quán)衡對(duì)于做出正確的選擇、了解正確的含義以及在現(xiàn)實(shí)中驗(yàn)證系統(tǒng)的正確性非常重要。
驗(yàn)證與維護(hù)現(xiàn)實(shí)中的正確性
在我們明確了抉擇和權(quán)衡之后，我們?cè)撊绾卧趯?shí)際系統(tǒng)中維護(hù)正確性呢?
系統(tǒng)模型檢查是驗(yàn)證分布式邏輯的安全性和活性(尤其是安全性)的常用選項(xiàng)之一。模型檢查很有用，因?yàn)樗剿髁讼到y(tǒng)最終可能出現(xiàn)的所有狀態(tài)�，F(xiàn)在有相當(dāng)多的工具，如 TLA+ 就非常有名，除此之外還有更多的新興技術(shù)，如語(yǔ)義感知模型檢查。
為了驗(yàn)證分布式系統(tǒng)的實(shí)際運(yùn)行實(shí)現(xiàn)的正確性，僅靠模型檢查是不夠的。
很少有項(xiàng)目會(huì)發(fā)布關(guān)于如何維護(hù)其系統(tǒng)的正確性并對(duì)其進(jìn)行驗(yàn)證的相關(guān)信息。但其中一些項(xiàng)目做到了。
例如，Kafka 的各種系統(tǒng)測(cè)試 每天都在運(yùn)行，世界上的任何人都可以檢查并查看 哪些工作符合預(yù)期，哪些工作不正常。
Cassandra 對(duì)他們的綜合測(cè)試方法寫(xiě)了一篇很棒的文章。
我真的希望，會(huì)有更多的產(chǎn)品、項(xiàng)目和系統(tǒng)能夠?qū)λ麄兺度霚y(cè)試和正確性驗(yàn)證方面的工作更加開(kāi)放。
如果我們看一下準(zhǔn)備運(yùn)行生產(chǎn)機(jī)分布式系統(tǒng)需要做些什么，就會(huì)發(fā)現(xiàn)有很多事情需要去做。
當(dāng)然，對(duì)于小范圍場(chǎng)景并確保多個(gè)服務(wù)協(xié)同工作良好，單元測(cè)試和集成測(cè)試是必不可少的。但這些還不夠!我們可以使用更多的技術(shù)。模糊測(cè)試和基于屬性的測(cè)試為你的系統(tǒng)提供了隨機(jī)生成的輸入，以確�；緦傩曰谄湟�(guī)范是正確的。實(shí)際上，我在 Microsoft 從事過(guò)一個(gè)關(guān)于模糊測(cè)試的項(xiàng)目，總體來(lái)說(shuō)，這是一個(gè)非常吸引人的話題。性能測(cè)試對(duì)收集各種組件的延遲和吞吐量的數(shù)據(jù)非常有用。故障注入有助于檢查系統(tǒng)在故障情況下是否可用，以及預(yù)期的系統(tǒng)屬性是否仍然保持正確。
綜上所述，導(dǎo)致最嚴(yán)重錯(cuò)誤的背后的大量原因，仍然是異常處理邏輯。
有些事情，我們無(wú)法完全解決。我們需要接受這樣一個(gè)事實(shí)：在我們編寫(xiě)完所有的測(cè)試和檢查之后，無(wú)論如何，錯(cuò)誤都會(huì)存在。我們是人類，再加上上下文切換，因此我們不可能知曉每一件事，有太多的活動(dòng)部分了。我們永遠(yuǎn)沒(méi)有探索過(guò)新的領(lǐng)域，如果我們害怕離開(kāi)所熟悉的領(lǐng)域，那么我們就永遠(yuǎn)不會(huì)取得進(jìn)展。但是，我們絕對(duì)可以為處理意外錯(cuò)誤做出更好的準(zhǔn)備，找到模式，并試圖解決導(dǎo)致錯(cuò)誤的原因。這就是為什么檢測(cè)代碼很重要，可觀察性也很重要。當(dāng)我們意識(shí)到這種可能性并為解決生產(chǎn)錯(cuò)誤奠定基礎(chǔ)時(shí)，就不那么可怕了。
題外話
產(chǎn)品變化很快，描述它們的一致性、彈性和性能的術(shù)語(yǔ)極其繁多�；靖拍詈蜋�(quán)衡仍然存在，并不斷積累。它們?cè)诠铝⒌那闆r下并沒(méi)有什么用處，但是了解它們，對(duì)于做出正確的選擇和在實(shí)踐中保持正確性是必不可少的。當(dāng)我們的系統(tǒng)在特定級(jí)別的響應(yīng)性和安全性有強(qiáng)烈要求的場(chǎng)景中受到信任時(shí)，正確性尤為重要。
如果你正在構(gòu)建某些內(nèi)容時(shí)，請(qǐng)捫心自問(wèn)：這會(huì)被誤解嗎?復(fù)雜性就像項(xiàng)目周?chē)囊欢路缽棄σ粯�，它使解釋、�?gòu)建、使用和改進(jìn)變得困難。試著讓你構(gòu)建的系統(tǒng)能夠被其他人理解，因?yàn)槔斫庥兄谡_性的提高。
正確性并不容易，也不是免費(fèi)的。你必須致力于此，并將其作為優(yōu)先事項(xiàng)。不僅僅是一個(gè)愿意這樣做的工程師的水平上，而是整個(gè)組織的水平。不要相信你的系統(tǒng)知識(shí)工作：測(cè)試它，驗(yàn)證它，并在事情失敗時(shí)做好準(zhǔn)備，向你的用戶和客戶展示你在演示系統(tǒng)方面投入了哪些技術(shù)和努力。
想想那些與你工作相關(guān)但沒(méi)有得到足夠重視的重要領(lǐng)域吧，如果你有機(jī)會(huì)和其他領(lǐng)域工作的其他人聊天，那就去做，了解他們?cè)诠ぷ髦兴媾R的挑戰(zhàn)，以及他們正在做出的權(quán)衡。虛心求教，與他們分享你的工作。這會(huì)幫助你成長(zhǎng)為一個(gè)更優(yōu)秀的工程師。
作者介紹：
Lena Hall，Microsoft 高級(jí)軟件工程師，從事大數(shù)據(jù)和分布式系統(tǒng)方向。曾在 Microsoft 研究院工作。同時(shí)也是一名技術(shù)演講者、機(jī)器學(xué)習(xí) ML4ALL 的組織者、Kafka 峰會(huì)的董事。
原文鏈接：Eventually Perfect Distributed Systems
標(biāo)簽： 分布式系統(tǒng) d
版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。
