微服務架構-利用事件驅動實作最終一致性-有解無憂

事務一致性

首先，我們來回顧一下ACID原則：

Atomicity：原子性，改變資料狀態要么是一起完成，要么一起失敗
Consistency：一致性，資料的狀態是完整一致的
Isolation：隔離線，即使有并發事務，互相之間也不影響
Durability：持久性，一旦事務提交，不可撤銷

在單體應用中，我們可以利用關系型資料庫的特性去完成事務一致性，但是一旦應用往微服務發展，根據業務拆分成不用的模塊，而且每個模塊的資料庫已經分離開了，這時候，我們要面對的就是分布式事務了，需要自己在代碼里頭完成ACID了，比較流行的解決方案有：兩階段提交、補償機制、本地訊息表（利用本地事務和MQ）、MQ的事務訊息（RocketMQ），
大家可以到此篇文章去了解一下：分布式事務的四種解決方案

CAP定理

1998年，加州大學的計算機科學家 Eric Brewer 提出，分布式系統有三個指標，

Consistency：一致性
Availability：可用性
Partition tolerance：磁區容錯

Eric Brewer 說，這三個指標不可能同時做到，這個結論就叫做 CAP 定理，
微服務中，不同模塊之間使用的資料庫是不同的，不同模塊之間部署的服務去也有可能是不用的，那么磁區容錯是無法避免的，因為服務之間的呼叫不能保證百分百的沒問題，所以系統設計必須考慮這種情況，因此，我們可以認為CAP的P總是成立的，剩下的C和A無法同時做到，
實際上根據分布式系統中CAP原則，當P(磁區容忍)發生的時候，強行追求C（一致性），會導致（A）可用性、吞吐量下降，此時我們一般用最終一致性來保證我們系統的AP能力，當然不是放棄C，而是放棄強一致性，而且在一般情況下CAP都能保證，只是在發生磁區容錯的情況下，我們可以通過最終一致性來保證資料一致，

事件驅動實作最終一致性

事件驅動架構在領域物件之間通過異步的訊息來同步狀態，有些訊息也可以同時發布給多個服務，在訊息引起了一個服務的同步后可能會引起另外訊息，事件會擴散開，嚴格意義上的事件驅動是沒有同步呼叫的，

例子：

在電商里面，用戶下單必須根據庫存來確定訂單是否成交，
專案架構：SpringBoot2+Mybatis+tk-Mybatis+ActiveMQ【因為小例子，不做成Spring Cloud架構】

首先，我們來看看正常的服務之間呼叫：

invoke
代碼：

@Override
@Transactional(rollbackFor = Exception.class)
public Result placeOrder(OrderQuery query) {
    Result result = new Result();
    // 先遠程呼叫Stock-Service去減少庫存
    RestTemplate restTemplate = new RestTemplate();
    //請求頭
    HttpHeaders headers = new HttpHeaders();
    headers.setContentType(MediaType.APPLICATION_JSON);
    //封裝成一個請求物件
    HttpEntity entity = new HttpEntity(query, headers);
    // 同步呼叫庫存服務的介面
    Result stockResult = restTemplate.postForObject("http://127.0.0.1:8081/stock/reduceStock",entity,Result.class);
    if (stockResult.getCode() == Result.ResultConstants.SUCCESS){
        Order order = new Order();
        BeanUtils.copyProperties(query,order);
        order.setOrderStatus(1);
        Integer insertCount = orderMapper.insertSelective(order);
        if (insertCount == 1){
            result.setMsg("下單成功");
        }else {
            result.setMsg("下單失敗");
        }
    }else {
        result.setCode(Result.ResultConstants.FAIL);
        result.setMsg("下單失敗："+stockResult.getMsg());
    }
    return result;
}

我們可以看到，這樣的服務呼叫的弊端多多：

1、訂單服務需同步等待庫存服務的回傳結果，介面結果回傳延誤，
2、訂單服務直接依賴于庫存服務，只要庫存服務崩了，訂單服務不能再正常運行，
3、訂單服務需考慮并發問題，庫存最后可能為負，

下面開始利用事件驅動實作最終一致性

1、在訂單服務新增訂單后，訂單的狀態是“已開啟”，然后發布一個Order Created事件到訊息佇列上

代碼：

@Transactional(rollbackFor = Exception.class)
public Result placeOrderByMQ(OrderQuery query) {
    Result result = new Result();
    // 先創建訂單，狀態為下單0
    Order order = new Order();
    BeanUtils.copyProperties(query,order);
    order.setOrderStatus(0);
    Integer insertCount = orderMapper.insertSelective(order);
    if (insertCount == 1){
        // 發送 訂單訊息
        MqOrderMsg mqOrderMsg = new MqOrderMsg();
        mqOrderMsg.setId(order.getId());
        mqOrderMsg.setGoodCount(query.getGoodCount());
        mqOrderMsg.setGoodName(query.getGoodName());
        mqOrderMsg.setStockId(query.getStockId());
        jmsProducer.sendOrderCreatedMsg(mqOrderMsg);
        // 此時的訂單只是開啟狀態
        result.setMsg("下單成功");
    }
    return result;
}

