分佈式架構知識

分佈式架構知識算法

本文力求從分佈式基礎理論,架構設計模式,工程應用,部署運維,業界方案這幾大方面,介紹基於MSA(微服務架構)的分佈式的知識體系大綱。從而對SOA到MSA進化有個立體的認識,從概念上和工具應用上更近一步瞭解微服務分佈式的本質,身臨其境的感覺如何搭建全套微服務架構的過程。數據庫

SOA到MSA的進化設計模式

SOA面向服務架構

因爲業務發展到必定層度後,須要對服務進行解耦,進而把一個單一的大系統按邏輯拆分紅不一樣的子系統,經過服務接口來通信,面向服務的設計模式,最終須要總線集成服務,並且大部分時候還共享數據庫,出現單點故障的時候會致使總線層面的故障,更進一步可能會把數據庫拖垮,因此纔有了更加獨立的設計方案的出現。網絡

MSA微服務架構

微服務是真正意義上的獨立服務,從服務入口到數據持久層,邏輯上都是獨立隔離的,無需服務總線來接入,但同時增長了整個分佈式系統的搭建和管理難度,須要對服務進行編排和管理,因此伴隨着微服務的興起,微服務生態的整套技術棧也須要無縫接入,才能支撐起微服務的治理理念。架構

一致性理論

咱們必須看一張關於一致性強弱對系統建設影響的對比圖:併發

 

 

強一致性ACID

單機環境下咱們對傳統關係型數據庫有苛刻的要求,因爲存在網絡的延遲和消息丟失,ACID即是保證事務的原則,這四大原則甚至咱們都不須要解釋出來就耳熟能詳了:運維

  • Atomicity:原子性,一個事務中的全部操做,要麼所有完成,要麼所有不完成,不會結束在中間某個環節。
  • Consistency:一致性,在事務開始以前和事務結束之後,數據庫的完整性沒有被破壞。
  • Isolation:隔離性,數據庫容許多個併發事務同時對其數據進行讀寫和修改的能力,隔離性能夠防止多個事務併發執行時因爲交叉執行而致使數據的不一致。
  • Durabilit:事務處理結束後,對數據的修改就是永久的,即使系統故障也不會丟失。

分佈式一致性CAP

分佈式環境下,咱們沒法保證網絡的正常鏈接和信息的傳送,因而發展出了CAP/FLP/DLS這三個重要的理論:異步

  • CAP:分佈式計算系統不可能同時確保一致性(Consistency)、可用性(Availablity)和分區容忍性(Partition)。
  • FLP:在異步環境中,若是節點間的網絡延遲沒有上限,只要有一個惡意的節點存在,就沒有算法能在有限的時間內達成共識。
  • DLS:

(1)在一個部分同步網絡的模型(也就是說:網絡延時有界限可是咱們並不知道在哪裏)下運行的協議能夠容忍1/3任意(換句話說,拜占庭)錯誤;分佈式

(2)在一個異步模型中的肯定性的協議(沒有網絡延時上限)不能容錯(不過這個論文沒有提起隨機化算法能夠容忍1/3的錯誤);微服務

(3)同步模型中的協議(網絡延時能夠保證小於已知d時間)能夠,使人吃驚的,達到100%容錯,雖然對1/2的節點出錯能夠發生的狀況有所限制

弱一致性BASE

多數狀況下,其實咱們也並不是必定要求強一致性,部分業務能夠容忍必定程度的延遲一致,因此爲了兼顧效率,發展出來了最終一致性理論BASE,BASE是指基本可用(Basically Available)、軟狀態( Soft State)、最終一致性( Eventual Consistency)

  • 基本可用(Basically Available):基本可用是指分佈式系統在出現故障的時候,容許損失部分可用性,即保證核心可用。
  • 軟狀態(Soft State):軟狀態是指容許系統存在中間狀態,而該中間狀態不會影響系統總體可用性。分佈式存儲中通常一份數據至少會有三個副本,容許不一樣節點間副本同步的延時就是軟狀態的體現。
  • 最終一致性(Eventual Consistency):最終一致性是指系統中的全部數據副本通過必定時間後,最終可以達到一致的狀態。弱一致性和強一致性相反,最終一致性是弱一致性的一種特殊狀況。

這些知識一部分知識,待之後學習其餘內容在作補充。

參考:https://mp.weixin.qq.com/s/izSkX-_3EShQnhc9DZatKg

相關文章
相關標籤/搜索