csdn: https://blog.csdn.net/zyndev/article/details/79604395
Spring Cloud 分布式事務管理
在微服務如火如荼的情況下，越來越多的項目開始嘗試改造成微服務架構(gòu)，微服務即帶來了項目開發(fā)的方便性，又提高了運維難度以及網(wǎng)絡不可靠的概率.
[TOC]
在說微服務的優(yōu)缺點時，有對比才會更加明顯，首先說一下單體式結(jié)構(gòu)
單體式架構(gòu)
在單體式架構(gòu)中，系統(tǒng)通常采用分層架構(gòu)模式（MVC），持久化層、表示層，業(yè)務邏輯層。架構(gòu)主要存在以下問題：
- 系統(tǒng)內(nèi)部互相訪問，耦合緊密導致難以維護；
- 各業(yè)務領(lǐng)域需要采用相同的技術(shù)棧，難以快速應用新技術(shù)（例如使用SSH很難向SSM改造）；
- 對系統(tǒng)的任何修改都必須整個系統(tǒng)一起重新部署/升級；
- 在系統(tǒng)負載增加時，難以進行水平擴展；
- 當系統(tǒng)中一處出現(xiàn)問題，會影響整個系統(tǒng)；
為了克服以上缺點，微服務架構(gòu)應運而生。微服務，又叫微服務架構(gòu)。微服務就是一些協(xié)同工作的小而自治的服務.
微服務架構(gòu)
優(yōu)點:
1. 技術(shù)異構(gòu)性
在不同的服務中，可以使用不同的技術(shù)來各自開發(fā)，只要保證服務間能相互協(xié)作即可
2. 彈性
當微服務中的某一個服務不可用時，不會影響整個系統(tǒng)，只會影響相關(guān)功能不可用
3. 擴展
易于擴展，使用小的多個服務，更加易于擴展新的功能
4. 簡化部署
某個服務的更新部署，不需要重新部署整個應用
5. 可組合
通過組合多個服務，可以提供一些新的功能
6. 可替代
因為每個微服務都比較小，重新實現(xiàn)某一個服務或者直接刪除該服務都是可操作的
缺點:
1. 復雜度高
微服務間通過REST、RPC等形式交互，相對于單體模式，需要考慮被調(diào)用方故障、過載、消息丟失等各種異常情況，代碼邏輯更加復雜。
對于微服務間的事務性操作，因為不同的微服務采用了不同的數(shù)據(jù)庫，將無法利用數(shù)據(jù)庫本身的事務機制保證一致性，需要引入二階段提交等技術(shù)。
同時，在微服務間存在少部分共用功能但又無法提取成微服務時，各個微服務對于這部分功能通常需要重復開發(fā)，或至少要做代碼復制，以避免微服務間的耦合，增加了開發(fā)成本。
2. 運維復雜
在采用微服務架構(gòu)時，系統(tǒng)由多個獨立運行的微服務構(gòu)成，需要一個設計良好的監(jiān)控系統(tǒng)對各個微服務的運行狀態(tài)進行監(jiān)控。運維人員需要對系統(tǒng)有細致的了解才對夠更好的運維系統(tǒng)。
3. 影響性能
相對于單體架構(gòu)，微服務的間通過REST、RPC等形式進行交互，通信的時延會受到較大的影響。
分布式事務的引入
正如上面所說
對于微服務間的事務性操作，因為不同的微服務采用了不同的數(shù)據(jù)庫，將無法利用數(shù)據(jù)庫本身的事務機制保證一致性，需要引入二階段提交等技術(shù)。
在單體項目中，很容易做到事務控制，而在多個服務之間很難實現(xiàn)
假設服務調(diào)用如下：
A B C D 的事務均在各個服務控制，如何做到，統(tǒng)一協(xié)調(diào)，保證數(shù)據(jù)的一致性？
分布式事務解決方案
基于XA協(xié)議的兩階段提交
XA是一個分布式事務協(xié)議，由提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫都實現(xiàn)了XA接口，而事務管理器作為全局的調(diào)度者，負責各個本地資源的提交和回滾。XA實現(xiàn)分布式事務的原理如下：
第一階段：
第二階段:
總的來說，XA協(xié)議比較簡單，而且一旦商業(yè)數(shù)據(jù)庫實現(xiàn)了XA協(xié)議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無法滿足高并發(fā)場景。XA目前在商業(yè)數(shù)據(jù)庫支持的比較理想，在mysql數(shù)據(jù)庫中支持的不太理想，mysql的XA實現(xiàn)，沒有記錄prepare階段日志，主備切換回導致主庫與備庫數(shù)據(jù)不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。
消息事務+最終一致性
所謂的消息事務就是基于消息中間件的兩階段提交，本質(zhì)上是對消息中間件的一種特殊利用，它是將本地事務和發(fā)消息放在了一個分布式事務里，保證要么本地操作成功成功并且對外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性.
該方案采用最終一致的，犧牲了一致性，換來了性能的大幅度提升。存在造成數(shù)據(jù)不一致的風險
TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業(yè)務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現(xiàn)了兩階段提交，不同的業(yè)務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式并不能很好地被復用。
具體實現(xiàn)
LCN
LCN分布式事務框架的核心功能是對本地事務的協(xié)調(diào)控制，框架本身并不創(chuàng)建事務，只是對本地事務做協(xié)調(diào)控制。因此該框架與其他第三方的框架兼容性強，支持所有的關(guān)系型數(shù)據(jù)庫事務，支持多數(shù)據(jù)源，支持與第三方數(shù)據(jù)庫框架一塊使用（例如 sharding-jdbc），在使用框架的時候只需要添加分布式事務的注解即可，對業(yè)務的侵入性低。LCN框架主要是為微服務框架提供分布式事務的支持，在微服務框架上做了進一步的事務機制優(yōu)化，在一些負載場景上LCN事務機制要比本地事務機制的性能更好，4.0以后框架開方了插件機制可以讓更多的第三方框架支持進來
目前 LCN為 4.1 版本
主要特點：
- 支持各種基于spring的db框架
- 兼容SpringCloud、Dubbo、motan
- 使用簡單，低依賴，代碼完全開源
- 基于切面的強一致性事務框架
- 高可用，模塊可以依賴RPC模塊做集群化，TxManager也可以做集群化
- 支持本地事務和分布式事務共存
- 支持事務補償機制，增加事務補償決策提醒
采用強一致性方案，事務要不全部成功，要不全部失敗，保證了事務的一致性，代碼簡單，原有項目只需引入相關(guān) jar 包，并在需要參與的事務的方法添加注解即可，節(jié)省了代碼改造成本.
Spring Cloud示例：
添加依賴
<properties>
<lcn.last.version>4.1.0</lcn.last.version>
</properties>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>transaction-springcloud</artifactId>
<version>${lcn.last.version}</version>
</dependency>
<dependency>
<groupId>com.codingapi</groupId>
<artifactId>tx-plugins-db</artifactId>
<version>${lcn.last.version}</version>
</dependency>
在需要執(zhí)行的事務上添加注解
@Override
@TxTransaction(isStart = true)
@Transactional
public int save() {
}
其中 @TxTransaction(isStart = true) 為lcn 事務控制注解，其中isStart = true 表示該方法是事務的發(fā)起方例如，服務A 需要調(diào)用服務B,服務B 需要調(diào)用服務C，此時 服務A為服務發(fā)起方，其余為參與方，參與方只需@TxTransaction 即可
在測試時需要將 事務管理服務啟動 txManager, 具體示例參看：https://www.txlcn.org
ByteTCC
ByteTCC是一個基于TCC（Try/Confirm/Cancel）機制的分布式事務管理器。兼容JTA，可以很好的與EJB、Spring等容器（本文檔下文說明中將以Spring容器為例）進行集成。
ByteTCC特性
1、支持Spring容器的聲明式事務管理；
2、支持普通事務、TCC事務、業(yè)務補償型事務等事務機制；
3、支持多數(shù)據(jù)源、跨應用、跨服務器等分布式事務場景；
4、支持長事務；
5、支持dubbo服務框架；
6、支持spring cloud；
該實現(xiàn)方式，需要在業(yè)務層編寫對應的 tcc（Try/Confirm/Cancel） 方法，開發(fā)需要一定的成本，同時某些業(yè)務可能無法保證數(shù)據(jù)可回滾
參考：
- https://github.com/codingapi/tx-lcn
- https://github.com/liuyangming/ByteTCC
- 微服務設計（Sam Newman）
[如果你喜歡就關(guān)注一下吧. 以后會寫一下我們公司在使用Spring Cloud 中遇到的問題和一些經(jīng)驗
