- 微服務的發展
微服務倡導將複雜的單體應用拆分爲若干個功能簡單，鬆耦合的服務。這樣可以降低開發難度、增強擴展性、便於敏捷開發，當前被越來越多的開發者推崇。很多互聯網行業巨頭、開源社區等都開始了微服務的討論和實踐。當前微服務的開發框架也非常多，比較著名的有Dubbo、SpringCloud、thrift 、grpc等。
- 微服務落地存在的問題
目前存在的主要困難有如下幾方面：
- 單體應用拆分爲分佈式系統後，進程之間的通訊機制和故障處理措施變得更加複雜。
- 系統微服務化後，一個看似簡單的功能，內部可能需要調用多個服務並操縱多個數據庫來實現，服務間的調用導致分佈式事務問題變得非常突出。
- 微服務數量衆多，其測試，部署，監控等都變得更加困難。
隨着RPC框架的成熟，第一個問題已經逐步得到解決。例如Dubbo支持多種通訊協議，Spring Cloud下的Ribbon，Feign等很好的支持Restful調用。對於第三個問題，隨着docker、devops技術的發展以及各公有云paas平臺自動化運維工具的推出，微服務的測試、部署與運維會變得越來越容易。而對於第二個問題，現在還沒有通用方案很好的解決微服務產生的事務問題。分佈式事務已經成爲微服務落地最大的阻礙，也是最具挑戰性的一個技術難題。
- 分佈式事務
-
數據庫事務
數據庫的事務介紹參見博客：事務及事務的隔離級別 -
分佈式事務
分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不同的分佈式系統的不同節點之上。 -
分佈式理論
CAP理論：
C: 一致性(Consistency)，在分佈式系統中的所有數據備份，在同一時刻是否同樣的值。
A: 可用性(Availability)，在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求。
P: 分區容錯性(Partition Tolerance)，以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。
三者不可同時滿足，而服務化中，更多的是提升A以及P，在這個過程中不可避免的會降低對C的要求。 -
分佈式事務的解決方案
- 基於XA協議的兩階段提交方案
- TCC方案
- 基於消息的最終一致性方案