本篇內(nèi)容主要講解“服務(wù)器集群容錯(cuò)是什么”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“服務(wù)器集群容錯(cuò)是什么”吧!

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),昆玉企業(yè)網(wǎng)站建設(shè),昆玉品牌網(wǎng)站建設(shè),網(wǎng)站定制,昆玉網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷,網(wǎng)絡(luò)優(yōu)化,昆玉網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

集群容錯(cuò)：集群服務(wù)調(diào)用失敗后，服務(wù)框架需要能夠在底層自動(dòng)容錯(cuò)，容錯(cuò)策略很多，分別適用于不同場(chǎng)景。下面將對(duì)集群容錯(cuò)的功能和設(shè)計(jì)進(jìn)行詳細(xì)說(shuō)明。

1、集群容錯(cuò)場(chǎng)景

    在分布式服務(wù)框架中，業(yè)務(wù)消費(fèi)者不需要了解服務(wù)提供者的具體位置，它發(fā)起的調(diào)用請(qǐng)求也不包含服務(wù)提供者的具體地址信息。因此，某個(gè)服務(wù)提供者是否可用對(duì)消費(fèi)者無(wú)關(guān)緊要，最終的服務(wù)調(diào)用成功才是最重要的。

    經(jīng)過(guò)服務(wù)路由之后，選定某個(gè)服務(wù)提供者進(jìn)行遠(yuǎn)程調(diào)用，但是服務(wù)調(diào)用可能出錯(cuò)，下面對(duì)可能的故障場(chǎng)景進(jìn)行分析。

    1.1、通信鏈路故障

        這里的鏈路指的是消費(fèi)者和服務(wù)提供者之間的鏈路（通常為長(zhǎng)連接），可能導(dǎo)致鏈路中斷的原因有
            1）、通信過(guò)程中，對(duì)方突然宕機(jī)導(dǎo)致鏈路中斷。
            2）、通信過(guò)程中，對(duì)方因?yàn)榻獯a失敗等原因Rest掉連接，導(dǎo)致鏈路中斷。
            3）、通信過(guò)程中，消費(fèi)者write SocketChannel發(fā)生IOException導(dǎo)致鏈路中斷。
            4）、通信過(guò)程中，消費(fèi)者read SocketChannel發(fā)生IOException異常導(dǎo)致鏈路中斷。
            5）、通信雙方因?yàn)闄z測(cè)心跳超時(shí)，主動(dòng)close SocketChannel導(dǎo)致鏈路中斷。
            6）、通信過(guò)程中，網(wǎng)絡(luò)出現(xiàn)閃斷故障。
            7）、通信過(guò)程中，交換機(jī)異常導(dǎo)致鏈路中斷。
            8）、通信過(guò)程中，消費(fèi)者或者服務(wù)提供者因?yàn)殚L(zhǎng)時(shí)間Full GC導(dǎo)致鏈路中斷。
        無(wú)論哪種原因?qū)е骆溌分袛啵紩?huì)導(dǎo)致本次服務(wù)調(diào)用失敗。

    1.2、服務(wù)端超時(shí)

        當(dāng)服務(wù)端無(wú)法再指定的時(shí)間內(nèi)返回應(yīng)答給客戶端，就會(huì)發(fā)生超時(shí)，導(dǎo)致超時(shí)的原因主要有：
            1）、服務(wù)端I/O線程沒(méi)有及時(shí)從網(wǎng)絡(luò)中讀取客戶端請(qǐng)求消息，導(dǎo)致該問(wèn)題的原因通常是I/O線程被意外阻塞或者執(zhí)行長(zhǎng)周 期操作
            2）、服務(wù)端業(yè)務(wù)處理緩慢，或者長(zhǎng)時(shí)間阻塞，列如查詢數(shù)據(jù)庫(kù)，由于沒(méi)索引導(dǎo)致全表查詢，耗時(shí)較長(zhǎng)。
            3）、服務(wù)端發(fā)生長(zhǎng)時(shí)間Full GC,導(dǎo)致所有業(yè)務(wù)線程暫停運(yùn)行，無(wú)法及時(shí)返回應(yīng)答給客戶端。

    1.3、服務(wù)端調(diào)用失敗

        有時(shí)會(huì)發(fā)生服務(wù)端調(diào)用失敗，導(dǎo)致服務(wù)端調(diào)用失敗的原因主要有如下幾種：
            1）、服務(wù)端解碼失敗，會(huì)返回消息解碼失敗異常。
            2）、服務(wù)端發(fā)生動(dòng)態(tài)流控，返回流控異常。
            3）、服務(wù)消息隊(duì)列積壓率超過(guò)最大閾值，返回系統(tǒng)擁塞異常。
            4）、訪問(wèn)權(quán)限校驗(yàn)失敗，返回權(quán)限相關(guān)異常。
            5）、違反SLA(Service-Level Agreement:服務(wù)等級(jí)協(xié)議)策略，返回SLA控制相關(guān)異常。
            6）、其他系統(tǒng)異常。
        需要指出的是服務(wù)調(diào)用異常不包括業(yè)務(wù)方面的處理異常，例如數(shù)據(jù)庫(kù)異常、用戶記錄不存在異常等。

