1. 為什么說：業(yè)務(wù)系統(tǒng)一定要先實現(xiàn)優(yōu)雅關(guān)閉服務(wù)，才能使用 Spring Event?

Spring  廣播消息時，Spring會在 ApplicationContext 中查找所有的監(jiān)聽者，即需要 getBean 獲取 bean 實例。然而 Spring 有個限制————ApplicationContext 關(guān)閉期間，不得GetBean 否則會報錯。

這個知識點得來不易。它是我們公司在線上環(huán)境發(fā)生故障后，最終定位的原因，大家一定要重視！

前幾天，線上系統(tǒng)出現(xiàn)兩條異常日志Get Bean時找不到對應(yīng)的bean，調(diào)用堆棧讓我非常迷惑，為什么Get Bean找不到對應(yīng)的Bean呢? 如下圖所示

圖片

堆棧中的信息 解釋了原因。Do not request a bean from a BeanFactory in a destroy method implementation

在應(yīng)用上下文關(guān)閉時，不得從上下文中Get Bean。恰好，這個問題出現(xiàn)在服務(wù)關(guān)閉期間.....

由于系統(tǒng)流量較高，日訂單幾百萬，即便在低峰期單機的并發(fā)度也是比較高的，所以服務(wù)在關(guān)閉期間有少量流量進來或未處理完。這個場景下，使用 Spring Event 發(fā)布事件，Spring 無法正常廣播事件，一定會出現(xiàn)異常，導致處理失??！

大家一定要切記！使用 SpringEvent 之前，一定要先治理服務(wù)，確保服務(wù)關(guān)閉時，先切斷入口流量（Http、MQ、RPC），然后再關(guān)閉服務(wù)，關(guān)閉 Spring 上下文！

詳細的分析請參考：

https://juejin.cn/post/7281159113882468371

2. 為什么服務(wù)啟動階段，Spring Event 事件丟失了？

我們公司遇到的情況是， Kafka conumser 在 init-method 階段開始消費，然而 Spring EventListener 被注冊進 Spring 的時間點滯后于 init-method 時間點，所以 Kafka Consumer 中使用 Spring Event 發(fā)布事件時，沒有找到監(jiān)聽者，出現(xiàn)消息處理丟失的情況。

從下圖中可以看到 init-method 時間點 滯后于 EventListener 被注冊的時間點。

圖片

簡單來說：SpringBoot 會在Spring完全啟動完成后，才開啟Http流量。這給了我們啟示：應(yīng)該在Spring啟動完成后開啟入口流量。Rpc和 MQ流量 也應(yīng)該如此，所以建議大家 在 SmartLifecype 或者 ContextRefreshedEvent 等位置 注冊服務(wù)，開啟流量。

最佳實踐是：改造系統(tǒng)開啟入口流量（Http、MQ、RPC）的時機，確保在Spring 啟動完成后開啟入口流量。

什么業(yè)務(wù)特點適合發(fā)布——訂閱模式

每一個優(yōu)秀的程序員都應(yīng)該有自己的工具箱，他能在不同的業(yè)務(wù)場景選擇最合適的工具。

SpringEvent 適合哪些業(yè)務(wù)場景呢？這由訂閱發(fā)布模式的特性決定

• 事件發(fā)布者并不關(guān)心事件如何被處理
• 事件發(fā)布者不關(guān)心事件處理的結(jié)果
• 事件訂閱者有多個，可異步訂閱，也可以同步訂閱。
• 事件訂閱者之間各自獨立，互不依賴。

發(fā)布訂閱模式實現(xiàn)了發(fā)布和訂閱兩個模塊的解耦。但是對于強一致性的場景，并不適合使用發(fā)布訂閱模式。

3. 強一致性場景不適合 訂閱發(fā)布模式

強一致性的業(yè)務(wù)例如提單場景。提單階段，庫存扣減成功和訂單提單成功務(wù)必完全一致。庫存扣減失敗但提單成功；提單失敗，庫存未回滾等場景都是要避免發(fā)生的異常場景！

提單場景，使用 Spring Event會有很多問題。假設(shè)提單前，發(fā)布提單前置事件，事件訂閱者的業(yè)務(wù)邏輯可能有扣減庫存，鎖定優(yōu)惠券資源等操作。庫存扣減失敗或者鎖定資源失敗需要回滾整個提單流程，然而 Spring  事件訂閱模式無法提供這種 訂閱異?！?gt;回滾 的能力。

事件發(fā)布者無法獲知哪些訂閱消費失敗，哪些訂閱者成功？無法準確的觸發(fā)回滾流程。（如果基于 Spring Event 強行搞回滾，也可以做到，但方案會很復(fù)雜?。?/p>

4. 最終一致性的業(yè)務(wù)特性適合——發(fā)布訂閱模式

最終一致性場景非常適合使用 Spring Event。

例如提單成功后，發(fā)布 MQ ，釋放鎖等資源，可使用 SpringEvent 解耦。為什么呢？因為業(yè)務(wù)上確保提單成功后，提單實際上已經(jīng)成功，后續(xù)的收尾工作不應(yīng)該觸發(fā)訂單提單失敗。

在提單成功事件的訂閱者中，只有一種執(zhí)行結(jié)果——成功。即使出現(xiàn)失敗，也應(yīng)該重試直至成功。例如 發(fā)布 提單成功MQ 消息，釋放提單鎖等資源都是務(wù)必成功的業(yè)務(wù)邏輯。

