分佈式業務的異常解決思路

         傳統意義上的事務被定義在數據層面，它是指一組原子操做，這組原子操做必須按照既定的順序所有執行成功 。 若是某一個或者多個原子操做失敗，則回退全部以前的原子操做到原來的狀態 。
         事務的特色主要有四個：原子性（ Atomicity ）、 一致性（ Consistency ）、隔離性（ Isolation ）和持久性（ Durability ）。        

        一個標準的事務必須同時知足這四個特性，不然就沒法保持業務數據的正確性一一而且在 SQL 規範中也明肯定義了這些特性的實現標準，例如它定義了四類事務隔離級別： Read Uncommitted （讀未提交〉、 Read Committed （讀己提交）、 Repeatable Read（可重複讀 ）和 Serializable （ 可串行化〉 。
        

       傳統業務環境下這些原子數據操做都在同一個數據庫實例上完成 ， 而隨着企業中各系統的複雜度增長，就可能會出現事務跨兩個或者多個系統數據庫實例的狀況 ， 後一種事務處理機制就是常說的分佈式事務。

1.分佈式事務與兩階段提交協議（2PC）--做用於系統數據層
         兩階段提交協議（ 2PC ） 。 簡單來講這個協議中提到兩個階段是指準備階段和提交階段

         它的實現通常須要一個事務協調者來統一全部工做，協調者首先向參與事務動做的各個數據節點提交準備請求（也叫檢查請求），並等待全部參與此事務的數據節點返回確認信息。當各個數據節點收到這個準備請求後就會檢查本身是否有條件執行本身負責的處理部分，而且執行但不提交各自負責的這部分數據操做。這是一個同步過程，在收到全部節點確認信息以前協調者都不會發出下一步的執行指令， 各個節點被鎖定／預佔的資源也不會被釋放一一由於各數據節點的處理過程都未正式提交。

          若是在這個過程當中任何一個數據節點返回了「不可用」或者等待超時，那麼協調者就會向各個參與事務動做的處理節點發出「回液」指令，各個處理節點就會 回滾／釋放資源，並將回滾結果回饋給協調者 ；若是協調者收到全部處理節點「準備好」／「贊成」的信號，那麼就會進入第二個階段一一通知各個處理節點「提交」 。當各個處理節點收到第二步指令後，就會正式提交上一步已經完成的處理動做，並向協調者回饋「完成」消息 。

        分佈式事務己經有很是多的實現組件和成功案例，例如第三方組件:
       > JOTM (Java Open Transaction Manager）就是一個成熟的分佈式事務管理器，如今許多 Tomcat 服務器上都是用它提供的分佈式事務功能：
       > Atomikos 也是一款經常使用的分佈式事務管理器，也是目前配合Spring 集成的一款分佈式事務管理器 。

2.關係型數據庫的設計的 ACID 原理
         即原子性（ Atomicity ）、 一致性（ Consistency ）、隔離性（ Isolation ）和持久性（ Durability ），並且關係型數據庫廣泛採用事務技術實現 ACID原理，其中每個事務就是最小的原子操做，還能夠設置不一樣的事務級別，包括可讀未提交、可重複讀這樣的事務級別：關係型數據庫還規定了 一旦事務正確提交就不能進行數據回滾 ， 若是要繼續修改數據就只能啓動一個新的事務 。 而這一切都是爲了保證數據庫系統是一個強一致性系統。 就連架設在各個關係型數據庫實例之上的分佈式事務機制，也是爲了保證這個 目標。
         只要有任何一個參與分佈式事務過程的數據庫實例出現異常，整個分佈式事務就沒法正常提交 ，固然也就沒法完成數據寫操做 。 注意，數據是能夠在事務操做的同時進行讀操做的，即便某些節點出現了 問題其餘數據庫節點也能夠承擔這個讀操做 ， 由於這樣的操做不存在一致性改變的風險。

3.TCC (Try Commit Cancel)--做用於系統RPC層
         TCC 過程其實是 2PC 的一種變形，它與後者的關鍵區別在於 TCC 的思路着重於原子服務而非具體數據操做。 Try步驟的細分工做又包括業務檢查和資源預佔，而對於如何實現這個過程，在 TCC 中並無明確要求必須經過對持久層數據進行寫操做，這就便於架構師在服務層而非在數據層上設計 TCC 的實現。

4.CAP
         分佈式系統的知識體系中有一個很是重要的概念一一CAP 原理。這個原理指導着大多數分佈式系統的設計過程 ，
         CAP 原理大體是說分佈式系統中必定存在三個特性 ： 一 致性( Consistency ）、分區容忍性（ Partition ）和可用性（ Availability ） 。
HBase選擇了C（一致性）與P（分區可容忍性），Cassandra選擇了A（可用性）與P（分區可容忍性），HDFS 選擇了P（分區可容忍性）與A（可用性）

        分區性的要求：數據 X 至少也應該在不一樣的節點上存儲多份(至少應該有三份)，存儲的副本量越多越能保證數據 X 的安全，也越能保證即便在多個節點同時不可用的狀況下，數據 X 也一樣可以被訪問 。
        一致性的要求：當客戶端發出數據 X 的更新請求後， 從任何一個節點訪問數據 X 均可以拿到它最新的狀態。若是真要達到這麼理論的一致性要求，那就只能讓全部須要讀／寫數據 X的客戶端等待 ， 直到完成數據 X 的全部副本同步後，再依次進行響應 。 但這樣作又不知足可用性要求。
        可用性的要求：任何一個沒有發生故障的節點必須在有限的時間內返回結果。然而，若是系統可以作到當某個節點發生網絡分區後，將它從系統中剔除，由其它節點繼續提供服務。雖然沒有知足CAP中A的要求，可是，只要恢復時間足夠快，也符合高可用的要求。

5.BASE
         BASE ，即 基本可用 （ Basically Availble ）、軟狀態（ Soft State ）和最終一致（ Eventual Consistency ） ， 任何分佈式系統都不可能以 CAP 原理中三個特性同時做爲設計目標，沒有任何分區容忍性的分佈式系統甚至都不能稱爲分佈式系統。

        一致性的概念：強一致性和最終一致性 。
         強一致性能夠歸納爲任什麼時候刻客戶在分佈式系統中獲取數據 X，不管它在分佈式系統的哪一個節點進行這個操做，其獲取到的數據 X 都是一致的 。 從這個定義來看 ，分佈式事務機制就是一種強一致性的實現 。
         弱一致性不是說不保持數據的一致性，而是說不保證數據每時每刻都一致，也不承諾什麼 時候才能保證分佈式系統的任何節點都能讀取到一致的數據。而最終一致性是弱一致性的一種特定結果， 便是承諾基於弱一致性，在通過一個數據不一致的時間窗口後，最終能保證數據一致 。 這個數據不一致的時間窗口在客戶端看來很是短，並且分佈式系統還能夠經過多種方式向客戶端屏蔽不一致的數據，例
如主從副本方式 。

        BASE 的核心思路是在保證可用性和分區容忍性的前提下，找到一個犧牲一致性的程度，而最終一致性爲咱們指明瞭 這個程度一一保證數據最終一致便可。那麼對於跨系統分佈式業務咱們也能夠借鑑這個概念： 各個原子服務無須關心其餘原子服務何時執行或者執行順序，只須要各自負責本身的那部分業務，並最終完成處理便可。若是出現須要回退的狀況，則各個原子服務負責取消本身負責的那部分操做 ， 回到原始狀態 。

6.事務補償機制
         這種機制自己並不提供事務，而是在須要進行回溶操做時可以依據某種手段獲知整個執行路徑，並完成符合業務規則的逆向執行動做。爲了保證事務補償機制可以運行，業務系統提供了某個原子服務就必須提供一個和這個原子服務反向操做的另外一個原子服務，這樣才能夠保證事務補償機制在任何一個正 向執行的分佈式業務工做的環境中，都有一個與之對應的反向執行過程。

        當一個原子服務被執行時數據即時被更改，佔用資源使用後即時被釋放，執行日誌被詳細記錄。若是某一個原子服務執行失敗並非將以前未提交數據回滾，而是經過一個對應的反向服務將以前的結果逆向執行，這裏的逆向執行將從新修改數據 、 從新佔用資源、從新生成新的日誌。根據各個原子服務間的依賴性，這個執行過程既能夠是順序執行的又能夠是並行執行的。

        事務補償機制能夠經過多種方式進行實現:
         1.獨立實現一個事務補償控制模塊，井向這個模塊註冊每個正向方法和對應的逆向方法，跨系統業務由這個模塊負責執行井在出現執行錯誤的狀況下進行重試或者逆向執行：
         2.採用日誌方式進行實現，將跨系統業務的發起方和各個執行方執行的每一步寫入日誌，並在出現執行錯誤時利用日誌記錄的信息分析和執行回滾策略，最後還要經過日誌記錄整個業務是否達到了最終一致性。

        應用場景：
         事務補償機制能夠解決長耗時業務過程當中資源佔用的問題，可是仍是不能有效縮短業務執行時間 。由於在每一個原子服務執行完成後資源就被釋放了，而不是像兩階段提交協議那樣在整個業務執行完成前都須要獨佔資源。
         事務補償機制雖然部分解決了分佈式事務在業務系統的適用度問題，可是它自己也不是完美的。例如它不適用須要保證明時一致性的業務場景，

6.可靠的異步消息

可靠的異步消息系統是目前解決這類問題(電商訂單涉及多個子系統調用的問題)所經常使用的方式，
  「可靠」的定義是消息系統不會無端丟失消息，保證消息送達到指定的目標系統：
  「異步」是指消息的發送方（又稱生產方）在迭出消息後 ，無須等待消息接收方（又稱消費方）反饋任何結果便可執行後續的操做。
  典型的可靠的異步消息系統有 ActiveMQ 、 RabbitMQ 和 RocketMQ。

7.爲保持最終一致性的事務補償機制，或者又是可異步工做的可靠消息系統，在設計和使用時都須要注意問題
         1）注意重試操做：因爲分佈式業務的各個執行步驟存在於不一樣的系統中，這些系統依靠網絡進行互相通訊，因此在服務的調用過程當中不可能保證 100%成功 。 也就是說即便每一個原子服務工做正常，整個分佈式業務的工做過程也可能由於某些工做環境緣由而調用失敗，因此一旦某個原子服務調用失敗，協調者要作的事情並非當即進行業務回滾、逆向操做或者異常消息通知，而應該首先進行重試操做，這是爲了排除包括網絡抖動、主從服務切換在內的服務臨時不可用狀況 。通過必定數量的重試後，若是服務仍是不可用，則協調者再進行業務回液、逆向操做或者異常消息通知 。 以上示例代碼的客戶端並無任何的重試過程，就開始進行逆向操做了 。

        2）注意冪等性：所謂冪等性是指參與同 一個分佈式業務的各個操做步驟，不管執行多少次操做動做其結果都與執行一次操做動做後的結果一致。實際上這是對重試操做特性的一種支持，因爲重試操做在異常狀況下進行，因此誰也不能保證原子服務不會被錯誤地屢次調用，甚至不能保證請求發起者不會錯誤地重複發起同一個分佈式業務操做過程 。 例如，訂單生成時要避免重複生成的狀況發生、訂單執行過程要防止出 現重複生成配送單的狀況、訂單逆向執行的退款步驟要防止重複退款的狀況發生。

        3）注意基於日誌：日誌的做用可歸納爲事中記錄和過後回溯， 一個分佈式服務過程的每個執行步驟都應該詳細記錄日誌，不管這個過程是正向執行仍是逆向執行； 在分佈式服務執行完成後也應該記錄日誌，不管這個分佈式服務執行是否成功 。這些日誌能夠在分佈式業務執行結束後檢查最後的執行效果，在協調器出現窯機時利用日 志恢復協調器執行狀態保持執行過程的一致性，在須要進行逆向執行時也可利用日誌找到對應的回溯路徑。以以前的示例代碼來講 ， Invoker 角色中的代碼雖然能夠在某個原子服務出現異常時，按照分佈式業務對應的逆向過程進行執行，可是卻沒有使用任何辦法保證逆向過程執行的可靠性一一沒有記錄日誌 。 因此要是某個原子服務執行的逆向過程失敗，整個系統的數據一致性就沒有保證了。

        4）參與分佈式服務的各個原子服務，在沒有業務間依賴的狀況下能夠採用並行執行的方式縮短整個分佈式服務的執行時間 ，提升執行效率。

8.Hystrix與熔斷機制

        經過多種手段幫助技術人員解決系統間調用時的錯誤，防止系統雪崩效應。Hystrix 將分佈式業務的正向操做和逆向操做分離開，並經過設置最長等待時間、拋出異常等方式讓逆向操做自動執行。

關鍵點
         1）首先 Hystrix 的單次執行是以一個命令完成的，其內是一個完整的命令模式，其外向開發人員暴露的是一個命令元素（Command 角色，其實現爲HystrixCommand<R> 類或 HystrixExecutable<R>接口）。
開發人員須要實現其中的 run（）方法與getFallback（）方法

        2）Hystrix 將具體的任務（一個 Command 角色）放入線程池中執行，並且 Hystrix 中不但能夠管理 一 個線程池，還能夠爲不一樣的 Command 設置不一樣的ThreadPoo!Key ， 讓它們工做在不一樣 的線程池中

        3）Hystrix 對 Command 的執行分爲三種方式，同步執行 execute()、異步執行 queue()和帶有觀察器的執行方式 observe()

9.系統間服務調用的問題
         1）訪問權限問題： 在整個系統生態環境中，不是任何用戶均可以隨意訪問任意業務服務接口的 。 除了訪問接口的用戶組、用戶和密碼管理（或者是公私鑰文件），還須要限制用戶的訪問權限。
         2）版本控制問題： 爲了子系統可以保證 24 小時連續提供服務，就須要標註服務接口的版本號，讓以前沒有完成升級的服務節點提供／訪問老版本的服務接口：己經完成升級的服務節點提供新版本的服務接口。
         3）服務時效、次數控制問題： 各個子系統提供的服務自己也是具備時效性的。好比某一個服務 Y 只在天天早上 10 : 00～11 :00 才能提供訪問調用，且對於某個用戶來講天天只能調用 100 次。
         4）性能措施問題： 系統服務接口可以承受多大的 TPS 是衡量其性能的一個重要指標 。 可是在生產環境下，每每再高的系統接口都會遇到 TPS 瓶頸。在此種狀況下，咱們通常會準備備用手段對請求進行導流，
         5）跨平臺性問題： 在有歷史遺留狀況的系統中，或者有多個技術背景不一樣的團隊同時進行研發的大中型業務系統中，這就要求遠程業務接口可以支持多種語言客戶端的調用 。 目前對這類問題的解決方法無外乎幾種：
（1)一種是使用各開發語言都更容易理解和管理的基於網絡應用層協議的接口調用方式，例如 HTTP RESTful 形式的服務接口：
（2)一種是基於某種支持跨語言特性的RPC 組件提供接口支持，例如基於 Apache Thrift提供的服務接口 ：
（3)還有一種是代理裝置，經過這個代理裝置，將某種語言某種消息格式的調用轉換爲另 一種語言另外一種消息格式的調用，而 ESB 技術就相似於這樣一種代理裝置。

