作者：阿里巴巴淘系技術
鏈接：https://www.zhihu.com/question/60761181/answer/1737592739
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
?

分享一套使用Spring特性優雅書寫業務代碼的方法。

大家在日常業務開發工作中相信多多少少遇到過下面這樣的幾個場景：

• 當某一個特定事件或動作發生以后，需要執行很多聯動動作，如果串行去執行的話太耗時，如果引入消息中間件的話又太重了；
• 想要針對不同的傳參執行不同的策略，也就是我們常說的策略模式，但10個人可能有10種不同的寫法，夾雜在一起總感覺不那么優雅；
• 自己的系統想要調用其他系統提供的能力，但其他系統總是偶爾給你一點“小驚喜”，可能因網絡問題報超時異常或被調用的某一臺分布式應用機器突然宕機，我們想要優雅無侵入式地引入重試機制。

?

其實上面提到的幾個典型業務開發場景Spring都為我們提供了很好的特性支持，我們只需要引入Spring相關依賴就可以方便快速的在業務代碼當中使用啦，而不用引入過多的三方依賴包或自己重復造輪子。下面我們就來看看Spring提供的強大魔力吧。

?

使用Spring優雅實現觀察者模式

觀察者模式定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并被自動更新，其主要解決一個對象狀態改變給其他關聯對象通知的問題，保證易用和低耦合。一個典型的應用場景是：當用戶注冊以后，需要給用戶發送郵件，發送優惠券等操作，如下圖所示。

?

使用觀察者模式后：

UserService 在完成自身的用戶注冊邏輯之后，僅僅只需要發布一個 UserRegisterEvent 事件，而無需關注其它拓展邏輯。其它 Service 可以自己訂閱 UserRegisterEvent 事件，實現自定義的拓展邏輯。Spring的事件機制主要由3個部分組成。

• ApplicationEvent：通過繼承它，實現自定義事件。另外，通過它的 source 屬性可以獲取事件源，timestamp 屬性可以獲得發生時間。
• ApplicationEventPublisher：通過實現它，來發布變更事件。
• ApplicationEventListener：通過實現它，來監聽指定類型事件并響應動作。這里就以上面的用戶注冊為例，來看看代碼示例。首先定義用戶注冊事件 UserRegisterEvent。

publicclass UserRegisterEvent extends ApplicationEvent {/*** 用戶名*/private String username;public UserRegisterEvent(Object source) {super(source);}public UserRegisterEvent(Object source, String username) {super(source);this.username = username;}public String getUsername() {return username;} }

?

然后定義用戶注冊服務類，實現 ApplicationEventPublisherAware 接口，從而將 ApplicationEventPublisher 注入進來。從下面代碼可以看到，在執行完注冊邏輯后，調用了 ApplicationEventPublisher的 publishEvent(ApplicationEvent event) 方法，發布了 UserRegisterEvent 事件。

?

