學習服務之間的調用，三個方法的演化

場景

業務場景：下單時扣減庫存，因爲比較簡單，商品和庫存都放到了一個上下文中

學習多個上下文之間的交互，協做，訂單上下文生成訂單時，扣減商品上下文中的庫存

第一個方法

第一個方法的技術選型，Redis，WebApiClient，EF CORE, Polly, ExceptionLess，雪花算法
把商品的庫存放到redis中，在redis中驗證庫存，redis中扣減庫存,生成訂單後使用WebApiClient調用商品上下文中扣減庫存的接口
問題：
1，在redis中驗證庫存，扣減庫存時，須要加上Look，多線程時，獲取redis中的庫存時不加鎖獲取的庫存可能不正確
2，確保WebApiClient調用接口能成功，使用polly 若是掉接口異常，失敗時，重試，重試過程當中記錄異常，和重試的次數，併發出通知。
3，性能不強，EF core 須要持久化訂單的數據，使用WebApiClient調用商品上下文中的接口有網絡開銷
4，WebApiClient請求異常，失敗時，Polly會進行重試，出現屢次調用的問題，商品上下文接口必須作冪等
5，如何保證不超賣，執行扣減庫存修改語句是帶上庫存必須大於0的條件

第二個方法

第二個方法的技術選型，Redis，CAP，Rabbitmq，EF CORE, Polly,ExceptionLess，雪花算法
把商品的庫存放到redis中，在redis中驗證庫存，redis中扣減庫存,生成訂單時開啓事務，使用CAP來發送消息到EventBus，商品上下文訂閱，扣減庫存
問題：
1，若是保證消息不丟，使用CAP,CAP是基於本地消息表的方式來實現的組件，發送消息和消費消息都已本地事務的方式記錄了發送和消費的狀況，若是失敗
會進行重試，重試必定的次數，能夠人工干預解決問題，也能夠作補償事件，
2，訂閱消息時可能出現異常，CAP會進行重試，同一消息會出現屢次消費的問題，商品上下文接口必須作冪等
3，CAP在發送，消費消息時都會已本地事務的方式，寫入一條信息到數據庫表中，進行了2次IO的交付

第三個方法

第三個方法的技術選型，Redis，Rabbitmq，CAP，EF CORE, Polly,ExceptionLess，雪花算法
以前看過一句話， 讀多寫少用緩存，寫多讀少用隊列，咱們可能使用隊列來提升咱們的處理能力，隊列能夠堆積消息，因此要使用消息隊列 使用CommandService來發送Command，DomainEventService來發送事件，CAP具備EventBus的功能，可是多了2次IO的交互，使用本身簡單封裝Rabbitmq來寫CommandService 事件會改變咱們系統的狀態，表明已經發生過的事實，比較重要，爲了確保安全選擇了CAP 當前端調用咱們接口時在Controller中使用CommandService發送command到EventBus，commandHandler訂閱消息，在redis中驗證庫存，redis中扣減庫存,生成訂單時開啓事務 使用DomainEventService來發送消息到EventBus，商品上下文訂閱，扣減庫存 問題： 1，CommandService的實現，參考Rabbitmq官網的demo以及文檔，參考CAP源碼 2，使用隊列後，沒有獲取到返回值，經過記錄日誌，查看消息的消費狀況 3，大大加強了框架的複雜性，查錯比較複雜 4，Rabbitmq沒有使用集羣，web也沒有使用集羣，數據沒有集羣，目前對於集羣的學習比較淺