分散式架構概述
隨著計算機系統規模變得越來越大，將所有的業務單元集中部署在一個或若干個大型機上的體系架構，已經越來越不能滿足當今計算機系統。同時，隨著微型計算機的出現，越來越多廉價的PC機成為了各大企業IT架構的首選，分散式的處理方式越來越受到業界的青睞。本文將介紹分散式架構的發展歷史和分散式架構的一些相關概念。
分散式架構的發展歷史
自20世紀60年代大型主機被髮明出來之後，憑藉其超強的計算和I/O處理能力，以及在穩定性和安全性方面的卓越表現，在很長一段時間內，大型主機引領了計算機行業以及商業計算領域的發展。在大型主機的研發上最知名的當屬IBM，其主導研發的革命性產物SYSTEM/360系列大型主機，是計算機發展史上的一個里程碑。
伴隨著大型主機時代的到來，集中式的計算機系統架構也成為了主流。但從20世紀80年代以來，計算機系統向網路化和微型化的發展日趨明顯，傳統的集中式處理模式越來越不能適應人們的需求。
集中式架構的劣勢：
1、通常一臺大型主機彙集了大量精密的計算機元件，操作非常複雜，導致培養一個能夠熟練運維大型主機的人的成本很高；
2、大型主機非常昂貴，一臺配置較好的IBM大型主機，其售價可能在上百萬美元，因此也只有像政府、金融和電信等企業才有能力採購大型主機；
3、集中式系統具有明顯的單點問題。一旦一臺大型主機出現了故障，那麼整個系統將處於不可用狀態；
4、在單一大型主機上進行系統的擴容往往比較困難。
"去 IOE"運動
IOE 指的是 IBM 小型機、Oracle 資料庫、EMC 的高階儲存。阿里巴巴在 2009 年發起了一項"去 IOE"運動。阿里巴巴過去一直採用的是 Oracle 資料庫，並利用小型機和高階儲存裝置提供高效能的資料處理和儲存服務。隨著業務的不斷髮展，資料量和業務量呈爆發性增長，傳統的集中式Oracle 資料庫架構在擴充套件性方面遭遇瓶頸。
分散式架構的常見概念
叢集
小飯店原來只有一個廚師，切菜洗菜備料炒菜全乾。後來客人多了，廚房一個廚師忙不過來，又請了個廚師，兩個廚師都能炒一樣的菜，這兩個廚師的關係是叢集。
分散式
為了讓廚師專心炒菜，把菜做到極致，又請了個配菜師負責切菜，備菜，備料，廚師和配菜師的關係是分散式，一個配菜師也忙不過來了，又請了個配菜師，兩個配菜師關係是叢集。
副本機制
副本(replica/copy)指在分散式系統中為資料或服務提供的冗餘。資料副本指在不同的節點上持久化同一份資料，當出現某一個節點的資料丟失時，可以從副本上讀取到資料。服務副本表示多個節點提供相同的服務，通過主從關係來實現服務的高可用方案。
分散式系統的難點
毫無疑問，分散式系統對於集中式系統而言，在實現上會更加複雜。分散式系統將會是更難理解、設計、構建和管理的，同時意味著應用程式的根源問題更難發現。
三態
在集中式架構中，我們呼叫一個介面返回的結果只有兩種，成功或者失敗，但是在分散式領域中，會出現“超時”這個狀態。
分散式事務
這是一個老生常談的問題，我們都知道事務就是對一系統操作的原子性保證。在單機的情況下，我們能夠依靠本機的資料庫連線和元件輕易做到事務的控制，但是分散式情況下，業務原子性操作很可能是跨服務的，這樣就導致了分散式事務。
例如 A和 B 操作分別是不同服務下的同一個事務操作內的操作，A 呼叫 B，A 如果可以清楚的知道 B 是否成功提交從而控制自身的提交還是回滾操作，但是在分散式系統中呼叫會出現一個新狀態就是超時，就是 A 無法知道 B 是成功還是失敗，這個時候 A是提交本地事務還是回滾呢？其實這是一個很難的問題，如果強行保證事務一致性，可以採取分散式鎖，但是那樣會增加系統複雜度而且會增大系統的開銷，而且事務跨越的服務越多，消耗的資源越大，效能越低，所以最好的解決方案就是避免分散式事務。
還有一種解決方案就是重試機制，但是重試如果不是查詢介面，必然涉及到資料庫的變更，如果第一次呼叫成功但是沒返回成功結果，那呼叫方第二次呼叫對呼叫方來說依然是重試，但是對於被呼叫方來說是重複呼叫，例如 A 向 B 轉賬，A-100，B + 100，這樣會導致 A 扣了 100，而 B 增加 200。這樣的結果不是我們期望的，因此需在要寫入的介面做冪等設計。多次呼叫和單次呼叫是一樣的效果。通常可以設定一個唯一鍵，在寫入的時候查詢是否已經存在，避免重複寫入。但是冪等設計的一個前提就是服務是高可用，否則無論怎麼重試都不能呼叫返回一個明確的結果呼叫方會一直等待，雖然可以限制重試的次數，但是這已經進入了異常狀態了。根據 CAP 和 BASE 理論，不可能在分散式情況下做到高可用和強一致性，一般都是保證最終一致性。
負載均衡
每個服務單獨部署，為了達到高可用，每個服務至少是兩臺機器，因為網際網路公司一般使用可靠性不是特別高的普通機器，長期執行宕機概率很高，所以兩臺機器能夠大大降低服務不可用的可能性，這正大型專案會採用十幾臺甚至上百臺來部署一個服務，這不僅是保證服務的高可用，更是提升服務的QPS。但是這樣又帶來一個問題，一個請求過來到底該路由到哪臺機器？
一致性
資料被分散或者複製到不同的機器上，如何保證各臺主機之間的資料的一致性將成為一個難點。
節點故障
分散式系統由多個節點組成，整個分散式系統完全出問題的概率是存在的，但是更多的情況是某個節點出問題。這種情況下我們實現分散式系統時需要考慮的問題。