1.前言
想想自己代碼裏面有沒有讓人眼前一亮的東西，想想還是有的，印象比較深的還真有那麼幾個，自己寫出來歸納整理一下，做個備份，也讓自己的腦袋運轉一下，最近腦袋越轉越慢了，感覺藥不能停啊！博客真的要堅持寫。
2.業務場景
自己有個功能模塊是這樣的，開通一個服務，我這裏就指定爲T服務（Telematics Service）而我們這個服務的開通要調用好幾個模塊的服務，例如：A/B/C/D/E/F…服務等等。
因爲調用鏈很長，我們要考慮，服務之間互通性的問題，不可能你一執行你的代碼邏輯能保證所有的服務ABCDEF…都能執行成功，有可能就斷在D這個服務這裏。這時通常的做法是直接拋個異常啥的，或者返回D服務操作失敗信息。但是真實的業務場景是這個T服務開通成功必須保證調用鏈裏面的所有服務都執行成功，而不是在某個節點執行失敗。
也有同學可能覺得這樣沒有問題，在執行一次不就行了，那麼我舉個例子大家看看是不是並不是你想象的那樣返回就行。
- A服務說你調用人家一次了，人家已經有了一個寶寶，國家沒有二胎政策，再生是違法的。開個玩笑，你數據再別人那邊已經存在了，你再次調用別人那邊數據已經存在通常的設計就是告訴你數據已經存在不允許重複插入。
- A服務操作正常，B服務如果是流程，你應經開通流量了，別人不會再給你開一次，會告訴你操作不合法，或者能再次調用別人接口，別人又給你加了流量，那不是白白送流量給別人，要是出現這種情況，公司豈不是要虧大發了。
- AB服務操作正常，C服務說我心情不好，我情緒不穩定，不想理你，各種超時網絡不穩定，導致C服務調用失敗。
- 再從設計的角度來看，你這邊很長的調用鏈，如果從頭開始，不止可能出現髒數據也很浪費時間，爲啥不能就從上一次斷開的位置運行勒既高效又有針對性。
3.設計思路
我們考慮ABCDEF。。。服務都有成功失敗兩個狀態，例如：
A（成功，失敗）
B（成功，失敗）
C（成功，失敗）
D（成功，失敗）
E（成功，失敗）
F（成功，失敗）
。。。
我們把這些狀態存在數據庫，那麼我們從數據庫拿到那個狀態就能很清楚的知道他在哪個環節出了問題，最開始我想到的是用字符串代替這個狀態，可以用英文單詞記錄，這樣我們可以很清楚的知道到底錯在哪個節點，但是一想我要怎麼在每個接口判斷一下，到底該怎麼知道我這個節點已經運行過，不用再運行，D節點失敗狀態A節點判斷我已經執行過了，想了想媽的英文單詞真麻煩啊該怎麼比啊！大於等於，這個設計真噁心，後面直接改爲數字了，123456789是真香，A=1 B=3 C=5 D=7 E=9是成功狀態，A=2 B=4 C=6 D=8 E=10是失敗狀態，這會D失敗我給serviceStatus=8，執行成功是9 那麼ABC只要符合下面幾個條件就不用執行了。
- 不爲空
- A節點等於1時，B節點等於3時。。。
- 8 > 2/4/6（2/4/6節點直接return true不用執行）
- 不爲9（9已經執行成功）
因爲 8 不大於 8所以我們流程不會停，不會return 所以我們執行到D，會再次執行，直到D 狀態爲9。這樣我們就做到了斷點觸發，職能定責。
4.補償策略
針對上面失敗的問題，我們還要有一套補償機制，讓那些失敗的T服務能正常開通，建議從兩個方面入手：
- 單獨設置一個接口來調用。
- 啓用定時任務，隔幾分鐘查詢一次那些開通失敗的，然後運行開通流程開通T服務。
這樣我們可以避免卡在這一環節，忘記了還有定時任務來處理，當然我沒有舉例portal頁面，portal頁面也能很清楚的看到哪些T服務開通成功，哪些開通失敗，失敗了具體失敗在哪個環節，失敗的環節可以單獨設置T服務開通按鈕，開通完畢以後可以隱藏按鈕。
記錄一下！！！