在大型復雜的應用中，業務模塊之間總是相互關聯，相互糾纏，無論對業務管理或軟體開發方面都會造成困惑：從業務管理方面難以厘清確切的管理范圍和職責：就是說不知一項業務具體誰來管，在軟體開發方面則無法確定開發人員的具體分工和維護責任，即確定一項業務功能具體靠誰來修改、優化，拿一個普通的網上購物程序來說，除商品揀選程序外的優惠價選定、庫存扣減、支付又會涉及商品定價管理、庫存管理、財務管理等獨立的業務模塊，如果純從軟體開發角度來描述：負責開發購物流程的開發人員還需要兼顧優惠價計算、庫存扣減、支付等業務操作，因為商品定價、庫存管理、財務管理等都有可能是其它人負責開發的業務模塊，一件商品揀選有可能造成該商品的定價調整、庫存變動可能驅動采購、配貨等業務的發生、支付也會是一些財務操作的啟動原因，購物流程開發人員應該是不容許直接去實作這些業務操作的，為了解決這些矛盾，必須先實作業務模塊的松散耦合，聽起來有點像CQRS，不過是更廣義的domainRS業務模塊分離，在接觸kafka之前，我們一般用soa模式由負責一塊業務功能開發的程式員提供一套完整的對外業務操作api，就可以實作程式員各自獨立作業，各管自己的一畝二分地，不過，完成的系統經常會出現內部處理業務速度跟不上外部api呼叫頻率的情況，輕者拖滯api呼叫執行緒，重則造成業務處理例外，這個時候kafka應該能在解決方案里發揮特殊作用：如果我們把kafka引入到業務模塊集成，業務模塊之間通過訊息/事件佇列event-queue進行溝通就可以實作更高程度的、更高效率的、交易事務型別的業務集成了，
這次我們拿具普遍代表性的庫存更新業務操作來作為示范案例，企業業務中幾乎所有關于商品流動的業務流程都會涉及到庫存狀態的轉變，顯然，每個業務流程在操作中都直接對庫存數進行修改是不妥當的：庫存變更的決定權應該在庫存管理業務，其它業務只能向庫存管理業務申報庫存變更提請，好了，可能大部分業務在提請庫存變更后就繼續進行下部分業務操作了，但也有些業務需要等待回復來確定請求執行狀態的，這就是上面提到的具代表性案例了，庫存更新業務具時效性，不同時間發生的庫存更新請求會產生不同的狀態結果，如：網購的秒殺，多個購物者同時對一種商品下單，同是庫存扣減請求，其中有些可能無法實作，又比如一個售票系統，多個售票視窗可能同時對同一張坐票進行揀選，系統必須考慮到這種多并發背景下資料操作的安全、準確、高效，
好了，通過以上分析，一個系統輪廓已經顯現出來了：這是一個獨立的庫存交易平臺，把庫存作為一項公共資源管理起來，外界業務模塊或者第三方軟體向平臺提請庫存狀態操作，通過http-service api把庫存查詢或者庫存更新請求提交平臺、平臺根據提交請求型別進行相關的庫存管理操作，如：確定最新的庫存狀態、根據庫存狀態向物流業務進行相關的庫存調配請求等等、然后可能需要盡快把結果回傳請求方，以此類推，其它型別的交易平臺如支付、商品資訊、商品調撥、商品收發等等都可以成為獨立的業務模塊，通過kafka把它們集成為一個整體，
在下篇我們可以討論一下用alpakka-kafka實作這個案例所需要考慮的一些技術方案，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/270638.html
標籤：Scala
上一篇：這個套圈圖不難畫