SpringCloud框架
針對這個架構圖我分層介紹一下：
1、是web服務器的選型，這個我選擇的是nginx+keepalived，haproxy也是一個選擇，但是haproxy在反向代理處理跨域訪問的時候問題很多。所以我們nginx有些地方做了keep-alive模式處理，減少了三次握手的次數，提高了連接效率。keepalived做nginx的負載，虛擬一個vip對外，兩個nginx做高可用，nginx本身反向代理zuul集羣。
2、api gateway，這裏的zuul很多人詬病，說是速度慢推薦直接用nginx，這裏我還是推薦使用zuul的，畢竟zuul含有攔截器和反向代理，在權限管理、單點登錄、用戶認證時候還是很有用的，而且zuul自帶ribbon負載均衡，如果你直接用nginx，還需要單獨做一個feign或者ribbon層，用來做業務集羣的負載層，畢竟直接把接口暴露給web服務器太危險了。這裏zuul帶有ribbon負載均衡和hystrix斷路器，直接反向代理serviceId就可以代理整個集羣了。
3、業務集羣，這一層我有些項目是分兩層的，就是上面加了一個負載層，下面是從service開始的，底層只是單純的接口，controller是單獨一層由feign實現，然後內部不同業務服務接口互調，直接調用controller層，只能說效果一般，多了一次tcp連接。所以我推薦合併起來，因爲做過spring cloud項目的都知道，feign是含有ribbon的，而zuul也含有ribbon，這樣的話zuul調用服務集羣，和服務集羣間接口的互調都是高可用的，保證了通訊的穩定性。Hystrix還是要有的，沒有斷路器很難實現服務降級，會出現大量請求發送到不可用的節點。當然service是可以改造的，如果改造成rpc方式，那服務之間互調又是另外一種情況了，那就要做成負載池和接口服務池的形式了，負載池調用接口池，接口池互相rpc調用，feign client只是通過實現接口達到了仿rpc的形式，不過速度表現還是不錯的。
4、redis緩存池，這個用來做session共享，分佈式系統session共享是一個大問題。同時呢，redis做二級緩存對降低整個服務的響應時間，並且減少數據庫的訪問次數是很有幫助的。當然redis cluster還是redis sentinel自己選擇。
5、eurake註冊中心這個高可用集羣，這裏有很多細節，比如多久刷新列表一次，多久監測心跳什麼的，都很重要。
6、spring admin，這個是很推薦的，這個功能很強大，可以集成turbine斷路器監控器，而且可以定義所有類的log等級，不用單獨去配置，還可以查看本地log日誌文件，監控不同服務的機器參數及性能，非常強大。它加上elk動態日誌收集系統，對於項目運維非常方便。
7、zipkin，這個有兩種方式，直接用它自己的功能界面查看方式，或者用stream流的方式，由elk動態日誌系統收集。但是我必須要說，這個對系統的性能損害非常大，因爲鏈路追蹤的時候會造成響應等待，而且等待時間非常長接近1秒，這在生產環境是不能忍受的，所以生產環境最好關掉，有問題調試的時候再打開。
8、消息隊列，這個必須的，分佈式系統不可能所有場景都滿足強一致性，這裏只能由消息隊列來作爲緩衝，這裏我用的是Kafka。
9、分佈式事物，我認爲這是分佈式最困難的，因爲不同的業務集羣都對應自己的數據庫，互相數據庫不是互通的，互相服務調用只能是相互接口，有些甚至是異地的，這樣造成的結果就是網絡延遲造成的請求等待，網絡抖動造成的數據丟失，這些都是很可怕的問題，所以必須要處理分佈式事物。我推薦的是利用消息隊列，採取二階段提交協議配合事物補償機制，具體的實現需要結合業務，這裏篇幅有限就不展開說了。
10、config配置中心，這是很有必要的，因爲服務太多配置文件太多，沒有這個很難運維。這個一般利用消息隊列建立一個spring cloud bus，由git存儲配置文件，利用bus總線動態更新配置文件信息。
11、實時分佈式日誌系統，logstash收集本地的log文件流，傳輸給elasticsearch，logstash有兩種方式，1、是每一臺機器啓動一個logstash服務，讀取本地的日誌文件，生成流傳給elasticsearch。2、logback引入logstash包，然後直接生產json流傳給一箇中心的logstash服務器，它再傳給elasticsearch。elasticsearch再將流傳給kibana，動態查看日誌，甚至zipkin的流也可以直接傳給elasticsearch。這個配合spring admin，一個查看動態日誌，一個查看本地日誌，同時還能遠程管理不同類的日誌級別，對集成和運維非常有利。
最後要說說，spring cloud的很多東西都比較精確，比如斷路器觸發時間、事物補償時間、http響應時間等，這些都需要好好的設計，而且可以優化的點非常多。比如：http通訊可以使用okhttp，jvm優化，nio模式，數據連接池等等，都可以很大的提高性能。
還有一個docker問題，很多人說不用docker就不算微服務。其實我個人意見，spring cloud本身就是微服務的，只需要jdk環境即可。編寫dockerfile也無非是集成jdk、添加jar包、執行jar而已，或者用docker compose，將多個不同服務的image組合run成容器而已。但是帶來的問題很多，比如通訊問題、服務器性能損耗問題、容器進程崩潰問題，當然如果你有一套成熟的基於k8s的容器管理平臺，這個是沒問題的，如果沒有可能就要斟酌了。而spring cloud本身就是微服務分佈式的架構，所以個人還是推薦直接機器部署的，當然好的DevOps工具將會方便很多。
作者github地址：https://github.com/cyc3552637
引言
面試中面試官喜歡問組件的實現原理，尤其是常用技術，我們平時使用了SpringCloud還需要了解它的實現原理，這樣不僅起到舉一反三的作用，還能幫助輕鬆應對各種問題及有針對的進行擴展。
以下是《Java深入微服務原理改造房產銷售平臺》課程講到的部分原理附圖，現在免費開放給大家，讓大家輕鬆應對原理面試題。
服務註冊發現組件Eureka工作原理
1、Eureka 簡介：
Eureka 是 Netflix 出品的用於實現服務註冊和發現的工具。 Spring Cloud 集成了 Eureka，並提供了開箱即用的支持。其中， Eureka 又可細分爲 Eureka Server 和 Eureka Client。
1.基本原理
上圖是來自eureka的官方架構圖，這是基於集羣配置的eureka；
- 處於不同節點的eureka通過Replicate進行數據同步
- Application Service爲服務提供者
- Application Client爲服務消費者
- Make Remote Call完成一次服務調用
服務啓動後向Eureka註冊，Eureka Server會將註冊信息向其他Eureka Server進行同步，當服務消費者要調用服務提供者，則向服務註冊中心獲取服務提供者地址，然後會將服務提供者地址緩存在本地，下次再調用時，則直接從本地緩存中取，完成一次調用。
當服務註冊中心Eureka Server檢測到服務提供者因爲宕機、網絡原因不可用時，則在服務註冊中心將服務置爲DOWN狀態，並把當前服務提供者狀態向訂閱者發佈，訂閱過的服務消費者更新本地緩存。
服務提供者在啓動後，週期性（默認30秒）向Eureka Server發送心跳，以證明當前服務是可用狀態。Eureka Server在一定的時間（默認90秒）未收到客戶端的心跳，則認爲服務宕機，註銷該實例。
2.Eureka的自我保護機制
在默認配置中，Eureka Server在默認90s沒有得到客戶端的心跳，則註銷該實例，但是往往因爲微服務跨進程調用，網絡通信往往會面臨着各種問題，比如微服務狀態正常，但是因爲網絡分區故障時，Eureka Server註銷服務實例則會讓大部分微服務不可用，這很危險，因爲服務明明沒有問題。
爲了解決這個問題，Eureka 有自我保護機制，通過在Eureka Server配置如下參數，可啓動保護機制
eureka.server.enable-self-preservation=true
它的原理是，當Eureka Server節點在短時間內丟失過多的客戶端時（可能發送了網絡故障），那麼這個節點將進入自我保護模式，不再註銷任何微服務，當網絡故障回覆後，該節點會自動退出自我保護模式。
自我保護模式的架構哲學是寧可放過一個，決不可錯殺一千
3. 作爲服務註冊中心，Eureka比Zookeeper好在哪裏
著名的CAP理論指出，一個分佈式系統不可能同時滿足C(一致性)、A(可用性)和P(分區容錯性)。由於分區容錯性在是分佈式系統中必須要保證的，因此我們只能在A和C之間進行權衡。在此Zookeeper保證的是CP, 而Eureka則是AP。
3.1 Zookeeper保證CP
當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊信息，但不能接受服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是zk會出現這樣一種情況，當master節點因爲網絡故障與其他節點失去聯繫時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30 ~ 120s, 且選舉期間整個zk集羣都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠最終恢復，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。
3.2 Eureka保證AP
Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊或時如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現以下幾種情況：
1. Eureka不再從註冊列表中移除因爲長時間沒收到心跳而應該過期的服務
2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其它節點上(即保證當前節點依然可用)
3. 當網絡穩定時，當前實例新的註冊信息會被同步到其它節點中
因此， Eureka可以很好的應對因網絡故障導致部分節點失去聯繫的情況，而不會像zookeeper那樣使整個註冊服務癱瘓。
4. 總結
Eureka作爲單純的服務註冊中心來說要比zookeeper更加“專業”，因爲註冊服務更重要的是可用性，我們可以接受短期內達不到一致性的狀況。不過Eureka目前1.X版本的實現是基於servlet的Java web應用，它的極限性能肯定會受到影響。期待正在開發之中的2.X版本能夠從servlet中獨立出來成爲單獨可部署執行的服務。
服務網關組件Zuul工作原理
一、zuul是什麼
zuul 是netflix開源的一個API Gateway 服務器, 本質上是一個web servlet應用。
Zuul 在雲平臺上提供動態路由，監控，彈性，安全等邊緣服務的框架。Zuul 相當於是設備和 Netflix 流應用的 Web 網站後端所有請求的前門。
zuul的例子可以參考 netflix 在github上的 simple webapp，可以按照netflix 在github wiki 上文檔說明來進行使用。
二、zuul的工作原理
1、過濾器機制
zuul的核心是一系列的filters, 其作用可以類比Servlet框架的Filter，或者AOP。
zuul把Request route到 用戶處理邏輯 的過程中，這些filter參與一些過濾處理，比如Authentication，Load Shedding等。
Zuul提供了一個框架，可以對過濾器進行動態的加載，編譯，運行。
Zuul的過濾器之間沒有直接的相互通信，他們之間通過一個RequestContext的靜態類來進行數據傳遞的。RequestContext類中有ThreadLocal變量來記錄每個Request所需要傳遞的數據。
Zuul的過濾器是由Groovy寫成，這些過濾器文件被放在Zuul Server上的特定目錄下面，Zuul會定期輪詢這些目錄，修改過的過濾器會動態的加載到Zuul Server中以便過濾請求使用。
下面有幾種標準的過濾器類型：
Zuul大部分功能都是通過過濾器來實現的。Zuul中定義了四種標準過濾器類型，這些過濾器類型對應於請求的典型生命週期。
(1) PRE：這種過濾器在請求被路由之前調用。我們可利用這種過濾器實現身份驗證、在集羣中選擇請求的微服務、記錄調試信息等。
(2) ROUTING：這種過濾器將請求路由到微服務。這種過濾器用於構建發送給微服務的請求，並使用Apache HttpClient或Netfilx Ribbon請求微服務。
(3) POST：這種過濾器在路由到微服務以後執行。這種過濾器可用來爲響應添加標準的HTTP Header、收集統計信息和指標、將響應從微服務發送給客戶端等。
(4) ERROR：在其他階段發生錯誤時執行該過濾器。
內置的特殊過濾器
zuul還提供了一類特殊的過濾器，分別爲：StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter：StaticResponseFilter允許從Zuul本身生成響應，而不是將請求轉發到源。
SurgicalDebugFilter：SurgicalDebugFilter允許將特定請求路由到分隔的調試集羣或主機。
自定義的過濾器
除了默認的過濾器類型，Zuul還允許我們創建自定義的過濾器類型。
例如，我們可以定製一種STATIC類型的過濾器，直接在Zuul中生成響應，而不將請求轉發到後端的微服務。
2、過濾器的生命週期
Zuul請求的生命週期如圖，該圖詳細描述了各種類型的過濾器的執行順序。
3、過濾器調度過程
4、動態加載過濾器
三、zuul 能做什麼？
Zuul可以通過加載動態過濾機制，從而實現以下各項功能：
驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。
審查與監控: 在邊緣位置追蹤有意義數據及統計結果，從而爲我們帶來準確的生產狀態結論。
動態路由: 以動態方式根據需要將請求路由至不同後端集羣處。
壓力測試: 逐漸增加指向集羣的負載流量，從而計算性能水平。
負載分配: 爲每一種負載類型分配對應容量，並棄用超出限定值的請求。
靜態響應處理: 在邊緣位置直接建立部分響應，從而避免其流入內部集羣。
多區域彈性: 跨越AWS區域進行請求路由，旨在實現ELB使用多樣化並保證邊緣位置與使用者儘可能接近。
除此之外，Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
四、zuul 與應用的集成方式
1、ZuulServlet - 處理請求（調度不同階段的filters，處理異常等）
ZuulServlet類似SpringMvc的DispatcherServlet，所有的Request都要經過ZuulServlet的處理
三個核心的方法preRoute(),route(), postRoute()，zuul對request處理邏輯都在這三個方法裏
ZuulServlet交給ZuulRunner去執行。
由於ZuulServlet是單例，因此ZuulRunner也僅有一個實例。
ZuulRunner直接將執行邏輯交由FilterProcessor處理，FilterProcessor也是單例，其功能就是依據filterType執行filter的處理邏輯
FilterProcessor對filter的處理邏輯。
首先根據Type獲取所有輸入該Type的filter，List<ZuulFilter> list。
遍歷該list，執行每個filter的處理邏輯，processZuulFilter(ZuulFilter filter)
RequestContext對每個filter的執行狀況進行記錄，應該留意，此處的執行狀態主要包括其執行時間、以及執行成功或者失敗，如果執行失敗則對異常封裝後拋出。
到目前爲止，zuul框架對每個filter的執行結果都沒有太多的處理，它沒有把上一filter的執行結果交由下一個將要執行的filter，僅僅是記錄執行狀態，如果執行失敗拋出異常並終止執行。
2、ContextLifeCycleFilter - RequestContext 的生命週期管理
ContextLifecycleFilter的核心功能是爲了清除RequestContext； 請求上下文RequestContext通過ThreadLocal存儲，需要在請求完成後刪除該對象。
RequestContext提供了執行filter Pipeline所需要的Context，因爲Servlet是單例多線程，這就要求RequestContext即要線程安全又要Request安全。
context使用ThreadLocal保存，這樣每個worker線程都有一個與其綁定的RequestContext，因爲worker僅能同時處理一個Request，這就保證了Request Context 即是線程安全的由是Request安全的。
3、GuiceFilter - GOOLE-IOC(Guice是Google開發的一個輕量級，基於Java5（主要運用泛型與註釋特性）的依賴注入框架(IOC)。Guice非常小而且快。)
4、StartServer - 初始化 zuul 各個組件 （ioc、插件、filters、數據庫等）
5、FilterScriptManagerServlet - uploading/downloading/managing scripts， 實現熱部署
Filter源碼文件放在zuul 服務特定的目錄， zuul server會定期掃描目錄下的文件的變化，動態的讀取\編譯\運行這些filter,
如果有Filter文件更新，源文件會被動態的讀取，編譯加載進入服務，接下來的Request處理就由這些新加入的filter處理。
http://www.cnblogs.com/lexiaofei/p/7080257.html
跨域時序圖
Ribbon工作原理
Ribbon 是netflix 公司開源的基於客戶端的負載均衡組件，是Spring Cloud大家庭中非常重要的一個模塊；Ribbon應該也是整個大家庭中相對而言比較複雜的模塊，直接影響到服務調度的質量和性能。全面掌握Ribbon可以幫助我們瞭解在分佈式微服務集羣工作模式下，服務調度應該考慮到的每個環節。
本文將詳細地剖析Ribbon的設計原理，幫助大家對Spring Cloud 有一個更好的認知。
一. Spring集成下的Ribbon工作結構
先貼一張總覽圖，說明一下Spring如何集成Ribbon的，如下所示：
image.png
Spring Cloud集成模式下的Ribbon有以下幾個特徵：
Ribbon 服務配置方式
每一個服務配置都有一個Spring ApplicationContext上下文，用於加載各自服務的實例。
比如，當前Spring Cloud 系統內，有如下幾個服務：
服務名稱 角色 依賴服務
order 訂單模塊 user
user 用戶模塊 無
mobile-bff 移動端BFF order,user
mobile-bff服務在實際使用中，會用到order和user模塊，那麼在mobile-bff服務的Spring上下文中，會爲order 和user 分別創建一個子ApplicationContext,用於加載各自服務模塊的配置。也就是說，各個客戶端的配置相互獨立，彼此不收影響
和Feign的集成模式
在使用Feign作爲客戶端時，最終請求會轉發成 http://<服務名稱>/<relative-path-to-service>的格式，通過LoadBalancerFeignClient， 提取出服務標識<服務名稱>，然後根據服務名稱在上下文中查找對應服務的負載均衡器FeignLoadBalancer，負載均衡器負責根據既有的服務實例的統計信息，挑選出最合適的服務實例
二、Spring Cloud模式下和Feign的集成實現方式
和Feign結合的場景下，Feign的調用會被包裝成調用請求LoadBalancerCommand，然後底層通過Rxjava基於事件的編碼風格，發送請求；Spring Cloud框架通過 Feigin 請求的URL，提取出服務名稱，然後在上下文中找到對應服務的的負載均衡器實現FeignLoadBalancer,然後通過負載均衡器中挑選一個合適的Server實例,然後將調用請求轉發到該Server實例上，完成調用，在此過程中，記錄對應Server實例的調用統計信息。
/**
* Create an {@link Observable} that once subscribed execute network call asynchronously with a server chosen by load balancer.
* If there are any errors that are indicated as retriable by the {@link RetryHandler}, they will be consumed internally by the
* function and will not be observed by the {@link Observer} subscribed to the returned {@link Observable}. If number of retries has
* exceeds the maximal allowed, a final error will be emitted by the returned {@link Observable}. Otherwise, the first successful
* result during execution and retries will be emitted.
*/
public Observable<T> submit(final ServerOperation<T> operation) {
final ExecutionInfoContext context = new ExecutionInfoContext();
if (listenerInvoker != null) {
try {
listenerInvoker.onExecutionStart();
} catch (AbortExecutionException e) {
return Observable.error(e);
}
}
// 同一Server最大嘗試次數
final int maxRetrysSame = retryHandler.getMaxRetriesOnSameServer();
//下一Server最大嘗試次數
final int maxRetrysNext = retryHandler.getMaxRetriesOnNextServer();
// Use the load balancer
// 使用負載均衡器，挑選出合適的Server，然後執行Server請求，將請求的數據和行爲整合到ServerStats中
Observable<T> o =
(server == null ? selectServer() : Observable.just(server))
.concatMap(new Func1<Server, Observable<T>>() {
@Override
// Called for each server being selected
public Observable<T> call(Server server) {
// 獲取Server的統計值
context.setServer(server);
final ServerStats stats = loadBalancerContext.getServerStats(server);
// Called for each attempt and retry 服務調用
Observable<T> o = Observable
.just(server)
.concatMap(new Func1<Server, Observable<T>>() {
@Override
public Observable<T> call(final Server server) {
context.incAttemptCount();//重試計數
loadBalancerContext.noteOpenConnection(stats);//鏈接統計
if (listenerInvoker != null) {
try {
listenerInvoker.onStartWithServer(context.toExecutionInfo());
} catch (AbortExecutionException e) {
return Observable.error(e);
}
}
//執行監控器，記錄執行時間
final Stopwatch tracer = loadBalancerContext.getExecuteTracer().start();
//找到合適的server後，開始執行請求
//底層調用有結果後，做消息處理
return operation.call(server).doOnEach(new Observer<T>() {
private T entity;
@Override
public void onCompleted() {
recordStats(tracer, stats, entity, null);
// 記錄統計信息
}
@Override
public void onError(Throwable e) {
recordStats(tracer, stats, null, e);//記錄異常信息
logger.debug("Got error {} when executed on server {}", e, server);
if (listenerInvoker != null) {
listenerInvoker.onExceptionWithServer(e, context.toExecutionInfo());
}
}
@Override
public void onNext(T entity) {
this.entity = entity;//返回結果值
if (listenerInvoker != null) {
listenerInvoker.onExecutionSuccess(entity, context.toExecutionInfo());
}
}
private void recordStats(Stopwatch tracer, ServerStats stats, Object entity, Throwable exception) {
tracer.stop();//結束計時
//標記請求結束，更新統計信息
loadBalancerContext.noteRequestCompletion(stats, entity, exception, tracer.getDuration(TimeUnit.MILLISECONDS), retryHandler);
}
});
}
});
//如果失敗，根據重試策略觸發重試邏輯
// 使用observable 做重試邏輯，根據predicate 做邏輯判斷，這裏做
if (maxRetrysSame > 0)
o = o.retry(retryPolicy(maxRetrysSame, true));
return o;
}
});
// next請求處理，基於重試器操作
if (maxRetrysNext > 0 && server == null)
o = o.retry(retryPolicy(maxRetrysNext, false));
return o.onErrorResumeNext(new Func1<Throwable, Observable<T>>() {
@Override
public Observable<T> call(Throwable e) {
if (context.getAttemptCount() > 0) {
if (maxRetrysNext > 0 && context.getServerAttemptCount() == (maxRetrysNext + 1)) {
e = new ClientException(ClientException.ErrorType.NUMBEROF_RETRIES_NEXTSERVER_EXCEEDED,
"Number of retries on next server exceeded max " + maxRetrysNext
+ " retries, while making a call for: " + context.getServer(), e);
}
else if (maxRetrysSame > 0 && context.getAttemptCount() == (maxRetrysSame + 1)) {
e = new ClientException(ClientException.ErrorType.NUMBEROF_RETRIES_EXEEDED,
"Number of retries exceeded max " + maxRetrysSame
+ " retries, while making a call for: " + context.getServer(), e);
}
}
if (listenerInvoker != null) {
listenerInvoker.onExecutionFailed(e, context.toFinalExecutionInfo());
}
return Observable.error(e);
}
});
}
從一組ServerList 列表中挑選合適的Server
/**
* Compute the final URI from a partial URI in the request. The following steps are performed:
* <ul>
* <li> 如果host尚未指定，則從負載均衡器中選定 host/port
* <li> 如果host 尚未指定並且尚未找到負載均衡器，則嘗試從 虛擬地址中確定host/port
* <li> 如果指定了HOST,並且URI的授權部分通過虛擬地址設置，並且存在負載均衡器，則通過負載就均衡器中確定host/port（指定的HOST將會被忽略）
* <li> 如果host已指定，但是尚未指定負載均衡器和虛擬地址配置，則使用真實地址作爲host
* <li> if host is missing but none of the above applies, throws ClientException
* </ul>
*
* @param original Original URI passed from caller
*/
public Server getServerFromLoadBalancer(@Nullable URI original, @Nullable Object loadBalancerKey) throws ClientException {
String host = null;
int port = -1;
if (original != null) {
host = original.getHost();
}
if (original != null) {
Pair<String, Integer> schemeAndPort = deriveSchemeAndPortFromPartialUri(original);
port = schemeAndPort.second();
}
// Various Supported Cases
// The loadbalancer to use and the instances it has is based on how it was registered
// In each of these cases, the client might come in using Full Url or Partial URL
ILoadBalancer lb = getLoadBalancer();
if (host == null) {
// 提供部分URI，缺少HOST情況下
// well we have to just get the right instances from lb - or we fall back
if (lb != null){
Server svc = lb.chooseServer(loadBalancerKey);// 使用負載均衡器選擇Server
if (svc == null){
throw new ClientException(ClientException.ErrorType.GENERAL,
"Load balancer does not have available server for client: "
+ clientName);
}
//通過負載均衡器選擇的結果中選擇host
host = svc.getHost();
if (host == null){
throw new ClientException(ClientException.ErrorType.GENERAL,
"Invalid Server for :" + svc);
}
logger.debug("{} using LB returned Server: {} for request {}", new Object[]{clientName, svc, original});
return svc;
} else {
// No Full URL - and we dont have a LoadBalancer registered to
// obtain a server
// if we have a vipAddress that came with the registration, we
// can use that else we
// bail out
// 通過虛擬地址配置解析出host配置返回
if (vipAddresses != null && vipAddresses.contains(",")) {
throw new ClientException(
ClientException.ErrorType.GENERAL,
"Method is invoked for client " + clientName + " with partial URI of ("
+ original
+ ") with no load balancer configured."
+ " Also, there are multiple vipAddresses and hence no vip address can be chosen"
+ " to complete this partial uri");
} else if (vipAddresses != null) {
try {
Pair<String,Integer> hostAndPort = deriveHostAndPortFromVipAddress(vipAddresses);
host = hostAndPort.first();
port = hostAndPort.second();
} catch (URISyntaxException e) {
throw new ClientException(
ClientException.ErrorType.GENERAL,
"Method is invoked for client " + clientName + " with partial URI of ("
+ original
+ ") with no load balancer configured. "
+ " Also, the configured/registered vipAddress is unparseable (to determine host and port)");
}
} else {
throw new ClientException(
ClientException.ErrorType.GENERAL,
this.clientName
+ " has no LoadBalancer registered and passed in a partial URL request (with no host:port)."
+ " Also has no vipAddress registered");
}
}
} else {
// Full URL Case URL中指定了全地址，可能是虛擬地址或者是hostAndPort
// This could either be a vipAddress or a hostAndPort or a real DNS
// if vipAddress or hostAndPort, we just have to consult the loadbalancer
// but if it does not return a server, we should just proceed anyways
// and assume its a DNS
// For restClients registered using a vipAddress AND executing a request
// by passing in the full URL (including host and port), we should only
// consult lb IFF the URL passed is registered as vipAddress in Discovery
boolean shouldInterpretAsVip = false;
if (lb != null) {
shouldInterpretAsVip = isVipRecognized(original.getAuthority());
}
if (shouldInterpretAsVip) {
Server svc = lb.chooseServer(loadBalancerKey);
if (svc != null){
host = svc.getHost();
if (host == null){
throw new ClientException(ClientException.ErrorType.GENERAL,
"Invalid Server for :" + svc);
}
logger.debug("using LB returned Server: {} for request: {}", svc, original);
return svc;
} else {
// just fall back as real DNS
logger.debug("{}:{} assumed to be a valid VIP address or exists in the DNS", host, port);
}
} else {
// consult LB to obtain vipAddress backed instance given full URL
//Full URL execute request - where url!=vipAddress
logger.debug("Using full URL passed in by caller (not using load balancer): {}", original);
}
}
// end of creating final URL
if (host == null){
throw new ClientException(ClientException.ErrorType.GENERAL,"Request contains no HOST to talk to");
}
// just verify that at this point we have a full URL
return new Server(host, port);
}
三. LoadBalancer--負載均衡器的核心
LoadBalancer 的職能主要有三個：
維護Sever列表的數量(新增、更新、刪除等)
維護Server列表的狀態(狀態更新)
當請求Server實例時，能否返回最合適的Server實例
本章節將通過詳細闡述着這三個方面。
3.1 負載均衡器的內部基本實現原理
先熟悉一下負載均衡器LoadBalancer的實現原理圖：
Eureka與Ribbon整合工作原理
Eurek進行服務的註冊與發現(請看之前的筆記[Spring Cloud Eureka搭建註冊中心])
ribbon進行RestTemplate負載均衡策略(下期寫ribbon實現負載均衡以及手寫負責均衡)
hystrix 實現熔斷機制以及通過dashboard查看熔斷信息(有時間寫hystrix dashboard詳解)
項目結構如下(不包含Eureka服務註冊與發現)，另外部署
image.png
spring-cloud-study-provider 作爲服務提供者將服務註冊到Eureka集羣
spring-cloud-study-api 作爲項目api提供基礎類庫支持
spring-cloud-study-consumer 作爲服務消費者從Eureka集羣獲取提供者信息，並進行消費，集成了Eureka，ribbon, hystrix, hystrix dashboard
Eureka主要實現服務的註冊與發現(請看之前的筆記[Spring Cloud Eureka搭建註冊中心])，這裏不在重複
消費端eureka配置
eureka:
client:
register-with-eureka: false
fetch-registry: true
service-url:
defaultZone: http://eureka-server.com:7001/eureka/,http://eureka-client1.com:7002/eureka/,http://eureka-client2.com:7003/eureka/
服務提供方eureka配置
eureka:
client:
service-url:
defaultZone: http://eureka-server.com:7001/eureka/,http://eureka-client1.com:7002/eureka/,http://eureka-client2.com:7003/eureka/
register-with-eureka: true
fetch-registry: false
instance:
instance-id: spring-cloud-study-provider # 調用服務時需要此名稱(全部大寫)
prefer-ip-address: true
ribbon實現負載均衡，默認採用：輪詢。
引用jar
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-ribbon</artifactId>
<version>1.3.1.RELEASE</version>
</dependency>
在RestTemplat加入LoanBalance註釋即可
@Configuration
public class RestConfigBean {
@Bean
@LoadBalanced
public RestTemplate getRestTemplate()
{
return new RestTemplate();
}
}
hystrix 實現熔斷機制以及通過dashboard進行監控
引入jar依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
<version>1.3.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
<version>1.3.1.RELEASE</version>
</dependency>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-metrics-event-stream</artifactId>
<version>1.5.12</version>
</dependency>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-javanica</artifactId>
<version>1.5.12</version>
</dependency>
啓動hystrix有及hystrix dashboard
@SpringBootApplication
@EnableDiscoveryClient #啓用eureak服務發現
@EnableHystrix # 啓用hystrix熔斷
@EnableHystrixDashboard # 啓用hystrix dashboard服務監控
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
}
重要步驟
先啓動eureka服務器，這邊啓動三臺,模擬集羣, 訪問
http://eureka-server.com:7001/
http://eureka-client1.com:7002/
http://eureka-client2.com:7003/
如果訪問地址出現下圖，表示eureka啓動成功
image.png
啓動服務提供者，將服務註冊到eureka服務器
[http://eureka-server.com:7001/](http://eureka-server.com:7001/)
[http://eureka-client1.com:7002/](http://eureka-client1.com:7002/)
[http://eureka-client2.com:7003/](http://eureka-client2.com:7003/)
訪問以上地址，出現下圖，表示服務提供者註冊服務到eureka集羣成功
image.png
啓動服務提供者，從eureka集羣獲取服務提供者信息，並進行服務消費，啓動成功後，進行測試
image.png
image.png
http://localhost:9001/dept/get/2 訪問這個地址時，出現RuntimeException異常，將進行熔斷，將返回getIdError方法的內容
image.png
查看熔斷信息(訪問地址：http://localhost:9001/hystrix)
image.png
地址欄輸入：localhost:9001/hystrix.stream
title：隨便輸入
點擊 按鈕提交
訪問：http://localhost:9001/dept/get/2, 服務提供者控制檯將出現異常
查詢hystrix dashboard頁面，刷新
image.png
解決分佈式一致性
主要內容包括4部分：
傳統分佈式事務不是微服務中一致性的最佳選擇
微服務架構中應滿足數據最終一致性原則
微服務架構實現最終一致性的三種模式
對賬是最後的終極防線。
我們先來看一下第一部分，傳統使用本地事務和分佈式事務保證一致性
傳統單機應用一般都會使用一個關係型數據庫，好處是應用可以使用 ACID transactions。爲保證一致性我們只需要：開始一個事務，改變（插入，刪除，更新）很多行，然後提交事務（如果有異常時回滾事務）。更進一步，藉助開發平臺中的數據訪問技術和框架（如Spring），我們需要做的事情更少，只需要關注數據本身的改變。隨着組織規模不斷擴大，業務量不斷增長，單機應用和數據庫已經不足以支持龐大的業務量和數據量，這個時候需要對應用和數據庫進行拆分，就出現了一個應用需要同時訪問兩個或兩個以上的數據庫情況。開始我們用分佈式事務來保證一致性，也就是我們常說的兩階段提交協議（2PC）。
本地事務和分佈式事務現在已經非常成熟，相關介紹很豐富，此處不多作討論。我們下面來討論以下爲什麼分佈式事務不適用於微服務架構。
首先，對於微服務架構來說，數據訪問變得更加複雜，這是因爲數據都是微服務私有的，唯一可訪問的方式就是通過API。這種打包數據訪問方式使得微服務之間鬆耦合，並且彼此之間獨立非常容易進行性能擴展。
其次，不同的微服務經常使用不同的數據庫。應用會產生各種不同類型的數據，關係型數據庫並不一定是最佳選擇。例如，某個產生和查詢字符串的應用採用Elasticsearch的字符搜索引擎；某個產生社交圖片數據的應用可以採用圖數據庫，例如，Neo4j；基於微服務的應用一般都使用SQL和NoSQL結合的模式。但是這些非關係型數據大多數並不支持2PC。可見在微服務架構中已經不能選擇分佈式事務了。
依據CAP理論，必須在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網絡故障導致失去連接時。
依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和數據庫之間維護數據一致性是非常根本的需求，微服務架構中應選擇滿足最終一致性。
當然選擇了最終一致性，就要保證到最終的這段時間要在用戶可接受的範圍之內。那麼我們怎麼實現最終一致性呢？
從一致性的本質來看，是要保證在一個業務邏輯中包含的服務要麼都成功，要麼都失敗。那我們怎麼選擇方向呢？保證成功還是保證失敗呢？我們說業務模式決定了我們的選擇。實現最終一致性有三種模式：可靠事件模式、業務補償模式、TCC模式。
可靠事件模式屬於事件驅動架構，當某件重要事情發生時，例如更新一個業務實體，微服務會向消息代理髮佈一個事件。消息代理會向訂閱事件的微服務推送事件，當訂閱這些事件的微服務接收此事件時，就可以完成自己的業務，也可能會引發更多的事件發佈。1. 如訂單服務創建一個待支付的訂單，發佈一個“創建訂單”的事件
支付服務消費“創建訂單”事件，支付完成後發佈一個“支付完成”事件
訂單服務消費“支付完成”事件，訂單狀態更新爲待出庫。
從而就實現了完成的業務流程。但是這並不是一個完美的流程。
這個過程可能導致出現不一致的地方在於：某個微服務在更新了業務實體後發佈事件卻失敗；雖然微服務發佈事件成功，但是消息代理未能正確推送事件到訂閱的微服務；接受事件的微服務重複消費了事件。
可靠事件模式在於保證可靠事件投遞和避免重複消費，可靠事件投遞定義爲：（a）每個服務原子性的業務操作和發佈事件
（b）消息代理確保事件傳遞至少一次。避免重複消費要求服務實現冪等性，如支付服務不能因爲重複收到事件而多次支付。
因爲現在流行的消息隊列都實現了事件的持久化和at least once的投遞模式，（b）特性（消息代理確保事件投遞至少一次）已經滿足，今天不做展開。
下面分享的內容主要從可靠事件投遞和實現冪等性兩方面來討論，我們先來看可靠事件投遞。首先我們來看一個實現的代碼片段，這是從某生產系統上截取下來的。
根據上述代碼及註釋，初看可能出現3種情況：
操作數據庫成功，向消息代理投遞事件也成功
操作數據庫失敗，不會向消息代理中投遞事件了
操作數據庫成功，但是向消息代理中投遞事件時失敗，向外拋出了異常，剛剛執行的更新數據庫的操作將被回滾從上面分析的幾種情況來看，貌似沒有問題。但是仔細分析不難發現缺陷所在，在上面的處理過程中存在一段隱患時間窗口。
微服務A投遞事件的時候可能消息代理已經處理成功，但是返回響應的時候網絡異常，導致append操作拋出異常。最終結果是事件被投遞，數據庫確被回滾。
2) 在投遞完成後到數據庫commit操作之間如果微服務A宕機也將造成數據庫操作因爲連接異常關閉而被回滾。最終結果還是事件被投遞，數據庫卻被回滾。這個實現往往運行很長時間都沒有出過問題，但是一旦出現了將會讓人感覺莫名很難發現問題所在。下面給出兩種可靠事件投遞的實現方式：
一.本地事件表
本地事件表方法將事件和業務數據保存在同一個數據庫中，使用一個額外的“事件恢復”服務來恢復事件，由本地事務保證更新業務和發佈事件的原子性。考慮到事件恢復可能會有一定的延時，服務在完成本地事務後可立即向消息代理髮佈一個事件。
微服務在同一個本地事務中記錄業務數據和事件
微服務實時發佈一個事件立即通知關聯的業務服務，如果事件發佈成功立即刪除記錄的事件
事件恢復服務定時從事件表中恢復未發佈成功的事件，重新發布，重新發布成功才刪除記錄的事件其中第2條的操作主要是爲了增加發布事件的實時性，由第三條保證事件一定被髮布。本地事件表方式業務系統和事件系統耦合比較緊密，額外的事件數據庫操作也會給數據庫帶來額外的壓力，可能成爲瓶頸。
二、外部事件表
外部事件表方法將事件持久化到外部的事件系統，事件系統需提供實時事件服務以接受微服務發佈事件，同時事件系統還需要提供事件恢復服務來確認和恢復事件。
業務服務在事務提交前，通過實時事件服務向事件系統請求發送事件，事件系統只記錄事件並不真正發送
業務服務在提交後，通過實時事件服務向事件系統確認發送，事件得到確認後事件系統才真正發佈事件到消息代理
業務服務在業務回滾時，通過實時事件向事件系統取消事件
如果業務服務在發送確認或取消之前停止服務了怎麼辦呢？事件系統的事件恢復服務會定期找到未確認發送的事件向業務服務查詢狀態，根據業務服務返回的狀態決定事件是要發佈還是取消該方式將業務系統和事件系統獨立解耦，都可以獨立伸縮。但是這種方式需要一次額外的發送操作，並且需要發佈者提供額外的查詢接口介紹完了可靠事件投遞再來說一說冪等性的實現，有些事件本身是冪等的，有些事件卻不是。
如果事件本身描述的是某個時間點的固定值（如賬戶餘額爲100），而不是描述一條轉換指令（如餘額增加10），那麼這個事件是冪等的。我們要意識到事件可能出現的次數和順序是不可預測的，需要保證冪等事件的順序執行，否則結果往往不是我們想要的。如果我們先後收到兩條事件，（1）賬戶餘額更新爲100，（2）賬戶餘額更新爲120。
1.微服務收到事件（1）
2.微服務收到事件（2）
3. 微服務再次收到事件1
顯然結果是錯誤的，所以我們需要保證事件（2）一旦執行事件（1）就不能再處理，否則賬戶餘額仍不是我們想要的結果。
爲保證事件的順序一個簡單的做法是在事件中添加時間戳，微服務記錄每類型的事件最後處理的時間戳，如果收到的事件的時間戳早於我們記錄的，丟棄該事件。如果事件不是在同一個服務器上發出的，那麼服務器之間的時間同步是個難題，更穩妥的做法是使用一個全局遞增序列號替換時間戳。
對於本身不具有冪等性的操作，主要思想是爲每條事件存儲執行結果，當收到一條事件時我們需要根據事件的id查詢該事件是否已經執行過，如果執行過直接返回上一次的執行結果，否則調度執行事件。
重複處理開銷大事件使用事件存儲過濾重複事件
在這個思想下我們需要考慮重複執行一條事件和查詢存儲結果的開銷。重複處理開銷小的事件重複處理如果重複處理一條事件開銷很小，或者可預見只有非常少的事件會被重複接收，可以選擇重複處理一次事件，在將事件數據持久化時由數據庫拋出唯一性約束異常。
如果重複處理一條事件的開銷相比額外一次查詢的開銷要高很多，使用一個過濾服務來過濾重複的事件，過濾服務使用事件存儲存儲已經處理過的事件和結果。
當收到一條事件時，過濾服務首先查詢事件存儲，確定該條事件是否已經被處理過，如果事件已經被處理過，直接返回存儲的結果；否則調度業務服務執行處理，並將處理完的結果存儲到事件存儲中。
一般情況下上面的方法能夠運行得很好，如果我們的微服務是RPC類的服務我們需要更加小心，可能出現的問題在於，（1）過濾服務在業務處理完成後纔將事件結果存儲到事件存儲中，但是在業務處理完成前有可能就已經收到重複事件，由於是RPC服務也不能依賴數據庫的唯一性約束；（2）業務服務的處理結果可能出現位置狀態，一般出現在正常提交請求但是沒有收到響應的時候。
對於問題（1）可以按步驟記錄事件處理過程，比如事件的記錄事件的處理過程爲“接收”、“發送請求”、“收到應答”、“處理完成”。好處是過濾服務能及時的發現重複事件，進一步還能根據事件狀態作不同的處理。
對於問題（2）可以通過一次額外的查詢請求來確定事件的實際處理狀態，要注意額外的查詢會帶來更長時間的延時，更進一步可能某些RPC服務根本不提供查詢接口。此時只能選擇接收暫時的不一致，時候採用對賬和人工接入的方式來保證一致性。
補償模式
爲了描述方便，這裏先定義兩個概念：
業務異常：業務邏輯產生錯誤的情況，比如賬戶餘額不足、商品庫存不足等。
技術異常：非業務邏輯產生的異常，如網絡連接異常、網絡超時等。
補償模式使用一個額外的協調服務來協調各個需要保證一致性的微服務，協調服務按順序調用各個微服務，如果某個微服務調用異常（包括業務異常和技術異常）就取消之前所有已經調用成功的微服務。
補償模式建議僅用於不能避免出現業務異常的情況，如果有可能應該優化業務模式，以避免要求補償事務。如賬戶餘額不足的業務異常可通過預先凍結金額的方式避免，商品庫存不足可要求商家準備額外的庫存等。
我們通過一個實例來說明補償模式，一家旅行公司提供預訂行程的業務，可以通過公司的網站提前預訂飛機票、火車票、酒店等。
假設一位客戶規劃的行程是，
（1）上海-北京6月19日9點的某某航班，
（2）某某酒店住宿3晚，
（3）北京-上海6月22日17點火車。在客戶提交行程後，旅行公司的預訂行程業務按順序串行的調用航班預訂服務、酒店預訂服務、火車預訂服務。最後的火車預訂服務成功後整個預訂業務纔算完成。
如果火車票預訂服務沒有調用成功，那麼之前預訂的航班、酒店都得取消。取消之前預訂的酒店、航班即爲補償過程。
爲了降低開發的複雜性和提高效率，協調服務實現爲一個通用的補償框架。補償框架提供服務編排和自動完成補償的能力。
要實現補償過程，我們需要做到兩點：
首先要確定失敗的步驟和狀態，從而確定需要補償的範圍。
在上面的例子中我們不光要知道第3個步驟（預訂火車）失敗，還要知道失敗的原因。如果是因爲預訂火車服務返回無票，那麼補償過程只需要取消前兩個步驟就可以了；但是如果失敗的原因是因爲網絡超時，那麼補償過程除前兩個步驟之外還需要包括第3個步驟。
其次要能提供補償操作使用到的業務數據。
比如一個支付微服務的補償操作要求參數包括支付時的業務流水id、賬號和金額。理論上說實際完成補償操作可以根據唯一的業務流水id就可以，但是提供更多的要素有益於微服務的健壯性，微服務在收到補償操作的時候可以做業務的檢查，比如檢查賬戶是否相等，金額是否一致等等。
做到上面兩點的辦法是記錄完整的業務流水，可以通過業務流水的狀態來確定需要補償的步驟，同時業務流水爲補償操作提供需要的業務數據。
當客戶的一個預訂請求達到時，協調服務（補償框架）爲請求生成一個全局唯一的業務流水號。並在調用各個工作服務的同時記錄完整的狀態。
記錄調用bookFlight的業務流水，調用bookFlight服務，更新業務流水狀態
記錄調用bookHotel的業務流水，調用bookHotel服務，更新業務流水狀態
記錄調用bookTrain的業務流水，調用bookTrain服務，更新業務流水狀態
當調用某個服務出現異常時，比如第3步驟（預訂火車）異常
協調服務（補償框架）同樣會記錄第3步的狀態，同時會另外記錄一條事件，說明業務出現了異常。然後就是執行補償過程了，可以從業務流水的狀態中知道補償的範圍，補償過程中需要的業務數據從記錄的業務流水中獲取。
對於一個通用的補償框架來說，預先知道微服務需要記錄的業務要素是不可能的。那麼就需要一種方法來保證業務流水的可擴展性，這裏介紹兩種方法：大表和關聯表。
大表顧明思議就是設計時除必須的字段外，還需要預留大量的備用字段，框架可以提供輔助工具來幫助將業務數據映射到備用字段中。
關聯表，分爲框架表和業務表，技術表中保存爲實現補償操作所需要的技術數據，業務表保存業務數據，通過在技術表中增加業務表名和業務表主鍵來建立和業務數據的關聯。
大表對於框架層實現起來簡單，但是也有一些難點，比如預留多少字段合適，每個字段又需要預留多少長度。另外一個難點是如果向從數據層面來查詢數據，很難看出備用字段的業務含義，維護過程不友好。
關聯表在業務要素上更靈活，能支持不同的業務類型記錄不同的業務要素；但是對於框架實現上難度更高，另外每次查詢都需要複雜的關聯動作，性能方面會受影響。
有了上面的完整的流水記錄，協調服務就可以根據工作服務的狀態在異常時完成補償過程。但是補償由於網絡等原因，補償操作並不一定能保證100%成功，這時候我們還要做更多一點。
通過重試保證補償過程的完整。從而滿足最終一致性。
補償過程作爲一個服務調用過程同樣存在調用不成功的情況，這個時候需要通過重試的機制來保證補償的成功率。當然這也就要求補償操作本身具備冪等性。
關於冪等性的實現在前面做過討論。
重試策略
如果只是一味的失敗就立即重試會給工作服務造成不必要的壓力，我們要根據服務執行失敗的原因來選擇不同的重試策略。
如果失敗的原因不是暫時性的，由於業務因素導致（如業務要素檢查失敗）的業務錯誤，這類錯誤是不會重發就能自動恢復的，那麼應該立即終止重試。
如果錯誤的原因是一些罕見的異常，比如因爲網絡傳輸過程出現數據丟失或者錯誤，應該立即再次重試，因爲類似的錯誤一般很少會再次發生。
如果錯誤的原因是系統繁忙（比如http協議返回的500或者另外約定的返回碼）或者超時，這個時候需要等待一些時間再重試。
重試操作一般會指定重試次數上線，如果重試次數達到了上限就不再進行重試了。這個時候應該通過一種手段通知相關人員進行處理。
對於等待重試的策略如果重試時仍然錯誤，可逐漸增加等待的時間，直到達到一個上限後，以上限作爲等待時間。
如果某個時刻聚集了大量需要重試的操作，補償框架需要控制請求的流量，以防止對工作服務造成過大的壓力。
另外關於補償模式還有幾點補充說明：
微服務實現補償操作不是簡單的回退到業務發生時的狀態，因爲可能還有其他的併發的請求同時更改了狀態。一般都使用逆操作的方式完成補償。
補償過程不需要嚴格按照與業務發生的相反順序執行，可以依據工作服務的重用程度優先執行，甚至是可以併發的執行。
有些服務的補償過程是有依賴關係的，被依賴服務的補償操作沒有成功就要及時終止補償過程。
如果在一個業務中包含的工作服務不是都提供了補償操作，那我們編排服務時應該把提供補償操作的服務放在前面，這樣當後面的工作服務錯誤時還有機會補償。
設計工作服務的補償接口時應該以協調服務請求的業務要素作爲條件，不要以工作服務的應答要素作爲條件。因爲還存在超時需要補償的情況，這時補償框架就沒法提供補償需要的業務要素。
補償模式就介紹到這裏，下面介紹第三種模式：TCC模式（Try-Confirm-Cancel）
一個完整的TCC業務由一個主業務服務和若干個從業務服務組成，主業務服務發起並完成整個業務活動，TCC模式要求從服務提供三個接口：Try、Confirm、Cancel。
1) Try：完成所有業務檢查 預留必須業務資源2) Confirm：真正執行業務 不作任何業務檢查 只使用Try階段預留的業務資源 Confirm操作滿足冪等性3) Cancel： 釋放Try階段預留的業務資源 Cancel操作滿足冪等性整個TCC業務分成兩個階段完成。
第一階段：主業務服務分別調用所有從業務的try操作，並在活動管理器中登記所有從業務服務。當所有從業務服務的try操作都調用成功或者某個從業務服務的try操作失敗，進入第二階段。
第二階段：活動管理器根據第一階段的執行結果來執行confirm或cancel操作。如果第一階段所有try操作都成功，則活動管理器調用所有從業務活動的confirm操作。否則調用所有從業務服務的cancel操作。
需要注意的是第二階段confirm或cancel操作本身也是滿足最終一致性的過程，在調用confirm或cancel的時候也可能因爲某種原因（比如網絡）導致調用失敗，所以需要活動管理支持重試的能力，同時這也就要求confirm和cancel操作具有冪等性。
在補償模式中一個比較明顯的缺陷是，沒有隔離性。從第一個工作服務步驟開始一直到所有工作服務完成（或者補償過程完成），不一致是對其他服務可見的。另外最終一致性的保證還充分的依賴了協調服務的健壯性，如果協調服務異常，就沒法達到一致性。
TCC模式在一定程度上彌補了上述的缺陷，在TCC模式中直到明確的confirm動作，所有的業務操作都是隔離的（由業務層面保證）。另外工作服務可以通過指定try操作的超時時間，主動的cancel預留的業務資源，從而實現自治的微服務。
TCC模式和補償模式一樣需要需要有協調服務和工作服務，協調服務也可以作爲通用服務一般實現爲框架。與補償模式不同的是TCC服務框架不需要記錄詳細的業務流水，完成confirm和cancel操作的業務要素由業務服務提供。
在第4步確認預訂之前，訂單只是pending狀態，只有等到明確的confirm之後訂單才生效。
如果3個服務中某個服務try操作失敗，那麼可以向TCC服務框架提交cancel，或者什麼也不做由工作服務自己超時處理。
TCC模式也不能百分百保證一致性，如果業務服務向TCC服務框架提交confirm後，TCC服務框架向某個工作服務提交confirm失敗（比如網絡故障），那麼就會出現不一致，一般稱爲heuristic exception。
需要說明的是爲保證業務成功率，業務服務向TCC服務框架提交confirm以及TCC服務框架向工作服務提交confirm/cancel時都要支持重試，這也就要confirm/cancel的實現必須具有冪等性。如果業務服務向TCC服務框架提交confirm/cancel失敗，不會導致不一致，因爲服務最後都會超時而取消。
另外heuristic exception是不可杜絕的，但是可以通過設置合適的超時時間，以及重試頻率和監控措施使得出現這個異常的可能性降低到很小。如果出現了heuristic exception是可以通過人工的手段補救的。
如果有些業務由於瞬時的網絡故障或調用超時等問題，通過上文所講的3種模式一般都能得到很好的解決。但是在當今雲計算環境下，很多服務是依賴於外部系統的可用性情況，在一些重要的業務場景下還需要週期性的對賬來保證真實的一致性。比如支付系統和銀行之間每天日終是都會有對賬過程。
以上就是今天分享的內容，主要介紹的是微服務架構中需要滿足最終一致性原則以及實現最終一致性的3種模式。
級聯故障流程
圖片描述
斷路器組件Hystrix工作原理
1、Netflix Hystrix斷路器是什麼？
Netflix Hystrix是SOA/微服務架構中提供服務隔離、熔斷、降級機制的工具/框架。Netflix Hystrix是斷路器的一種實現，用於高微服務架構的可用性，是防止服務出現雪崩的利器。
2、爲什麼需要斷路器？
在分佈式架構中，一個應用依賴多個服務是非常常見的，如果其中一個依賴由於延遲過高發生阻塞，調用該依賴服務的線程就會阻塞，如果相關業務的QPS較高，就可能產生大量阻塞，從而導致該應用/服務由於服務器資源被耗盡而拖垮。
另外，故障也會在應用之間傳遞，如果故障服務的上游依賴較多，可能會引起服務的雪崩效應。就跟數據癱瘓，會引起依賴該數據庫的應用癱瘓是一樣的道理。
當一個應用依賴多個外部服務，一切都正常的情況下，如下圖：
如果其中一個依賴發生延遲，當前請求就會被阻塞
出現這種情況後，如果沒有應對措施，後續的請求也會被持續阻塞
每個請求都佔用了系統的CPU、內存、網絡等資源，如果該應用的QPS較高，那麼該應用所以的服務資源會被快速消耗完畢，直至應用死掉。如果這個出問題的依賴（Dependency I），不止這一個應用，亦或是受影響的應用上層也有更多的依賴，那就會帶來我們前面所提到的服務雪崩效應。
所以，爲了應對以上問題，就需要有支持服務隔離、熔斷等操作的工具
二、Hystrix 簡介
1、Hystrix具備哪些能力/優點？
在通過網絡依賴服務出現高延遲或者失敗時，爲系統提供保護和控制
可以進行快速失敗，縮短延遲等待時間和快速恢復：當異常的依賴回覆正常後，失敗的請求所佔用的線程會被快速清理，不需要額外等待
提供失敗回退（Fallback）和相對優雅的服務降級機制
提供有效的服務容錯監控、報警和運維控制手段
2、Hystrix 如何解決級聯故障/防止服務雪崩？
Hystrix將請求的邏輯進行封裝，相關邏輯會在獨立的線程中執行
Hystrix有自動超時策略，如果外部請求超過閾值，Hystrix會以超時來處理
Hystrix會爲每個依賴維護一個線程池，當線程滿載，不會進行線程排隊，會直接終止操作
Hystrix有熔斷機制： 在依賴服務失效比例超過閾值時，手動或者自動地切斷服務一段時間
所以，當引入了Hystrix之後，當出現某個依賴高延遲的時候：
三、Hystrix 工作原理
1、Hystrix工作流
1、創建HystrixCommand 或者 HystrixObservableCommand 對象
2、執行命令execute()、queue()、observe()、toObservable()
3、如果請求結果緩存這個特性被啓用，並且緩存命中，則緩存的迴應會立即通過一個Observable對象的形式返回
4、檢查熔斷器狀態，確定請求線路是否是開路，如果請求線路是開路，Hystrix將不會執行這個命令，而是直接執行getFallback
5、如果和當前需要執行的命令相關聯的線程池和請求隊列，Hystrix將不會執行這個命令，而是直接執行getFallback
6、執行HystrixCommand.run()或HystrixObservableCommand.construct()，如果這兩個方法執行超時或者執行失敗，則執行getFallback()
7、Hystrix 會將請求成功，失敗，被拒絕或超時信息報告給熔斷器，熔斷器維護一些用於統計數據用的計數器。
這些計數器產生的統計數據使得熔斷器在特定的時刻，能短路某個依賴服務的後續請求，直到恢復期結束，若恢復期結束根據統計數據熔斷器判定線路仍然未恢復健康，熔斷器會再次關閉線路。
依賴隔離
Hystrix採用艙壁隔離模式隔離相互之間的依賴關係，並限制對其中任何一個的併發訪問。
線程&線程池
客戶端（通常指Web應用）通過網絡請求依賴時，Hystrix會將請求外部依賴的線程與會將App容器(Tomcat/Jetty/…)線程隔離開，以免請求依賴出現延遲時影響請求線程。
Hystrix會爲每個依賴維護一個線程池，當線程滿載，不會進行線程排隊，會Return fallback或者拋出異常
可能會有人有疑問，爲什麼不依賴於HTTP Client去做容錯保護（快速失敗、熔斷等），而是在訪問依賴之外通過線程&線程池隔離的方式做這個斷路器（Hystrix）。
主要是以下幾個方面：
不同的依賴執行的頻率不同，需要分開來對待
不同的依賴可能需要不同的Client的工具/協議來訪問，比如我們可能用HTTP Client，可能用Thrift Client。
Client在執行的過程中也可能會出現非網絡異常，這些都應該被隔離
Client的變化會引起斷路器的變化
所以，Hystrix這樣設計的好處是：
斷路器功能與不同的Client Library隔離
不同依賴之間的訪問互不影響
當發生大量異常時，不會造成App Container的響應線程排隊，並且當異常的依賴恢復正常後，失敗的請求所佔用的線程會被快速清理，不需要額外等待
爲不支持異步的依賴提供了異步的可能
這樣做的成本是，多了一些線程上的資源消耗（排隊，調度和上下文切換），不過從官方給到的數據上可能，這個消耗完全可以接受。目前Netflix每天有100億+的Hystrix命令執行，平均每個應用實例都有40+個線程池。每個線程池有5-20個線程 依然運行良好（不過這裏 ken.io 不得不吐槽下，官方沒有透露單個實例硬件配置）
官方給了一組測試數據，在單個應用實例60QPS，且每秒鐘有350個Hystix子線程（350次Hystrix Command執行）的情況下。Hystrix的線程成本通常爲0-3ms，如果CPU使用率超過90%，這個線程成本爲有所上升約爲9ms。相對於網絡請求的時間消耗，這個成本完全可以接受。
四、備註
本文參考
https://github.com/Netflix/Hystrix/wiki
分佈式追蹤Sleuth工作原理
一、概述
在單體應用時代，接口緩慢能夠被迅速定位和發現，而隨着分佈式微服務的流行，服務之間的調用關係越來越複雜，錯中複雜的調用關係使得我們想找到某一個接口的效率緩慢變得非常困難，而分佈式服務調用跟蹤組件就解決了這個 問題。Sleuth是SprinCloud在分佈式系統中提供追蹤解決方案,zipkin是基於Google Dapper的分佈式鏈路調用監控系統。先介紹下有關的專業術語，
Span：基本工作單元，例如，在一個新建的span中發送一個RPC等同於發送一個迴應請求給RPC，span通過一個64位ID唯一標識，trace以另一個64位ID表示，span還有其他數據信息，比如摘要、時間戳事件、關鍵值註釋(tags)、span的ID、以及進度ID(通常是IP地址)
Trace：一系列spans組成的一個樹狀結構，例如，如果你正在跑一個分佈式服務工程，你可能需要創建一個trace。
Annotation：用來及時記錄一個事件的存在，一些核心annotations用來定義一個請求的開始和結束
cs - Client Sent -客戶端發起一個請求，這個annotion描述了這個span的開始
sr - Server Received -服務端獲得請求並準備開始處理它，如果將其sr減去cs時間戳便可得到網 絡延遲
ss - Server Sent -註解表明請求處理的完成(當請求返回客戶端)，如果ss減去sr時間戳便可得到服 務端需要的處理請求時間
cr - Client Received -表明span的結束，客戶端成功接收到服務端的回覆，如果cr減去cs時間戳 便可得到客戶端從服務端獲取回覆的所有所需時間
二、功能開發實現
1.創建zipkin-server服務
zipkin-server主要作用是使用ZipkinServer 的功能，收集調用數據鏈，並提供展示頁面供用戶使用。創建普通的SpringBoot項目zipkin-server，在pom.xml文件中增加如下依賴
<dependencies>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-server</artifactId>
</dependency>
<dependency>
<groupId>io.zipkin.java</groupId>
<artifactId>zipkin-autoconfigure-ui</artifactId>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
在ZipKinServerApplication主方法上添加@EnableZipkinServer註解，啓用ZipkinServer功能。
@EnableZipkinServer
@SpringBootApplication
public class ZipkinServerApplication {
public static void main(String[] args) {
SpringApplication.run(ZipkinServerApplication.class, args);
}
}
修改配置文件
spring.application.name=zipkin-server
server.port=9107
啓動服務，可以看到鏈路監控頁面，此時沒有收集到任何鏈路調用記錄。
2.給原先服務增加鏈路追蹤支持
給eureka-provider、eureka-consumer、gateway三個服務增加如下依賴
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
該依賴內部包含了兩個依賴，等於同時引入了spring-cloud-starter-sleuth，spring-cloud-sleuth-zipkin兩個依賴。
修改配置文件
#配置zipkin
#指定zipkin的服務端，用於發送鏈路調用報告
spring.zipkin.base-url=http://10.17.5.50:9107
# 採樣率，值爲[0,1]之間的任意實數，這裏代表100%採集報告。
spring.sleuth.sampler.percentage=1
重新部署啓動服務，調用zuul接口，觀察zipkin-server頁面，生成調用鏈路
三、小結
本文還只是基本的鏈路分析，如果生產上使用，還需要把監控內容持久化、把監控內容發送從http模式切換到MQ等改造，這些內容下次再詳細介紹。
碼雲地址：https://gitee.com/gengkangkang/springcloud.git
github地址：https://github.com/gengkangkang/springcloud.git
SpringBoot自動配置工作原理
Spring Boot的配置文件
初識Spring Boot時我們就知道，Spring Boot有一個全局配置文件：application.properties或application.yml。
我們的各種屬性都可以在這個文件中進行配置，最常配置的比如：server.port、logging.level.* 等等，然而我們實際用到的往往只是很少的一部分，那麼這些屬性是否有據可依呢？答案當然是肯定的，這些屬性都可以在官方文檔中查找到：
https://docs.spring.io/spring-boot/docs/2.1.0.RELEASE/reference/htmlsingle/#common-application-properties
（所以，話又說回來，找資料還得是官方文檔，百度出來一大堆，還是稍顯業餘了一些）
除了官方文檔爲我們提供了大量的屬性解釋，我們也可以使用IDE的相關提示功能，比如IDEA的自動提示，和Eclipse的YEdit插件，都可以很好的對你需要配置的屬性進行提示，下圖是使用Eclipse的YEdit插件的效果，Eclipse的版本是：STS 4。
以上，是Spring Boot的配置文件的大致使用方法，其實都是些題外話。
那麼問題來了：這些配置是如何在Spring Boot項目中生效的呢？那麼接下來，就需要聚焦本篇博客的主題：自動配置工作原理或者叫實現方式。
工作原理剖析
Spring Boot關於自動配置的源碼在spring-boot-autoconfigure-x.x.x.x.jar中：
當然，自動配置原理的相關描述，官方文檔貌似是沒有提及。不過我們不難猜出，Spring Boot的啓動類上有一個@SpringBootApplication註解，這個註解是Spring Boot項目必不可少的註解。那麼自動配置原理一定和這個註解有着千絲萬縷的聯繫！
@EnableAutoConfiguration
@SpringBootApplication是一個複合註解或派生註解，在@SpringBootApplication中有一個註解@EnableAutoConfiguration，翻譯成人話就是開啓自動配置，其定義如下：
而這個註解也是一個派生註解，其中的關鍵功能由@Import提供，其導入的AutoConfigurationImportSelector的selectImports()方法通過SpringFactoriesLoader.loadFactoryNames()掃描所有具有META-INF/spring.factories的jar包。spring-boot-autoconfigure-x.x.x.x.jar裏就有一個這樣的spring.factories文件。
這個spring.factories文件也是一組一組的key=value的形式，其中一個key是EnableAutoConfiguration類的全類名，而它的value是一個xxxxAutoConfiguration的類名的列表，這些類名以逗號分隔，如下圖所示：
這個@EnableAutoConfiguration註解通過@SpringBootApplication被間接的標記在了Spring Boot的啓動類上。在SpringApplication.run(...)的內部就會執行selectImports()方法，找到所有JavaConfig自動配置類的全限定名對應的class，然後將所有自動配置類加載到Spring容器中。
自動配置生效
每一個XxxxAutoConfiguration自動配置類都是在某些條件之下才會生效的，這些條件的限制在Spring Boot中以註解的形式體現，常見的條件註解有如下幾項：
@ConditionalOnBean：當容器裏有指定的bean的條件下。
@ConditionalOnMissingBean：當容器裏不存在指定bean的條件下。
@ConditionalOnClass：當類路徑下有指定類的條件下。
@ConditionalOnMissingClass：當類路徑下不存在指定類的條件下。
@ConditionalOnProperty：指定的屬性是否有指定的值，比如@ConditionalOnProperties(prefix=”xxx.xxx”, value=”enable”, matchIfMissing=true)，代表當xxx.xxx爲enable時條件的布爾值爲true，如果沒有設置的情況下也爲true。
以ServletWebServerFactoryAutoConfiguration配置類爲例，解釋一下全局配置文件中的屬性如何生效，比如：server.port=8081，是如何生效的（當然不配置也會有默認值，這個默認值來自於org.apache.catalina.startup.Tomcat）。
在ServletWebServerFactoryAutoConfiguration類上，有一個@EnableConfigurationProperties註解：開啓配置屬性，而它後面的參數是一個ServerProperties類，這就是習慣優於配置的最終落地點。
在這個類上，我們看到了一個非常熟悉的註解：@ConfigurationProperties，它的作用就是從配置文件中綁定屬性到對應的bean上，而@EnableConfigurationProperties負責導入這個已經綁定了屬性的bean到spring容器中（見上面截圖）。那麼所有其他的和這個類相關的屬性都可以在全局配置文件中定義，也就是說，真正“限制”我們可以在全局配置文件中配置哪些屬性的類就是這些XxxxProperties類，它與配置文件中定義的prefix關鍵字開頭的一組屬性是唯一對應的。
至此，我們大致可以瞭解。在全局配置的屬性如：server.port等，通過@ConfigurationProperties註解，綁定到對應的XxxxProperties配置實體類上封裝爲一個bean，然後再通過@EnableConfigurationProperties註解導入到Spring容器中。
而諸多的XxxxAutoConfiguration自動配置類，就是Spring容器的JavaConfig形式，作用就是爲Spring 容器導入bean，而所有導入的bean所需要的屬性都通過xxxxProperties的bean來獲得。
可能到目前爲止還是有所疑惑，但面試的時候，其實遠遠不需要回答的這麼具體，你只需要這樣回答：
Spring Boot啓動的時候會通過@EnableAutoConfiguration註解找到META-INF/spring.factories配置文件中的所有自動配置類，並對其進行加載，而這些自動配置類都是以AutoConfiguration結尾來命名的，它實際上就是一個JavaConfig形式的Spring容器配置類，它能通過以Properties結尾命名的類中取得在全局配置文件中配置的屬性如：server.port，而XxxxProperties類是通過@ConfigurationProperties註解與全局配置文件中對應的屬性進行綁定的。
通過一張圖標來理解一下這一繁複的流程：
圖片來自於王福強老師的博客：https://afoo.me/posts/2015-07-09-how-spring-boot-works.html
總結
綜上是對自動配置原理的講解。當然，在瀏覽源碼的時候一定要記得不要太過拘泥與代碼的實現，而是應該抓住重點脈絡。
一定要記得XxxxProperties類的含義是：封裝配置文件中相關屬性；XxxxAutoConfiguration類的含義是：自動配置類，目的是給容器中添加組件。
而其他的主方法啓動，則是爲了加載這些五花八門的XxxxAutoConfiguration類。
——
原文鏈接：https://blog.csdn.net/u014745069/article/details/83820511
————————————————
版權聲明：本文爲CSDN博主「程序中的MKS」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/mkmkmkhh/article/details/101996991