10.SOA架構
         SOA ( Service-Oriented Architecture ） 中文全稱 「面向服務的架構」 。 SOA 主要圍繞多個 「服務」如何進行集成以達到某種服務目的進行討論 。
         服務: 在業務系統中被髮布出來供用戶使用，並可以完成一個完整業務過程的功能。

           服務着眼於完整的業務：服務的定義對象是業務系統中的完整業務功能。
         服務的粒度雖然相對粗放，但倒是可控的：服務拆分的目標是保留重用度：務粒度的拆分徹底依據業務系統中業務過程進行定義和分析
         服務集成的目的是造成一個新的服務：對企業內部（或者企業間〉的業務服務進行集成，被集成的業務服務稱之爲原子服務，集成的目 的是重用這些原子服務造成一個新的服務。
         SOA 需保證屏蔽細節：從技術細節層面看，開發語言、外傳輸協議、消息格式均可以使用 SOA 進行集成與轉換；從業務細節層面看， 第三方系統只須要知道調用某一個服務就能夠達到業務目的，至於提供服務的業務系統如何實現業務過程則無須關心。
         SOA 讓各業務系統保持鬆散：經過屏蔽各業務系統技術細節和業務細節，兼容各業務系統的不一樣傳輸協議和不一樣消息格式，可讓經過 SOA進行業務集成的，各個業務系統保持低禍合狀態。

11.ESB
         SOA 架構模型是解決問題的綱領性思路，在這個規則下ESB ( Enterprise Service Bus ，企業服務總線〉是其一種具體辦法。
爲了知足 SOA 架構思想的設計要點，達到既定的工做目標， ESB 總錢技術至少須要幫助這些業務系統完成如下工做。
         · 多種調用協議的兼容支撐和轉換
         · 多種消息格式兼容支撐和轉換
         · 服務監控管理（註冊、安全、版本、優先級）：首先業務系統提供的服務可能會以－定週期發生變化，ESB可以保證在這樣的狀況下集成服務依然能夠工做；其次ESB 應該有一套完整的功能來保證服務集成的安全性和權限 。
         · 服務集成和編排：服務編排的做用就是明確原子服務執行的前後順序、判斷原子服務執行的條件、確保集成後的新服務可以按照業務設計者的要求正常工做 。

常見的 ESB 產品
1.IBM 提供了兩款純軟件的 ESB 產品 ： IBM WebSphere ESB 和 IBM WebSphere MessageBroker（WMB〉
2.Oracle Service Bus ( OSB ）是 Oracle 的付費產品，和 WMB 相似， OSB 也是全分佈式的ESB 產品
3.普元 ESB 產品是國內比較有表明性的擁有自 主產權的 ESB 產品 。
4.Mule ESB 是服務提供商 MuleSoft的產品
5.Apache Camel 是 Apache 基金會下的一個頂級開源項目，它提供了一套消息路由規則、消息轉換引擎和服務編排等能力。 不過它並無現成的消息轉換組件

12.服務治理框架
         ESB 企業總線的存在目的之一是知足企業建設過程當中新系統和遺留系統的集成問題，因此ESB 中的一個功能側重點就是協議轉換和信息轉發

        服務治理框架並不進行原子服務的真實調用，而只記錄原子服務的調用地址、權限、熔斷方案、備用路徑等信息，井在各原子服務調用時監控實時壓力 。當D 系統須要調用外圍系統時，首先會請求服務治理框架拿到真實的調用路徑 ， 再自行進行調用。

        下降了服務調用的跨平臺能力、服務編排能力和對遺留系統的集成能力，可是顯著提升了各系統間的調用吞吐量以及各系統集成到服務治理框架上的難度，很是適合互聯網系統對於輕量化和快速部署的要求。

        常見的服務治理框架軟件 1. 阿里 DUBBO 2. Spring Cloud（Config、Eureka、Hystrix、Zuul、Ribbon等）