多執行緒與分散式 三、分散式基礎
什麼是分散式？
權威定義：
利用物理架構形成多個自治的處理元素，不共享記憶體，但是通過傳送資訊合作。——Leslie Lamport
分散式的作用
實際工作中的痛點
- 工程臃腫
- 測試、上線繁瑣
- 開發效率低
單體應用的問題
- 應用程式碼耦合嚴重，功能擴充套件難
- 新需求開發互動週期長，測試工作量大
- 新加入的開發同事需要很長時間才能熟悉系統
- 升級維護也很困難（改動任何一點地方都要升級整個系統）
- 系統性能提升艱難，可用性低，不穩定
分散式的好處
- 增大系統容量
- 加強系統可用
- 因為模組化，所以系統模組重用度更高
- 因為軟體服務模組被拆分，開發和釋出速度可以並行並變得更快
- 系統擴充套件性更高
- 團隊協作流程也會得到改善
- 技術升級
分散式和單體結構的對比
| 傳統單體架構 | 分散式架構 | |
|---|---|---|
| 新人的學習成本 | 業務邏輯成本高 | 架構邏輯成本高 |
| 部署、運維 | 容易 | 釋出頻繁、釋出順序複雜、運維難 |
| 隔離性 | 一損俱損，殃及魚池 | 故障影響範圍小 |
| 架構設計 | 難度低 | 難度指數級上升 |
| 系統性能 | 響應快、吞度量小 | 響應慢、吞吐量大 |
| 測試成本 | 低 | 很高 |
| 技術多樣性 | 技術單一且封閉 | 技術多樣且開放 |
| 系統擴充套件性 | 擴充套件性差 | 擴充套件性很好 |
| 系統管理成本 | 成本低 | 成本高 |
CAP定理
CAP
-
C(Consistency ，一致性)：讀操作是否總能讀到前一個寫操作的結果
-
A(Availability ，可用性)：非故障節點應該在合理的時間內作出合理的響應
-
P(Partition tolerance ，分割槽容錯性)：當出現網路分割槽現象後，系統能夠繼續執行，即網路斷開，不能互相通訊時的情況
-
三者最多隻能選其二，不可兼得
CAP怎麼選
什麼時候可用性高於一致性？
- 有一個網站，一更新沒必要所有人都同步，可以稍微延遲一點，但是要求無論何時訪問網站，都能看得到
什麼場合一致性高於可用性？
- 支付場合，可以允許暫時不可用，但是決不允許不一致
叢集: 是對整個系統複製多份，部署到不同的伺服器上，用於分散壓力。
分散式: 是把系統拆分成子系統，部署到不同的伺服器上，用於分散能力。
實際專案中通常是分散式+叢集部署。
叢集、分散式、微服務的區別
叢集和分散式的區別
分散式：一個業務拆分多個子業務，部署在不同的伺服器上（模組中相互通訊）
叢集：同一個業務，部署在多個伺服器上（一個單體服務部署到多臺機器上，每個叢集都是一套程式碼，通過負載均衡去排程。不同機器可以不通訊。就像每個店各有一個廚師）
叢集和微服務的區別
叢集：分散壓力（把壓力通過複製機器的方式分散出去）微服務：分散能力（把能力拆分）
微服務和分散式的區別
微服務是架構設計方式，按邏輯角度對架構進行拆分，是邏輯架構。把大服務拆除小服務，獨立部署，服務間通過通訊進行呼叫，每個服務獨立開發測試
分散式是系統部署的方式，機器和機器間會遇到哪些通訊上的問題，如何容錯，考慮物理架構
先做邏輯架構，再做物理架構
分散式的拆分
分散式的核心就一個字：拆。只要是將一個專案拆分成了多個模組，並將這些模組分開部署，那就算是分散式。有兩種拆分方式：水平拆分，或垂直拆分。
水平拆分
-
將一個專案根據“三層架構”拆分成表示層（JSP+Servlet） 、業務邏輯層（Service） 和資料訪問層（DAO），然後再分開部署：把表示層部署在伺服器A上，把Service和DAO層部署在伺服器B上，然後伺服器A和伺服器B之間通過dubbo等RPC進行進行整合。
-
這種不是微服務的架構設計，但是使用的分散式部署。
垂直拆分
-
將專案拆分成幾個模組，例如使用者模組，訂單模組等，分別部署到各個伺服器上，
-
這種屬於微服務的架構設計，並且使用分散式部署。