Spring Cloud為開發(fā)者提供了快速構(gòu)建分布式系統(tǒng)中的一些常見工具，如分布式配置中心，服務(wù)發(fā)現(xiàn)與注冊中心，智能路由，服務(wù)熔斷及降級，消息總線，分布式追蹤的解決方案等。
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計、做網(wǎng)站、義安網(wǎng)絡(luò)推廣、成都微信小程序、義安網(wǎng)絡(luò)營銷、義安企業(yè)策劃、義安品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供義安建站搭建服務(wù)，24小時服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
本次實戰(zhàn)以模擬下單流程為背景，結(jié)合Spring Cloud Netflix和分布式事務(wù)解決方案中Try Confirm Cancel模式與基于事件驅(qū)動的服務(wù)架構(gòu)作為實戰(zhàn)演示。
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
本實例遵循的是Atomikos公司對微服務(wù)的分布式事務(wù)所提出的RESTful TCC解決方案。
RESTful TCC模式分3個階段執(zhí)行
Trying階段主要針對業(yè)務(wù)系統(tǒng)檢測及作出預(yù)留資源請求，若預(yù)留資源成功，則返回確認(rèn)資源的鏈接與過期時間。
Confirm階段主要是對業(yè)務(wù)系統(tǒng)的預(yù)留資源作出確認(rèn)，要求TCC服務(wù)的提供方要對確認(rèn)預(yù)留資源的接口實現(xiàn)冪等性，若Confirm成功則返回204，資源超時則證明已經(jīng)被回收且返回404。
Cancel階段主要是在業(yè)務(wù)執(zhí)行錯誤或者預(yù)留資源超時后執(zhí)行的資源釋放操作，Cancel接口是一個可選操作，因為要求TCC服務(wù)的提供方實現(xiàn)自動回收的功能，所以即便是不認(rèn)為進行Cancel，系統(tǒng)也會自動回收資源。
本實例中的order-ms與membership-ms之間的通信是基于事件驅(qū)動的。當(dāng)訂單被成功創(chuàng)建并且付款成功之后，該訂單的部分信息將會發(fā)往membership-ms以進行積分的增加。
從系統(tǒng)層面看，order-ms在EDA中是屬于Publisher角色，自然而然地membership-ms就是Subscriber。
Publisher中的事件狀態(tài)轉(zhuǎn)換如下：
NEW —> PENDING —> DONE
NEW —> PENDING —> FAILED / NO_ROUTE / NOT_FOUND / ERROR
Subscriber中的事件狀態(tài)轉(zhuǎn)換如下：
NEW —> DONE
NEW —> FAILED / NOT_FOUND / ERROR
部分功能介紹：
Publisher發(fā)送消息之前先將消息落地，目的是防止消息的錯誤發(fā)布（業(yè)務(wù)數(shù)據(jù)被回滾而消息卻發(fā)布至Broker）。
Publisher會周期性地掃描NEW狀態(tài)的消息，并發(fā)布至Broker。
啟用mandatory與publisher confirms機制，在消息被持久化至磁盤后將會收到basic.ack，此時可選擇將消息轉(zhuǎn)換為DONE或者是直接將其刪除。
Publisher將消息發(fā)布至Broker后會將其狀態(tài)由NEW更新為PENDING，PENDING狀態(tài)的事件將會由另一定時器掃描在當(dāng)前時鐘的3秒之前發(fā)布，但是卻并未得到basic.ack的事件，并重新發(fā)布至Broker。意在消除在單實例的情況下因crash而導(dǎo)致消息狀態(tài)丟失的邊緣情況。
Subscriber的消息冪等性。
Zuul在本實例中僅作為路由所使用，配置降低Ribbon的讀取與連接超時上限。
多個對等Eureka節(jié)點組成高可用集群，并將注冊列表的自我保護的閾值適當(dāng)降低。
如果遠程配置中有密文{cipher}*，那么該密文的解密將會延遲至客戶端啟動的時候. 因此客戶端需要配置AES的對稱密鑰encrypt.key，并且客戶端所使用的JRE需要安裝Java 8 JCE，否則將會拋出Illegal key size相關(guān)的異常。 (本例中Docker Compose構(gòu)建的容器已經(jīng)安裝了JCE，如果遠程配置文件沒有使用{cipher}*也不必進行JCE的安裝)
為了達到開箱即用，選用公開倉庫Github或者GitOsc。
本項目中有兩個自定義注解?@com.github.prontera.Delay?控制方法的延時返回時間；
@com.github.prontera.RandomlyThrowsException?隨機拋出異常，人為地制造異常。
默認(rèn)的遠程配置如下
solar: ??delay: ????time-in-millseconds:?0 ??exception: ????enabled:?false ????factor:?7
這些自定義配置正是控制方法返回的時延，隨機異常的因子等。
我在服務(wù)order，product，account和tcc中的所有Controller上都添加了以上兩個注解，當(dāng)遠程配置的更新時候，可以手工刷新/refresh或通過webhook等方法自動刷新本地配置. 以達到模擬微服務(wù)繁忙或熔斷等情況。
此應(yīng)用提供了管理Spring Boot服務(wù)的簡單UI，下圖是在容器中運行時的服務(wù)健康檢測頁
提供近實時依賴的統(tǒng)計和監(jiān)控面板，以監(jiān)測服務(wù)的超時，熔斷，拒絕，降級等行為。
Zipkin是一款開源的分布式實時數(shù)據(jù)追蹤系統(tǒng)，其主要功能是聚集來自各個異構(gòu)系統(tǒng)的實時監(jiān)控數(shù)據(jù)，用來追蹤微服務(wù)架構(gòu)下的系統(tǒng)時延問題. 下圖是對order服務(wù)的請求進行追蹤的情況。
首次啟動時通過Flyway自動初始化數(shù)據(jù)庫。
對spring cloud config server采用fail fast策略，一旦遠程配置服務(wù)無法連接則無法啟動業(yè)務(wù)服務(wù)。
用于獲取用戶信息，用戶注冊，修改用戶余額，預(yù)留余額資源，確認(rèn)預(yù)留余額，撤銷預(yù)留余額。
用于獲取產(chǎn)品信息，變更商品庫存，預(yù)留庫存資源，確認(rèn)預(yù)留庫存，撤銷預(yù)留庫存。
TCC資源協(xié)調(diào)器，其職責(zé)如下：
對所有參與者發(fā)起Confirm請求。
無論是協(xié)調(diào)器發(fā)生的錯誤還是調(diào)用參與者所產(chǎn)生的錯誤，協(xié)調(diào)器都必須有自動恢復(fù)重試功能，尤其是在確認(rèn)的階段，以防止網(wǎng)絡(luò)抖動的情況。
order服務(wù)是本項目的入口，盡管所提供的功能很簡單：
下單. 即生成預(yù)訂單，為了更好地測試TCC功能，在下單時就通過Feign向服務(wù)account與product發(fā)起預(yù)留資源請求，并且記錄入庫。
確認(rèn)訂單. 確認(rèn)訂單時根據(jù)訂單ID從庫中獲取訂單，并獲取預(yù)留資源確認(rèn)的URI，交由服務(wù)tcc統(tǒng)一進行確認(rèn)，如果發(fā)生沖突即記錄入庫，等待人工處理。
用于訂單付款成功后，對下單用戶的積分進行增加操作。該服務(wù)與訂單服務(wù)是基于消息驅(qū)動以進行通信，達到事務(wù)的最終一致性。
下圖為product服務(wù)的Swagger接口文檔，根據(jù)下文的服務(wù)字典可知，本接口文檔可通過http://localhost:8040/swagger-ui.html進行訪問.?order，account和tcc的文檔訪問方式亦是如出一撤。
在項目根路徑下執(zhí)行腳本build.sh，該腳本會執(zhí)行Maven的打包操作，并會迭代目錄下的*-compose.yml進行容器構(gòu)建。
構(gòu)建完成后需要按照指定的順序啟動，需要注意的一點是容器內(nèi)服務(wù)的啟動是需要備留預(yù)熱時間，并非Docker容器啟動后容器內(nèi)的所有服務(wù)就能馬上啟動起來，要注意區(qū)分容器的啟動和容器內(nèi)的服務(wù)的啟動，建議配合docker-compse logs來觀察啟動情況。而且容器之間的服務(wù)是有依賴的，如account-ms和product-ms此類業(yè)務(wù)服務(wù)的啟動是會快速失敗于config-ms的失聯(lián)。所以建議按照以下順序啟動Docker容器，并且在一組Docker容器服務(wù)完全啟動后，再啟動下一組的Docker容器。
啟動MySQL，RabbitMQ等基礎(chǔ)組件
docker-compose?-f?infrastructure-compose.yml?up?-d
啟動Eureka Server與Config Server
docker-compose?-f?basic-ms-compose.yml?up?-d
啟動監(jiān)控服務(wù)
docker-compose?-f?monitor-ms-compose.yml?up?-d
啟動業(yè)務(wù)服務(wù)
docker-compose?-f?business-ms-compose.yml?up?-d
因為程序本身按照Docker啟動，所以對于hostname需要在hosts文件中設(shè)置正確才能正常運行：
##?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
根據(jù)依賴關(guān)系，程序最好按照以下的順序執(zhí)行
docker mysql > docker rabbitmq > eureka server > config server > zipkin server > 其他業(yè)務(wù)微服務(wù)（account-ms, product-ms, order-ms, tcc-coordinator-ms等）
根據(jù)附表中的服務(wù)字典，我們通過Zuul或Swagge對order服務(wù)進行預(yù)訂單生成操作。
重慶分公司
重慶分公司
POST?http://localhost:7291/order/api/v1/orders
Content-Type:?application/json;charset=UTF-8
{
??"product_id":?7,
??"user_id":?1
}成功后我們將得到預(yù)訂單的結(jié)果
{
??"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
}此時我們再確認(rèn)訂單
(如果想測試預(yù)留資源的補償情況，那么就等15s后過期再發(fā)請求，注意容器與宿主機的時間)
POST?http://localhost:7291/order/api/v1/orders/confirmation
Content-Type:?application/json;charset=UTF-8
{
??"order_id":?15
}如果成功確認(rèn)則返回如下結(jié)果
{
??"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事務(wù)，當(dāng)然你也可以測試超時和沖突的情況，這里就不再贅述。
本例中默認(rèn)使用Github或GitOsc中的公開倉庫，出于自定義的需要，我們可以在本地構(gòu)建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中g(shù)it倉庫的相關(guān)驗證等參數(shù)即可。
鑒于Spring Boot Actuator的端點所帶來的兩面性，除了可以增加spring-boot-starter-security來獲得強度較弱的HTTP Basic認(rèn)證外，我們還可以修改management.port和management.context-path來提高***成本. 是的，我對每一個服務(wù)都修改了以上兩個屬性，并且兼容了Eureka Server，Hystrix Dashboard，Spring Boot Admin，使這些監(jiān)控服務(wù)仍能正確工作. 因為對以上兩個參數(shù)修改，我們的監(jiān)控路徑有所變化，如下表：
?
