組件化、分布式、服務化、微服務、CAP定論、BASE


組件化、分佈式、服務化、微服務、CAP定論、BASE

組件化和模塊化

中心思想都是分而治之。目的都是將一個

龐大的系統拆分成多個組件或者說是模塊

組件化

將一個大的軟件系統按照分離關注點的形式,拆分成多個獨立的組件,主要目的就是減少耦合。一個獨立的組件可以是一個軟件包、web服務、web資源或者是封裝了一些函數的模塊。這樣,獨立出來的組件可以單獨維護和升級而不會影響到其他的組件。

模塊化

目的在於將一個程序按照其功能做拆分,分成相互獨立的模塊,以便於每個模塊只包含與其功能相關的內容,模塊之間通過接口調用。將一個大的系統模塊化之後,每個模塊都可以被高度複用

集中式與分佈式

集中式

一個主機帶多個終端。終端沒有數據處理能力,僅負責數據的錄入和輸出。而運算、存儲等全部在主機上進行。採用採用單機部署。

分佈式

分佈式意味著可以採用更多的普通計算機組成分佈式集群對外提供服務。把不同的模塊部署到不同的機器上,各個模塊之間通過遠程服務調用(RPC)等方式進行通信。

服務化

服務化架構使搭建分佈式系統成為了可能。服務化是一種粗粒度、松耦合的以服務為中心的架構,服務之間通過定義明確的協議和接口進行通信。這裡說到的“服務”,本質上來說,就是指“RPC”。但是在一個複雜的業務環境,如何管理和協同這些大量的RPC才是最麻煩的事情。所以,一般提到的“服務化”更多指的是對RPC的管理

。服務化一般關注服務註冊,服務協調,服務可用性,服務通訊協議和內容交換等。

微服務架構

通過將功能分散到各個離散的服務中以實現對解決方案的解耦。重點就是業務系統需要徹底的組件化和服務化。微服務不再強調傳統SOA架構裡面比較重的ESB企業服務總線。微服務把所有的“思考”邏輯包括路由、消息解析等放在服務內部,去掉一個大一統的ESB,服務間輕通信,是比SOA更徹底的拆分。

CAP定論

一個分佈式系統最多隻能同時滿足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)這三項中的兩項。

C一致性即更新操作成功並返回客戶端完成後,所有節點在同一時間的數據完全一致。

A可用性服務一直可用,而且是正常響應時間。

P分區容錯性即分佈式系統在遇到某節點或網絡分區故障的時候,仍然能夠對外提供滿足一致性和可用性的服務。

  1. 對於多數大型互聯網應用的場景,一般保證滿足P和A,捨棄C(一致性無法保證,退而求其次保證最終一致性)。雖然某些地方會影響客戶體驗,但沒達到造成用戶流失的嚴重程度。如原來同步架構的時候如果沒有庫存,就馬上告訴客戶庫存不足無法下單。但在微服務框架下訂單和庫存可能是兩個微服務對應兩個數據庫,用戶下單時訂單服務是立即生成的,很可能過了一會系統通知你訂單被取消掉(最終一致性)。就像搶購“小米手機”一樣,幾十萬人在排隊,排了很久告訴你沒貨了,明天再來吧。
  2. 對於涉及到錢財這樣不能有一絲讓步的場景,C必須保證。網絡發生故障寧可停止服務,這是保證CA,捨棄P。
  3. 還有一種是保證CP,捨棄A。例如網絡故障事只讀不寫。

BASE

BASE 是 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)三個短語的縮寫。是對CAP中AP的一個擴展

  1. 基本可用:分佈式系統在出現故障時,允許損失部分可用功能,保證核心功能可用。
  2. 軟狀態:允許系統中存在中間狀態,這個狀態不影響系統可用性,這裡指的是CAP中的不一致。
  3. 最終一致:最終一致是指經過一段時間後,所有節點數據都將會達到一致。

BASE解決了CAP中理論沒有網絡延遲,在BASE中用軟狀態和最終一致,保證了延遲後的一致性。BASE和 ACID 是相反的,它完全不同於ACID的強一致性模型,而是通過犧牲強一致性來獲得可用性,並允許數據在一段時間內是不一致的,但最終達到一致狀態


分享到:


相關文章: