這是典型的程式業務處理的方式。——接收到請求入參後，先進行前置校驗，如果校驗失敗直接中止返回，否則才走後續的業務處理流程。 ...
我們來看一個案例。
前端頁面上，用戶在訂單詳情頁確認完信息後，點擊“確認支付”，發起餘額支付。
這裡，我們做如下3項設定。
1）後臺程式暴露的“支付”Rest介面名為 order/pay。
2）後臺程式對於“支付”的處理邏輯，我們簡化成下麵的業務流程。
3）後臺程式是微服務結構，包括提供RestAPI介面的springmvc服務和後面的訂單服務、賬戶服務。
那麼， 比較下麵兩種實現方式，左邊第一種是在order/pay這個rest介面里先查單校驗訂單狀態，通過後才調用訂單服務的“支付訂單”RPC介面。右邊第二種是直接轉發請求給訂單服務的“支付訂單”RPC介面。你更傾向於哪一種實現方式呢？
相比來說，我認為第一種更靠譜一些。
Why？
看上去，雖然兩種實現方式都能達到目的，第一種方式還多了一個前置的校驗。為什麼我建議採用第一種方式呢？
這是典型的程式業務處理的方式。——接收到請求入參後，先進行前置校驗，如果校驗失敗直接中止返回，否則才走後續的業務處理流程。
有同學就說了，按第二種實現方式，直接調用訂單服務的“支付訂單”RPC介面，“支付訂單”RPC介面的實現里不是也有訂單狀態的前置校驗嗎？
這是有區別的。按第一種實現方式的話，支付訂單RPC介面除了流程圖裡的實現方式外，也可以省掉查詢訂單這一步，直接通過包含狀態機冪等的update操作來變更訂單狀態（sql諸如UPDATE order SET pay_status='PAYED' WHERE order_no = '001' AND pay_status = 'INIT'），根據update是否成功來決定後面的扣減用戶餘額的邏輯。如果採用第二種實現方式，那就最好先老老實實的通過查詢訂單來判斷狀態，畢竟資料庫的update成本比select要高很多。
從技術的角度來分析，兩種實現方式也是有區別的。“支付訂單”作為一個業務處理的RPC介面，我們要做的控制會比較多，例如事務控制、冪等、異常處理、耗時、鎖、監控，等等。因此，從這個角度來看，在確認需要支付訂單的時候再調用“支付訂單”，是不是更合理呢？
類似的案例，也包括，我們的MQ消費者，在從隊列里拿到消息後，先進行必要的判斷和校驗，然後再調用業務方法。而不是一上來就直接把參數丟給業務方法。
本文設計文稿自：https://www.processon.com/view/link/611e38c2e0b34d3511f7c479
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/17765857.html
