摘要：中大致分為兩部分事務(wù)管理器和本地資源管理器。具體實(shí)現(xiàn)分布式事務(wù)框架的核心功能是對本地事務(wù)的協(xié)調(diào)控制，框架本身并不創(chuàng)建事務(wù)，只是對本地事務(wù)做協(xié)調(diào)控制。

在微服務(wù)如火如荼的情況下，越來越多的項(xiàng)目開始嘗試改造成微服務(wù)架構(gòu)，微服務(wù)即帶來了項(xiàng)目開發(fā)的方便性，又提高了運(yùn)維難度以及網(wǎng)絡(luò)不可靠的概率.

@[toc]
在說微服務(wù)的優(yōu)缺點(diǎn)時(shí)，有對比才會更加明顯，首先說一下單體式結(jié)構(gòu)

在單體式架構(gòu)中，系統(tǒng)通常采用分層架構(gòu)模式（MVC），持久化層、表示層，業(yè)務(wù)邏輯層。架構(gòu)主要存在以下問題：

系統(tǒng)內(nèi)部互相訪問，耦合緊密導(dǎo)致難以維護(hù)；

各業(yè)務(wù)領(lǐng)域需要采用相同的技術(shù)棧，難以快速應(yīng)用新技術(shù)（例如使用SSH很難向SSM改造）；

對系統(tǒng)的任何修改都必須整個(gè)系統(tǒng)一起重新部署/升級；

在系統(tǒng)負(fù)載增加時(shí)，難以進(jìn)行水平擴(kuò)展；

當(dāng)系統(tǒng)中一處出現(xiàn)問題，會影響整個(gè)系統(tǒng)；

為了克服以上缺點(diǎn)，微服務(wù)架構(gòu)應(yīng)運(yùn)而生。微服務(wù)，又叫微服務(wù)架構(gòu)。微服務(wù)就是一些協(xié)同工作的小而自治的服務(wù).

1. 技術(shù)異構(gòu)性

在不同的服務(wù)中，可以使用不同的技術(shù)來各自開發(fā)，只要保證服務(wù)間能相互協(xié)作即可

2. 彈性

當(dāng)微服務(wù)中的某一個(gè)服務(wù)不可用時(shí)，不會影響整個(gè)系統(tǒng)，只會影響相關(guān)功能不可用

3. 擴(kuò)展

易于擴(kuò)展，使用小的多個(gè)服務(wù)，更加易于擴(kuò)展新的功能

4. 簡化部署

某個(gè)服務(wù)的更新部署，不需要重新部署整個(gè)應(yīng)用

5. 可組合

通過組合多個(gè)服務(wù)，可以提供一些新的功能

6. 可替代

因?yàn)槊總€(gè)微服務(wù)都比較小，重新實(shí)現(xiàn)某一個(gè)服務(wù)或者直接刪除該服務(wù)都是可操作的

1. 復(fù)雜度高

微服務(wù)間通過REST、RPC等形式交互，相對于單體模式，需要考慮被調(diào)用方故障、過載、消息丟失等各種異常情況，代碼邏輯更加復(fù)雜。

對于微服務(wù)間的事務(wù)性操作，因?yàn)椴煌奈⒎?wù)采用了不同的數(shù)據(jù)庫，將無法利用數(shù)據(jù)庫本身的事務(wù)機(jī)制保證一致性，需要引入二階段提交等技術(shù)。

同時(shí)，在微服務(wù)間存在少部分共用功能但又無法提取成微服務(wù)時(shí)，各個(gè)微服務(wù)對于這部分功能通常需要重復(fù)開發(fā)，或至少要做代碼復(fù)制，以避免微服務(wù)間的耦合，增加了開發(fā)成本。

2. 運(yùn)維復(fù)雜

在采用微服務(wù)架構(gòu)時(shí)，系統(tǒng)由多個(gè)獨(dú)立運(yùn)行的微服務(wù)構(gòu)成，需要一個(gè)設(shè)計(jì)良好的監(jiān)控系統(tǒng)對各個(gè)微服務(wù)的運(yùn)行狀態(tài)進(jìn)行監(jiān)控。運(yùn)維人員需要對系統(tǒng)有細(xì)致的了解才對夠更好的運(yùn)維系統(tǒng)。

3. 影響性能

相對于單體架構(gòu)，微服務(wù)的間通過REST、RPC等形式進(jìn)行交互，通信的時(shí)延會受到較大的影響。

正如上面所說

對于微服務(wù)間的事務(wù)性操作，因?yàn)椴煌奈⒎?wù)采用了不同的數(shù)據(jù)庫，將無法利用數(shù)據(jù)庫本身的事務(wù)機(jī)制保證一致性，需要引入二階段提交等技術(shù)。

在單體項(xiàng)目中，很容易做到事務(wù)控制，而在多個(gè)服務(wù)之間很難實(shí)現(xiàn)

假設(shè)服務(wù)調(diào)用如下：

A B C D 的事務(wù)均在各個(gè)服務(wù)控制，如何做到，統(tǒng)一協(xié)調(diào)，保證數(shù)據(jù)的一致性？

XA是一個(gè)分布式事務(wù)協(xié)議，由提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫實(shí)現(xiàn)，比如Oracle、DB2這些商業(yè)數(shù)據(jù)庫都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交和回滾。XA實(shí)現(xiàn)分布式事務(wù)的原理如下：
第一階段：

第二階段:

總的來說，XA協(xié)議比較簡單，而且一旦商業(yè)數(shù)據(jù)庫實(shí)現(xiàn)了XA協(xié)議，使用分布式事務(wù)的成本也比較低。但是，XA也有致命的缺點(diǎn)，那就是性能不理想，特別是在交易下單鏈路，往往并發(fā)量很高，XA無法滿足高并發(fā)場景。XA目前在商業(yè)數(shù)據(jù)庫支持的比較理想，在mysql數(shù)據(jù)庫中支持的不太理想，mysql的XA實(shí)現(xiàn)，沒有記錄prepare階段日志，主備切換回導(dǎo)致主庫與備庫數(shù)據(jù)不一致。許多nosql也沒有支持XA，這讓XA的應(yīng)用場景變得非常狹隘。

所謂的消息事務(wù)就是基于消息中間件的兩階段提交，本質(zhì)上是對消息中間件的一種特殊利用，它是將本地事務(wù)和發(fā)消息放在了一個(gè)分布式事務(wù)里，保證要么本地操作成功成功并且對外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性.

該方案采用最終一致的，犧牲了一致性，換來了性能的大幅度提升。存在造成數(shù)據(jù)不一致的風(fēng)險(xiǎn)

所謂的TCC編程模式，也是兩階段提交的一個(gè)變種。TCC提供了一個(gè)編程框架，將整個(gè)業(yè)務(wù)邏輯分為三塊：Try、Confirm和Cancel三個(gè)操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態(tài)，如果更新訂單失敗，則進(jìn)入Cancel階段，會去恢復(fù)庫存?？傊琓CC就是通過代碼人為實(shí)現(xiàn)了兩階段提交，不同的業(yè)務(wù)場景所寫的代碼都不一樣，復(fù)雜度也不一樣，因此，這種模式并不能很好地被復(fù)用。

https://github.com/codingapi/...

LCN分布式事務(wù)框架的核心功能是對本地事務(wù)的協(xié)調(diào)控制，框架本身并不創(chuàng)建事務(wù)，只是對本地事務(wù)做協(xié)調(diào)控制。因此該框架與其他第三方的框架兼容性強(qiáng)，支持所有的關(guān)系型數(shù)據(jù)庫事務(wù)，支持多數(shù)據(jù)源，支持與第三方數(shù)據(jù)庫框架一塊使用（例如 sharding-jdbc），在使用框架的時(shí)候只需要添加分布式事務(wù)的注解即可，對業(yè)務(wù)的侵入性低。LCN框架主要是為微服務(wù)框架提供分布式事務(wù)的支持，在微服務(wù)框架上做了進(jìn)一步的事務(wù)機(jī)制優(yōu)化，在一些負(fù)載場景上LCN事務(wù)機(jī)制要比本地事務(wù)機(jī)制的性能更好，4.0以后框架開方了插件機(jī)制可以讓更多的第三方框架支持進(jìn)來

目前 LCN為 4.1 版本

主要特點(diǎn)：

支持各種基于spring的db框架

兼容SpringCloud、Dubbo、motan

使用簡單，低依賴，代碼完全開源

基于切面的強(qiáng)一致性事務(wù)框架

高可用，模塊可以依賴RPC模塊做集群化，TxManager也可以做集群化

支持本地事務(wù)和分布式事務(wù)共存

支持事務(wù)補(bǔ)償機(jī)制，增加事務(wù)補(bǔ)償決策提醒

采用強(qiáng)一致性方案，事務(wù)要不全部成功，要不全部失敗，保證了事務(wù)的一致性，代碼簡單，原有項(xiàng)目只需引入相關(guān) jar 包，并在需要參與的事務(wù)的方法添加注解即可，節(jié)省了代碼改造成本.

Spring Cloud示例：

添加依賴

   4.1.0



    com.codingapi
    transaction-springcloud
    ${lcn.last.version}



   com.codingapi
   tx-plugins-db
   ${lcn.last.version}

在需要執(zhí)行的事務(wù)上添加注解

@Override
@TxTransaction(isStart = true)
@Transactional
public int save() {
}

其中 @TxTransaction(isStart = true) 為lcn 事務(wù)控制注解，其中isStart = true 表示該方法是事務(wù)的發(fā)起方例如，服務(wù)A 需要調(diào)用服務(wù)B,服務(wù)B 需要調(diào)用服務(wù)C，此時(shí) 服務(wù)A為服務(wù)發(fā)起方，其余為參與方，參與方只需@TxTransaction 即可

在測試時(shí)需要將 事務(wù)管理服務(wù)啟動 txManager, 具體示例參看：https://www.txlcn.org

https://github.com/liuyangmin...

ByteTCC是一個(gè)基于TCC（Try/Confirm/Cancel）機(jī)制的分布式事務(wù)管理器。兼容JTA，可以很好的與EJB、Spring等容器（本文檔下文說明中將以Spring容器為例）進(jìn)行集成。

ByteTCC特性
1、支持Spring容器的聲明式事務(wù)管理；
2、支持普通事務(wù)、TCC事務(wù)、業(yè)務(wù)補(bǔ)償型事務(wù)等事務(wù)機(jī)制；
3、支持多數(shù)據(jù)源、跨應(yīng)用、跨服務(wù)器等分布式事務(wù)場景；
4、支持長事務(wù)；
5、支持dubbo服務(wù)框架；
6、支持spring cloud；

該實(shí)現(xiàn)方式，需要在業(yè)務(wù)層編寫對應(yīng)的 tcc（Try/Confirm/Cancel） 方法，開發(fā)需要一定的成本，同時(shí)某些業(yè)務(wù)可能無法保證數(shù)據(jù)可回滾

查看示例：https://github.com/liuyangmin...

參考：

https://github.com/codingapi/...

https://github.com/liuyangmin...

微服務(wù)設(shè)計(jì)（Sam Newman）

如果你喜歡就關(guān)注一下吧. 以后會寫一下我們公司在使用Spring Cloud 中遇到的問題和一些經(jīng)驗(yàn)