久等了，SOFABoot 3.0 正式釋出，支援 Spring Boot 2.0

摘要： 前言 久等了！SOFABoot 正式釋出 3.0.0，支援 Spring Boot 2.0～～ SOFABoot 是螞蟻金服開源的基於 Spring Boot 的研發框架，它在 Spring Boot 的基礎上，提供了諸如 Readiness Check，類隔離，日誌空間隔離等能力。在...

前言

久等了！SOFABoot 正式釋出 3.0.0，支援 Spring Boot 2.0～～

SOFABoot 是螞蟻金服開源的基於 Spring Boot 的研發框架，它在 Spring Boot 的基礎上，提供了諸如 Readiness Check，類隔離，日誌空間隔離等能力。在增強了 Spring Boot 的同時，SOFABoot 提供了讓使用者可以在 Spring Boot 中非常方便地使用 SOFA 中介軟體的能力。

自今年 4 月份 SOFABoot 開源至今，我們收到了非常多來自社群同學的反饋，也非常開心看到很多社群同學積極的參與到 SOFAStack 開源共建，這極大了鼓舞了我們建設 SOFAStack 開源社群的決心，力圖把 SOFAStack 社群和生態建設更加繁榮。對於 Spring Boot 2.0 的支援也是社群呼聲非常高的特性之一，經過了幾個月的 SNAPSHOT 版本的釋出，在此，我們宣佈推出 SOFABoot 3.0 版本，支援 Spring Boot 2.0。在 SOFABoot 3.0 中，可以將 SOFABoot 擴充套件能力和 Spring Boot 2.x 官方元件無縫整合。此外，我們在 SOFABoot 3.0 中相容了 Spring Cloud 元件整合，可以很方便地在 SOFABoot 框架中整合 Spring Cloud 元件，如 Zuul, Config 等。

以下，本文將詳細介紹 SOFABoot 3.0 相較 SOFABoot 2.x 的變更。

Spring Boot 升級 2.x

SOFABoot 3.0 版本升級 Spring Boot 版本至 2.0。鑑於Spring Boot 社群最近剛公告 1.x 版本將維護至明年 8 月份為止，未來，我們也將主力維護 SOFABoot 3.x 版本，近期也將釋出 SOFABoot 3.1 升級 Spring Boot 版本至 2.1。

Spring Cloud 相容

在 SOFABoot 2.x 中，存在部分元件和 SOFABoot 相容性問題。在 SOFABoot 3.x 中，對 Spring Cloud 各元件進行了比較完備的相容性測試和問題修復，保證了 SOFABoot 3.x 與 Spring Cloud 良好的相容性。

WebFlux 框架相容

Spring Boot 2.x 引入了 WebFlux 框架，SOFABoot 3.x 主要在兩個方面相容了 WebFlux 框架；

• 健康檢查相容了 ReactiveHealthIndicator 擴充套件介面，業務對這個介面的擴充套件實現將會納入到 Readiness Check；

• 相容對 WebFlux 網路請求進行埋點，埋點日誌格式和檔案保持對普通 MVC 請求相容，詳細參考ofollow,noindex" target="_blank">MVC 埋點請求

JDK 版本支援

SOFABoot 3.x 最低要求執行在 JDK 8 及其以上版本，不支援 JDK 6，7.

健康檢查

SOFABoot 為 Spring Boot 的健康檢查能力增加了 Readiness Check 能力，以確保應用在正常對外服務前，所有元件及業務本身處於健康狀態。相較於與 SOFABoot 2.x, SOFABoot 3.0 在健康檢查做了很大的重構，主要是剝離了部分螞蟻金服內部相容邏輯，採用更加友好的編碼方案；其次，SOFABoot 3.0 健康檢查提供了多種不同場景下的健康檢查擴充套件形式，支援 Spring Boot 2.x 引入的ReactiveHealthIndicator 擴充套件介面，豐富了健康檢查擴充套件特性。

調整 Readiness Check Endpoint 路徑

在 SOFABoot 2.x 中，檢視健康檢查結果的 Endpoint 為/health/readiness ，而在 SOFABoot 3.0 中，變更為/actuator/readiness 。

擴充套件介面變更

在 SOFABoot 3.x 中，提供四種方式擴充套件健康檢查，分別是

• HealthChecker

• HealthIndicator(Spring Boot 原生)

• ReactiveHealthIndicator(Spring Boot 原生)

• ReadinessCheckCallback

這四個介面的擴充套件實現執行順序是 HealthChecker > HealthIndicator, ReactiveHealthIndicator > ReadinessCheckCallback，相同介面的擴充套件實現執行順序則遵循 Spring Boot 標準的方案。即擴充套件類可以額外實現兩個標準的 Order 介面：

• org.springframework.core.Ordered

• org.springframework.core.PriorityOrdered

或者使用註解

• org.springframework.core.annotation.Order

這些介面的擴充套件實現處理結果將會在健康檢查結果查中展現。

刪除 SofaBootBeforeHealthCheckEvent 事件

在 SOFABoot 2.x 中，我們沒有提供支援對健康檢查擴充套件實現進行排序，導致使用者無法預期自身擴充套件執行時機。如上述，SOFABoot 3.x 支援各元件擴充套件實現的排序，因此該事件可以統一使用HealthChecker 介面和高優先順序順序實現替代。其次，在 SOFABoot 2.x 中，SofaBootBeforeHealthCheckEvent 事件的處理邏輯結果並不會反應在健康檢查結果中，使用HealthChecker 替代之後，這部分邏輯處理自然變成健康檢查的一部分，可供檢視。

刪除 DefaultHealthChecker 介面

使用 JDK8 預設方法特性，刪除 DefaultHealthChecker 介面，使用者可以直接使用 HealthChecker 介面替代 DefaultHealthChecker.

刪除 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 介面

在 SOFABoot 2.x 中，這兩個介面是兩種場景下的健康檢查回撥；推薦 SOFABoot 官方 Starter 使用 SofaBootMiddlewareAfterReadinessCheckCallback，而業務應用推薦使用SofaBootAfterReadinessCheckCallback，框架將優先執行 SofaBootMiddlewareAfterReadinessCheckCallback 的擴充套件實現，然後執行 SofaBootAfterReadinessCheckCallback 的擴充套件實現。這樣的設計有兩個缺陷：

• 兩個介面本質沒有區別，但是隱藏了先後順序邏輯，給使用者引入了額外的學習成本；

• 只考慮了 SofaBootMiddlewareAfterReadinessCheckCallback 和 SofaBootAfterReadinessCheckCallback 兩個介面的順序，但無法保證相同介面實現的執行順序。

SOFABoot 3.x 中則引入了統一的健康檢查回撥介面 ReadinessCheckCallback，無論是官方 Starter 還是業務都實現這個介面，順序的控制則遵循 Spring Boot 標準的方案。即通過額外實現兩個標準的 Order 介面：

• org.springframework.core.Ordered

• org.springframework.core.PriorityOrdered

或者使用註解

• org.springframework.core.annotation.Order

控制各個擴充套件實現的執行順序。

版本檢視

調整 Versions Endpoint 路徑

在 SOFABoot 2.x 中，版本資訊檢視的 Endpoint 為 /sofaboot/versions ，而在 SOFABoot 3.0 中，變更為 /actuator/versions

總結

以上是 SOFABoot 3.x 詳細的變更記錄，近期有升級或者試用的同學可以通過Github 聯絡，我們會及時的答覆與支援。