建站
咨詢
售后
建站咨詢
新聞中心
譯者 | 崔皓
目前成都創(chuàng)新互聯(lián)公司已為1000多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬主機、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、深澤網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
策劃 | 云昭
分布式系統(tǒng)設(shè)計是一個難題，難就難在設(shè)計過程中是不會提供直接反饋的。往往有些問題的產(chǎn)生是來源于設(shè)計的，例如：可擴展性問題、彈性問題、數(shù)據(jù)問題。然而，通常的解決方案是治標不治本——僅僅對系統(tǒng)進行修補以使其保持運行，但是潛在的設(shè)計問題仍然存在，并且可能在不同的情況下再次爆發(fā)。當系統(tǒng)在生產(chǎn)環(huán)境中出現(xiàn)故障，再去分析與設(shè)計相關(guān)的根本原因就需要付出更多的努力，同時會引來大量的組織爭論。
和分布式系統(tǒng)代碼審查一樣，本文會給出簡單的清單，列出在審查分布式系統(tǒng)功能（多個系統(tǒng)協(xié)同工作）的設(shè)計時要注意的事項。
本文會從三個方面考慮分布式設(shè)計問題：一致性與可用性、域耦合以及可觀察性。前兩者經(jīng)常相互泄漏，因為分布式系統(tǒng)就像一個復(fù)雜的網(wǎng)格，每個設(shè)計選擇都會影響其他多個事物。每個方面的問題都可以作為一個大主題來討論，因此以下指南代表了對任何設(shè)計審查的底線。
根據(jù)問題的用例對應(yīng)上下文，檢查完這些基礎(chǔ)知識后，就可以針對研究特定方向進行深入研究了。相反，如果在檢查中發(fā)現(xiàn)問題，那就需要格外小心了。
一致性或可用性
需要提前聲明的是本文中的“系統(tǒng)”是指一組獨立系統(tǒng)，多個這樣的“系統(tǒng)”以不同的方式協(xié)作為用戶提供最終服務(wù)。一致性與可用性是針對多個協(xié)作系統(tǒng)而言的。
CPA定理告訴我們，我們可以根據(jù)系統(tǒng)的一致性、可用性和分區(qū)容錯性，然后選擇其中任意兩個。如果說分區(qū)容錯生活的一部分，也就是無法避免的。那么CAP 定理的真正選擇就會落到一致性和可用性之間了—也就是選擇“AP”系統(tǒng)（在分區(qū)容錯下的可用性）或者個“CP”系統(tǒng)（在分區(qū)容錯下的一致性）。
軟件架構(gòu)的一個基本規(guī)則是所有軟件都會失敗。假設(shè)需要保持三個組件之間的一致性才能使設(shè)計的功能正常工作。這種做法會使得該功能變得脆弱，因為如果任何一個組件都有可能出現(xiàn)故障，一旦出現(xiàn)故障該功能就無法正常工作。此時我們需要面對“單點故障”問題了 ——實際上我們有三個有可能出現(xiàn)故障的組件?。?！當我們努力保持使整個系統(tǒng)的一致性時，就越容易讓它在最輕微的影響下發(fā)生故障。保持同步的組件越多，這種情況就越糟糕。
幸運的是，對于這個問題是有解的。
在單個系統(tǒng)中，CP 和 AP是二元選擇的（例如 MySQL 是一致的，Cassandra 不是），也就是非此即彼的關(guān)系。但在分布式系統(tǒng)中，卻并非如此它們之間并不是非黑即白，而是存在灰度地帶。每個組件可能會保持一致性（訂單、庫存和付款），但整個系統(tǒng)角度來看可以設(shè)計成保持最終一致性。這種方式也給我們留有余地，從而增強系統(tǒng)的可用性。由此我們的指導(dǎo)方針就是設(shè)計整體系統(tǒng)的可用性，即便個別子系統(tǒng)存在不可用的情況，隨著時間的推移也可以實現(xiàn)整個系統(tǒng)的可用性。
使用異步消息進行通信
它幫我們消除一致性壓力的有力武器，異步消息通信的引入有利于將可用性和特性作為ReactiveManifesto的主要準則?？紤]使組件之間的異步通信（通過消息代理傳遞消息），而不是直接使用請求-響應(yīng)式 API 調(diào)用。如果說同步通信是硅谷的可卡因的話，那么同步API調(diào)用就是分布式系統(tǒng)設(shè)計的可卡因?？梢运伎家幌隆绻麅蓚€系統(tǒng)不必保持一致，那么我們?yōu)槭裁匆ㄟ^同步的方式立即完成調(diào)用呢？（正如同步通信模型所要求的那樣）。請求-響應(yīng)模型創(chuàng)建了一種時間耦合形式（“立即服務(wù)這個請求！”）在調(diào)用者和被調(diào)用者之間，如果后者出現(xiàn)不可用的狀況，就會導(dǎo)致調(diào)用者的調(diào)用失敗，從而會導(dǎo)致調(diào)用者的級聯(lián)故障。異步通信允許被調(diào)用系統(tǒng)按照自己的節(jié)奏處理請求，從而減輕可用性的壓力。
雖然異步消息傳遞是一個強大的工具，但在采用它時必須牢記以下幾件事。
定義最低可接受的用戶體驗——對于每個最終用戶體驗，定義最低的一致的體驗。例如，用戶贏得了在線游戲，是否必須以全有或全無的方式記入獎勵積分、獎勵他在排行榜上的新位置、并通知他的所有朋友以及向他發(fā)送通知呢？很明顯，如果我們越能在核心、一致的體驗之外做更多的事情，遇到系統(tǒng)故障的可能性就越小。在討論需求時，必須對此毫不留情，并且支持它所需的最低要求——其他一切都應(yīng)該通過異步完成。
通過這個示例，我們可以根據(jù)在線游戲的各個與用戶相關(guān)的環(huán)節(jié)進行拆解，并且進行設(shè)計。獎勵得分不一定在游戲結(jié)束的時候才給予，而是可以在游戲過程中通過異步的方式更新積分。同理：排行榜、和發(fā)送通知的功能也可以異步進行。這些東西需要在需求設(shè)計階段就定義好，只要在滿足用戶最低要求的游戲體驗的情況下，將各個游戲步驟進行拆解異步就好了。
保證最終一致性：無論單個用戶操作還是客戶端請求都可以跨多個組件修改數(shù)據(jù)，因此需要通過設(shè)計應(yīng)保證所有系統(tǒng)將在某個指定時間對用戶請求達成共識——即使是通過分布式回滾的方式進行。
系統(tǒng)地保證 SLA 的一致性：它是非常有價值的，可能有一個最終一致性的計劃，但是如果沒有設(shè)置和執(zhí)行設(shè)定時間框架的機制，就不可能從緩慢的處理中檢測到故障。由于我們無法確定事件在處理過程中是否引發(fā)錯誤或消息是否在網(wǎng)絡(luò)中丟失，因此需要通過明確的時間硬綁定來維持最終的一致性保證。
域耦合
好分布式系統(tǒng)設(shè)計會在正確的抽象級別將不同的事物進行拆分。拆分之后的分隔線被稱為域邊界，并且使用獨特的溝通語言和域特有的功能接口來對域邊界進行標識。例如，消息代理域會封裝消息、交付保證、存儲媒體等信息。支付域會封裝交易、支付網(wǎng)關(guān)等信息。
雖然這這里會提到到微服務(wù)中界限上下文的概念，但這一概念是廣泛適用的。例如，支付可以是一個域，其中支付網(wǎng)關(guān)和交易可以支付域的子域。
根據(jù)域設(shè)計的概念來進行分布式系統(tǒng)架構(gòu)，其主要思想是在同一級別對域進行解耦，同時在父域級別建立內(nèi)聚。例如，在上面的示例中，試圖讓支付網(wǎng)關(guān)和事務(wù)在實現(xiàn)時盡可能相互分離，不過作為同一域的一部分應(yīng)該要求術(shù)語和數(shù)據(jù)模型保持一致性。
創(chuàng)建域邊界：隨著微服務(wù)采用率的大幅上升，通過底層技術(shù)分離的方式來識別組件域的方式就顯得尤為重要來。識別哪些組件屬于哪個域以及外部系統(tǒng)如何與這些系統(tǒng)通信也是很重要的。我們可能會使用多種服務(wù)來處理貨物（跟蹤服務(wù)、掃描服務(wù)、審計服務(wù)等），但外部用戶應(yīng)該使用有聚合的“物流”域?qū)嶓w和API來訪問域中的功能組件。構(gòu)建域邊界的最好工具是API 網(wǎng)關(guān)，它可以透過域本身抽象出更高級別API 背后的內(nèi)部細節(jié)。
使用標準領(lǐng)域語言在系統(tǒng)之間進行通信：兩個組件之間的交流應(yīng)該通過：現(xiàn)有實體 + 實體的狀態(tài) +實體可能執(zhí)行操作 的方式進行，不要去創(chuàng)建一些不屬于兩個域的構(gòu)造然后讓它們進行通信?？梢允褂猛ㄐ烹p方的構(gòu)造來實現(xiàn)這一點，這取決于我們想要事件還是消息。如果您發(fā)現(xiàn)兩個組件之間的通信需要創(chuàng)建某種特殊語言，那么就意味著組件的拆分方式存在問題，或者需要通過中間組件，該組件存在于這兩個組件之間，利用中間組件的方式讓兩個組件進行通信。
將多域/多組件操作分離到工作流中——有一種域耦合發(fā)生的常見方式，即當一個組件開始對多組件工作流進行端到端控制。這意味著當前域知道各種其他域、以及它們的行為和其邊界之外的“工作流”的性質(zhì)。這種意識使組件與現(xiàn)有工作流耦合，因此難以擴展。
如果一個功能需要調(diào)用多個組件，應(yīng)該將此功能從對應(yīng)的域核心服務(wù)中分離出來，并將其劃為有狀態(tài)的組件。該組件可以應(yīng)用到專用的編排服務(wù)或某種BPM 系統(tǒng)中。有狀態(tài)的組件意味著可以從一個地方獲得重試、錯誤報告、SLA等諸多信息。
如果我們不能對所有事情都使用顯式編排，使用編排來構(gòu)建工作流也是一個可行的選擇，但需要使用某種方式來跟蹤任務(wù)完成SLA，以減少長期工作流的脆弱性。
跨組件建模業(yè)務(wù)流程：上述觀點的一個推論是，我們應(yīng)該對業(yè)務(wù)流程進行端到端建模，而不應(yīng)該考慮技術(shù)邊界。由于我們已經(jīng)通過轉(zhuǎn)移編排到工作流的方式來解耦域，因此在狹窄的團隊邊界內(nèi)構(gòu)建工作流是沒有意義的。應(yīng)該使工作流盡可能多地包含整個業(yè)務(wù)流程——這將建立業(yè)務(wù)知識的中央存儲庫，并提供對運營狀態(tài)的可見性。
事件優(yōu)先與消息：解耦域更喜歡使用 pub-sub（發(fā)布訂閱） 模型的事件功能，而不是目標消息。雖然這取決于許多其他因素，但它增強了對其他域的不可知性，因為發(fā)布者不關(guān)心pub-sub 模型中的消費者，因此消除了發(fā)布者和消費者域之間的耦合。
可觀察性
用Charity Majors的話來說，可觀察性可以用來回答有關(guān)系統(tǒng)的新問題，同時無需窺視系統(tǒng)內(nèi)部的能力。我認為可觀察性分為兩種：技術(shù)和業(yè)務(wù)。我們應(yīng)該能夠解釋系統(tǒng)的技術(shù)狀態(tài)，并且可以通過業(yè)務(wù)指標來確定它的運行狀態(tài)。
使用事件數(shù)據(jù)來構(gòu)建度量：任何系統(tǒng)的基本工作單元是事件，系統(tǒng)會用自己的領(lǐng)域語言來解釋事件。事件可以是任何類型（例如ORDER_CREATED、REQUEST_RECEIVED、ERROR_RESPONSE_RETURNED）。一個有追求的想法是，我們會將整個系統(tǒng)信息建模，并通過發(fā)送事件的方式與外部系統(tǒng)進行通訊，同時對事件進行保存和分析用以獲取更多的信息，而不是通過常見的日志跟蹤方式來獲取信息。擁有原始事件數(shù)據(jù)的好處是可以與領(lǐng)域建模方法同步，并且可以隨時使用原始數(shù)據(jù)并獲取新的指標。這比瀏覽非結(jié)構(gòu)化文本日志、Spans、traces和任意Prometheus/Statsd 類型指標的組合要好得多。
將原始數(shù)據(jù)存儲在一個中心位置：遵守上面給出的可觀察性定義的唯一方法是存儲來自系統(tǒng)的原始數(shù)據(jù)，因為當我們開始只處理預(yù)定義的指標時，就被它們束縛而失去了回答“新”問題的能力。反對使用原始數(shù)據(jù)的一個常見觀點就是需要更多的容量存儲它們，但可以采取一些方法緩解容量的問題（例如：采樣等），反過來看原始數(shù)據(jù)的存儲在面對新的故障時，為系統(tǒng)提供的診斷能力就顯得無價了。在分布式系統(tǒng)中，將可觀察性數(shù)據(jù)集中存放顯然比存放在分布式孤島中要好的多，這樣更加利于提升對整體系統(tǒng)的洞察力。
一般準則
使用異步框架來實現(xiàn)——我之前寫過關(guān)于如何使用異步編程來擴展系統(tǒng)。因此，在調(diào)用遠程系統(tǒng)時，應(yīng)該確保以異步方式進行，以免阻塞應(yīng)用程序線程。這需要在早期的實現(xiàn)/設(shè)計中考慮，如果應(yīng)用程序框架不允許這樣做，或者應(yīng)用程序的基本框架不是為此而設(shè)計的，那么您就不走運了。如果您可以選擇異步，請始終接受它——當意外的流量激增時，您的系統(tǒng)和您的團隊會感謝您。
了解你的調(diào)用者——根據(jù)定義，沒有人會為分布式系統(tǒng)負責。因此，我們應(yīng)該對內(nèi)部系統(tǒng)采取盡可能多的預(yù)防措施，就像對外部系統(tǒng)采取的措施一樣。如果可以的話，其中至少要強制執(zhí)行速率限制，同時要了解您的調(diào)用者。這將有助于在出現(xiàn)問題時，隔離問題的根源——當系統(tǒng)著火時使用才使用IP 地址識別源頭就太晚了。
知道何時失敗——我已經(jīng)談了很多關(guān)于如何讓系統(tǒng)在不同條件下保持可用性的問題了。但在某些情況下，失敗總比做錯事要好。在許多情況下，一致性是完全可以接受的選擇，我們應(yīng)該小心不要過度補償它們。
譯者介紹
崔皓，社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗，10年分布式架構(gòu)經(jīng)驗。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過60萬?！斗植际郊軜?gòu)原理與實踐》作者。
分享文章：如何衡量分布式系統(tǒng)的好壞？
網(wǎng)頁路徑：http://www.5511xx.com/article/dhpehsc.html
