【分佈式】—架構設計

1.2、分佈式架構設計

1、SOA和微服務

SOA 各模塊間相互調用，ESB來隔離各模塊，各模塊都走ESB。
特點：1.有序。2.複用。3.高效。

微服務架構：業務需要徹底的組件化和服務化
特點：1.組件化。2.按業務能力劃分服務和開發團隊。3.去中心化。4.基礎設施的自動化。

差異：1、微服務沒有強調ESB，而是到各個模塊去組件化。
          2、SOA注重的系統集成，微服務是完全獨立完全分離。

2、領域驅動設計及業務驅動劃分

3、分佈式架構的基本理論CAP、BASE以及應用

a、分佈式一致性的問題

數據一致性就是指在對一個副本數據進行更新的時候，必 須確保也能夠更新其他的 副本，否則不同副本之間的數據 將不一致


     
那麼如何去解決這個問題？按照正常的思路，我們可能會 想，既然是因爲網絡延遲導致的問題，那麼我們可以把同 步動作進行阻塞，用戶 2 在查詢的時候必須要等到數據同 步完成以後再來做。但是這個方案帶來的問題是性能會收 到非常大的影響。
所以我們沒有辦法找到一種能夠滿足數據一致性、 又不影響系統運行的性能的方案。
強一致性（保證數據一致性，但是會影響系統的性能。）、弱一致性（系統的性能很好，保證請求後有成功或失敗返回，jin儘可能的保證某個時間內數據的一致性。）最終一致性（最終一致性是弱一致性的一個特例，系統 會保證在一定時間內，能夠達到一個數據一致的狀態。是弱一致性 中非常推崇的一種一致性模型，也是業界在大型分佈式系 統的數據一致性上比較用的多的模型 ）

b、CAP

一致性(Consistency)、可用性(Availability)、分區容錯性(Partition-toleranc)

這三個基本需求，最多隻能同時滿足其中兩項_(CP/AP)_

CAP並不是一個普適性原理和指導思想，它僅 適用於原子讀寫的NoSql場景中，並不適用於數據庫系統

c、BASE

1、基本可用（搜索有1s變成2s。降級頁面（當前訪問量過多））

2、軟狀態 （狀態機） 待支付、交易處理中、交易成功、交易失敗

3、數據最終一致性 （基於MQ）

核心思想：即使無法做到強一致性，但每個 應用都可以根據自身業務特點，採用適當的方式來使系統 達到最終一致

4、什麼是分佈式架構下的高可用設計

1.避免單點故障

a、負載金恆技術（failover選址/硬件負載/軟件負載/去中心化的軟件負載（gossip（redis-cluster）））

b、熱備 （linux HA）

c、多機房（同城災備、異地災備）

2、應用的高可用性

a、故障監控（系統監控（cpu、內存）/鏈路監控/日誌監控）自動預警

b、應用的容錯設計、（服務降流、限流） 自我保護能力

c、數據量 （數據分片、讀寫分離）

5、分佈式架構下的可伸縮設計

垂直伸縮 （提升硬件能力）

水平伸縮 （增加服務器）

CDN 內容分發網絡。

6、構建高性能的分佈式架構