構建分散式架構的重要因素
阿新 • • 發佈：2018-11-17
一．馮諾依曼模型：
計算機體系中的經典理論-馮.諾依曼體系：計算機硬體由運算器、 控制器、儲存器、輸入裝置、輸出裝置五大部分組成。在分散式領域中，不管架 構怎麼變化，計算機仍沒有跳出該體系的範疇。
二．分散式領域中馮諾依曼模型的變化
1.輸入裝置的變化
在分散式系統架構中，輸入裝置可以分兩類，第一類是互相連線的多個節點，在接收其他節點傳來的資訊作為該節點的輸入；另一種就是傳統意義上的人機互動的輸入裝置了
2.輸出裝置的變化
輸出和輸入類似，也有兩種，一種是系統中的節點向其他節點傳輸 資訊時，該節點可以看作是輸出裝置；另一種就是傳統意義上的人 際互動的輸出裝置，比如使用者的終端
3.控制器的變化
在單機中，控制器指的是 CPU 中的控制器，在分散式系統中，控 制器主要的作用是協調或控制節點之間的動作和行為；比如硬體負 載均衡器；LVS軟負載；規則伺服器等
4.運算器
在分散式系統中，運算器是由多個節點來組成的。運用多個節點的 計算能力來協同完成整體的計算任務
5.儲存器
在分散式系統中，我們需要把承擔儲存功能的多個節點組織在一起， 組成一個整體的儲存器；比如資料庫、redis（key-value儲存）
三．分散式系統的特點
分散式系統對於集中式系統而言，在實現上會更加複雜。分散式系統將會是更難理解、設計、構建 和管理的，同 時意味著應用程式的根源問題更難發現。
1.三態
在集中式架構中，我們呼叫一個介面返回的結果只有兩種， 成 功或者失敗，但是在分散式領域中，會出現“超時”這個狀態。
2.分散式事務
事務就是一系列操作的 原子性保證，在單機的情況下，我們能夠依靠本機的資料庫連 接和元件輕易做到事務的控制，但是分散式情況下，業務原子 性操作很可能是跨服務的，這樣就導致了分散式事務的出現，例如A 和B操作分別是不同服務下的同一個事務內的操作，A調 用B，A可以清楚的知道B是否成功提交從而控制自身的 提交還是回滾操作，但是在分散式系統中呼叫會出現一個新狀 態就是超時，就是A無法知道B是成功還是失敗，這個時候A 是提交本地事務還是回滾呢？其實這是一個很難的問題，如果 強行保證事務一致性，可以採取分散式鎖，但是那樣會增加系 統複雜度而且會增大系統的開銷，而且事務跨越的服務越多， 消耗的資源越大，效能越低，所以最好的解決方案就是避免分 布式事務。 還有一種解決方案就是重試機制，但是重試如果不是查詢介面，必然涉及到資料庫的變更，如果第一次呼叫成功但是沒返回成 功結果，那麼對於呼叫方來說第二次呼叫依然是重試，但是 對於被呼叫方來說是重複呼叫。這樣的結果不 是我們期望的，因此需要在寫入的介面做冪等設計。多次呼叫 和單次呼叫是一樣的效果。通常可以設定一個唯一鍵，在寫入 的時候查詢是否已經存在，避免重複寫入。但是冪等設計的一 個前提就是服務是高可用，否則無論怎麼重試都不能呼叫返回 一個明確的結果，呼叫方會一直等待，雖然可以限制重試的次數， 但是這已經進入了異常狀態，甚至到了極端情況還是需要人 肉補償處理。其實根據CAP和BASE理論，不可能在高可用分 布式情況下做到一致性，一般都是最終一致性保證。
3.負載均衡
每個服務單獨部署，為了達到高可用，每個服務至少是兩臺機 器，因為網際網路公司一般使用可靠性不是特別高的普通機器， 長期執行宕機概率很高，所以兩臺機器能夠大大降低服務不可 用的可能性，大型專案會採用十幾臺甚至上百臺來部署一 個服務，這不僅是保證服務的高可用，更是提升服務的 QPS， 但是一個請求過來到底路由到哪臺機器？ 路由演算法很多，如DNS路由，如果session在本機，還會根據 使用者id或則cookie等資訊路由到固定的機器，當然現在應用伺服器為了擴充套件的方便都會設計為無狀態的，session 會儲存 到專有的 session 伺服器，所以不會涉及到拿不到 session 問 題。路由規則可以隨機獲取，但實際情況肯定比這個複雜，在一定範圍內隨機，但是在大的範 圍也會分為很多個域，例如如果為了保證異地多活的多機房， 跨機房呼叫的開銷太大，肯定會優先選擇同機房的服務，這個 要參考具體的機器分佈來考慮。
4.一致性
資料被分散或者複製到不同的機器上，如何保證各臺主機之間 的資料的一致性將成為一個難點。
5.故障的獨立性
分散式系統由多個節點組成，整個分散式系統完全出問題的概 率是存在的，但是在實踐中出現更多的是某個節點出問題，其 他節點都沒問題。這種情況下我們實現分散式系統時需要考慮 得更加全面些 。