2、容錯(cuò)策略

    服務(wù)不同，容錯(cuò)策略也往往不同。下面看看集群容錯(cuò)和路由策略之間的關(guān)系。如圖1-1所示：
     
                                        圖1-1：集群容錯(cuò)和服務(wù)路由的關(guān)系

    消費(fèi)者根據(jù)配置的路由策略選擇某個(gè)目標(biāo)地址之后，發(fā)起遠(yuǎn)程服務(wù)調(diào)用，在此期間如果發(fā)生遠(yuǎn)程服務(wù)調(diào)用異常，則需要框架進(jìn)行集群容錯(cuò)，重新進(jìn)行選路和調(diào)用，集群容錯(cuò)是系統(tǒng)自動(dòng)執(zhí)行的，上層用戶并不關(guān)心底層的服務(wù)調(diào)用過(guò)程。

    2.1、失敗自動(dòng)切換（Failover）

        服務(wù)調(diào)用失敗自動(dòng)切換策略指的是當(dāng)發(fā)生RPC調(diào)用異常時(shí)，重新選路，查找下一個(gè)可用的服務(wù)提供者。

        服務(wù)發(fā)布的時(shí)候，可以指定服務(wù)的集群容錯(cuò)策略。消費(fèi)者可以覆蓋服務(wù)提供者的通用配置，實(shí)現(xiàn)個(gè)性化的容錯(cuò)策略。

        Failover策略的設(shè)計(jì)思路如下：消費(fèi)者路由操作完成之后，獲得目標(biāo)地址，調(diào)用通信框架的消息發(fā)送接口發(fā)送請(qǐng)求，監(jiān)聽服務(wù)端應(yīng)答。如果返回的結(jié)果時(shí)RPC調(diào)用異常（超時(shí)、流控、解碼失敗等系統(tǒng)異常），根據(jù)消費(fèi)者集群容錯(cuò)的策略進(jìn)行容錯(cuò)路由，如果是Failover，則重新返回到路由Handler的入口，從路由節(jié)點(diǎn)繼續(xù)執(zhí)行。選路完成之后，對(duì)目標(biāo)地址進(jìn)行對(duì)比，防止重新路由到故障服務(wù)節(jié)點(diǎn)，過(guò)濾掉上次的故障服務(wù)提供者之后，調(diào)用通信框架的消息發(fā)送接口發(fā)送請(qǐng)求消息。

        分布式服務(wù)框架提供Failover容錯(cuò)策略，但是用戶在使用時(shí)需要自己保證用對(duì)地方，下面對(duì)應(yīng)用場(chǎng)景進(jìn)行總結(jié)：
            1）、讀操作，因?yàn)橥ǔＫ莾绲鹊摹?br/>            2）、冪等性服務(wù)，保證調(diào)用1次與N次效果相同。
        需要特別指出的是，失敗重試會(huì)增加服務(wù)調(diào)用時(shí)延，因此框架必須對(duì)失敗重試的最大數(shù)做限制，通常默認(rèn)為3，防止無(wú)限制重試導(dǎo)致服務(wù)調(diào)用時(shí)延不可控。

    2.2、失敗通知（Failback）

        很多業(yè)務(wù)場(chǎng)景中，消費(fèi)者需要能夠獲取到服務(wù)調(diào)用失敗的具體信息，通過(guò)對(duì)失敗錯(cuò)誤碼等異常信息的判斷，決定后續(xù)的執(zhí)行策略，例如非冪等性服務(wù)調(diào)用。

        Failback的設(shè)計(jì)方案如下：服務(wù)框架獲取到服務(wù)提供者返回的RPC異常響應(yīng)之后，根據(jù)策略進(jìn)行容錯(cuò)。如果是Failback模式，則不再重試其他服務(wù)提供者，而是將RPC異常通知給消費(fèi)者，由消費(fèi)者捕獲異常進(jìn)行后續(xù)處理。

    2.3、失敗緩存（Failcache）

        Failcache策略是失敗自動(dòng)恢復(fù)的一種，在實(shí)際開發(fā)中應(yīng)用場(chǎng)景如下：
            √ 服務(wù)狀態(tài)路由，必須定點(diǎn)發(fā)送到指定的服務(wù)提供者。當(dāng)發(fā)生鏈路中斷、流控等服務(wù)暫時(shí)不可用時(shí)，服務(wù)框架將消息暫時(shí)緩存起來(lái)，等待周期T，重新發(fā)送，回到服務(wù)提供者能夠正常處理該消息。
             √ 對(duì)時(shí)延要求不敏感的服務(wù)。系統(tǒng)服務(wù)調(diào)用失敗，通常是鏈路暫時(shí)不可用、服務(wù)流控、GC掛住服務(wù)提供者進(jìn)程等，這種失敗不是永久性的，他的失敗是可預(yù)期的。如果消費(fèi)者調(diào)用對(duì)時(shí)延不敏感，可以考慮使用自動(dòng)恢復(fù)模式。既先緩存、再等待、最后重試。
             √ 通知類服務(wù)。對(duì)服務(wù)調(diào)用的實(shí)時(shí)性不高，可以容忍自動(dòng)恢復(fù)帶來(lái)的時(shí)延增長(zhǎng)。

        為了保證可靠性，F(xiàn)ailcache策略在設(shè)計(jì)的時(shí)候需要考慮如下幾個(gè)要素：

              √ 緩存時(shí)間、緩存對(duì)象上限數(shù)等需要做出限制，防止內(nèi)存溢出。
              √ 緩存淘汰算法的選擇，是否支持用戶配置。
              √ 定時(shí)重試的周期T，重試的最大次數(shù)等需要做出限制并支持用戶指定。

    2.4、快速失?。‵ailfast）

        在業(yè)務(wù)高峰期，對(duì)于一些非核心的服務(wù)，希望只調(diào)用一次，失敗也不再重試，為重要的核心服務(wù)節(jié)約寶貴的運(yùn)行資源。此時(shí)快速失敗是個(gè)不錯(cuò)的選擇。

        快速失敗策略設(shè)計(jì)簡(jiǎn)單，獲取到服務(wù)異常之后，直接忽略異常，記錄異常日志。

    2.5、容錯(cuò)策略擴(kuò)展

        無(wú)論服務(wù)框架支持多少種容錯(cuò)策略，業(yè)務(wù)在實(shí)際使用過(guò)程中一定會(huì)有不適應(yīng)的地方，通過(guò)開放容錯(cuò)策略接口的方式，可以支持用戶自定義擴(kuò)展容錯(cuò)策略。

        在集群容錯(cuò)設(shè)計(jì)的時(shí)候，需要考慮擴(kuò)展性，主要從以下幾方面進(jìn)行設(shè)計(jì)：

            1）、容錯(cuò)接口的開放。
            2）、屏蔽底層細(xì)節(jié)，用戶定制簡(jiǎn)單。
            3）、配置應(yīng)當(dāng)支持?jǐn)U展，不要讓用戶擴(kuò)展服務(wù)框架Schema。

到此，相信大家對(duì)“服務(wù)器集群容錯(cuò)是什么”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！