架構雜談《三》

架構雜談《三》

一致性問題

　　前面的《架構雜談一》和《架構雜談二》 雜談了從服務化到微服務架構的演進，並確定了服務化和微服務架構是一脈相承的。微服務在服務化架構的基礎上，對服務化的細節和方案進行了優化和細化，重點突出了無中心化管理的微服務架構，經過對服務進行有效的拆分來實現敏捷開發和自動化部署，並在海量用戶的請求下，提升了微服務架構下較細粒度的水平伸縮能力。

　　然而，微服務架構並非萬能的它能夠說就是一把雙刃劍，咱們在享受它帶來的便利的同時，也會遇到數據和服務之間不一致性的問題，在爲服務架構下多個服務經過非可靠的網絡通訊，如何讓服務之間高效的通訊和協做，如何解決系統之間狀態不一致等問題，這能夠說是咱們在使用微服務架構後不得不面對的問題。

一、什麼是一致性

　　一致性是一個抽象的概念，在不一樣的場景下有不一樣的含義，在傳統IT時代，一致性一般指強一致性，在雜談互聯網時代的一致性以前，咱們先了解一下互聯網時代的特色：

• 互聯網時代信息量大，須要很是強大的計算能力
• 互聯網時代要求對用戶的響應速度快，還要求吞吐量指標向外擴展（水平伸縮）

　　經過這些個互聯網時代的特色分析後，咱們發現單節點的服務器沒法知足人們的需求，服務節點開始池化。可是池化不是越多越好的（常言說，人多不必定能解決全部問題），還得有序、合理的分配任務，並有效的進行管理，因而在互聯網時代討論最多的話題就是拆分。拆分又通常分爲水平和垂直，這不單指對數據庫或者緩存的拆分，主要是表達一種分而治之的思想和邏輯

　水平拆分：因爲單一節點沒法知足性能的需求，須要擴展成多個節點，多個節點之間具備一致的功能，組成一個服務池，一個節點服務一部分的請求量，全部節點共同處理大規模的高併發的請求量。

　垂直拆分：按照功能進行拆分，把一個複雜的功能拆分紅多個單1、簡單的功能，因爲每一個功能職責單1、簡單，使得維護和變動變的更容易、簡單和安全，因此更易於產品迭代，還可以快速地進行敏捷發佈和上線。

　　在這樣的一個互聯網時代，一致性指分佈式服務化之間的弱一致性，包括應用系統的一致性和數據的一致性。

　　不管是水平仍是垂直拆分，都解決了特定場景下的特定問題，然而，拆分後的系統或者服務化的系統的最大問題就是一致性問題。

二、解決一致性問題的思路

　　一、ACID

　　　　如何保證一致性問題呢？咱們在學習關係性數據庫時都學習了ACID原理，這裏簡單的對ACID作個介紹。

　　　　A：原子性

　　　　C：一致性

　　　　 I：隔離性

　　　　D：持久性

　　　　具備ACID特性的數據庫支持強一致性，強一致性表明數據庫自己不會出現不一致，每一個事務都是原子的（要麼成功要麼失敗），事務間是隔離的，互相不受影響。最終狀態是持久的。所以，數據庫會從一個明確的狀態過渡到另一個明確的狀態，中間的臨時狀態是不會出現的。若是出現也會及時地自動修復，所以是強一致性的。然而，前面提到，互聯網項目大多數具備大規模、高併發的特性，必須使用拆分的理念。即便使用關係型數據庫，單機是難以知足存儲和吞吐量上的性能需求。因爲業務規則的限制，咱們沒法將相關數據分到同一個數據庫分片，這時就須要實現最終一致性。

　　二、CAP　

　　因爲對系統或者數據進行了拆分，咱們的系統再也不是單機系統，而是分佈式系統。針對分佈式系統的CAP原理有三個元素。

　　C：一致性。在分佈式系統中的全部數據備份，在統一時刻具備相同的值，全部節點在同一時刻讀取的數據都是最新的數據副本。（Consistency）

　　A：可用性，好的響應性能。徹底的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成並進行響應。（Availability）

　　P：分區容忍性。儘管網絡上有部分消息丟失，但系統仍然可繼續工做。（Partition tolerance）

　　CAP原理說明，任何分佈式系統只可知足以上兩點，沒法三者兼顧。因爲關係型數據庫是單節點無複製的，所以不具備分區容忍性，可是具備一致性和可用性。而分佈式的服務化系統都須要知足分區容忍性，這就須要咱們在一致性和可用性二者中進行權衡選擇。

　　三、BASE

　　eBay的架構師Dan Pritchett源於對大規模分佈式系統的實踐總結，在ACM上發表文章提出BASE理論，BASE理論是對CAP理論的延伸，核心思想是即便沒法作到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用能夠採用適合的方式達到最終一致性（Eventual Consitency）。（BASE 思想解決了CAP提出的分佈式系統的一致性和可用性不可兼得的問題）

　　BASE思想與ACID原理大相徑庭，它知足CAP原理，經過犧牲強一致性得到可用性，通常應用於服務化系統的應用層或者大數據處理系統中，經過達到最終一致性來儘可能知足業務的絕大多數需求。

　　BASE思想的三個元素。

　　BA：基本可用（Basically Available）。

　　S：軟狀態，狀態能夠在一段時間內不一樣步（Soft State）。

　　E：最終一致性，在必定的時間內，最終數據達成一致性便可。（Eventually Consistent）

　　軟狀態是實現BASE思想的方法，基本可用和最終一致性是目標。以BASE 思想實現的系統因爲不保證強一致性，因此係統在處理請求的過程當中能夠存在短暫的不一致，在短暫的不一致的時間內，請求處理處於臨時狀態中，系統在進行每步操做時，經過記錄每一個臨時狀態，在系統出現故障時能夠從這些中間狀態繼續處理未完成的請求或者退回到原始狀態，最終達到一致狀態 。

　　有了BASE 思想做爲基礎，咱們對複雜的分佈式事務進行拆解，對其中的每一個步驟記錄其狀態，有問題能夠根據記錄的狀態來繼續執行任務，達到最終一致性。

說明：

　　一、參考書籍：《分佈式服務架構：原理、設計與實戰》

　　二、若有不合適的地方請反饋。綜合後更改。