歷史
自從20世紀60年代大型主機被髮明出來以後，憑藉其超強的計算和I/O處理能力以及在穩定性和安全性方面的卓越表現，在很長一段時間內，大型主機引領了計算機行業以及商業計算領域的發展。由於大型主機卓越的性能和良好的穩定性，其在單機處理能力方面的優勢非常明顯，使得IT系統快速進入了集中式處理階段，其對應的計算機系統稱爲集中式系統。
但從20世紀80年代以來，隨着微型計算機的出現，越來越多廉價的PC機成爲了各大IT企業架構的首選，分佈式的處理方式越來越受到業界的青睞，計算機系統正在經歷一場前所未有的從集中式到分佈式架構的變革。
主要有以下幾點原因：
-
大型主機的人才培養成本非常高，通常一臺大型主機彙集了大量精密的計算機組件，操作非常複雜，這對一個運維人員掌握其技術細節提出了非常高的要求。
-
大型主機也是非常昂貴的，通常一臺配置較好的IBM大型主機，其售價達到上百萬美元甚至更高，因此也只有像政府、金融和電信等企業纔有能力採購大型主機。
-
集中式有非常明顯的單點問題，大型主機雖然在性能和穩定性方面表現卓越，但並不代表其永遠不會出故障。一旦一臺大型主機出現了故障，那麼整個系統將處於不可用的狀態，後果相當嚴重。
-
隨着業務的不斷髮展，用戶訪問量迅速提高， 計算機系統的規模也在不斷擴大，在單一大型主機上進行擴容往往比較困難。
-
隨着PC機性能的不斷提升和網絡技術的快速普及，大型主機的市場份額變得越來越小，很多企業開始放棄原來的大型主機，而改用小型機和普通PC服務器來搭建分佈式計算機。
集中式系統架構
集中式系統就是指由一臺或多臺主計算機組成中心節點，數據集中存儲於這個中心節點中，並且整個系統的所有業務單元都集中部署在這個中心節點上，系統所有的功能均由其集中處理。也就是說，集中式系統中，每個終端或客戶端及其僅僅負責數據的錄入和輸出，而數據的存儲與控制處理完全交由主機來完成。
分佈式系統架構
分佈式系統是一個硬件或軟件組件分佈在不同的網絡計算機上，彼此之間僅僅通過消息傳遞進行通信和協調的系統。一個標準的分佈式系統在沒有任何特定業務邏輯約束的情況下，都會有以下幾個特徵：
-
分佈性
分佈式系統中的多臺計算機都會在空間上隨意分佈，這些計算機可能被放在不同的機櫃上，也可能在不同的機房中，甚至分佈在不同的城市。同時，其分佈情況也會隨時變動。 -
對等性
分佈式系統中的計算機沒有主/從之分，既沒有控制整個系統的主機，也沒有被控制的從機，組成分佈式系統的所有節點都是對等的。副本(Replica)是分佈式系統最常見的概念之一，指的是分佈式系統對數據和服務提供的一種冗餘方式。在常見的分佈式系統中，爲了對外提高可用的服務，我們往往會對數據和服務進行副本處理。數據副本是指在不同的節點上持久化同一份數據，當某一個節點上存儲的數據丟失時，可以從副本上讀取到該數據，這是解決分佈式系統數據丟失問題最爲有效的手段。另一類副本是服務副本，指多個節點提供同樣的服務，每個節點都有能力接收來自外部的請求並進行相應的處理。 -
併發性
在一個計算機網絡中，程序運行過程中的併發性操作是非常常見的行爲，例如，同一個分佈式系統的多個節點，可能會併發地操作一些共享的資源，諸如數據庫或分佈式存儲等，如何準確並高效地協調分佈式併發操作也成爲了分佈式系統架構與設計中最大的挑戰之一。 -
缺乏全局時鐘
一個典型的分佈式系統是由一系列空間上隨意分佈的多個進程組成的，具有明顯的分佈性，這些進程之間通過交換消息來進行相互通信。因此，在分佈式系統中，很難定義兩個事件究竟誰先誰後，原因就是因爲分佈式系統缺乏一個全局的始終控制序列。 -
故障總是會發生
組成分佈式系統的所有計算機，都有可能發生任何形式的故障。一個被大量工程實踐過的黃金定理是：任何在設計階段考慮到的異常情況，一定會在系統實際運行中發生，並且，在系統實際運行中還會遇到很多在設計時未考慮到的異常故障。所以，除非需求指標允許，在系統設計時不能放過任何異常情況。 -
處理單點故障
在整個分佈式系統中，如果某個角色或者功能只有某臺單機在支撐，那麼這個節點稱爲單點，其發生的故障稱爲單點故障，也就是通常說的SPoF（Single Point of Failure），避免單點而對關鍵就是把這個功能從單機實現變爲集羣實現，當然，這種變化一般會比較困難，否則就不會有單點問題了。如果不能把單點變爲集羣實現，那麼一般還有兩種選擇：1、給這個單點做好備份，能夠在出現問題時進行恢復，並且儘量做到自動恢復。2、降低單點故障的影響範圍。
集中式架構vs分佈式架構
| 核心要素 | 集中式架構 | 分佈式架構 |
|---|---|---|
| 成本 | 高 | 低 |
| 安全/自主性 | 低 | 高 |
| 靈活/兼容性 | 中 | 高 |
| 擴展/伸縮性 | 中 | 高 |
| 可用性 | 中 | 高 |
| 一致/可靠性 | 高 | 中 |
| 維護性 | 高 | 中 |
| 業務恢復 | 中 | 高 |
業務支撐能力
在集中式架構下，爲了應對更高的性能，更大的數據量，往往只能向上升級到更高配置的機器，如升級更強的 CPU，升級多核，升級內存，升級存儲等，一般這種方式被稱爲 Scale Up，但單機的性能永遠都有瓶頸,隨着業務量的增長，只能通過 Scale Out 的方式來支持，即橫向擴展出同樣架構的服務器。在集中式架構下，由於單個服務器的造價昂貴，所以 Scale Out 的方式成本非常高，無法做到按需擴展。而分佈式架構的解決方案是基於廉價的 PC Server 來做 Scale Out, 藉助高速網絡組建的 PC 集羣在整體上提供的計算能力已大幅高於傳統主機，並且成本很低，橫向的擴展性還可帶來系統良好的成長性。
分佈式架構在價格成本、自主研發、靈活兼容、伸縮擴展方面有比較顯著的優勢。互聯網行業具有請求量大，數據量大的特點，業務上又可能在集中的時間段出現高於日常流量數倍的業務高峯，這些特徵對架構的可擴展性提出了極高的要求。
可用性與一致性
集中式系統的計算、存儲都在一套硬件體系內，無需面對網絡分區（網絡無法連接）問題，能很容易實現高一致性，並通過存儲的冗餘和軟硬件結合的高度優化，達到了較高的可靠性。但在可用性方面，由於集中式架構在設計上是一個單點，單機不可用即全部不可用，所以集中式的系統只能在停機維護時暫停業務，這一點在很多互聯網場景下是難以接受的。
分佈式架構設計，天然就有多個節點，很容易通過主備（HA）、冗餘、哈希等手段實現計算和存儲冗餘備份，從而實現高可用。但是，分佈式架構多個節點的設計也帶來了保持一致性和高可靠性上的巨大挑戰。根據CAP理論，任何基於網絡的數據共享系統（即分佈式系統）最多隻能滿足數據一致性（Consistency）、可用性（Availability）和網絡分區容忍（Partition Tolerance）三個特性中的兩個。在大規模的分佈式環境下，網絡故障是常態，所以網絡分區是必須容忍的現實，只能在可用性和一致性兩者間做出選擇，即 CP 模型或者 AP 模型，實際的選擇需要通過業務場景來權衡。
對於一些離線的應用，或者對可用率不敏感的業務，可以適當犧牲可用性來保證強一致，即採用 CP 模型，這樣會大大簡化設計，系統具備不可用的發現和恢復機制就能讓系統保持正常的運轉，純粹的 CP 模型還是比較簡單，但適用場景也非常有限。更多場景需要保證提供連續可靠的服務，需要在採取AP模型的同時儘可能保證一致性。根據BASE三要素，在保證單機事務的 ACID 原則的前提下，確保全局分佈式事務的最終一致性。
運維複雜度與故障恢復能力
在發佈部署方面，集中式架構部署結構簡單，設備數量少，一般只需應對百臺內規模的代碼/配置更新，通過簡單的腳本或者平臺就可以自動化完成，發佈時間一般也能控制在小時級別。而且採用集中式架構的系統一般比較穩定，發佈週期也不會太頻繁；在分佈式環境下，千臺甚至萬臺服務器的規模很常見，如果按照傳統的串行操作和自動化腳本，整個發佈週期會非常長，一旦出現問題，回滾也會非常慢。在分佈式架構下，往往需要提供 P2P 分發或類似的技術手段來加速發佈過程，同時通過 beta 發佈、分組發佈、藍綠髮布等手段來解決大規模集羣下的發佈驗證、灰度引流和快速回滾等問題。
在系統監控方面，集中式架構比較簡單。而在分佈式環境下做監控，主要挑戰在於海量日誌的實時分析和秒級展示。系統運行的狀態分散在上萬臺規模的集羣中，每時每刻都在產生新的狀態。監控系統需要通過日誌或者消息的方式採集整個集羣的數據做各種統計分析。在巨大的業務量下，每晚一秒鐘發現問題就會帶來大量的業務異常，在極端情況下還會產生不可估量的損失。因此，也需要監控體系具備秒級的實時計算能力。
在系統的容災機制和故障恢復方面，集中式架構一般會採用主備複製和主備切換的方式來實現，幾種典型設計原則包括一主多備，同城雙活，兩地三中心等。集中式的容災方案比較成熟，也沉澱了數據複製、鏡像快照、一體化遷移等一系列容災相關的技術，可以從容應對各種場景，但仍然在以下幾個方面存在不足：
- 成本較高：在集中式架構下，經典的災備方案一般會做全量備份，在一些改進方案中會通過餘量空間做交叉互備等方式來降低成本，但整體上看還成本還是較高。爲 1% 甚至概率更低的災難場景，而付出與支撐當前業務量相等的成本，這對需要承載海量業務的互聯網業務來說更是一個巨大的負擔；
- 恢復時間較長：災備方案中大量用到數據複製技術，但由於網絡帶寬或者異地延遲等問題，在恢復時，需要等待數據完全一致後才能切換，而且無論備份數據是冷備還是熱備，切換都有一個預熱的過程。綜合切換複雜度和上述的技術限制等因素，很難縮短恢復時間。
- 業務影響面較大：由於集中式架構本身擴展性的不足，所有業務都跑在一個單點上，一旦發生故障就可能影響到所有用戶。在承載海量業務的系統上，這種影響更容易被放大，尤其在金融系統上，更有可能引發一些社會事件。
分佈式架構在容災恢復方面卻有着天然的優勢，數據天然分佈在不同的存儲、機房和城市，而且架構上容易按合適的容量進行水平拆分，隨着這幾年互聯網的高速發展，各家互聯網公司都遇到了集中式架構下災備方案的幾個痛點，並進行了類似的架構改造，一般業界稱之爲單元化改造，其本質是將分佈式下可擴展的特性運用到災備場景，這個在第四章節中有提到。這種架構能將業務影響面控制在一定的範圍內（取決於單元的大小），並通過交叉互備降低災備成本，這種機房架構下的邏輯單元具備以下三個特徵：
- 每個單元在業務處理能力上自包含，對外承載一定業務分片的業務流量，內部的系統調用鏈路和各類存儲訪問是局部化在本單元內的；
- 每個單元的實時數據是獨立不共享的，配置類數據或讀多寫少且對延時性要求不高的數據全局共享；
- 單元間的通信統一管控，儘量以異步化消息進行通信，同步調用則通過單元間代理方案實現，實現網絡上的收斂，便於監控和管控。
該架構解決了以下四個關鍵問題：
- 由於儘量減少了跨單元交互和使用異步化，使得異地部署成爲可能。整個系統的水平可伸縮性大大提高，不再依賴同城 IDC ，真正實現異地多活架構；
- 可以實現 N+1 的異地災備策略，大大縮減災備成本，同時確保災備設施真實可用；
- 整個系統已無單點存在，大大提升了整體的高可用性；同城和異地部署的多個單元可用作互備的容災設施，通過運維管控平臺進行快速切換，有機會實現 100% 的持續可用率；
- 該架構下業務級別的流量入口和出口形成了統一的可管控、可路由的控制點，整體系統的可管控能力得到很大提升。基於該架構，線上壓測、流量管控、灰度發佈等以前難以實現的運維管控模式，現在能夠十分輕鬆地實現。
總結
分佈式架構在成本、安全性、靈活性、可伸縮性等方面有明顯優勢，隨着互聯網的發展，需要處理的交易量與數據量越來越大，分佈式架構在這方面的優勢也會越來越明顯。集中式系統在可維護性、一致性方面有優勢，而分佈式系統需要達到同等或更高的可維護性與高一致性，需要通過先進的分佈式中間件與大規模運維平臺來支持。
參考博文：https://blog.csdn.net/qq_27384769/article/details/80223473
