站在全局角度看，分布式系統(tǒng)的本質(zhì)是什么？其實說白了，就是兩點：“分治”和“冗余”。分治和冗余使得分布式系統(tǒng)具備了核心價值，那么它的價值是什么？

這一篇中，我們將聊聊分布式系統(tǒng)的本質(zhì)。 分布式系統(tǒng)的價值 談到分布式系統(tǒng)的價值，可能就得從 1953 年說起了。在這一年，埃布·格羅希（Herb Grosch）提出了一個他觀察得出的規(guī)律——Grosch 定律。維基百科中是這樣描述的： 計算機性能隨著成本的平方而增加。如果計算機 A 的成本是計算機 B 的兩倍，那么計算機 A 的速度應(yīng)該是計算機 B 的四倍。 這一論斷與當(dāng)時的大型機技術(shù)非常吻合，因而使得許多機構(gòu)都盡其所能購買最大的單個大型機。其實，這也非常符合慣性思維，簡單粗暴。 然而，1965 年高登·摩爾（Gordon Moore）提出了摩爾定律。經(jīng)過幾年的發(fā)展，人們發(fā)現(xiàn)摩爾定律的預(yù)測是符合現(xiàn)實的。這就意味著，集中式系統(tǒng)的運算能力每隔一段時間才能提升一倍。 那么，到底要隔多久呢？這個“時間”有很多版本，比如廣為流傳的 18 個月版本，以及 Gordon Moore 本人堅持的 2 年版本。這里我們不用太過糾結(jié)于實際情況到底是哪個“時間”版本，因為這其中隱含的意思更重要，即：如果你的系統(tǒng)需承載的計算量的增長速度大于摩爾定律的預(yù)測，那么在未來的某一個時間點，集中式系統(tǒng)將無法承載你所需的計算量。 而這只是一個內(nèi)在因素，真正推動分布式系統(tǒng)發(fā)展的催化劑是“經(jīng)濟”因素。 人們發(fā)現(xiàn)，用廉價機器的集合組成的分布式系統(tǒng)，除了可以獲得超過 CPU 發(fā)展速度的性能外，花費更低，具有更好的性價比，并且還可以根據(jù)需要增加或者減少所需機器的數(shù)量。 所以，我們得到一個新結(jié)論：無論是要以低價格獲得普通的性能，還是要以較高的價格獲得極高的性能，分布式系統(tǒng)都能夠滿足。并且受規(guī)模效應(yīng)的影響，系統(tǒng)越大，性價比帶來的收益越高。 之后，進入到互聯(lián)網(wǎng)快速發(fā)展的時期，我們看到了分布式系統(tǒng)相比集中式系統(tǒng)的另一個更明顯的優(yōu)勢：更高的可用性。例如，有 10 個能夠承載 10000 流量的相同的節(jié)點，如果其中的 2 個掛了，只要實際流量不超過 8000，系統(tǒng)依然能夠正常運轉(zhuǎn)。 而這一切的價值，都是建立在分布式系統(tǒng)的“分治”和“冗余”之上的。 分 治 分治，字面意思是“分而治之”，和我們的大腦在解決問題時的思考方式是一樣的。我們可以將整個過程分為 3 步：分解 -> 治理 -> 歸并。而分治思想的表現(xiàn)形式多樣，分層、分塊都是它的體現(xiàn)。

這么做的好處是：問題越小越容易被解決，并且，只要解決了所有子問題，父問題就都可以被解決了。但是，這么做的時候，需要滿足一個最重要的條件：不同分支上的子問題，不能相互依賴，需要各自獨立。因為一旦包含了依賴關(guān)系，子問題和父問題之間就失去了可以被“歸并”的意義。在軟件開發(fā)領(lǐng)域，我們把這個概念稱為“耦合度”和“內(nèi)聚度”，這兩個度量概念非常重要。 耦合度，指的是軟件模塊之間相互依賴的程度。比如，每次調(diào)用方法 A 之后都需要同步調(diào)用方法 B，那么此時方法 A 和 B 間的耦合度是高的。 內(nèi)聚度，指的是模塊內(nèi)的元素具有的共同點的相似程度。比如，一個類中的多個方法有很多的共同之處，都是做支付相關(guān)的處理，那么這個類的內(nèi)聚度是高的。 內(nèi)聚度通常與耦合度形成對比。低耦合通常與高內(nèi)聚相關(guān)，反之亦然。 所以，當(dāng)你打算進行分治的時候，耦合度和內(nèi)聚度就是需要考慮的重點。 下面我們來看個例子，體會一下耦合度和內(nèi)聚度的含義。（圖僅用于表達含義，切勿作其他參考） 假設(shè)一個電商平臺，為了應(yīng)對更大的訪問量，需要拆分一個同時包含商品、促銷的系統(tǒng)。如果垂直拆分，是這樣：

