分佈式架構知識算法
本文力求從分佈式基礎理論,架構設計模式,工程應用,部署運維,業界方案這幾大方面,介紹基於MSA(微服務架構)的分佈式的知識體系大綱。從而對SOA到MSA進化有個立體的認識,從概念上和工具應用上更近一步瞭解微服務分佈式的本質,身臨其境的感覺如何搭建全套微服務架構的過程。數據庫
SOA到MSA的進化設計模式
因爲業務發展到必定層度後,須要對服務進行解耦,進而把一個單一的大系統按邏輯拆分紅不一樣的子系統,經過服務接口來通信,面向服務的設計模式,最終須要總線集成服務,並且大部分時候還共享數據庫,出現單點故障的時候會致使總線層面的故障,更進一步可能會把數據庫拖垮,因此纔有了更加獨立的設計方案的出現。網絡
微服務是真正意義上的獨立服務,從服務入口到數據持久層,邏輯上都是獨立隔離的,無需服務總線來接入,但同時增長了整個分佈式系統的搭建和管理難度,須要對服務進行編排和管理,因此伴隨着微服務的興起,微服務生態的整套技術棧也須要無縫接入,才能支撐起微服務的治理理念。架構
咱們必須看一張關於一致性強弱對系統建設影響的對比圖:併發
單機環境下咱們對傳統關係型數據庫有苛刻的要求,因爲存在網絡的延遲和消息丟失,ACID即是保證事務的原則,這四大原則甚至咱們都不須要解釋出來就耳熟能詳了:運維
分佈式環境下,咱們沒法保證網絡的正常鏈接和信息的傳送,因而發展出了CAP/FLP/DLS這三個重要的理論:異步
(1)在一個部分同步網絡的模型(也就是說:網絡延時有界限可是咱們並不知道在哪裏)下運行的協議能夠容忍1/3任意(換句話說,拜占庭)錯誤;分佈式
(2)在一個異步模型中的肯定性的協議(沒有網絡延時上限)不能容錯(不過這個論文沒有提起隨機化算法能夠容忍1/3的錯誤);微服務
(3)同步模型中的協議(網絡延時能夠保證小於已知d時間)能夠,使人吃驚的,達到100%容錯,雖然對1/2的節點出錯能夠發生的狀況有所限制
多數狀況下,其實咱們也並不是必定要求強一致性,部分業務能夠容忍必定程度的延遲一致,因此爲了兼顧效率,發展出來了最終一致性理論BASE,BASE是指基本可用(Basically Available)、軟狀態( Soft State)、最終一致性( Eventual Consistency)
這些知識一部分知識,待之後學習其餘內容在作補充。
參考:https://mp.weixin.qq.com/s/izSkX-_3EShQnhc9DZatKg