基于Spring Cloud Netflix的TCC柔性事務和EDA事件驅動示例

Solar

Spring Cloud為開發者提供了快速構建分布式系統中的一些常見工具，如分布式配置中心，服務發現與注冊中心，智能路由，服務熔斷及降級，消息總線，分布式追蹤的解決方案等。

本次實戰以模擬下單流程為背景，結合Spring Cloud Netflix和分布式事務解決方案中Try Confirm Cancel模式與基于事件驅動的服務架構作為實戰演示。

開發環境

• Docker 1.13.1

• Docker Compose 1.11.1

• Docker MySQL 5.7.17

• Docker RabbitMQ 3.6.6

• Java8 with JCE

• Spring Cloud Camden.SR6

?

系統結構

?

Try Confirm Cancel 補償模式

本實例遵循的是Atomikos公司對微服務的分布式事務所提出的RESTful TCC解決方案。

RESTful TCC模式分3個階段執行

1. Trying階段主要針對業務系統檢測及作出預留資源請求，若預留資源成功，則返回確認資源的鏈接與過期時間。

2. Confirm階段主要是對業務系統的預留資源作出確認，要求TCC服務的提供方要對確認預留資源的接口實現冪等性，若Confirm成功則返回204，資源超時則證明已經被回收且返回404。

3. Cancel階段主要是在業務執行錯誤或者預留資源超時后執行的資源釋放操作，Cancel接口是一個可選操作，因為要求TCC服務的提供方實現自動回收的功能，所以即便是不認為進行Cancel，系統也會自動回收資源。

?

Event Driven Architecture 基于事件驅動架構

本實例中的order-ms與membership-ms之間的通信是基于事件驅動的。當訂單被成功創建并且付款成功之后，該訂單的部分信息將會發往membership-ms以進行積分的增加。

從系統層面看，order-ms在EDA中是屬于Publisher角色，自然而然地membership-ms就是Subscriber。

Publisher中的事件狀態轉換如下：

• NEW —> PENDING —> DONE

• NEW —> PENDING —> FAILED / NO_ROUTE / NOT_FOUND / ERROR

  

Subscriber中的事件狀態轉換如下：

• NEW —> DONE

• NEW —> FAILED / NOT_FOUND / ERROR

  

部分功能介紹：

1. Publisher發送消息之前先將消息落地，目的是防止消息的錯誤發布（業務數據被回滾而消息卻發布至Broker）。

2. Publisher會周期性地掃描NEW狀態的消息，并發布至Broker。

3. 啟用mandatory與publisher confirms機制，在消息被持久化至磁盤后將會收到basic.ack，此時可選擇將消息轉換為DONE或者是直接將其刪除。

4. Publisher將消息發布至Broker后會將其狀態由NEW更新為PENDING，PENDING狀態的事件將會由另一定時器掃描在當前時鐘的3秒之前發布，但是卻并未得到basic.ack的事件，并重新發布至Broker。意在消除在單實例的情況下因crash而導致消息狀態丟失的邊緣情況。

5. Subscriber的消息冪等性。

?

基礎組件

Zuul Gateway

Zuul在本實例中僅作為路由所使用，配置降低Ribbon的讀取與連接超時上限。

Eureka H.A.

多個對等Eureka節點組成高可用集群，并將注冊列表的自我保護的閾值適當降低。

Config Server

• 如果遠程配置中有密文{cipher}*，那么該密文的解密將會延遲至客戶端啟動的時候. 因此客戶端需要配置AES的對稱密鑰encrypt.key，并且客戶端所使用的JRE需要安裝Java 8 JCE，否則將會拋出Illegal key size相關的異常。 (本例中Docker Compose構建的容器已經安裝了JCE，如果遠程配置文件沒有使用{cipher}*也不必進行JCE的安裝)

• 為了達到開箱即用，選用公開倉庫Github或者GitOsc。

• 本項目中有兩個自定義注解?@com.github.prontera.Delay?控制方法的延時返回時間；

  @com.github.prontera.RandomlyThrowsException?隨機拋出異常，人為地制造異常。

  默認的遠程配置如下

  solar:
  ??delay:
  ????time-in-millseconds:?0
  ??exception:
  ????enabled:?false
  ????factor:?7

  這些自定義配置正是控制方法返回的時延，隨機異常的因子等。

  我在服務order，product，account和tcc中的所有Controller上都添加了以上兩個注解，當遠程配置的更新時候，可以手工刷新/refresh或通過webhook等方法自動刷新本地配置. 以達到模擬微服務繁忙或熔斷等情況。

?

監控服務

Spring Boot Admin

此應用提供了管理Spring Boot服務的簡單UI，下圖是在容器中運行時的服務健康檢測頁

?

Hystrix Dashboard

提供近實時依賴的統計和監控面板，以監測服務的超時，熔斷，拒絕，降級等行為。

?

Zipkin Server

Zipkin是一款開源的分布式實時數據追蹤系統，其主要功能是聚集來自各個異構系統的實時監控數據，用來追蹤微服務架構下的系統時延問題. 下圖是對order服務的請求進行追蹤的情況。

?

業務服務

首次啟動時通過Flyway自動初始化數據庫。

對spring cloud config server采用fail fast策略，一旦遠程配置服務無法連接則無法啟動業務服務。

account

用于獲取用戶信息，用戶注冊，修改用戶余額，預留余額資源，確認預留余額，撤銷預留余額。

product

用于獲取產品信息，變更商品庫存，預留庫存資源，確認預留庫存，撤銷預留庫存。

tcc coordinator

TCC資源協調器，其職責如下：

• 對所有參與者發起Confirm請求。

