.net core 自帶分佈式事務的微服務開源框架JMS

事務的統一性是微服務的一個重點問題，簡潔有效的控制事務，更是程序員所須要的。JMS的誕生，就是爲了更簡單、更有效的控制事務。

先看一段調用微服務的代碼： 

            using (var ms = new JMSClient())
            {
                //調用用戶信息微服務，建立新用戶
                var uis = ms.GetMicroService<UserInfoService>();
                var userid = uis.CreateUser();

                //調用銀行微服務，建立用戶的銀行帳號
                var bks = tran.GetMicroService<BankService>();
                bks.CreateBankAccount( userid );

                //統一提交事務
                ms.Commit();
            }    

 代碼中，分別調用了兩個不一樣的微服務，作了一些業務操做，最後，經過Commit方法，統一提交這兩個微服務的事務。

因爲tran對象被using包裹，在這中間，任意一個代碼發生異常，總體事務都會被回滾。

這樣的代碼風格，比較簡潔，也符合一向的編程習慣。

 

咱們再看一下微服務端的代碼：

UserInfoService:
        public int CreateUser(TransactionDelegate tranDelegate)
        {
            var dbContext = new UserInfoDBContext();

            //編寫新增用戶的業務代碼
            .........

            //把數據庫的事務提交和回滾，放到委託當中
            tranDelegate.CommitAction = () => dbContext.CommitTransaction();
            tranDelegate.RollbackAction = () => dbContext.RollbackTransaction();

            return newUserId;
        }

BankService：
        public int CreateBankAccount(TransactionDelegate tranDelegate,int userid)
        {
            var dbContext = new BankDBContext();

            //...編寫建立銀行帳戶的業務代碼


            //把數據庫的事務提交和回滾，放到委託當中
            tranDelegate.CommitAction = () => dbContext.CommitTransaction();
            tranDelegate.RollbackAction = () => dbContext.RollbackTransaction();

            return userBankId;
        }

微服務寫完業務邏輯，最後，把事務的提交和回滾放到委託當中，由框架自動調用。

 

JMS會在全部微服務執行完畢後，統一調用微服務掛起的委託，提交事務。若是有任意一個微服務執行出錯、宕機或者離線，其餘微服務的操做會被回滾，而離線的微服務，它所掛起的事務，也會在10秒以內回滾。

而分佈式事務，有一種狀況是沒法避免的，就是最終統一提交事務時，雖然確認了各個微服務器響應正常，能夠正常提交事務，這時候，全部服務器響應號召，提交了事務，可是，最後發現，有一臺服務器宕機了。這種狀況，是分佈式系統沒法避免的，可是，經過執行日誌所提供的數據，能夠把宕機的服務，手動再執行一次。

 事務實現原理

應用層

應用層調用微服務，微服務返回調用結果，並告知應用層，微服務端是否有事務放在委託當中。

當應用層繼續調用其餘微服務的時候，若是發生異常，那麼，通知全部微服務的委託回滾事務；

若是沒有發生異常，所有微服務調用完畢，先確認一下全部調用的微服務器是否還正常響應，任何一個服務器響應不正常，也通知全部服務器的遠程委託回滾事務；

若是全部服務器響應正常，那麼通知遠程委託提交事務；

提交事務過程當中，若是某個服務器出現網絡異常，繼續嘗試幾回與服務器通信，完成提交事務的通知工做；

微服務端

接到應用層指令，執行完函數，返回結果給應用層，而後繼續和應用層保持長鏈接，保持心跳。

若是一切正常，最後，會響應應用層的指令，提交/回滾事務；

若是鏈接意外斷開，把事務委託交到委託中心，而委託中心，在10秒內，若是收不到應用層的指令，那麼，本身回滾委託的事務。

JMS特性

一、支持分佈式事務控制（強一致性和非強一致性）；

二、支持分佈式事務鎖；

三、網關支持雙機熱備；

四、支持配置文件統一在網關部署、更新；

五、支持SSL雙向校驗；

六、可自定義定時任務；

七、負載均衡根據微服務的CPU使用率和當前請求數進行平均分配，也可本身編寫負載均衡規則；

八、支持小巧的雙重加密token（長度爲68字符），實現用戶無狀態登陸；

 

JMS支持的網絡架構方案

方案1：只暴露應用服務器

 這是應用服務器和微服務溝通，效率最高的方案，也是咱們使用最多的。若是咱們的服務器不是要部署在全國各地，那麼能夠多臺服務器使用同一個局域網，只暴露應用服務器做爲惟一的訪問入口。

方案2：暴露應用服務器和代理服務器

 服務器須要分佈在不一樣的地域，爲了安全起見，能夠經過一個代理服務器，訪問網關和微服務。

方案3：暴露全部服務器

服務器須要分佈在不一樣的地域，爲了更高的效率和更低的成本，能夠把全部服務器暴露在互聯網上，與服務器之間的通信，通過SSL雙向加密機制保證安全。

 以上3個方案即是JMS所支持的網絡架構，根據實際狀況，自由配置適合本身的方案。

 

下一篇，JMS開發示例（一）

這裏給出JMS的源碼庫地址：

https://github.com/simpleway2016/JMS

qq交流羣：1030042218