在微服務如火如荼的情況下，越來越多的項目開始嘗試改造成微服務架構，微服務即帶來了項目開發的方便性，又提高了運維難度以及網絡不可靠的概率.
在說微服務的優缺點時，有對比才會更加明顯，首先說一下單體式結構
單體式架構
在單體式架構中，系統通常采用分層架構模式（MVC），持久化層、表示層，業務邏輯層。架構主要存在以下問題：
- 系統內部互相訪問，耦合緊密導致難以維護；
- 各業務領域需要采用相同的技術棧，難以快速應用新技術（例如使用SSH很難向SSM改造）；
- 對系統的任何修改都必須整個系統一起重新部署/升級；
- 在系統負載增加時，難以進行水平擴展；
- 當系統中一處出現問題，會影響整個系統；
為了克服以上缺點，微服務架構應運而生。微服務，又叫微服務架構。微服務就是一些協同工作的小而自治的服務.
微服務架構
優點:
1. 技術異構性
在不同的服務中，可以使用不同的技術來各自開發，只要保證服務間能相互協作即可
2. 彈性
當微服務中的某一個服務不可用時，不會影響整個系統，只會影響相關功能不可用
3. 擴展
易於擴展，使用小的多個服務，更加易於擴展新的功能
4. 簡化部署
某個服務的更新部署，不需要重新部署整個應用
5. 可組合
通過組合多個服務，可以提供一些新的功能
6. 可替代
因為每個微服務都比較小，重新實現某一個服務或者直接刪除該服務都是可操作的
缺點:
1. 復雜度高
微服務間通過REST、RPC等形式交互，相對於單體模式，需要考慮被調用方故障、過載、消息丟失等各種異常情況，代碼邏輯更加復雜。
對於微服務間的事務性操作，因為不同的微服務采用了不同的數據庫，將無法利用數據庫本身的事務機制保證一致性，需要引入二階段提交等技術。
同時，在微服務間存在少部分共用功能但又無法提取成微服務時，各個微服務對於這部分功能通常需要重復開發，或至少要做代碼復制，以避免微服務間的耦合，增加了開發成本。
2. 運維復雜
在采用微服務架構時，系統由多個獨立運行的微服務構成，需要一個設計良好的監控系統對各個微服務的運行狀態進行監控。運維人員需要對系統有細致的了解才對夠更好的運維系統。
3. 影響性能
相對於單體架構，微服務的間通過REST、RPC等形式進行交互，通信的時延會受到較大的影響。
分布式事務的引入
正如上面所說
對於微服務間的事務性操作，因為不同的微服務采用了不同的數據庫，將無法利用數據庫本身的事務機制保證一致性，需要引入二階段提交等技術。
在單體項目中，很容易做到事務控制，而在多個服務之間很難實現
假設服務調用如下：
A B C D 的事務均在各個服務控制，如何做到，統一協調，保證數據的一致性？
分布式事務解決方案
基於XA協議的兩階段提交
XA是一個分布式事務協議，由提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：
第一階段：
第二階段:
總的來說，XA協議比較簡單，而且一旦商業數據庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往並發量很高，XA無法滿足高並發場景。XA目前在商業數據庫支持的比較理想，在mysql數據庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日志，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。
消息事務+最終一致性
所謂的消息事務就是基於消息中間件的兩階段提交，本質上是對消息中間件的一種特殊利用，它是將本地事務和發消息放在了一個分布式事務里，保證要么本地操作成功成功並且對外發消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性.
該方案采用最終一致的，犧牲了一致性，換來了性能的大幅度提升。存在造成數據不一致的風險
TCC編程模式
所謂的TCC編程模式，也是兩階段提交的一個變種。TCC提供了一個編程框架，將整個業務邏輯分為三塊：Try、Confirm和Cancel三個操作。以在線下單為例，Try階段會去扣庫存，Confirm階段則是去更新訂單狀態，如果更新訂單失敗，則進入Cancel階段，會去恢復庫存。總之，TCC就是通過代碼人為實現了兩階段提交，不同的業務場景所寫的代碼都不一樣，復雜度也不一樣，因此，這種模式並不能很好地被復用。