架構雜談《三》
一致性問題
前面的《架構雜談一》和《架構雜談二》 雜談了從服務化到微服務架構的演進，並肯定了服務化和微服務架構是一脈相承的。微服務在服務化架構的基礎上，對服務化的細節和方案進行了優化和細化，重點突出了無中心化管理的微服務架構，通過對服務進行有效的拆分來實現敏捷開發和自動化部署，並在海量使用者的請求下，提高了微服務架構下較細粒度的水平伸縮能力。
然而，微服務架構並不是萬能的它可以說就是一把雙刃劍，我們在享受它帶來的便利的同時，也會遇到資料和服務之間不一致性的問題，在為服務架構下多個服務通過非可靠的網路通訊，如何讓服務之間高效的通訊和協作，如何解決系統之間狀態不一致等問題，這可以說是我們在使用微服務架構後不得不面對的問題。
1、什麼是一致性
一致性是一個抽象的概念，在不同的場景下有不同的含義，在傳統IT時代，一致性通常指強一致性，在雜談網際網路時代的一致性之前，我們先了解一下網際網路時代的特點：
- 網際網路時代資訊量大，需要非常強大的計算能力
- 網際網路時代要求對使用者的響應速度快，還要求吞吐量指標向外擴充套件（水平伸縮）
通過這些個網際網路時代的特點分析後，我們發現單節點的伺服器無法滿足人們的需求，服務節點開始池化。但是池化不是越多越好的（常言說，人多不一定能解決所有問題），還得有序、合理的分配任務，並有效的進行管理，於是在網際網路時代討論最多的話題就是拆分。拆分又一般分為水平和垂直，這不單指對資料庫或者快取的拆分，主要是表達一種分而治之的思想和邏輯
水平拆分：由於單一節點無法滿足效能的需求，需要擴充套件成多個節點，多個節點之間具有一致的功能，組成一個服務池，一個節點服務一部分的請求量，所有節點共同處理大規模的高併發的請求量。
垂直拆分：按照功能進行拆分，把一個複雜的功能拆分成多個單一、簡單的功能，由於每個功能職責單一、簡單，使得維護和變更變的更容易、簡單和安全，所以更易於產品迭代，還能夠快速地進行敏捷釋出和上線。
在這樣的一個網際網路時代，一致性指分散式服務化之間的弱一致性，包括應用系統的一致性和資料的一致性。
無論是水平還是垂直拆分，都解決了特定場景下的特定問題，然而，拆分後的系統或者服務化的系統的最大問題就是一致性問題。
2、解決一致性問題的思路
1、ACID
如何保證一致性問題呢？我們在學習關係性資料庫時都學習了ACID原理，這裡簡單的對ACID做個介紹。
A：原子性
C：一致性
I：隔離性
D：永續性
具有ACID特性的資料庫支援強一致性，強一致性代表資料庫本身不會出現不一致，每個事務都是原子的（要麼成功要麼失敗），事務間是隔離的，互相不受影響。最終狀態是持久的。因此，資料庫會從一個明確的狀態過渡到另外一個明確的狀態，中間的臨時狀態是不會出現的。如果出現也會及時地自動修復，因此是強一致性的。然而，前面提到，網際網路專案大多數具有大規模、高併發的特性，必須使用拆分的理念。即使使用關係型資料庫，單機是難以滿足儲存和吞吐量上的效能需求。由於業務規則的限制，我們無法將相關資料分到同一個資料庫分片，這時就需要實現最終一致性。
2、CAP
由於對系統或者資料進行了拆分，我們的系統不再是單機系統，而是分散式系統。針對分散式系統的CAP原理有三個元素。
C：一致性。在分散式系統中的所有資料備份，在統一時刻具有相同的值，所有節點在同一時刻讀取的資料都是最新的資料副本。（Consistency）
A：可用性，好的響應效能。完全的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成並進行響應。（Availability）
P：分割槽容忍性。儘管網路上有部分訊息丟失，但系統仍然可繼續工作。（Partition tolerance）
CAP原理說明，任何分散式系統只可滿足以上兩點，無法三者兼顧。由於關係型資料庫是單節點無複製的，因此不具有分割槽容忍性，但是具有一致性和可用性。而分散式的服務化系統都需要滿足分割槽容忍性，這就需要我們在一致性和可用性兩者中進行權衡選擇。
3、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 思想作為基礎，我們對複雜的分散式事務進行拆解，對其中的每個步驟記錄其狀態，有問題可以根據記錄的狀態來繼續執行任務，達到最終一致性。
說明：
1、參考書籍：《分散式服務架構：原理、設計與實戰》
2、如有不合適的地方請反饋。綜合後更改。