假如我們面對的場景僅僅是具體的商品詳情展示頁面，很顯然，用水平拆分的效果會更好。因為傳統(tǒng)的商品展示必然會同時展示促銷，所以，如果用水平拆分，一次請求即可獲取所有數(shù)據(jù)，內(nèi)聚度非常高，并且此時模塊間完全沒有耦合。而如果是垂直拆分的話，就需要同時請求 2 個節(jié)點的數(shù)據(jù)并進行組合，因此耦合度更高、內(nèi)聚度更差。 但是，這樣的假設(shè)在真實的電商場景中是不存在的。從全局來看，訂單、購物車、商品列表等許多其他場景也需要促銷信息。并且這個時候我們發(fā)現(xiàn)引入了一些新的主體，諸如訂單、購物車、商品分類等等。這個時候，水平拆分帶來的好處越來越小，因為這樣只解決了多個耦合中的一個，低耦合喪失了。并且隨著商品和促銷與外界的關(guān)聯(lián)越來越多，必然有些場景僅僅涉及到商品和促銷的其中一個，但是處理的時候，我們還需要避免受到另一個的影響。如此，高內(nèi)聚也喪失了。 這個時候，反而通過垂直拆分可以獲得更優(yōu)的耦合度和內(nèi)聚度，如下圖。

這個時候，最高的耦合關(guān)系從原先的 6 降到了 4，并且商品和促銷各自的處理相互不受影響。 所以，你會發(fā)現(xiàn)隨著業(yè)務(wù)的變化，耦合度與內(nèi)聚度也會發(fā)生變化。因此，及時地進行梳理和調(diào)整，可以避免系統(tǒng)的復(fù)雜度快速增長，才能最大程度的發(fā)揮“分治”帶來的好處。 綜上，分治可以簡化解題的難度，通過高內(nèi)聚、低耦合的協(xié)作關(guān)系達到更好“性能與經(jīng)濟比”，來承載更大的流量。而“冗余”則帶來了系統(tǒng)可以 7*24 小時不間斷運作的希望。 冗 余 這里的冗余并不等同于代碼的冗余、無意義的重復(fù)勞動，而是我們有意去做的、人為增加的重復(fù)部分。其目的是容許在一定范圍內(nèi)出現(xiàn)故障，而系統(tǒng)不受影響，如下圖。

此時，我們可以將冗余的節(jié)點部署在一個獨立的環(huán)境中。這個獨立的環(huán)境，可能是處于同一個局域網(wǎng)內(nèi)的不同主機，也可能是在不同的局域網(wǎng)，還可能是在不同的機房。很顯然，它們能夠應(yīng)對的故障范圍是逐步遞增的。 但是，像這種單純地為了備用而做的冗余，最大的弊端是，如果沒有出現(xiàn)故障，那么冗余的這部分資源就白白浪費了，不能發(fā)揮任何作用。所以，我們才提出了諸如雙主多活、讀寫分離之類的概念，以提高資源利用率。 當(dāng)然，除了軟件層面，硬件層面的冗余也是同樣的道理。比如，磁盤陣列可以容忍幾塊之內(nèi)磁盤損壞，而不會影響整體。 不過也很顯然，當(dāng)故障影響范圍大于你冗余的容量時，系統(tǒng)依然會掛。所以，既然你無法預(yù)知故障的發(fā)生情況，那么做冗余的時候需要平衡的另一端就是成本。相比更多的冗余，追求更好的性價比更合理一些。 在我們生活中的冗余也到處存在。比如，大部分的飛機和直升機的發(fā)動機都是偶數(shù)的，汽車中的電子控制系統(tǒng)的冗余機制等。就好比替身與真身的關(guān)系，冗余的就是替身。它可以和真身同時活動，也可以代替真身活動。 分治和冗余講究的都是分散化，最終形成一個完整的系統(tǒng)還需要將它們“連接”起來。天下沒有免費的午餐，獲得分布式系統(tǒng)價值的同時，這個“再連接”的過程就是我們相比集中式系統(tǒng)要做的額外工作。 再連接 如何將拆分后的各個節(jié)點再次連接起來，從模式上來說，主要是去中心化與中心化之分。