2、庫存服務在監聽到訊息佇列OrderCreated中的訊息，將庫存表中商品的庫存減去下單數量，然后再發送一個Stock Locked事件給訊息佇列，

代碼：

/**
 * 接收下單訊息
 * @param message 接收到的訊息
 * @param session 背景關系
 */
@JmsListener(destination = ORDER_CREATE,containerFactory = "myListenerContainerFactory")
@Transactional(rollbackFor = Exception.class)
public void receiveOrderCreatedMsg(Message message, Session session){
    try {
        if (message instanceof ActiveMQObjectMessage){
            MqStockMsg result = new MqStockMsg();
            ActiveMQObjectMessage objectMessage=(ActiveMQObjectMessage)message;
            MqOrderMsg msg = (MqOrderMsg)objectMessage.getObject();
            Integer updateCount = stockMapper.updateNumByStockId(msg.getStockId(),msg.getGoodCount());
            if (updateCount >= 1){
                result.setSuccess(true);
                result.setOrderId(msg.getId());
            }else {
                result.setSuccess(false);
            }
            // 手動ack，使訊息出佇列，不然會不斷消費
            message.acknowledge();
            // 發送庫存鎖定訊息到MQ
            jmsProducer.sendStockLockedMsg(result);
        }
    } catch (JMSException e) {
        log.error("接收訂單創建訊息報錯："+e.getMessage());
    }
}

仔細的朋友可能會看到：message.acknowledge()，即手動確認訊息，因為在保證庫存服務的邏輯能正常執行后再確認訊息已消費，可以保證訊息的投遞可靠性，萬一在庫存服務執行時報出例外，我們可以做到重新消費該下單訊息，
3、訂單服務接收到Stock Locked事件，將訂單的狀態改為“已確認”
Order Change
代碼：

/**
 * 判斷是否還有庫存，有庫存更新訂單狀態為1，無庫存更新訂單狀態為2，并且通知用戶（WebSocket）
 * @param message
 */
@JmsListener(destination = STOCK_LOCKED,containerFactory = "myListenerContainerFactory")
@Transactional(rollbackFor = Exception.class)
public void receiveStockLockedMsg(Message message, Session session){
    try {
        if (message instanceof ActiveMQObjectMessage){
            ActiveMQObjectMessage objectMessage=(ActiveMQObjectMessage)message;
            MqStockMsg msg = (MqStockMsg)objectMessage.getObject();
            if (msg.isSuccess()){
                Order updateOrder = new Order();
                updateOrder.setId(msg.getOrderId());
                updateOrder.setOrderStatus(1);
                orderMapper.updateByPrimaryKeySelective(updateOrder);
                log.info("訂單【"+msg.getOrderId()+"】下單成功");
            }else {
                Order updateOrder = new Order();
                updateOrder.setId(msg.getOrderId());
                updateOrder.setOrderStatus(2);
                orderMapper.updateByPrimaryKeySelective(updateOrder);
                // 通知用戶庫存不足，訂單被取消
                log.error("訂單【"+msg.getOrderId()+"】因庫存不足被取消");
            }
            // 手動ack，使訊息出佇列，不然會不斷消費
            message.acknowledge();
        }
    } catch (JMSException e) {
        log.error("接收庫存鎖定訊息報錯："+e.getMessage());
    }
}

同樣，這里我們也是會利用手動確認訊息來保證訊息的投遞可靠性，
至此，已經全部搞定了，我們看一下和正常的服務呼叫對比如何：

1、訂單服務不再直接依賴于庫存服務，而是將下單事件發送到MQ中，讓庫存監聽，
2、訂單服務能真正的作為一個模塊獨立運行，
3、解決了并發問題，而且MQ的佇列處理效率非常的高，

但是也存在下面的問題：

1、用戶體驗改變了：因為使用事件機制，訂單是立即生成的，可是很有可能過一會，系統會提醒你沒貨了，，這就像是排隊搶購一樣，排著排著就被通知沒貨了，不用再排隊了，
2、資料庫可能會存在很對沒有完成下單的訂單，

最后，如果真的要考慮用戶體驗，并且不想資料庫存在很多不必要的資料，該怎么辦？
那就把訂單服務和庫存服務聚合在一起吧，解決當前的問題應當是首先要考慮的，我們設計微服務的目的是本想是解決業務并發量，而現在面臨的卻是用戶體驗的問題，所以架構設計也是需要妥協的，
最主要是，我們是經過思考和分析的，每個方案能做到哪種程度，能應用到哪種場景，正所謂，技術要和實際場景結合，我們不能為了追求新技術而生搬硬套，

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/48422.html

標籤：架構設計

上一篇：Docker Compose安裝Registry后配置WebUI與客戶端

下一篇：談談技術債務