微服务可靠性设计--转
原文地址：http://www.infoq.com/cn/articles/micro-service-reliability-design?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage
微服務可靠性設計
1. 背景
微服務化之后，系統分布式部署，傳統單個流程的本地API調用被拆分成多個微服務之間的跨網絡調用，由于引入了網絡通信、序列化和反序列化等操作，系統發生故障的概率提高了很多。
微服務故障，有些是由于業務自身設計或者編碼不當導致，有些是底層的微服務化框架容錯能力不足導致。在實際項目中，需要從業務和平臺兩方面入手，提升微服務的可靠性。
1.1. 無處不在的故障
1.1.1. 分布式部署和調用
傳統單體架構一個完整的業務流程往往在同一個進程內部完成處理，不需要進行分布式協作，它的工作原理如下所示：
圖1-1 傳統單體架構本地方法調用
微服務化之后，不同的微服務采用分布式集群部署方式，服務的消費者和提供者通常運行在不同的進程中，需要跨網絡做RPC調用，它的工作原理如下所示：
圖1-2 微服務分布式RPC調用
分布式調用之后，相比于傳統單體架構的本地方法調用，主要引入了如下潛在故障點：
- 序列化與反序列化：微服務的請求和應答都需要經過序列化和反序列化，做消息的跨網絡通信，由于數據結構不一致、不支持的數據類型、對方編解碼錯誤等都會導致序列化和反序列化失敗，進而導致微服務調用失敗。
- 網絡問題：常見的包括網絡超時、網絡閃斷、網絡單通、網絡擁塞等，都可能會導致微服務遠程調用的失敗。
1.1.2. 大型系統微服務進程內合設
理想情況下，每個微服務都獨立打包和部署，微服務之間天然就支持進程級隔離，但事實上，對于一個大規模的企業IT系統、或者大型網站，是由成百上千個微服務組成的，在實踐中，微服務通常是不可能做到百分之百獨立部署的，原因如下：
不同的微服務合設在同一個進程之中，就會引入一系列潛在的故障點，例如：
- 處理較慢的微服務會阻塞其它微服務
- 某個微服務故障蔓延，可能導致整個進程不可用
- 低優先級的微服務，搶占高優先級微服務的資源
1.1.3. 微服務健康度
傳統情況下，往往使用服務注冊中心檢測微服務的狀態，當檢測到服務提供者不可用時，會將故障的服務信息廣播到集群所有節點，消費者接收到服務故障通知消息之后，根據故障信息中的服務名稱、IP地址等信息，對故障節點進行隔離。它的工作原理如下所示：
圖1-3 微服務狀態檢測
使用基于心跳或者會話的微服務狀態檢測，可以發現微服務所在進程宕機、網絡故障等問題，但在實際業務中，微服務并非“非死即活”，它可能處于“亞健康狀態”，服務調用失敗率很高，但又不是全部失敗。或者微服務已經處于過負荷流控狀態，業務質量受損，但是又沒有全部中斷。
使用簡單的微服務狀態檢測，很難應對上述這些場景。通過對微服務的運行質量建模，利用微服務健康度模型，根據采集的各種指標對微服務健康度實時打分，依據打分結果采取相應的可靠性對策，可以更有針對性的保障系統的可靠性。
1.1.4. 同步的I/O操作
在整個微服務調用過程中，主要會涉及到三類I/O操作：
- 網絡I/O操作，涉及到網絡讀寫
- 磁盤I/O操作，主要是記錄日志、話單、寫本地文件等
- 數據庫訪問，例如Java使用JDBC驅動進行數據庫操作
圖1-4 微服務涉及的主要I/O操作
凡是涉及到I/O操作的，如果I/O操作是同步阻塞模式，例如Java的BIO、文件File的讀寫操作、數據庫訪問的JDBC接口等，都是同步阻塞的。只要訪問的網絡、磁盤或者數據庫實例比較慢，都會導致調用方線程的阻塞。由于線程是Java虛擬機比較重要的資源，當大量微服務調用線程被阻塞之后，系統的吞吐量將嚴重下降。
1.1.5. 第三方SDK API調用
在微服務中，調用第三方SDK API，也可能會引入新的故障點，例如通過FTP客戶端訪問遠端的FTP服務，或者使用MQ客戶端訪問MQ服務，如果這些客戶端API的容錯性設計不好，也會導致調用方的級聯故障，這些故障是潛在和隱性的，在設計的時候往往容易被忽視，但它帶來的風險和危害是巨大的。
1.2. 微服務可靠性
軟件可靠性是指在給定時間內，特定環境下軟件無錯運行的概率。軟件可靠性包含了以下三個要素：
1) 規定的時間：軟件可靠性只是體現在其運行階段，所以將運行時間作為規定的時間的度量。運行時間包括軟件系統運行后工作與掛起(啟動但空閑)的累計時間。由于軟件運行的環境與程序路徑選取的隨機性，軟件的失效為隨機事件，所以運行時間屬于隨機變量。
2) 規定的環境條件:環境條件指軟件的運行環境。它涉及軟件系統運行時所需的各種支持要素，如支持硬件、操作系統、其它支持軟件、輸入數據格式和范圍以及操作規程等。
3) 規定的功能:軟件可靠性還與規定的任務和功能有關。由于要完成的任務不同，則調用的子模塊就不同(即程序路徑選擇不同)，其可靠性也就可能不同。所以要準確度量軟件系統的可靠性必須首先明確它的任務和功能。
1.2.1. 關鍵的可靠性因素
微服務的運行質量，除了自身的可靠性因素之外，還受到其它因素的影響，包括網絡、數據庫訪問、其它相關聯的微服務運行質量等。微服務的可靠性設計，需要考慮上述綜合因素，總結如下：
圖1-5 微服務可靠性設計模型
2. 異步I/O操作
2.1. 網絡I/O
2.1.1. 使用同步阻塞I/O的問題
以Java為例，在JDK 1.4推出JAVA NIO1.0之前，基于JAVA的所有Socket通信都采用了同步阻塞模式（BIO），這種一請求一應答的通信模型簡化了上層的應用開發，但是在可靠性和性能方面存在巨大的弊端：
2-1 傳統Java 同步阻塞I/O模型
采用BIO通信模型的服務端，通常由一個獨立的Acceptor線程負責監聽客戶端的連接，接收到客戶端連接之后為客戶端連接創建一個新的線程處理請求消息，處理完成之后，返回應答消息給客戶端，線程銷毀，這就是典型的一請求一應答模型。該架構最大的問題就是不具備彈性伸縮能力，當并發訪問量增加后，服務端的線程個數和并發訪問數成線性正比，由于線程是JAVA虛擬機非常寶貴的系統資源，當線程數膨脹之后，系統的性能急劇下降，隨著并發量的繼續增加，可能會發生句柄溢出、線程堆棧溢出等問題，并導致服務器最終宕機。
2.1.2. 使用非阻塞I/O通信
微服務進行遠程通信時，通過使用非阻塞I/O，可以解決由于網絡時延大、高并發接入等導致的服務端線程數膨脹或者線程被阻塞等問題。
以Java為例，從JDK1.4開始，JDK提供了一套專門的類庫支持非阻塞I/O，可以在java.nio包及其子包中找到相關的類和接口。JDK1.7之后，又提供了NIO2.0類庫，支持異步I/O操作。
利用JDK的異步非阻塞I/O，可以實現一個I/O線程同時處理多個客戶端鏈路，讀寫操作不會因為網絡原因被阻塞，I/O線程可以高效的并發處理多個客戶端鏈路，實現I/O多路復用，它的工作原理如下所示：
2-2 Java非阻塞I/O模型
使用非阻塞I/O進行通信，以Java語言為例，建議策略如下：
1) TCP私有協議：建議直接基于Netty開發。
2) HTTP/Restful/SOAP等：選擇支持非阻塞I/O的Web框架。也可以選擇基于Netty構建的開源應用層協議棧框架，例如支持異步Restful的RestExpress。
2.2. 磁盤I/O
微服務對磁盤I/O的操作分為兩類：
- 直接文件操作：例如調用File的open、write、read等接口，進行文件操作。
- 間接文件操作：例如調用日志類庫寫日志，雖然微服務并沒有直接操作日志文件，但是日志類庫底層還是會進行文件的讀寫等操作。
在實際項目中，最容易被忽視的就是日志操作。不同的日志類庫，寫日志的機制不同，以Log4j 1.2.X版本為例，當日志隊列滿之后，有多種策略：
- 同步等待，直到新的日志消息能夠入隊列，它會阻塞當前業務線程。
- 丟棄當前的日志消息，不會阻塞當前業務線程。
- 不入隊列，由當前調用寫日志的業務線程執行日志I/O操作，如果此時磁盤I/O寫入速度慢，則會阻塞當前業務線程。
在實際生產環境中，我們就遇到過類似問題，在某些時段，磁盤WIO達到10+持續幾秒鐘-10幾秒鐘，然后又恢復正常。WIO較高的時段，需要寫接口日志、話單等，由于系統默認采用的是同步等待策略，結果導致通信I/O線程、微服務調度線程等都被阻塞，最終鏈路因為心跳超時被強制關閉、微服務被大量阻塞在消息隊列中導致內存居高不小、響應超時等。
由于偶現的WIO高導致同步寫日志被阻塞，繼而引起通信線程、微服務調用線程級聯故障，定位起來非常困難，平時Code Review也很難被注意到。所以，隱性的磁盤I/O操作，更需要格外關注。
要解決上面的問題，有三種策略：
- 使用非阻塞I/O,對文件進行異步讀寫操作。
- 業務層面封裝一個異步的I/O操作，最簡單的策略就是由一個獨立的線程或者線程池來執行磁盤I/O操作。
- 選擇支持非阻塞方式調用的I/O類庫，例如使用log4j的異步日志API。
以JDK1.7為例，它提供了異步的文件I/O操作類庫，基于該類庫，就不需要擔心磁盤I/O操作被阻塞：
2-3 JDK1.7異步非阻塞文件接口
自己在上層封裝異步I/O操作，也比較簡單，它的優點是可以實現磁盤I/O操作與微服務之間的線程隔離，但是底層仍然使用的是同步阻塞I/O，如果此時磁盤的I/O比較高，依然會阻塞寫磁盤的I/O線程。它的原理如下所示：
2-4 應用層封裝的異步文件操作
將文件I/O操作封裝成一個Task或者Event，投遞到文件I/O線程池的消息隊列中，根據投遞結果，構造I/O操作相關聯的Future對象給微服務調用線程。通過向Future對象注冊Listener并實現callback接口，可以實現異步回調通知，這樣微服務和文件I/O操作就實現了線程隔離。文件I/O操作耗時，并不會阻塞微服務調度線程。
當使用第三方文件I/O操作類庫時，需要注意下相關API，盡量使用支持異步非阻塞接口的API，如果沒有，則需要考慮是否做上層的異步封裝。
2.3. 數據庫操作
部分數據庫訪問支持非阻塞方式，例如Oracle的OCI，它支持non-blocking模式和blocking模式：阻塞方式就是當調用 OCI操作時，必須等到此OCI操作完成后服務器才返回客戶端相應的信息，不管是成功還是失敗。非阻塞方式是當客戶端提交OCI操作給服務器后，服務器立即返回OCI_STILL_EXECUTING信息，而并不等待服務端的操作完成。對于non-blocking方式，應用程序若收到一個OCI函數的返回值為OCI_STILL_EXECUTING時必須再次對每一個OCI函數的返回值進行判斷，判斷其成功與否。 可通過設置服務器屬性為OCI_ATTR_NONBLOCKING_MODE來實現。
對于Java語言而言，由于JDK本身提供了數據庫連接驅動相關的接口定義，JDBC驅動本身就是同步API接口，因此，Java語言的開源ORM框架也都是同步阻塞的，例如MyBatis、Hibernate等。
盡管大部分數據庫訪問接口是同步阻塞的，但是由于數據庫中間件的超時控制機制都比較成熟，因此通過合理設置超時時間，可以避免微服務的數據庫訪問被長時間掛住。
也可以在應用上層封裝異步數據庫操作層，實現微服務調度與數據庫操作的線程級隔離，原理2.2章節已經介紹過，采用該方式同樣存在兩點不足：
- 排隊現象：如果某個數據庫操作非常耗時，超時時間配置的又比較大（例如30S），會導致后續的數據庫操作在隊列中排隊。
- 無法充分發揮數據庫效能：由于底層數據庫訪問采用同步阻塞的方式，所以不能高效發揮數據庫的效能。
3. 故障隔離
由于大部分微服務采用同步接口調用，而且多個領域相關的微服務會部署在同一個進程中，很容易發生“雪崩效應”，即某個微服務提供者故障，導致調用該微服務的消費者、或者與故障微服務合設在同一個進程中的其它微服務發生級聯故障，最終導致系統崩潰。
為了避免“雪崩效應”的發生，需要支持多種維度的依賴和故障隔離，以實現微服務的HA。
3.1. 通信鏈路隔離
由于網絡通信本身通常不是系統的瓶頸，因此大部分服務框架會采用多線程+單個通信鏈路的方式進行通信，原理如下所示：
3-1 多線程-單鏈路P2P通信模式
正如前面章節所述，由于微服務使用異步非阻塞通信，單個I/O線程可以同時并發處理多個鏈路的消息，而且網絡讀寫都是非阻塞的，因此采用多線程+單鏈路的方式進行通信性能本身問題不大。但是從可靠性角度來看，只支持單鏈路本身又存在一些可靠性隱患，我們從下面的案例中看下問題所在。
某互聯網基地微服務架構上線之后，發現在一些時段，經常有業務超時，超時的業務沒有固定規律。經定位發現當有較多的批量內容同步、語音和視頻類微服務調用時，系統的整體時延就增高了很多，而且存在較突出的時延毛刺。由于這些操作獲取的消息碼流往往達到數M到數十兆，微服務之間又采用單鏈路的方式進行P2P通信，導致大碼流的傳輸影響了其它消息的讀寫效率，增大了微服務的響應時延。
問題定位出來之后，對微服務之間的通信機制做了優化，節點之間支持配置多鏈路，每個鏈路之間還可以實現不同策略的隔離，例如根據消息碼流大小、根據微服務的優先級等策略，實現鏈路級的隔離，優化之后的微服務通信機制：
圖3-2 支持多鏈路隔離
3.2. 調度資源隔離
3.2.1. 微服務之間隔離
當多個微服務合設運行在同一個進程內部時，可以利用線程實現不同微服務之間的隔離。
對于核心微服務，發布的時候可以獨占一個線程/線程池，對于非核心微服務，則可以共享同一個大的線程池，在實現微服務隔離的同時，避免線程過于膨脹：
圖3-3 微服務之間故障隔離
假如非核心服務3發生故障，長時間阻塞線程池1的工作線程，其它與其共用線程池消息隊列的非核心服務1和服務2只能在隊列中排隊等待，當服務3釋放線程之后，排隊的服務1和服務2可能已經超時，只能被丟棄掉，導致業務處理失敗。
采用線程池隔離的核心服務1和服務2，由于各自獨占線程池，擁有獨立的消息隊列，它的執行不受發生故障的非核心服務1影響，因此可以繼續正常工作。通過獨立線程池部署核心服務，可以防止故障擴散，保障核心服務的正常運行。
3.2.2. 第三方依賴隔離
在微服務中通常會調用第三方中間件服務，例如分布式緩存服務、分布式消息隊列、NoSQL服務等。只要調用第三方服務，就會涉及跨網絡操作，由于客戶端SDK API的封裝，很多故障都是隱性的，因此，它的可靠性需要額外關注。
整體而言，第三方依賴隔離可以采用線程池 + 響應式編程（例如RxJava）的方式實現，它的原理如下所示：
1) 對第三方依賴進行分類，每種依賴對應一個獨立的線程/線程池。
2) 微服務不直接調用第三方依賴的API，而是使用異步封裝之后的API接口。
3) 異步調用第三方依賴API之后，獲取Future對象。利用響應式編程框架，可以訂閱后續的事件，接收響應，針對響應進行編程。
利用Netflix開源的hystrix + RxJava，可以快速實現第三方依賴的隔離，后續章節我們會詳細介紹下如何使用。
3.3. 進程級隔離
對于核心的微服務，例如商品購買、用戶注冊、計費等，可以采用獨立部署的方式，實現高可用性。
3.3.1. 容器隔離
微服務鼓勵軟件開發者將整個軟件解耦為功能單一的服務，并且這些服務能夠獨立部署、升級和擴容。如果微服務抽象的足夠好，那么微服務的這一優點將能夠提升應用的敏捷性和自治理能力。
利用Docker容器部署微服務，可以帶來如下幾個優點：
- 高效：Docker容器的啟動和停止不需要幾分鐘，只要幾百毫秒就足夠了。使用Docker部署微服務，微服務的啟動和銷毀速度非常快，在高壓力時，可以實現秒級彈性伸縮。
- 高性能：Docker容器的性能接近裸的物理機，比VM平均高20%+。
- 隔離性：利用Docker，可以實現0.1 core的隔離。基于細粒度的資源隔離機制，可以實現高密度的部署微服務，同時實現它們之間的資源層隔離，保障微服務的可靠性。
- 可移植性：在基于虛擬機的解決方案中，應用的可移植性通常來說會受到云提供商所提供的虛擬機格式限制。如果應用程序需要部署到不同類型的虛擬機中，需要針對特定的虛擬機格式做鏡像文件，新增很多額外的開發和測試工作量。Docker容器的設計理念是“一次編寫，到處運行”，這可以使開發者避免上面這種限制。
基于Docker容器部署微服務，實現物理資源層隔離示意圖如下所示：
圖3-4? 基于Docker容器的微服務隔離
3.3.2. VM隔離
除了Docker容器隔離，也可以使用VM對微服務進行故障隔離，相比于Docker容器，使用VM進行微服務隔離存在如下優勢：
4. 集群容錯
當微服務不可用時，需要根據預置的策略做容錯處理，大部分的容錯能力和策略是公共的，因此可以下沉到服務框架中實現。
4.1. 路由容錯
當集群環境中微服務調用失敗之后，利用路由容錯機制，可以在底層實現微服務的自動容錯處理，提升系統的可靠性。
常用的容錯策略包括：
- 失敗自動切換機制：微服務調用失敗自動切換策略指的是當發生服務調用異常時，重新選路，查找下一個可用的微服務提供者。微服務發布的時候，可以指定服務的集群容錯策略。消費者可以覆蓋服務提供者的通用配置，實現個性化的容錯策略。
- 失敗回調機制：微服務調用失敗之后，提供異常回調接口，執行微服務消費者自定義的失敗處理邏輯。
- 快速失敗機制：在業務高峰期，對于一些非核心的服務，希望只調用一次，失敗也不再重試，為重要的核心服務節約寶貴的運行資源。此時，快速失敗是個不錯的選擇。快速失敗策略的設計比較簡單，獲取到服務調用異常之后，直接忽略異常，記錄異常日志。
4.2. 服務降級
大促或者業務高峰時，為了保證核心服務的SLA，往往需要停掉一些不太重要的業務，例如商品評論、論壇或者粉絲積分等。
另外一種場景就是某些服務因為某種原因不可用，但是流程不能直接失敗，需要本地Mock服務端實現，做流程放通。以圖書閱讀為例，如果用戶登錄余額鑒權服務不能正常工作，需要做業務放通，記錄消費話單，允許用戶繼續閱讀，而不是返回失敗。
通過服務治理的服務降級功能，即可以滿足上述兩種場景的需求。
4.2.1. 強制降級
當外界的觸發條件達到某個臨界值時，由運維人員/開發人員決策，對某類或者某個服務進行強制降級。
強制降級的常用策略：
4.2.2. 容錯降級
當非核心服務不可用時，可以對故障服務做業務邏輯放通，以保障核心服務的運行。
容錯降級與屏蔽降級的主要差異是：
容錯降級的常用策略如下：
4.2.3. 服務降級Portal
利用服務治理Portal，可以在線的動態修改微服務的降級策略，實時生效，它的界面如下所示：
圖4-1 服務降級配置界面
4.3. 熔斷機制
熔斷機制（Circuit Breaker），也叫自動停盤機制，是指當股指波幅達到規定的熔斷點時，交易所為控制風險采取的暫停交易措施。
在微服務領域，熔斷機制是從消費端保護微服務提供者的措施，當微服務的運行質量低于某個臨界值時，啟動熔斷機制，暫停微服務調用一段時間，以保障后端的微服務不會因為持續過負荷而宕機。
4.3.1. 工作原理
微服務的熔斷機制原理如下所示：
它的工作原理示意如下：
圖4-2 微服務熔斷器工作原理
熔斷器機制能保證微服務消費者在微服務運行狀態不佳時，快速返回結果，避免大量的同步等待。并且能在指定周期T后繼續偵測微服務是否可用, 以實現故障恢復之后的自動感知。
4.3.2. 微服務健康度
熔斷器開關的狀態取決于微服務的運行質量，微服務的運行質量通常由多種因素決定，具有多個衡量因子。通過對微服務健康度建模，可以實現對微服務運行質量的360°實時評估。
微服務健康度模型如下所示：
圖4-3 微服務健康度模型
微服務運維體系通過分布式日志采集系統、告警系統、性能KPI數據采集等，利用在線大數據實時分析技術，通過健康度模型，對微服務的健康度按照周期進行實時打分，同時將微服務的得分通過消息隊列訂閱發布出去，各個節點訂閱微服務的健康度得分，與熔斷器閾值進行比較，修改熔斷器開關的狀態。
5. 流量控制
當資源成為瓶頸時，服務框架需要對消費者做限流，啟動流控保護機制。流量控制有多種策略，比較常用的有：針對訪問速率的靜態流控、針對資源占用的動態流控等。
在實踐中，各種流量控制策略需要綜合使用才能起到較好的效果。
5.1. 動態流控
動態流控的最終目標是為了保命，并不是對流量或者訪問速度做精確控制。當系統負載壓力非常大時，系統進入過負載狀態，可能是CPU、內存資源已經過載，也可能是應用進程內部的資源幾乎耗盡，如果繼續全量處理業務，可能會導致消息嚴重積壓或者應用進程宕機。
動態流控檢測的資源包括：
- CPU使用率。
- 內存使用率（對于Java，主要是JVM內存使用率）。
- 隊列積壓率。
主機CPU、內存使用率采集算法非常多，例如使用java.lang.Process執行top、sar等外部命令獲取系統資源使用情況，然后解析后計算獲得資源使用率。也可以直接讀取操作系統的系統文件獲取相關數據，需要注意的是，無論是執行操作系統的本地命令，還是直接讀取操作系統的資源使用率文件，都是操作系統本地相關的，不同的操作系統和服務器，命令和輸出格式可能存在很大差異。在計算時需要首先判斷操作系統類型，然后調用相關操作系統的資源采集接口實現類，通過這種方式就可以支持跨平臺。
動態流控是分級別的，不同級別拒掉的消息比例不同，這取決于資源的負載使用情況。例如當發生一級流控時，拒絕掉1/4的消息；發生二級流控時，拒絕掉1/2消息；發生三級流控時，所有的消息都被流控掉。
不同的級別有不同的流控閾值，系統上線后會提供默認的；流控閾值，不同流控因子的流控閾值不同，業務上線之后通常會根據現場的實際情況做閾值調優，因此流控閾值需要支持在線修改和動態生效。
需要指出的是為了防止系統波動導致的偶發性流控，無論是進入流控狀態還是從流控狀態恢復，都需要連續采集N次并計算平均值，如果連續N次平均值大于流控閾值，則進入流控狀態；同理，只有連續N次資源使用率平均值低于流控閾值，才能脫離流控恢復正常。
5.2. 靜態流控
靜態流控主要針對客戶端訪問速率進行控制，它通常根據服務質量等級協定（SLA）中約定的QPS做全局流量控制，例如計費服務的靜態流控閾值為200 QPS，則無論集群有多少個計費服務實例，它們總的處理速率之和不能超過200 QPS。
由于微服務具備彈性伸縮、動態上線和下線等特性，因此集群中某個微服務實例的節點個數是動態變化的，采用傳統的平均分配制無法做到精準的控制。
在實踐中，比較成熟的集群靜態流控策略是動態配額申請制，它的工作原理如下：
5.3. 用戶自定義流控機制
不同的業務，存在不同的流控策略，例如基于微服務優先級的流控、基于節假日的流控、基于業務字段的流控等。底層的服務框架無法實現所有業務級的定制流控策略，因此，過于業務化的流控往往由業務通過自定義流控機制定制實現。
服務框架提供服務調用入口的攔截點和切面接口，由業務實現自定義流控。也可以提供基礎的流控框架，供業務實現流控條件判斷、流控執行策略等，簡化業務的定制工作量。
6. 使用Hystrix提升微服務可靠性
6.1. Hystrix簡介
Hystrix是Netflix開源的一個可靠性組件，主要用于分布式環境中的依賴解耦，Hystrix library通過添加延遲容忍和容錯邏輯來控制分布式服務之間的相互影響，通過服務之間訪問的隔離點阻止連鎖故障，并提供了失敗回調機制，來改進系統的可靠性。
Hystrix提供如下機制來提升分布式系統的可靠性：
- 保護通過第三方客戶端API依賴訪問，控制其延遲和故障
- 阻止級聯故障和“雪崩效應”
- 提供熔斷機制，快速失敗和恢復
- 失敗回調和優雅降級機制
- 近實時檢測、報警和KPI指標展示
6.2. Hystrix的核心功能
Hystrix提供了一些非常有價值、與具體微服務框架實現無關的特性，方便不同的分布式系統集成使用。
6.2.1. 依賴隔離
Hystrix使用命令模式HystrixCommand(Command)包裝依賴調用邏輯，每個命令在單獨線程/信號授權下執行。依賴調用的超時時間可配置，如果超時，則則返回失敗或者執行fallback邏輯。原理如下所示：
圖6-1 基于線程/信號的依賴隔離
6.2.2. 熔斷器
Hystrix會先經過熔斷器，此時如果熔斷器的狀態是打開，則說明已經熔斷，這時將直接進行降級處理，不會繼續將請求發到線程池。
熔斷器的開關狀態由熔斷算法決定，它的原理如下：
- 判斷是否熔斷：根據bucket中記錄的次數，計算錯誤率。如果錯誤率達到熔斷預置的閾值，則開啟熔斷開關。
- 熔斷恢復：對于被熔斷的請求，暫停處理一段時間之后（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()），允許單個請求通過，若請求成功，則取消熔斷，否則，繼續熔斷。
Hystrix熔斷器的工作原理如下所示：
圖6-2 Hystrix熔斷機制
6.2.3. 優雅降級
當微服務調用異常、超時，或者熔斷時，可以通過回調Fallback（）的方式實現業務的優雅降級，它的原理如下所示：
圖6-3 Hystrix優雅降級機制
6.2.4. Reactive編程
Hystrix支持響應式編程，并提供了相關接口給用戶，如下所示：
利用響應式編程，可以更加優雅和靈活的實現異步回調邏輯的處理。
6.2.5. 信號量隔離
為了降低線程資源的開銷，Hystrix提供了信號量Semaphores，用于實現輕量級的依賴隔離。
開發者可以限制系統對某一個依賴的最高并發數，這個基本上等同于并發流控策略。每次微服務調用依賴時都會檢查一下是否到達信號量的限制值，如達到則拒絕。該隔離策略的優點是不新起線程，減少上下文切換和線程數，缺點是無法配置斷路，每次都一定會去嘗試獲取信號量。
6.3. 集成Hystrix
由于Hystrix與特定的分布式系統、微服務框架無關，是個通用的分布式系統可靠性組件，可以通過類庫集成的方式方便的集成到已有的微服務架構體系中。
6.3.1. 集成架構
在已有微服務體系中集成Hystrix的策略如下：
集成架構示例如下：
圖6-4? 集成Hystrix的微服務架構
6.3.2. 集成Hystrix帶來的優點
第三方依賴隔離具備一定的通用性，例如數據庫隔離、磁盤I/O隔離、第三方服務調用隔離等，如果各自構建一套隔離機制，除了增加工作量之外，后續維護起來也比較麻煩。
另外，業務微服務自身也會引入第三方依賴，如果沒有通用的隔離機制，則業務需要自己構建業務級的隔離體系，相應的開發難度和工作量都較大，架構上也很難統一。
集成Hystrix，可以快速的構建微服務的隔離、熔斷、優雅降級和響應式編程體系，提升系統的可靠性。
另外，Hystrix非常成熟，在Netflix已經經歷過苛刻的生產環境考驗，它的可靠性和成熟度完全能夠滿足大部分業務場景的需要。
7. 附錄
7.1. 參考文獻
Netflix Hystrix.
https://github.com/Netflix/Hystrix/wiki/How-To-Use
https://github.com/Netflix/Hystrix/wiki/How-it-Works
轉載于:https://www.cnblogs.com/davidwang456/p/6840150.html
總結
以上是生活随笔為你收集整理的微服务可靠性设计--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 预发环境与生产环境共享数据库时定时任务重
- 下一篇： 唯品会API网关设计与实践--转