@Service publicclass UserService implements ApplicationEventPublisherAware { // <1>private Logger logger = LoggerFactory.getLogger(getClass());private ApplicationEventPublisher applicationEventPublisher;@Overridepublic void setApplicationEventPublisher(ApplicationEventPublisher applicationEventPublisher) {this.applicationEventPublisher = applicationEventPublisher;}public void register(String username) {// ... 執行注冊邏輯logger.info("[register][執行用戶({}) 的注冊邏輯]", username);// <2> ... 發布applicationEventPublisher.publishEvent(new UserRegisterEvent(this, username));} }

?

創建郵箱Service，實現 ApplicationListener 接口，通過 E 泛型設置感興趣的事件，實現 onApplicationEvent(E event) 方法，針對監聽的 UserRegisterEvent 事件，進行自定義處理。

@Service publicclass EmailService implements ApplicationListener<UserRegisterEvent> { // <1>private Logger logger = LoggerFactory.getLogger(getClass());@Override@Async// <3>public void onApplicationEvent(UserRegisterEvent event) { // <2>logger.info("[onApplicationEvent][給用戶({}) 發送郵件]", event.getUsername());} }

創建優惠券Service，不同于上面的實現 ApplicationListener 接口方式，在方法上，添加 @EventListener 注解，并設置監聽的事件為 UserRegisterEvent。這是另一種使用方式。

@Service publicclass CouponService {private Logger logger = LoggerFactory.getLogger(getClass());@EventListener// <1>public void addCoupon(UserRegisterEvent event) {logger.info("[addCoupon][給用戶({}) 發放優惠劵]", event.getUsername());} }

看到這里，細心的同學可能想到了發布訂閱模式，其實觀察者模式于發布訂閱還是有區別的，簡單來說，發布訂閱模式屬于廣義上的觀察者模式，在觀察者模式的 Subject 和 Observer 的基礎上，引入 Event Channel 這個中介，進一步解耦。圖示如下，可以看出，觀察者模式更加輕量，通常用于單機，而發布訂閱模式相對而言更重一些，通常用于分布式環境下的消息通知場景。

使用Spring Retry優雅引入重試機制

如今，Spring Retry是一個獨立的包了(早期是Spring Batch的一部分)，下面是使用Spring Retry框架進行重試的幾個重要步驟。第一步：加入Spring Retry依賴包

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

第二步：在應用中包含main()方法的類或者在包含@Configuration的類上加上@EnableRetry注解 第三步：在想要進行重試的方法(可能發生異常)上加上@Retryable注解

@Retryable(maxAttempts=5,backoff = @Backoff(delay = 3000)) public void retrySomething() throws Exception{logger.info("printSomething{} is called");thrownew SQLException(); }

在上面這個案例當中的重試策略就是重試5次，每次延時3秒。詳細的使用文檔看這里，它的主要配置參數有下面這樣幾個。其中exclude、include、maxAttempts、value幾個屬性很容易理解，比較看不懂的是backoff屬性，它也是個注解，包含delay、maxDelay、multiplier、random四個屬性。

• delay：如果不設置的話默認是1秒
• maxDelay：最大重試等待時間
• multiplier：用于計算下一個延遲時間的乘數(大于0生效)
• random：隨機重試等待時間(一般不用)

?

Spring Retry的優點很明顯，第一，屬于Spring大生態，使用起來不會太生硬；第二，只需要在需要重試的方法上加上注解并配置重試策略屬性就好，不需要太多侵入代碼。

但同時也存在兩個主要不足，第一，由于Spring Retry用到了Aspect增強，所以就會有使用Aspect不可避免的坑——方法內部調用，如果被 @Retryable 注解的方法的調用方和被調用方處于同一個類中，那么重試將會失效；第二，Spring的重試機制只支持對異常進行捕獲，而無法對返回值進行校驗判斷重試。如果想要更靈活的重試策略可以考慮使用Guava Retry，也是一個不錯的選擇。

?

?

優雅使用Spring特性完成業務策略模式

策略模式相信大家都應該比較熟悉，它定義了一系列的算法，并將每一個算法封裝起來，使每個算法可以相互替代，使算法本身和使用算法的客戶端分割開來，相互獨立。

其適用的場景是這樣的：一個大功能，它有許多不同類型的實現（策略類），具體根據客戶端來決定采用哪一個策略類。比如下單優惠策略、物流對接策略等，應用場景還是非常多的。

舉一個簡單的例子，業務背景是這樣的：平臺需要根據不同的業務進行鑒權，每個業務的鑒權邏輯不一樣，都有自己的一套獨立的判斷邏輯，因此需要根據傳入的 bizType 進行鑒權操作，首先我們定義一個權限校驗處理器接口如下。

/*** 業務權限校驗處理器*/ publicinterface PermissionCheckHandler {/*** 判斷是否是自己能夠處理的權限校驗類型*/boolean isMatched(BizType bizType);/*** 權限校驗邏輯*/PermissionCheckResultDTO permissionCheck(Long userId, String bizCode); } 業務1的鑒權邏輯我們假設是這樣的： /*** 冷啟動權限校驗處理器*/ @Component publicclass ColdStartPermissionCheckHandlerImpl implements PermissionCheckHandler {@Overridepublic boolean isMatched(BizType bizType) {return BizType.COLD_START.equals(bizType);}@Overridepublic PermissionCheckResultDTO permissionCheck(Long userId, String bizCode) {//業務特有鑒權邏輯} } 業務2的鑒權邏輯我們假設是這樣的： /*** 趨勢業務權限校驗處理器*/ @Component publicclass TrendPermissionCheckHandlerImpl implements PermissionCheckHandler {@Overridepublic boolean isMatched(BizType bizType) {return BizType.TREND.equals(bizType);}@Overridepublic PermissionCheckResultDTO permissionCheck(Long userId, String bizCode){//業務特有鑒權邏輯} }

可能還有很多其他的業務鑒權邏輯，這里就不一一列舉了，實現邏輯像上面這樣組織就好了。接著就到了關鍵的地方了，上面我們定義了這么多策略，應該怎么優雅的組織起來呢，這就需要用到Spring提供的一些擴展特性了，Spring主要為我們提供了三類擴展點，分別對應不同Bean生命周期階段：

• Aware接口
• BeanPostProcessor
• InitializingBean 和 init-method

我們這里用到的主要是 Aware 接口和 InitializingBean 兩個擴展點，其主要用法如下代碼所示，關鍵點就在于實現 ApplicationContextAware 接口的 setApplicationContext 方法和 InitializingBean 接口的 afterPropertiesSet 方法。

實現 ApplicationContextAware 接口的目的就是要拿到 Spring 容器的資源，從而方便的使用它提供的 getBeansOfType 方法(該方法返回的是 map 類型，key 對應 beanName, value 對應 bean)；而實現 InitializingBean 接口的目的則是方便為 Service 類的 handlers 屬性執行定制初始化邏輯。

?

可以很明顯的看出，如果以后還有一些其他的業務需要制定相應的鑒權邏輯，我們只需要編寫對應的策略類就好了，無需再破壞當前 Service 類的邏輯，很好的保證了開閉原則。

/*** 權限校驗服務類*/ @Slf4j @Service publicclass PermissionServiceImplimplements PermissionService, ApplicationContextAware, InitializingBean {private ApplicationContext applicationContext;//注：這里可以使用Map，偷個懶private List<PermissionCheckHandler> handlers = new ArrayList<>();@Overridepublic PermissionCheckResultDTO permissionCheck(ArtemisSellerBizType artemisSellerBizType, Long userId,String bizCode) {//省略一些前置邏輯PermissionCheckHandler handler = getHandler(artemisSellerBizType);return handler.permissionCheck(userId, bizCode);}private PermissionCheckHandler getHandler(ArtemisSellerBizType artemisSellerBizType) {for (PermissionCheckHandler handler : handlers) {if (handler.isMatched(artemisSellerBizType)) {return handler;}}returnnull;}@Overridepublic void afterPropertiesSet() throws Exception {for (PermissionCheckHandler handler : applicationContext.getBeansOfType(PermissionCheckHandler.class).values()) {handlers.add(handler);log.warn("load permission check handler [{}]", handler.getClass().getName());}}@Overridepublic void setApplicationContext(ApplicationContext applicationContext) throws BeansException {this.applicationContext = applicationContext;} }

當然在這里相信不少同學會有疑問，那就是這里在獲取 handler 處理器 bean 的時候，所有的 bean 是不是已經初始化好了？會不會存在有的 handler 還沒有初始化好的情況？

?

答案是不會的，Spring Bean 的聲明周期保證了這一點(當然前提是 handler 自身不會有特殊的初始化邏輯)。經過實際驗證，所有的 handler 會在 Service 初始化操作前 ready，感興趣的同學可以編寫代碼驗證，可以先在相應鉤子處打上日志直接輸出結果驗證，然后在 Spring 源碼關鍵處打上斷點 debug，相信會有不少收獲。

?

總結&思考

公司里的有些代碼有點年齡，有些類寫的又臭又長，很多地方充斥著代碼壞味道，如重復的代碼，過長的參數列，散彈式修改，基本型偏執等等，不一一展開。每天要面對這些代碼進行開發，不僅消磨了我們對技術的熱情也讓人變得毫無斗志，很多同學會想——反正都已經這樣了，那我也就這么來吧，相信不少小伙伴都有這樣的遭遇與困惑。

但唯一不能停下來的就是進步，即使面對惡龍還是不能放棄抵抗。當然，在做需求的時候，很多時候也不能去修改那些代碼，太耗時太費勁，風險太大。那自己起碼也要思考一下如何設計代碼才能去避免以后出現同樣的情況，讓自己下次不要犯同樣的錯誤。

當我們在實際編寫代碼的時候，需要留意探索一下Spring有沒有為我們提供一些已有的工具類和擴展點。一方面，使用Spring提供的這些特性可以讓我們少造輪子，避免引入其他比較重的類庫；另一方面，Spring對JDK等庫提供的一些類和規范進行了抽象封裝，易用性更好，更貼合開發者需求。

總結

以上是生活随笔為你收集整理的使用Spring特性优雅书写业务代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。