[[396759]]

本文轉載自微信公眾號「三太子敖丙」，作者三太子敖丙。轉載本文請聯系三太子敖丙公眾號。

正文

在電商里面處理復雜的業務邏輯場景很多，我們還是以創建商品為列子。很多人可能會問創建商品很復雜嗎?我們接著往下看就知道了。

創建商品流程：

• 參數必填性校驗
• 參數數據轉換
• 商品基礎信息校驗
• 商品與商家之間的校驗
• 類目信息校驗
• 商品交易信息校驗(這個看公司業務決定)
• SKU相關信息校驗
• 商品是否需要有特定標簽校驗(看公司業務決定)
• 商品類型校驗(普通，卡片，視頻.......)
• 商品風控校驗
• 保存商品信息
• 保存SKU信息
• 保存商品詳情信息
• 重量模版
• 運費
• 配送區域
• 。。。。。。。

大家現在看看覺得創建一個上還簡單嗎?這里商品類型里面還涉及到各個業務場景校驗，我們就先不談了。針對這樣的情況我們應該怎么去寫這個代碼呢?我翻看了一下以前大學寫的一些代碼整體的代碼格式大概也就是這個樣子

這么寫其實也沒有什么問題，功能也能實現。但是這么寫其實有很多弊端的：

• 代碼可讀性不高
• 代碼擴展性不高
• 耦合性太強，有些東西不好公用
• (重點)整體創建執行流程時間太長，串行調用下游服務

看到這樣代碼我們首先都是吐槽一頓，然后還是老老實實是去改。有動手能力強的同學可能會想著去優化一下。再看看這個流程，其實在創建商品的時候我們很多校驗和保存數據是m沒有依賴且互不影響的，我們完全可以去并行執行。

節省創建商品的流程時間，提高用戶體驗。(PS：就好比兩條高速一條堵車，一條暢通無阻，選哪條?)所以針對這么并行問題我還是給大家畫了一個流程圖：

通過這圖我們看到創建一個商品流程，我們調用的下游服務可能是有十幾二十個或者更多，假設我們一次RPC調用的平均返回時間是50毫秒，串行執行時間可能就到1-2秒了，那么我們并行執行話也就200到300毫秒了。

所以本著這種思想可能有人會問，為什么我不能異步，不能用消息?創建商品假設用異步消息的話，如果消費失敗那用戶創建的商品成功保存其他信息失敗了，那對用戶來說不是更加體驗不好了?

說了這么多我們開始擼代碼了

先創建一個Context 上下文，作為我們的調用下游服務的返回結果

圖片

第二步創建我們的流程節點，這相當于就是保存我們整個流程中需要執行下游服務的節點，以Map作為保存數據，NodeConf 節點設置參數，自定義請求服務超時時間(因為并行我們是用的線程池或者通過get設置時間get返回值結果)

第三步引擎類，這個也是我們的核心類。通過我們添加的node節點判斷我們哪些流程是需要串行的那些是需要并行的，通過線程池創建線程放入Feature中，來達到同步執行的效果。

在使用線程池的時候我們需要考慮不要設置的參數過大，開啟另外的線程也是會占用機器內脆的，一個線程按1兆來算，你開啟幾百上千個，也會占用很大的一部分內存。盡可能的去采用池化思想，這里就按大家實際場景去做測試。

第四步執行Call方法，也就是執行我們的node節點。

第5步創建節點接口，這里我們要定義一個ResultKey，這個Key也就是跟我流程中的這個節點所綁定，在獲取數據的時候也就是通過者key來標識

第6步因為我們在節點里面存的Class類，所以我們得通過實現ApplicationContextAware類來獲取Spring容器中的bean實例

第7步那就是來創建兩個測試node節點

最后當然就是我們的測試結果啦，這里我們創建兩個節點NodeOne 和NodeTwo 作為模擬真實業務場景的節點，通過一個后面的three作為一個group 需要并行執行的節點。

看完代碼最后再給大家來一個總體的流程圖吧

看完是不是覺得感覺自己頓悟，以后再面對復雜流程的業務也就OK拿下了。

思考

其實這里還有很多優化點，每個人遇到復雜的場景可能也不一樣，只能說給大家提供一個思想吧，針對不同的場景大家再去做改造吧!!!

給大家做一個擴展：

細心的同學可能會發現這都是強依賴性，能不能有弱依賴在里面呢?

答案：當然可以有弱依賴了，在 FlowNode.NodeConf中我們既然可以設置超時時間 我們也可以在添加一個參數來確定是都是弱依賴。在我們的future.get獲取結果的時候當出現異常可以catch住，強依賴則終止流程返回錯誤信息，否則記錄錯誤日志，流程continue

我們流程保存現在是用的靜態代碼塊，可不可以換其他的方式保存節點呢?

答案：這個當然也可以，我們保存在數據庫，ACM，Apollo等等都是可以的。這個取決于你們自己的業務和成本問題。因為流程我們一般是不會經常換的，所以我還是建議代碼寫死就好了

采用線程池去調用下游服務，會不會造成服務鏈路追蹤失敗呢?

答案：這個不能說絕對，但是如果是保存在ThreadLocal中那肯定是會失效的，ThreadLocal中的KEY也就跟當前線程的ID有關，都開啟新的線程了，那肯定也就是丟失了

如果采用了ThreadLocal 在節點中是不是就失效了?

答案：第三點已經給出答案了

總結

今天的復雜業務邏輯的流程引擎也就完結了，在我每次看到新的技術以及知識點的時候我都有一種開悟的感覺，引用 鄧寧-克魯格的心理效應來說，在我們的這個年紀其實就是開悟之坡。后

面我會接著再為大家怒肝設計模式，完了也就會再跟大家聊聊重構。其實也就是用我們的設計模式來優化我們的代碼。