一、服務架構演進
1.單體應用：
最初的所有業務全部融合在一起，我們最初接觸到的一個java應用開發完成之後打成一個war包進行部署。
優點：
1）架構簡單，所有專案模組部署在一起，對於小型專案來說方便維護
缺點：
1）所有模組耦合在一起，對於大型專案來說不易與開發和維護
2）耦合度過高，一旦一個模組出現問題，會導致整個專案不可用
3）無法針對某個具體的模組來提升效能
4）無法進行水平擴充套件
2.垂直應用：
為滿足業務需求，將單體應用部署多份到不同伺服器上。但是無法根據某個模組來進行優化和效能提升，比如有些模組屬於CPU密集型的，有些屬於IO密集型的。無法進行鍼對性的優化。垂直應用架構就是將單體應用拆分未及格互不相干的應用，來提升整個系統的效能。比如針對C端的部署成一個應用，管理後臺部署成一個服務，C端一般流量大，這個時候只需要把C端的服務多部署幾個節點，而管理後臺訪問量則不需要。
優點：
1）可以根據不同系統的訪問情況進行鍼對性優化
2）能夠實現水平擴充套件
3）各系統分擔流量，解決併發量問題
4）子系統故障，不影響其他子系統執行，提高整體的容錯率
缺點：
1）拆分後各系統相對獨立，無法進行相互呼叫
2）難免存在重疊的業務，重複開發，增加維護成本
3.分散式應用
垂直應用越來越多，重複的的程式碼也會越來越多，這個時候就講重複的業務抽離出來形成單獨的服務，提供給其他業務某塊呼叫。這個時候一般拆分成表現層和服務層，服務層負責處理業務邏輯，提供給表現層呼叫，表現層負責和前端進行互動。
優點：
1）重複程式碼抽離，提高程式碼複用
2）可以針對性的進行優化
缺點：
1）系統之間呼叫關係，依賴關係變得複雜
2）系統維護成本變高
4.SOA（面向服務）架構
分散式架構下，當服務部署越來越多的時候，服務之間的關係，呼叫越來越複雜，這個時候我們需要增加統一的排程中心，對所有服務進行管理。增加註冊中心，解決各個服務之間的依賴和呼叫關係，使其自動註冊與發現。這個時候服務的粒度任然比較粗。
缺點：
1）某個服務出現問題，可能造成服務不可用
2）增加測試、運維成本
5.微服務架構
微服務架構是在SOA基礎上進一步的擴充套件和拆分。將一個大專案拆分成一個個小的可獨立部署的微服務，每個服務有自己的資料庫。
優點：
1）服務徹底拆分，各個服務獨立打包部署，獨立升級維護
2）每個服務複雜的業務清晰，利於後期擴充套件升級、維護
3）服務之間採用REST或者RPC協議通訊
缺點：
1）開發成本高（對開發人員要求更高）
2）成本更高，每個服務都需要機器來部署
3）涉及各個服務的容錯性問題
4）涉及資料一致性問題
5）涉及分散式事務問題
二、分散式事務場景
1.跨JVM程式
因為服務拆分之後，要完成一個完整業務流程就可能涉及到多個服務之間呼叫。
2.跨資料庫例項
分庫導致或者本身業務就是操作不同的庫
3.多個服務訪問單資料庫
三、資料一致性解決方案
ACID特性：利用資料庫事務的ACID（原子性、一致性、隔離性、永續性）特性。有些分散式事務解決方案其實最終也是要依賴資料庫的此特性。比如阿里seata中的AT模式。還有DTP模型、2PC模型（兩階段提交）、3PC（三階段提交）、TCC模型、可靠訊息最終一致性模型、最大努力通知模型
四、分散式事務基本理論
分散式事務的兩大基本理論：CAP理論和Base理論
CAP（consistency一致性、可用性availability、分割槽容錯性partition tolerance）
要滿足一致性那麼我們在各個節點之間同步資料的時候，需要對資源進行鎖定等所有節點都同步完成之後再返回資料。防止在同步過程中應用程式從從節點讀取到不一致的資料。
可用性所有請求都會被響應，不會存在響應超時或錯誤的情況。
分割槽容錯，如果將系統部署在一個節點，那麼當節點出現故障時，整個系統將不可用。
因此需要多個節點部署，一個節點掛掉，其他節點也能對外提供服務。分割槽容錯時一個分散式系統必須具備的基礎能力。
AP：放棄一致性，但是一般都會考慮最終一致性。允許多個節點在一定時間內資料存在差異，一定時間之後達到一致。比如eureka，節點之間同步資料是一個定時任務從其他節點去同步資料的，定時任務沒有觸發的這個時間內，節點之間的資料是不一致的。
CP：放棄可用性。當系統對一致性要求比較高的時候使用。比如ZK，寫入資料時需要保證過半的節點寫入之後，leader才會提交結果並返回。以此來保證資料的一致性。
CA：放棄分割槽容錯性，此時系統不會進行分割槽，也不用考慮網路不通，節點掛掉等情況，嚴格來說此時的系統已經不是一個分散式系統了。
Base理論是對AP的一個擴充套件，它犧牲了強一致性來獲得可用性。Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）的縮寫。
軟狀態比如訂單中可以設計“支付中”，“退款中”這種中間狀態，過一段時間之後變成“支付成功”“退款成功”。
後續：
強一致性分散式事務解決方案、最終一致性分散式事務解決方案