隨著計算機系統規模變得越來越大，將所有的業務單元集中部署在一個或若干個大型機上的體系結構，已經越來越不能滿足當今計算機系統，尤其是大型互聯網系統的快速發展，各種靈活多變的系統架構模型層出不窮。分佈式的處理方式越來越受到業界的青睞——計算機系統正在經歷一場前所未有的從集中式向分佈式架構的變革。
集中式與分佈式
集中式系統
所謂的集中式系統就是指由一臺或多臺主計算機組成中心節點，數據集中存儲於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統的所有功能均由其集中處理。
集中式系統的最大的特點就是部署結構非常簡單，底層一般採用從IBM、HP等廠商購買到的昂貴的大型主機。因此無需考慮如何對服務進行多節點的部署，也就不用考慮各節點之間的分佈式協作問題。但是，由於採用單機部署，很可能帶來系統大而複雜、難於維護、發生單點故障（單個點發生故障的時候會波及到整個系統或者網絡，從而導致整個系統或者網絡的癱瘓）、擴展性差等問題。
分佈式系統
分佈式系統是一個硬件或軟件組件分佈在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。簡單來說就是一群獨立計算機集合共同對外提供服務，但是對於系統的用戶來說，就像是一臺計算機在提供服務一樣。分佈式意味著可以採用更多的普通計算機（相對於昂貴的大型機）組成分佈式集群對外提供服務。計算機越多，CPU、內存、存儲資源等也就越多，能夠處理的併發訪問量也就越大。
從分佈式系統的概念中我們知道，各個主機之間通信和協調主要通過網絡進行，所以分佈式系統中的計算機在空間上幾乎沒有任何限制，這些計算機可能被放在不同的機櫃上，也可能被部署在不同的機房中，還可能在不同的城市中，對於大型的網站甚至可能分佈在不同的國家和地區。但是，無論空間上如何分佈，一個標準的分佈式系統應該具有以下幾個主要特徵：
分佈性
分佈式系統中的多臺計算機之間在空間位置上可以隨意分佈，同時，機器的分佈情況也會隨時變動。
對等性
分佈式系統中的計算機沒有主／從之分，即沒有控制整個系統的主機，也沒有被控制的從機，組成分佈式系統的所有計算機節點都是對等的。副本（Replica）是分佈式系統最常見的概念之一，指的是分佈式系統對數據和服務提供的一種冗餘方式。在常見的分佈式系統中，為了對外提供高可用的服務，我們往往會對數據和服務進行副本處理。數據副本是指在不同節點上持久化同一份數據，當某一個節點上存儲的數據丟失時，可以從副本上讀取該數據，這是解決分佈式系統數據丟失問題最為有效的手段。另一類副本是服務副本，指多個節點提供同樣的服務，每個節點都有能力接收來自外部的請求並進行相應的處理。
併發性
在一個計算機網絡中，程序運行過程的併發性操作是非常常見的行為。例如同一個分佈式系統中的多個節點，可能會併發地操作一些共享的資源，如何準確並高效地協調分佈式併發操作也成為了分佈式系統架構與設計中最大的挑戰之一。
缺乏全局時鐘
在分佈式系統中，很難定義兩個事件究竟誰先誰後，原因就是因為分佈式系統缺乏一個全局的時鐘序列控制。
故障總是會發生
組成分佈式系統的所有計算機，都有可能發生任何形式的故障。除非需求指標允許，在系統設計時不能放過任何異常情況。
分佈式系統面臨的問題
通信異常
分佈式系統需要在各個節點之間進行網絡通信，因此網絡通信都會伴隨著網絡不可用的風險或是系統不可用都會導致最終分佈式系統無法順利完成一次網絡通信。另外，即使分佈式系統各節點之間的網絡通信能夠正常進行，其延時也會遠大於單機操作，會影響消息的收發的過程，因此消息丟失和消息延遲變得非常普遍。
網絡分區
當網絡由於發生異常情況，導致分佈式系統中部分節點之間的網絡延時不斷增大，最終導致組成分佈式系統的所有節點中，只有部分節點之間能夠進行正常通信，而另一些節點則不能——我們將這個現象稱為網絡分區，就是俗稱的“腦裂”。當網絡分區出現時，分佈式系統會出現局部小集群，在極端情況下，這些局部小集群會獨立完成原本需要整個分佈式才能完成的功能，這就對分佈式一致性提出類非常大的挑戰。
三態
分佈式系統的每一次請求與響應，存在特有的“三態”概念，即成功、失敗與超時。當出現超時現象時，網絡通信的發起方是無法確定當前請求是否被成功處理的。
節點故障
節點故障則是分佈式環境下另一個比較常見的問題，指的是組成分佈式系統的服務器節點出現的宕機或“僵死”現象。
分佈式事務
在單機數據庫中，我們很容易能夠實現一套滿足ACID特性的事務處理系統，但在分佈式數據庫中，數據分散在不同的機器上，如何對這些數據進行分佈式的事務處理具有非常大的挑戰。但是在分佈式計算領域，為了保證分佈式應用程序的可靠性，分佈式事務是無法迴避的。
分佈式事務是指事務的參與者、支持的服務器、資源服務器以及事務管理器分別位於分佈式系統的不同節點之上。通常一個分佈式事務中會涉及對多個數據源或業務系統的操作。一個最典型的分佈式事務場景：一個跨銀行的轉賬操作涉及調用兩個異地的銀行服務，其中一個是本地銀行提供的取款服務，另一個則是目標銀行提供的存款服務，這兩個服務本身是無狀態並且是互相獨立的，共同構成了一個完整的分佈式事務。
對於一個高訪問量、高併發的互聯網分佈式系統來說，如果我們期望實現一套嚴格滿足ACID特性的分佈式事務，很可能出現的情況就是在系統的可用性和嚴格一致性之間出現衝突——因為當我們要求分佈式系統具有嚴格一致性時，很可能就需要犧牲掉系統的可用性。但毋庸置疑的一點是，可用性又是一個所有消費者不允許我們討價還價的系統屬性，比如淘寶網這樣在線網站就要求能夠7*24小時不間斷地對外提供服務，而對於一致性，則更加是所有消費者對於一個軟件系統的剛需。因此，在可用性和一致性之間永遠無法存在一個兩全其美的方案，於是如何構建一個兼顧可用性和一致性的分佈式系統成為了無數工程師探討的難題，出現了諸如CAP和BASE這樣的分佈式系統經典理論。
CAP定理
CAP理論告訴我們，一個分佈式系統不可能同時滿足一致性（C：Consistency）、可用性（A：Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時滿足其中的兩項。
一致性
在分佈式環境中，一致性是指數據在多個副本之間是否能夠保持一致性的特性。在一致性的需求下，當一個系統在數據一致性的狀態下執行更新操作後，應該保證系統的數據仍然處於一致的狀態。在分佈式系統中，如果能夠做到針對一個數據項的更新操作執行成功後，所有的用戶都可以讀取到其最新的值，那麼這樣的系統被認為具有強一致性（或嚴格的一致性）。
可用性
可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。
分區容錯性
分區容錯性約束了一個分佈式系統需要具有如下特性：分佈式系統遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性的可用性的服務，除非是整個網絡環境環境都發生了故障。需要注意的是，組成一個分佈式系統的每個節點的加入與退出都可以看作是一個特殊的網絡分區。
在進行對CAP定理的應用時，我們就需要拋棄其中的一項，下表是拋棄CAP定理中任意一項特性的場景說明。
對於一個分佈式系統，分區容錯性可以說是一個最基本的要求。既然是分佈式系統，那麼分佈式系統中的組件必然需要被部署到不同的節點，否則也就無所謂分佈式系統了，因此必然出現子網絡。而對於分佈式系統而言，網絡問題又是一個必定會出現的異常情況，因此分區容錯性也就稱為了一個分佈式系統必然需要面對和解決的問題。因此係統架構設計師往往需要把精力花在如何根據業務特點在C（一致性）和A（可用性）之間尋求平衡。
BASE理論
BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的簡寫，是由eBay的架構師提出的。BASE是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）
基本可用
基本可用是指分佈式系統在出現不可預知故障的時候，允許損失部分可用性——但請注意，這絕不等價於系統不可用。“基本可用”的典型例子：
1、響應時間上損失：正常情況下，一個在線搜索引擎需要在0.5秒之內返回給用戶相應的查詢結果，但由於出現故障，查詢結果的響應
時間增加到了1-2秒。
2、功能上的損失：正常情況下，在一個電子商務網站上進行購物，消費者幾乎能夠順利地完成每一筆訂單，但是在大促購物高峰的時候，由於消費
者的購物行為激增，為了保護購物系統的穩定性，部分消費者可能被引導到一個降級頁面。
弱狀態
弱狀態也稱為軟狀態，和硬狀態相對，是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
最終一致性
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
如果想對Java分佈式、高併發、微服務等技術感興趣可以加我的架構進階群：574683650，群裡有阿里大牛分享經驗。
最近沒有什麼時間給大家更新，因為在研究區塊鏈，本人也在學習，學習是不分階段的。。
閱讀更多 Java後端架構 的文章
