Spring Event的最佳實踐：從失敗中學習
1. 為什么說：業務系統一定要先實現優雅關閉服務，才能使用 Spring Event?
Spring 廣播消息時，Spring會在 ApplicationContext 中查找所有的監聽者，即需要 getBean 獲取 bean 實例。然而 Spring 有個限制————ApplicationContext 關閉期間，不得GetBean 否則會報錯。
這個知識點得來不易。它是我們公司在線上環境發生故障后，最終定位的原因，大家一定要重視！
前幾天，線上系統出現兩條異常日志Get Bean時找不到對應的bean，調用堆棧讓我非常迷惑，為什么Get Bean找不到對應的Bean呢? 如下圖所示
圖片
堆棧中的信息 解釋了原因。Do not request a bean from a BeanFactory in a destroy method implementation
在應用上下文關閉時，不得從上下文中Get Bean。恰好，這個問題出現在服務關閉期間.....
由于系統流量較高，日訂單幾百萬，即便在低峰期單機的并發度也是比較高的，所以服務在關閉期間有少量流量進來或未處理完。這個場景下，使用 Spring Event 發布事件，Spring 無法正常廣播事件，一定會出現異常，導致處理失敗！
大家一定要切記！使用 SpringEvent 之前，一定要先治理服務，確保服務關閉時，先切斷入口流量（Http、MQ、RPC），然后再關閉服務，關閉 Spring 上下文！
詳細的分析請參考：
2. 為什么服務啟動階段，Spring Event 事件丟失了？
我們公司遇到的情況是， Kafka conumser 在 init-method 階段開始消費，然而 Spring EventListener 被注冊進 Spring 的時間點滯后于 init-method 時間點，所以 Kafka Consumer 中使用 Spring Event 發布事件時，沒有找到監聽者，出現消息處理丟失的情況。
從下圖中可以看到 init-method 時間點 滯后于 EventListener 被注冊的時間點。
圖片
簡單來說：SpringBoot 會在Spring完全啟動完成后，才開啟Http流量。這給了我們啟示：應該在Spring啟動完成后開啟入口流量。Rpc和 MQ流量 也應該如此，所以建議大家 在 SmartLifecype 或者 ContextRefreshedEvent 等位置 注冊服務，開啟流量。
最佳實踐是：改造系統開啟入口流量（Http、MQ、RPC）的時機，確保在Spring 啟動完成后開啟入口流量。
什么業務特點適合發布——訂閱模式
每一個優秀的程序員都應該有自己的工具箱，他能在不同的業務場景選擇最合適的工具。
SpringEvent 適合哪些業務場景呢？這由訂閱發布模式的特性決定
- 事件發布者并不關心事件如何被處理
- 事件發布者不關心事件處理的結果
- 事件訂閱者有多個，可異步訂閱，也可以同步訂閱。
- 事件訂閱者之間各自獨立，互不依賴。
發布訂閱模式實現了發布和訂閱兩個模塊的解耦。但是對于強一致性的場景，并不適合使用發布訂閱模式。
3. 強一致性場景不適合 訂閱發布模式
強一致性的業務例如提單場景。提單階段，庫存扣減成功和訂單提單成功務必完全一致。庫存扣減失敗但提單成功；提單失敗，庫存未回滾等場景都是要避免發生的異常場景！
提單場景，使用 Spring Event會有很多問題。假設提單前，發布提單前置事件，事件訂閱者的業務邏輯可能有扣減庫存，鎖定優惠券資源等操作。庫存扣減失敗或者鎖定資源失敗需要回滾整個提單流程，然而 Spring 事件訂閱模式無法提供這種 訂閱異常——>回滾 的能力。
事件發布者無法獲知哪些訂閱消費失敗，哪些訂閱者成功？無法準確的觸發回滾流程。（如果基于 Spring Event 強行搞回滾，也可以做到，但方案會很復雜！）
4. 最終一致性的業務特性適合——發布訂閱模式
最終一致性場景非常適合使用 Spring Event。
例如提單成功后，發布 MQ ，釋放鎖等資源，可使用 SpringEvent 解耦。為什么呢？因為業務上確保提單成功后，提單實際上已經成功，后續的收尾工作不應該觸發訂單提單失敗。
在提單成功事件的訂閱者中，只有一種執行結果——成功。即使出現失敗，也應該重試直至成功。例如 發布 提單成功MQ 消息，釋放提單鎖等資源都是務必成功的業務邏輯。
再來舉一個例子，我們公司在處理訂單消息時使用了Spring Event框架。在這個場景中，我們需要處理履約完成、退款完成、訂單過期等事件，并且每個事件都有一些獨立的業務邏輯，每一個業務場景都屬于最終一致性的場景。舉個例子，履約完成后需要將履約數據和訂單金額等數據通知結算系統。這個業務場景是最終一致性場景，而不是強一致性，這是因為通知結算即便失敗，重試即可，無需回滾履約過程。
如果我們不使用Spring Event，那么我就需要手動編寫觀察者模式，并將訂單消息根據狀態通知到相應的觀察者中。又或者每當新增一個業務邏輯時，我需要新增一個Kafka消費組，并且在代碼中解析訂單消息，然后根據狀態將事件發送給相應的訂閱者。總之我需要把事件按照狀態分發給對應的監聽者。
在這個場景中，使用Spring Event非常適合。可以將每個事件封裝為Spring Event，并且每個業務邏輯都可以通過@EventListener注解來注冊對應狀態的事件監聽器（不過需要注意的是，如果訂閱者過多，那么Kafka消息的消費時間可能會增加。那么該如何解決呢？）。使用 Spring Event 框架比自己手寫監聽者模式強多了。
5. 使用SpringEvent 要有額外的可靠性保證！
Spring Event適用于需要保證最終一致性的業務場景，但為了確保可靠性，必須提供重試能力。通過使用 applicationContext.publishEvent(event) 方法發布事件，Spring會按順序執行相關的訂閱者。如果出現異常，publishEvent 方法會拋出異常，發布者能夠感知訂閱邏輯處理失敗了。
在發布事件時，需要考慮事件訂閱邏輯出現異常的情況，我提出三種解決辦法
- 訂閱者自行重試
訂閱邏輯可自行重試保證成功。例如使用 Spring retry注解可以保證出現異常時，重新執行該方法。
以下代碼示例 performSuccess 方法拋出異常時，Spring 會重新執行該方法直至成功，最多重試 3 次，可設置間隔時間，重試間隔遞增時間。
@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 會自動進行重試。
此外，還可以將消息發送到專門的死信隊列，在死信隊列中重新消費消息！不同公司的 Kafka 重試能力實現方案可能不同，大家自行選擇。
主動上報故障異常到故障管理平臺
故障處理流程
當請求一直重試失敗超過最大重試次數時，業務系統會上報到故障 MQ，故障管理平臺消費 MQ，收集故障并落庫。研發同學收到故障通知，介入排查問題。同時研發同學在故障管理后臺可以看到故障列表、故障詳情。
排查問題原因、敦促相關同事修復問題后，點擊重試按鈕。故障管理后臺收到重試請求，會通過 Rpc SPI 調用到業務系統 重試故障，并告知管理后臺成功和失敗結果。
圖片
6. Spring 訂閱者務必保證冪等
為了提高可靠性，要有額外的重試機制保證 Spring 訂閱發布的可靠性。
有重試就要有冪等！要保證 訂閱者邏輯具備冪等性。Spring 不知道哪些訂閱者成功，哪些訂閱者失敗，下一次重試時，會全部執行所有的訂閱者。所以訂閱邏輯要做好冪等，防止數據不一致情況發生。
為什么有消息隊列 MQ ，還需要 Spring Event
曾經有掘友給我評論，說我司對 Spring Event 的應用場景應該替換為 MQ。在此我解釋一下
Spring Event和 MQ 都屬于訂閱發布模式的應用，然而 MQ 比 SpringEvent 強大且復雜。MQ 更適合應用之間的解耦、隔離、事件通知。例如訂單支付、訂單完成、訂單履約完成等等事件需要廣播出去，通知下游其他微服務， 這種場景更適合使用 MQ 。
然而對于應用內需要訂閱發布的場景更適合使用 SpringEvent。兩者并不矛盾，MQ 能力更強大，技術方案也更”重“一些。Spring Event 更加小巧適合應用內訂閱發布，實現業務邏輯解耦。