前者完全消除了中心節(jié)點故障帶來的全盤出錯的風(fēng)險，卻帶來了更高的節(jié)點間協(xié)作成本。后者通過中心節(jié)點的集中式管理大大降低了協(xié)作成本，但是一旦中心節(jié)點故障則全盤出錯。 另外，從技術(shù)角度來說，如何選擇通信協(xié)議和序列化機制，也是非常重要的。

雖然很多通訊協(xié)議和序列化機制完全可以承擔(dān)任何場景的連接責(zé)任，但是不同的協(xié)議和序列化機制在適合的場景下才能發(fā)揮它最大的優(yōu)勢。比如，需要更高性能的場景運用 TCP 協(xié)議優(yōu)于 HTTP 協(xié)議；需要更高吞吐量的場景運用 UDP 協(xié)議優(yōu)于 TCP 協(xié)議，等等。 總 結(jié) 不管系統(tǒng)的規(guī)模發(fā)展到多大，合理地拆分，加上合適的連接方式，那么至少會是一個運轉(zhuǎn)順暢、協(xié)作舒服的系統(tǒng)，至少能夠正常發(fā)揮分布式系統(tǒng)應(yīng)有的價值。 如今，我們發(fā)現(xiàn)分布式系統(tǒng)還可以發(fā)揮更多的作用。 比如，只要基于一個統(tǒng)一的上層通信協(xié)議，其下層的不同節(jié)點可以運用不同的技術(shù)棧來發(fā)揮不同技術(shù)各自的優(yōu)勢，比如用 Go 來應(yīng)對高并發(fā)場景，用 Python 來做數(shù)據(jù)分析等。 再比如，提高交付的速度，如下圖。

通過分配不同的團隊、人員同時進行多個模塊的開發(fā)，雖然總的耗時增加了，但是整體的交付速度加快了。 事物最本質(zhì)的東西是恒定的、不變的，可以指引我們的工作方向。分布式系統(tǒng)的本質(zhì)也是這樣。例如，這樣的“分治”方案耦合度和內(nèi)聚度是否最優(yōu)，這樣做“冗余”帶來的收益是否成本能夠接受。只要持續(xù)帶著這些思考，我們就好像拿著一桿秤，基于它，我們就可以去衡量各種變量影響，然后作權(quán)衡。比如成本、時間、人員、性能、易維護等等。也可以基于它去判斷什么樣的框架、組件、協(xié)議更適合當(dāng)前的環(huán)境。 需要不斷的權(quán)衡，也意味著分布式系統(tǒng)的設(shè)計工作一定不是一步到位，而是循序漸進的。因為過分為未知的未來做更多的考量，最終可能都會打水漂。所以，建議以多考慮 1~2 步為宜。假如以你所在的團隊中對重大技術(shù)升級的頻率來作為參考的話，做可供 2 個升級周期的設(shè)計，花一個升級周期的時間先實現(xiàn)第一階段，下個階段可以選擇直接實現(xiàn)剩下部分，也可繼續(xù)進行 2 個升級周期設(shè)計，開啟一個循環(huán)，持續(xù)迭代，并且不斷修正方向以更貼近現(xiàn)實的發(fā)展，就如下圖這樣。

在你的工作或者學(xué)習(xí)中，覺得分布式系統(tǒng)還具備哪些價值呢？可以在下方評論區(qū)留言。 本文彩蛋學(xué)習(xí)分布式系統(tǒng)架構(gòu)不是一件易事，但如果有人能推薦一些學(xué)習(xí)書籍、經(jīng)典資料，想必能讓這個過程變得更加事半功倍一點。你可以在 InfoQ 后臺回復(fù)關(guān)鍵詞：分布式，獲取技術(shù)博主左耳朵耗子推薦的分布式系統(tǒng)架構(gòu)經(jīng)典資料