介紹
Seata 是阿里巴巴開源的分佈式事務中間件，一種分佈式事務解決方案，具有高性能和易於使用的微服務架構。可前往：https://seata.io/zh-cn/docs/overview/what-is-seata.html進行查看
初衷
- 對業務無侵入：即減少技術架構上的微服務化所帶來的分佈式事務問題對業務的侵入
- 高性能：減少分佈式事務解決方案所帶來的性能消耗
分佈式事務產生背景
設想下面的一個場景，創建一個訂單，需要同時調用3個操作db的方法，如果放在單體應用中公用一個庫的情況，在一個事務中就可以完成全部操作，要成功全部成功，這個上可以通過事務保證的
但是隨着架構的演進和升級，單體架構已不能滿足高併發、高吞吐的要求了，微服務體系下的架構將會出現下面的這樣
很明顯，在分佈式環境下，各個服務應用都是獨立的數據庫(也可以共用，但是不建議這樣做)，在這種情況下，通常在創建一個訂單時，需要通過rpc的方式遠程調用其他的服務接口
設想仍然在創建訂單的邏輯中，通過rpc調用庫存和積分的接口，在創建訂單的事務中，庫存和積分的服務已經不屬於當前事務了，那麼一旦當某個服務調用失敗，訂單的數據可以回滾，可庫存和積分的數據怎麼回滾呢？
這只是考慮了調用兩個服務的情況，在一些大型的分佈式應用中，一個業務中調用4個5個服務的很常見，因此在微服務環境下，分佈式事務是一個很難迴避的問題。
2種情況討論
在常用的微服務化開發中，我想分兩種情況說明，我們知道，微服務要解決的一個很重要的問題是解耦，可以說解耦是將業務進行微服務化的關鍵，在如今比較成熟的微服務治理方案中，dubbo和springcloud是兩種比較成熟的可供選擇的方案，dubbo關注對內，而springcloud更多對外，這是一種使用上的劃分，這樣區分是想說明，如果微服務做的更徹底，完全是通過rpc的通信，那麼上面的分佈式事務的劃分以及對此的解決方案將會有更多的選擇
假如說，某個微服務完全不知道要調用的另一個服務的內部業務，僅僅知道接口及參數，即各自只關注自己服務內部的業務邏輯，這種情況下，要解決分佈式事務的問題，使用分佈式事務框架可能並不能很好的滿足，而是需要從架構的設計上全面考量，比如可以藉助消息中間件等
但是像本文開頭描述的情景，各個微服務來自於一個完整的業務拆分出去的，則選擇分佈式事務框架則是一個不錯的考慮
分佈式事務的實現思路
目前市面上，已經存在的關於分佈式事務解決方案，主要有兩種解決思路，JTA以及TCC
JTA可以理解爲一種規範，就像jdbc的規範，實現這一規範就可以滿足要求，比如像Jboss和weblogic，他們實現了這一規範，但是他們自身的問題很多，很難滿足移動互聯網時代下大併發、快速響應的要求
TCC，兩階段提交，可以理解爲一種設計思想，翻譯過來就是，Try , Confirm,Cancel，即嘗試，確認，取消，即在分佈式環境下，一個完整的業務要完成一些列數據庫的操作，需要經歷這幾個階段，通過這幾個階段的配合完成分佈式事務的成功，確保數據的一致性
基於TCC的思路，目前有不少大廠基於這個思想設計出了符合實際業務的架構，當然，隨着技術的發展，實現這一思路的分佈式事務中間件也應運而生，比如阿里不久前發佈的seata1.0版本，經過了一段時間的迭代和使用，目前已經開源出來。下面就seata的簡單使用進行說明(seata的詳細介紹可參閱官網:seata.io)
seata是什麼
Seata 是一款阿里巴巴團隊開源的分佈式事務解決方案，致力於提供高性能和簡單易用的分佈式事務服務。Seata 將爲用戶提供了 AT、TCC、SAGA 和 XA 事務模式，爲用戶打造一站式的分佈式解決方案。
爲什麼選擇seata
- 分佈式事務存在CAP的難題
- 阿里團隊開源，全世界程序員維護，有技術保障
- 成熟的分佈式應用，衆多的大廠使用案例
- 提供多種不同的分佈式事務實現模式(AT,TCC,Aaga)
seata常用幾種實現分佈式事務模式實現
AT模式：
- 基於支持本地 ACID 事務的關係型數據庫
- Java 應用，通過 JDBC 訪問數據庫
整體機制
兩階段提交協議的演變：
- 一階段本地事務提交前，需要確保先拿到 全局鎖
- 拿不到 全局鎖 ，不能提交本地事務。
- 拿 全局鎖 的嘗試被限制在一定範圍內，超出範圍將放棄，並回滾本地事務，釋放本地鎖
AT模式使用起來相對比較簡單，官網對此有完整的介紹，實現的思路是藉助於mysql數據庫自身的事務機制，通過維護一把全局的鎖和各自業務的鎖的方式，並藉助事務執行過程中的操作日誌來完美解決分佈式事務的問題，關於這一點有一些專業的術語可參閱官網說明
另外的一種TCC模式則是藉助TCC思想，通過編碼配合seata框架達到解決實現分佈式事務的目的，這裏就不再過多贅述
seata在AT模式下的實現思路
下面用一張圖來描述在seata的AT模式下實現本文開始提出的業務場景的解決思路
TC：事務協調者
RM：資源管理器
TM:事務管理器
按照圖中的調用流程，很好理解，seta框架裏面，規定了幾種角色，TC事務管理器用於管理全局的各個模塊的事務，我們可以想象，當在business服務中創建訂單，需要分別調用3個不同的微服務，每個微服務都要進行寫庫操作，各自都要開啓自己的本地事務，那麼對應的就是，當每個本地事務執行成功時向TC發送一個指令，告知TC本地事務的執行狀態，其他的事務也是如此，直到收到所有事務的commit指令然後進行總體提交
一旦任何一個本地事務失敗，TC收到指令，就通知所有事務進行回滾，這樣描述，TC就像zookeeper的功能，常用於協調集羣間服務的通信，其實就藉助了類似的思想
在AT模式下，實現分佈式事務需要在各個的微服務維護的數據庫中維護一張表叫做undo_log表，即通過這張表記錄了各個服務操作過程中產生的數據庫操作日誌記錄，方便數據回滾，當然這是由seata框架去完成的，我們只需要按照要求創建即可，官網也提供了這張表的sql腳本
如果用一段僞代碼來描述，則可以描述如下
business 服務 createOrder {
庫存服務 - 扣減庫存
積分服務 - 增加積分
}
AT模式下分佈式事務實現步驟
- TM端通過註解@GlobalTransactional進行全局事務的開啓、提交、回滾
- RM端seata通過擴展DataSource完成對DataSource的代理曾倩即DataSourceProxy,自動實現undo_log與TC上報
- TC端通過seata-server實現(即一個java服務，可以從官網下載)
本篇到此就要結束了，主要介紹了分佈式服務的產生和seata的簡單介紹和概念，下一篇，我們將基於本文開篇的業務場景進行具體的環境搭建與代碼演示，最後感謝觀看！