• 無論是協調器發生的錯誤還是調用參與者所產生的錯誤，協調器都必須有自動恢復重試功能，尤其是在確認的階段，以防止網絡抖動的情況。

order

order服務是本項目的入口，盡管所提供的功能很簡單：

• 下單. 即生成預訂單，為了更好地測試TCC功能，在下單時就通過Feign向服務account與product發起預留資源請求，并且記錄入庫。

• 確認訂單. 確認訂單時根據訂單ID從庫中獲取訂單，并獲取預留資源確認的URI，交由服務tcc統一進行確認，如果發生沖突即記錄入庫，等待人工處理。

membership

用于訂單付款成功后，對下單用戶的積分進行增加操作。該服務與訂單服務是基于消息驅動以進行通信，達到事務的最終一致性。

Swagger UI

下圖為product服務的Swagger接口文檔，根據下文的服務字典可知，本接口文檔可通過http://localhost:8040/swagger-ui.html進行訪問.?order，account和tcc的文檔訪問方式亦是如出一撤。

?

?

運行

Docker Compose運行

在項目根路徑下執行腳本build.sh，該腳本會執行Maven的打包操作，并會迭代目錄下的*-compose.yml進行容器構建。

構建完成后需要按照指定的順序啟動，需要注意的一點是容器內服務的啟動是需要備留預熱時間，并非Docker容器啟動后容器內的所有服務就能馬上啟動起來，要注意區分容器的啟動和容器內的服務的啟動，建議配合docker-compse logs來觀察啟動情況。而且容器之間的服務是有依賴的，如account-ms和product-ms此類業務服務的啟動是會快速失敗于config-ms的失聯。所以建議按照以下順序啟動Docker容器，并且在一組Docker容器服務完全啟動后，再啟動下一組的Docker容器。

1. 啟動MySQL，RabbitMQ等基礎組件

   docker-compose?-f?infrastructure-compose.yml?up?-d

2. 啟動Eureka Server與Config Server

   docker-compose?-f?basic-ms-compose.yml?up?-d

3. 啟動監控服務

   docker-compose?-f?monitor-ms-compose.yml?up?-d

4. 啟動業務服務

   docker-compose?-f?business-ms-compose.yml?up?-d

IDE運行

因為程序本身按照Docker啟動，所以對于hostname需要在hosts文件中設置正確才能正常運行：

##?solar
127.0.0.1?eureka1
127.0.0.1?eureka2
127.0.0.1?rabbitmq
127.0.0.1?zipkin_server
127.0.0.1?solar_mysql
127.0.0.1?gitlab

根據依賴關系，程序最好按照以下的順序執行

docker mysql > docker rabbitmq > eureka server > config server > zipkin server > 其他業務微服務（account-ms, product-ms, order-ms, tcc-coordinator-ms等）

?

示例

根據附表中的服務字典，我們通過Zuul或Swagge對order服務進行預訂單生成操作。

POST?http://localhost:7291/order/api/v1/orders
Content-Type:?application/json;charset=UTF-8

{
??"product_id":?7,
??"user_id":?1
}

成功后我們將得到預訂單的結果

{
??"data":?{
????"id":?15,
????"create_time":?"2017-03-28T18:18:02.206+08:00",
????"update_time":?"1970-01-01T00:00:00+08:00",
????"delete_time":?"1970-01-01T00:00:00+08:00",
????"user_id":?1,
????"product_id":?7,
????"price":?14,
????"status":?"PROCESSING"
??},
??"code":?20000
}

此時我們再確認訂單

(如果想測試預留資源的補償情況，那么就等15s后過期再發請求，注意容器與宿主機的時間)

POST?http://localhost:7291/order/api/v1/orders/confirmation
Content-Type:?application/json;charset=UTF-8

{
??"order_id":?15
}

如果成功確認則返回如下結果

{
??"data":?{
????"id":?15,
????"create_time":?"2017-03-28T18:18:02.206+08:00",
????"update_time":?"2017-03-28T18:21:32.78+08:00",
????"delete_time":?"1970-01-01T00:00:00+08:00",
????"user_id":?1,
????"product_id":?7,
????"price":?14,
????"status":?"DONE"
??},
??"code":?20000
}

至此就完成了一次TCC事務，當然你也可以測試超時和沖突的情況，這里就不再贅述。

?

拓展

使用Gitlab作為遠程配置倉庫

本例中默認使用Github或GitOsc中的公開倉庫，出于自定義的需要，我們可以在本地構建Git倉庫，這里選用Gitlab為例。

將以下配置添加至docker compose中的文件中并啟動Docker Gitlab容器：

gitlab:
????image:?daocloud.io/daocloud/gitlab:8.16.7-ce.0
????ports:
????????-?"10222:22"
????????-?"80:80"
????????-?"10443:443"
????volumes:
????????-?"./docker-gitlab/config/:/etc/gitlab/"
????????-?"./docker-gitlab/logs/:/var/log/gitlab/"
????????-?"./docker-gitlab/data/:/var/opt/gitlab/"
????environment:
????????-?TZ=Asia/Shanghai

將項目的config-repo添加至Gitlab中，并修改config-ms中git倉庫的相關驗證等參數即可。

?

服務字典

鑒于Spring Boot Actuator的端點所帶來的兩面性，除了可以增加spring-boot-starter-security來獲得強度較弱的HTTP Basic認證外，我們還可以修改management.port和management.context-path來提高***成本. 是的，我對每一個服務都修改了以上兩個屬性，并且兼容了Eureka Server，Hystrix Dashboard，Spring Boot Admin，使這些監控服務仍能正確工作. 因為對以上兩個參數修改，我們的監控路徑有所變化，如下表：

?