再來舉一個例子，我們公司在處理訂單消息時使用了Spring Event框架。在這個場景中，我們需要處理履約完成、退款完成、訂單過期等事件，并且每個事件都有一些獨立的業(yè)務(wù)邏輯，每一個業(yè)務(wù)場景都屬于最終一致性的場景。舉個例子，履約完成后需要將履約數(shù)據(jù)和訂單金額等數(shù)據(jù)通知結(jié)算系統(tǒng)。這個業(yè)務(wù)場景是最終一致性場景，而不是強一致性，這是因為通知結(jié)算即便失敗，重試即可，無需回滾履約過程。

如果我們不使用Spring Event，那么我就需要手動編寫觀察者模式，并將訂單消息根據(jù)狀態(tài)通知到相應(yīng)的觀察者中。又或者每當新增一個業(yè)務(wù)邏輯時，我需要新增一個Kafka消費組，并且在代碼中解析訂單消息，然后根據(jù)狀態(tài)將事件發(fā)送給相應(yīng)的訂閱者?？傊倚枰咽录凑諣顟B(tài)分發(fā)給對應(yīng)的監(jiān)聽者。

在這個場景中，使用Spring Event非常適合。可以將每個事件封裝為Spring Event，并且每個業(yè)務(wù)邏輯都可以通過@EventListener注解來注冊對應(yīng)狀態(tài)的事件監(jiān)聽器（不過需要注意的是，如果訂閱者過多，那么Kafka消息的消費時間可能會增加。那么該如何解決呢？）。使用 Spring Event 框架比自己手寫監(jiān)聽者模式強多了。

5. 使用SpringEvent 要有額外的可靠性保證！

Spring Event適用于需要保證最終一致性的業(yè)務(wù)場景，但為了確保可靠性，必須提供重試能力。通過使用 applicationContext.publishEvent(event) 方法發(fā)布事件，Spring會按順序執(zhí)行相關(guān)的訂閱者。如果出現(xiàn)異常，publishEvent 方法會拋出異常，發(fā)布者能夠感知訂閱邏輯處理失敗了。

在發(fā)布事件時，需要考慮事件訂閱邏輯出現(xiàn)異常的情況，我提出三種解決辦法

1. 訂閱者自行重試

訂閱邏輯可自行重試保證成功。例如使用 Spring  retry注解可以保證出現(xiàn)異常時，重新執(zhí)行該方法。

以下代碼示例 performSuccess 方法拋出異常時，Spring 會重新執(zhí)行該方法直至成功，最多重試 3 次，可設(shè)置間隔時間，重試間隔遞增時間。

@Retryable(value = Exception.class, maxAttempts = 3, backoff = @Backoff(delay = 100L, multiplier = 2))
public void performSuccess(PerformEvent event) {
    
}

使用 @Retryable 注解前，記得引入 spring-retry pom 依賴

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.4.RELEASE</version>
</dependency>

訂閱者依賴 Kafka 消費組重試

如果在 Kafka 消費者中使用Spring Event，處理重試非常容易。只需要在消費異常時，向 Kafka 返回消費失敗即可，Kafka 會自動進行重試。

此外，還可以將消息發(fā)送到專門的死信隊列，在死信隊列中重新消費消息！不同公司的 Kafka 重試能力實現(xiàn)方案可能不同，大家自行選擇。

主動上報故障異常到故障管理平臺

故障處理流程

當請求一直重試失敗超過最大重試次數(shù)時，業(yè)務(wù)系統(tǒng)會上報到故障 MQ，故障管理平臺消費 MQ，收集故障并落庫。研發(fā)同學收到故障通知，介入排查問題。同時研發(fā)同學在故障管理后臺可以看到故障列表、故障詳情。

排查問題原因、敦促相關(guān)同事修復(fù)問題后，點擊重試按鈕。故障管理后臺收到重試請求，會通過 Rpc SPI 調(diào)用到業(yè)務(wù)系統(tǒng) 重試故障，并告知管理后臺成功和失敗結(jié)果。

圖片

6. Spring 訂閱者務(wù)必保證冪等

為了提高可靠性，要有額外的重試機制保證 Spring 訂閱發(fā)布的可靠性。

有重試就要有冪等！要保證 訂閱者邏輯具備冪等性。Spring 不知道哪些訂閱者成功，哪些訂閱者失敗，下一次重試時，會全部執(zhí)行所有的訂閱者。所以訂閱邏輯要做好冪等，防止數(shù)據(jù)不一致情況發(fā)生。

為什么有消息隊列 MQ ，還需要 Spring Event

曾經(jīng)有掘友給我評論，說我司對 Spring Event 的應(yīng)用場景應(yīng)該替換為 MQ。在此我解釋一下

Spring Event和 MQ 都屬于訂閱發(fā)布模式的應(yīng)用，然而 MQ 比 SpringEvent 強大且復(fù)雜。MQ 更適合應(yīng)用之間的解耦、隔離、事件通知。例如訂單支付、訂單完成、訂單履約完成等等事件需要廣播出去，通知下游其他微服務(wù)， 這種場景更適合使用 MQ 。

然而對于應(yīng)用內(nèi)需要訂閱發(fā)布的場景更適合使用 SpringEvent。兩者并不矛盾，MQ 能力更強大，技術(shù)方案也更”重“一些。Spring Event 更加小巧適合應(yīng)用內(nèi)訂閱發(fā)布，實現(xiàn)業(yè)務(wù)邏輯解耦。