學(xué)習(xí)導(dǎo)圖

這篇文章來分享一下面試必備的Spring Cloud問題解析！?用XMind畫了一張導(dǎo)圖記錄?Spring Cloud?的學(xué)習(xí)筆記和一些面試解析

1.什么是微服務(wù)

微服務(wù)是一種架構(gòu)?格倦挂，也是?種服務(wù)肋殴；

微服務(wù)的顆粒?較?睦霎，?個(gè)?型復(fù)雜軟件應(yīng)?由多個(gè)微服務(wù)組成寺旺，?如Netflix?前由500多的微服務(wù)組成绢陌；

它采用UNIX設(shè)計(jì)的哲學(xué)凛剥，每種服務(wù)只做?件事效五，是?種松耦合的能夠被獨(dú)?開發(fā)和部署的?狀態(tài)化服務(wù)（獨(dú)?擴(kuò)展地消、升級和可替換）。

2. 微服務(wù)之間是如何獨(dú)立通訊的

Dubbo 使用的是 RPC 通信畏妖，?進(jìn)制傳輸脉执，占?帶寬?；

Spring Cloud 使?的是 HTTP RESTFul ?式戒劫。

3. springcloud和dubbo有哪些區(qū)別

Dubbo具有調(diào)度半夷、發(fā)現(xiàn)婆廊、監(jiān)控、治理等功能巫橄，?持相當(dāng)豐富的服務(wù)治理能力淘邻。Dubbo架構(gòu)下，注冊中?對等集群湘换，并會(huì)緩存服務(wù)列表已被數(shù)據(jù)庫失效時(shí)繼續(xù)提供發(fā)現(xiàn)功能宾舅，本身的服務(wù)發(fā)現(xiàn)結(jié)構(gòu)有很強(qiáng)的可?性與健壯性，?夠?持?訪問量的?站彩倚。

雖然Dubbo ?持短連接?數(shù)據(jù)量的服務(wù)提供模式筹我，但絕大多數(shù)情況下都是使??連接?數(shù)據(jù)量的模式提供服務(wù)使?的。所以帆离，對于類似于電商等同步調(diào)?場景多并且能?撐搭建Dubbo 這套?較復(fù)雜環(huán)境的成本的產(chǎn)品??蔬蕊，Dubbo 確實(shí)是一個(gè)可以考慮的選擇。但如果產(chǎn)品業(yè)務(wù)中由于后臺(tái)業(yè)務(wù)邏輯復(fù)雜哥谷、時(shí)間??導(dǎo)致異步邏輯?較多的話岸夯，可能Dubbo 并不合適。同時(shí)们妥，對于??不?的初創(chuàng)產(chǎn)品??猜扮，這么重的架構(gòu)維護(hù)起來也不是很方便。

Spring Cloud由眾多?項(xiàng)?組成监婶，如Spring Cloud Config破镰、Spring Cloud Netflix、Spring Cloud Consul 等压储，提供了搭建分布式系統(tǒng)及微服務(wù)常用的?具，如配置管理源譬、服務(wù)發(fā)現(xiàn)集惋、斷路器、智能路由踩娘、微代理刮刑、控制總線、一次性token养渴、全局鎖雷绢、選主、分布式會(huì)話和集群狀態(tài)等理卑，滿足了構(gòu)建微服務(wù)所需的所有解決?案翘紊。?如使?Spring Cloud Config 可以實(shí)現(xiàn)統(tǒng)?配置中?，對配置進(jìn)?統(tǒng)?管理藐唠；使?Spring Cloud Netflix 可以實(shí)現(xiàn)Netflix 組件的功能 - 服務(wù)發(fā)現(xiàn)（Eureka）帆疟、智能路由（Zuul）鹉究、客戶端負(fù)載均衡（Ribbon）。

Dubbo 提供了各種 Filter踪宠，對于上述中“?”的要素自赔，可以通過擴(kuò)展 Filter 來完善。

dubbo的開發(fā)難度較?柳琢，原因是dubbo的jar包依賴問題很多?型?程?法解決绍妨。

4. springboot和springcloud認(rèn)識(shí)

Spring Boot 是 Spring 的?套快速配置腳?架，可以基于Spring Boot 快速開發(fā)單個(gè)微服務(wù)柬脸，Spring Cloud是一個(gè)基于Spring Boot實(shí)現(xiàn)的云應(yīng)?開發(fā)?具他去；

Spring Boot專注于快速、?便集成的單個(gè)微服務(wù)個(gè)體肖粮，Spring Cloud關(guān)注全局的服務(wù)治理框架孤页；

Spring Boot使?了默認(rèn)?于配置的理念，很多集成?案已經(jīng)幫你選擇好了涩馆，能不配置就不配置行施；

Spring Cloud很?的?部分是基于Spring Boot來實(shí)現(xiàn)，可以不基于Spring Boot嗎魂那？不可以蛾号。

5. 什么是服務(wù)熔斷，什么是服務(wù)降級

服務(wù)熔斷：

如果檢查出來頻繁超時(shí)涯雅，就把consumer調(diào)?provider的請求鲜结，直接短路掉，不實(shí)際調(diào)?活逆，?是直接返回?個(gè)mock的值精刷。

服務(wù)降級：

consumer 端：?consumer 如果發(fā)現(xiàn)某個(gè)provider出現(xiàn)異常情況，?如蔗候，經(jīng)常超時(shí)(可能是熔斷引起的降級)怒允，數(shù)據(jù)錯(cuò)誤，這時(shí)锈遥，consumer可以采取?定的策略纫事，降級provider的邏輯，基本的有直接返回固定的數(shù)據(jù)所灸。

provider 端：?當(dāng)provider 發(fā)現(xiàn)流量激增的時(shí)候丽惶，為了保護(hù)?身的穩(wěn)定性，也可能考慮降級服務(wù)爬立。

1.直接給consumer返回固定數(shù)據(jù)

2.需要實(shí)時(shí)寫?數(shù)據(jù)庫的钾唬，先緩存到隊(duì)列?，異步寫?數(shù)據(jù)庫。

6. 微服務(wù)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

單?職責(zé)：每個(gè)微服務(wù)僅負(fù)責(zé)??業(yè)務(wù)領(lǐng)域的功能知纷；

?治：?個(gè)微服務(wù)就是?個(gè)獨(dú)?的實(shí)體壤圃，它可以獨(dú)?部署、升級琅轧，服務(wù)與服務(wù)之間通過REST等形式的標(biāo)準(zhǔn)接?進(jìn)?通信伍绳，并且?個(gè)微服務(wù)實(shí)例可以被替換成另?種實(shí)現(xiàn)，?對其它的微服務(wù)不產(chǎn)?影響乍桂。

邏輯清晰：微服務(wù)單?職責(zé)特性使微服務(wù)看起來邏輯清晰冲杀，易于維護(hù)。

簡化部署：單系統(tǒng)中修改?處需要部署整個(gè)系統(tǒng)睹酌，?微服務(wù)中修改?處可單獨(dú)部署?個(gè)服務(wù)

可擴(kuò)展：應(yīng)對系統(tǒng)業(yè)務(wù)增?的?法通常采?橫向（Scale out）或縱向（Scale up）的?向進(jìn)?擴(kuò)展权谁。分布式系統(tǒng)中通常要采?Scale out的?式進(jìn)?擴(kuò)展。

靈活組合：

技術(shù)異構(gòu)：不同的服務(wù)之間憋沿，可以根據(jù)??的業(yè)務(wù)特點(diǎn)選擇不通的技術(shù)架構(gòu)旺芽，如數(shù)據(jù)庫等。

缺點(diǎn)：

復(fù)雜度?：?服務(wù)調(diào)?要考慮被調(diào)??故障辐啄、過載采章、消息丟失等各種異常情況，代碼邏輯更加復(fù)雜壶辜；對于微服務(wù)間的事務(wù)性操作悯舟，因?yàn)椴煌奈⒎?wù)采?了不同的數(shù)據(jù)庫，將?法利?數(shù)據(jù)庫本身的事務(wù)機(jī)制保證?致性砸民，需要引??階段提交等技術(shù)抵怎。

運(yùn)維復(fù)雜：?系統(tǒng)由多個(gè)獨(dú)?運(yùn)?的微服務(wù)構(gòu)成，需要?個(gè)設(shè)計(jì)良好的監(jiān)控系統(tǒng)對各個(gè)微服務(wù)的運(yùn)?狀態(tài)進(jìn)?監(jiān)控岭参。運(yùn)維?員需要對系統(tǒng)有細(xì)致的了解才對夠更好的運(yùn)維系統(tǒng)反惕。

通信延遲：?微服務(wù)之間調(diào)?會(huì)有時(shí)間損耗，造成通信延遲演侯。

7. 使?中碰到的坑

超時(shí)：?確保Hystrix超時(shí)時(shí)間配置為?于配置的Ribbon超時(shí)時(shí)間

feign path：?feign客戶端在部署時(shí)若有contextpath應(yīng)該設(shè)置 path="/***"來匹配你的服務(wù)名承璃。

版本：?springboot和springcloud版本要兼容。

8. 列舉微服務(wù)技術(shù)棧

服務(wù)?關(guān)Zuul

服務(wù)注冊發(fā)現(xiàn)Eureka+Ribbon

服務(wù)配置中?Apollo

認(rèn)證授權(quán)中?Spring Security OAuth2

服務(wù)框架Spring Boot

數(shù)據(jù)總線Kafka

?志監(jiān)控ELK

調(diào)?鏈監(jiān)控CAT

Metrics監(jiān)控KairosDB

健康檢查和告警ZMon

限流熔斷和流聚合Hystrix/Turbine

9. eureka和zookeeper都可以提供服務(wù)的注冊與發(fā)現(xiàn)功能蚌本，他們的區(qū)別

Zookeeper保證CP

當(dāng)向注冊中?查詢服務(wù)列表時(shí)，我們可以容忍注冊中?返回的是?分鐘以前的注冊信息隘梨，但不能接受服務(wù)直接down掉不可?程癌。也就是說，服務(wù)注冊功能對可?性的要求要?于?致性轴猎。但是zk會(huì)出現(xiàn)這樣?種情況嵌莉，當(dāng)master節(jié)點(diǎn)因?yàn)?絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時(shí)，剩余節(jié)點(diǎn)會(huì)重新進(jìn)?leader選舉捻脖。問題在于锐峭，選舉leader的時(shí)間太?中鼠，30 ~ 120s, 且選舉期間整個(gè)zk集群都是不可?的，這就導(dǎo)致在選舉期間注冊服務(wù)癱瘓沿癞。在云部署的環(huán)境下援雇，因?絡(luò)問題使得zk集群失去master節(jié)點(diǎn)是較?概率會(huì)發(fā)?的事，雖然服務(wù)能夠最終恢復(fù)椎扬，但是漫?的選舉時(shí)間導(dǎo)致的注冊?期不可?是不能容忍的惫搏。

Eureka保證AP

Eureka看明?了這?點(diǎn)，因此在設(shè)計(jì)時(shí)就優(yōu)先保證可?性蚕涤。Eureka各個(gè)節(jié)點(diǎn)都是平等的筐赔，?個(gè)節(jié)點(diǎn)掛掉不會(huì)影響正常節(jié)點(diǎn)的?作，剩余的節(jié)點(diǎn)依然可以提供注冊和查詢服務(wù)揖铜。?Eureka的客戶端在向某個(gè)Eureka注冊或如果發(fā)現(xiàn)連接失敗茴丰，則會(huì)?動(dòng)切換?其它節(jié)點(diǎn)，只要有?臺(tái)Eureka還在天吓，就能保證注冊服務(wù)可?(保證可?性)贿肩，只不過查到的信息可能不是最新的(不保證強(qiáng)?致性)。除此之外失仁，Eureka還有?種?我保護(hù)機(jī)制尸曼，如果在15分鐘內(nèi)超過85%的節(jié)點(diǎn)都沒有正常的?跳，那么Eureka就認(rèn)為客戶端與注冊中?出現(xiàn)了?絡(luò)故障萄焦，?此時(shí)會(huì)出現(xiàn)以下?種情況：

Eureka不再從注冊列表中移除因?yàn)?時(shí)間沒收到?跳?應(yīng)該過期的服務(wù)

Eureka仍然能夠接受新服務(wù)的注冊和查詢請求控轿，但是不會(huì)被同步到其它節(jié)點(diǎn)上(即保證當(dāng)前節(jié)點(diǎn)依然可?)

當(dāng)?絡(luò)穩(wěn)定時(shí)，當(dāng)前實(shí)例新的注冊信息會(huì)被同步到其它節(jié)點(diǎn)中

因此拂封， Eureka可以很好的應(yīng)對因?絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況茬射，?不會(huì)像zookeeper那樣使整個(gè)注冊服務(wù)癱瘓。

10. eureka服務(wù)注冊與發(fā)現(xiàn)原理

每30s發(fā)送?跳檢測重新進(jìn)?租約冒签，如果客戶端不能多次更新租約在抛，它將在90s內(nèi)從服務(wù)器注冊中?移除。

注冊信息和更新會(huì)被復(fù)制到其他Eureka 節(jié)點(diǎn)萧恕，來?任何區(qū)域的客戶端可以查找到注冊中?信息刚梭，每30s發(fā)??次復(fù)制來定位他們的服務(wù)，并進(jìn)?遠(yuǎn)程調(diào)?票唆。

客戶端還可以緩存?些服務(wù)實(shí)例信息朴读，所以即使Eureka全掛掉，客戶端也是可以定位到服務(wù)地址的走趋。

11. dubbo服務(wù)注冊與發(fā)現(xiàn)原理

調(diào)?關(guān)系說明：

服務(wù)容器負(fù)責(zé)啟動(dòng),加載,運(yùn)?服務(wù)提供者衅金。

服務(wù)提供者在啟動(dòng)時(shí),向注冊中?注冊??提供的服務(wù)。

服務(wù)消費(fèi)者在啟動(dòng)時(shí),向注冊中?訂閱??所需的服務(wù)。

注冊中?返回服務(wù)提供者地址列表給消費(fèi)者,如果有變更,注冊中?將基于?連接推送變更數(shù)據(jù)給消費(fèi)者氮唯。

服務(wù)消費(fèi)者,從提供者地址列表中,基于軟負(fù)載均衡算法,選?臺(tái)提供者進(jìn)?調(diào)?,如果調(diào)?失敗,再選另?臺(tái)調(diào)?鉴吹。

服務(wù)消費(fèi)者和提供者,在內(nèi)存中累計(jì)調(diào)?次數(shù)和調(diào)?時(shí)間,定時(shí)每分鐘發(fā)送?次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中?。

12. 限流

1惩琉、http限流：我們使?nginx的limitzone來完成：

//這個(gè)表示使?ip進(jìn)?限流 zone名稱為req_one 分配了10m 空間使?漏桶算法 每秒鐘允許1個(gè)請求

limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s; //這邊burst表示可以瞬間超過20個(gè)請求 由于沒有noDelay參數(shù)因此需要排隊(duì) 如果超過這20個(gè)那么直接返回503

limit_req zone=req_three burst=20;復(fù)制代碼

2豆励、dubbo限流：dubbo提供了多個(gè)和請求相關(guān)的filter：ActiveLimitFilter ExecuteLimitFilter TPSLimiterFilter

1. ActiveLimitFilter：

@Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)復(fù)制代碼

作?于客戶端，主要作?是控制客戶端?法的并發(fā)度琳水；

當(dāng)超過了指定的active值之后該請求將等待前?的請求完成【何時(shí)結(jié)束呢肆糕？依賴于該?法的timeout 如果沒有設(shè)置timeout的話可能就是多個(gè)請求?直被阻塞然后等待隨機(jī)喚醒。

2. ExecuteLimitFilter：

@Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)復(fù)制代碼

作?于服務(wù)端在孝，?旦超出指定的數(shù)?直接報(bào)錯(cuò) 其實(shí)是指在服務(wù)端的并?度【需要注意這些都是指的是在單臺(tái)服務(wù)上?不是整個(gè)服務(wù)集群】

3. TPSLimiterFilter：

@Activate(group = Constants.PROVIDER, value = Constants.TPS_LIMIT_RATE_KEY)復(fù)制代碼

作?于服務(wù)端诚啃，控制?段時(shí)間內(nèi)的請求數(shù)；

默認(rèn)情況下取得tps.interval字段表示請求間隔 如果?法找到則使?60s 根據(jù)tps字段表示允許調(diào)?次數(shù)私沮。

使?AtomicInteger表示允許調(diào)?的次數(shù) 每次調(diào)?減少1次當(dāng)結(jié)果?于0之后返回不允許調(diào)?

3始赎、springcloud限流：

1.我們可以通過semaphore.maxConcurrentRequests,coreSize,maxQueueSize和queueSizeRejectionThreshold設(shè)置信號(hào)量模式下的最?并發(fā)量、線程池??仔燕、緩沖區(qū)??和緩沖區(qū)降級閾值造垛。

#不設(shè)置緩沖區(qū)，當(dāng)請求數(shù)超過coreSize時(shí)直接降級

hystrix.threadpool.userThreadPool.maxQueueSize=-1 #超時(shí)時(shí)間?于我們的timeout接?返回時(shí)間

hystrix.command.userCommandKey.execution.isolation.thread.timeoutInMilliseconds=15000復(fù)制代碼

這個(gè)時(shí)候我們連續(xù)多次請求/user/command/timeout接?晰搀，在第?個(gè)請求還沒有成功返回時(shí)五辽，查看輸出?志可以發(fā)現(xiàn)只有第?個(gè)請求正常的進(jìn)?到user-service的接?中，其它請求會(huì)直接返回降級信息外恕。這樣我們就實(shí)現(xiàn)了對服務(wù)請求的限流杆逗。

2.漏桶算法：??（請求）先進(jìn)?到漏桶?，漏桶以?定的速度出?鳞疲，當(dāng)?流?速度過?會(huì)直接溢出罪郊，可以看出漏桶算法能強(qiáng)?限制數(shù)據(jù)的傳輸速率。

3.令牌桶算法：?除了要求能夠限制數(shù)據(jù)的平均傳輸速率外尚洽，還要求允許某種程度的突發(fā)傳輸悔橄。這時(shí)候漏桶算法可能就不合適了，令牌桶算法更為適合腺毫。?如圖所示癣疟，令牌桶算法的原理是系統(tǒng)會(huì)以?個(gè)恒定的速度往桶?放?令牌，?如果請求需要被處理潮酒，則需要先從桶?獲取?個(gè)令牌睛挚，當(dāng)桶?沒有令牌可取時(shí)，則拒絕服務(wù)澈灼。

4、redis計(jì)數(shù)器限流；

13. springcloud核?組件及其作?叁熔，以及springcloud?作原理：

springcloud由以下?個(gè)核?組件構(gòu)成：

Eureka：?各個(gè)服務(wù)啟動(dòng)時(shí)委乌，Eureka Client都會(huì)將服務(wù)注冊到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊表荣回，從?知道其他服務(wù)在哪?

Ribbon：?服務(wù)間發(fā)起請求的時(shí)候遭贸，基于Ribbon做負(fù)載均衡，從?個(gè)服務(wù)的多臺(tái)機(jī)器中選擇?臺(tái)

Feign：?基于Feign的動(dòng)態(tài)代理機(jī)制心软，根據(jù)注解和選擇的機(jī)器壕吹，拼接請求URL地址，發(fā)起請求

Hystrix：?發(fā)起請求是通過Hystrix的線程池來?的删铃，不同的服務(wù)?不同的線程池耳贬，實(shí)現(xiàn)了不同服務(wù)調(diào)?的隔離，避免了服務(wù)雪崩的問題

Zuul：?如果前端猎唁、移動(dòng)端要調(diào)?后端系統(tǒng)咒劲，統(tǒng)?從Zuul?關(guān)進(jìn)?，由Zuul?關(guān)轉(zhuǎn)發(fā)請求給對應(yīng)的服務(wù)

14. eureka的缺點(diǎn)：

某個(gè)服務(wù)不可?時(shí)诫隅，各個(gè)Eureka Client不能及時(shí)的知道腐魂，需要1~3個(gè)?跳周期才能感知，但是逐纬，由于基于Netflix的服務(wù)調(diào)?端都會(huì)使?Hystrix來容錯(cuò)和降級蛔屹，當(dāng)服務(wù)調(diào)?不可?時(shí)Hystrix也能及時(shí)感知到，通過熔斷機(jī)制來降級服務(wù)調(diào)?豁生，因此彌補(bǔ)了基于客戶端服務(wù)發(fā)現(xiàn)的時(shí)效性的缺點(diǎn)兔毒。

15. eureka緩存機(jī)制：

第?層緩存：?readOnlyCacheMap，本質(zhì)上是ConcurrentHashMap：這是?個(gè)JVM的CurrentHashMap只讀緩存沛硅，這個(gè)主要是為了供客戶端獲取注冊信息時(shí)使?眼刃，其緩存更新，依賴于定時(shí)器的更新摇肌，通過和readWriteCacheMap 的值做對?擂红，如果數(shù)據(jù)不?致，則以readWriteCacheMap 的數(shù)據(jù)為準(zhǔn)围小。readOnlyCacheMap 緩存更新的定時(shí)器時(shí)間間隔昵骤，默認(rèn)為30秒

第?層緩存：?readWriteCacheMap，本質(zhì)上是Guava緩存：此處存放的是最終的緩存肯适， 當(dāng)服務(wù)下線变秦，過期，注冊框舔，狀態(tài)變更蹦玫，都會(huì)來清除這個(gè)緩存??的數(shù)據(jù)赎婚。 然后通過CacheLoader進(jìn)?緩存加載，在進(jìn)?readWriteCacheMap.get(key)的時(shí)候樱溉，?先看這個(gè)緩存??有沒有該數(shù)據(jù)挣输，如果沒有則通過CacheLoader的load?法去加載，加載成功之后將數(shù)據(jù)放?緩存福贞，同時(shí)返回?cái)?shù)據(jù)撩嚼。 readWriteCacheMap 緩存過期時(shí)間，默認(rèn)為 180 秒 挖帘。

緩存機(jī)制：?設(shè)置了?個(gè)每30秒執(zhí)??次的定時(shí)任務(wù)完丽，定時(shí)去服務(wù)端獲取注冊信息。獲取之后拇舀，存?本地內(nèi)存逻族。

16. 熔斷的原理，以及如何恢復(fù)你稚？

a. 服務(wù)的健康狀況 = 請求失敗數(shù) / 請求總數(shù).

熔斷器開關(guān)由關(guān)閉到打開的狀態(tài)轉(zhuǎn)換是通過當(dāng)前服務(wù)健康狀況和設(shè)定閾值?較決定的.

當(dāng)熔斷器開關(guān)關(guān)閉時(shí), 請求被允許通過熔斷器. 如果當(dāng)前健康狀況?于設(shè)定閾值, 開關(guān)繼續(xù)保持關(guān)閉. 如果當(dāng)前健康狀況低于設(shè)定閾值, 開關(guān)則切換為打開狀態(tài).

當(dāng)熔斷器開關(guān)打開時(shí), 請求被禁?通過.

當(dāng)熔斷器開關(guān)處于打開狀態(tài), 經(jīng)過?段時(shí)間后, 熔斷器會(huì)?動(dòng)進(jìn)?半開狀態(tài), 這時(shí)熔斷器只允許?個(gè)請求通過. 當(dāng)該請求調(diào)?成功時(shí), 熔斷器恢復(fù)到關(guān)閉狀態(tài). 若該請求失敗, 熔斷器繼續(xù)保持打開狀態(tài), 接下來的請求被禁?通過.

熔斷器的開關(guān)能保證服務(wù)調(diào)?者在調(diào)?異常服務(wù)時(shí), 快速返回結(jié)果, 避免?量的同步等待. 并且熔斷器能在?段時(shí)間后繼續(xù)偵測請求執(zhí)?結(jié)果, 提供恢復(fù)服務(wù)調(diào)?的可能瓷耙。

17. 服務(wù)雪崩？

簡介：?服務(wù)雪崩效應(yīng)是?種因服務(wù)提供者的不可?導(dǎo)致服務(wù)調(diào)?者的不可?,并將不可?逐漸放?的過程.

形成原因：

服務(wù)提供者不可

重試加?流量

服務(wù)調(diào)?者不可?

采?策略：

流量控制

改進(jìn)緩存模式

服務(wù)?動(dòng)擴(kuò)容

服務(wù)調(diào)?者降級服務(wù)

18.?什么是 Hystrix 斷路器刁赖？我們需要它嗎搁痛？

由于某些原因，employee-consumer 公開服務(wù)會(huì)引發(fā)異常宇弛。在這種情況下使用 Hystrix 我們定義了一個(gè)回退方法鸡典。如果在公開服務(wù)中發(fā)生異常，則回退方法返回一些默認(rèn)值

中斷枪芒，并且員工使用者將一起跳過 firtsPage 方法彻况，并直接調(diào)用回退方法。 斷路器的目的是給第一頁方法或第一頁方法可能調(diào)用的其他方法留出時(shí)間舅踪，并導(dǎo)致異撑Ω剩恢復(fù)〕槁担可能發(fā)生的情況是悍赢，在負(fù)載較小的情況下，導(dǎo)致異常的問題有更好的恢復(fù)機(jī)會(huì) 货徙。

19. 多個(gè)消費(fèi)者調(diào)?同?接?左权，eruka默認(rèn)的分配?式是什么？

RoundRobinRule:輪詢策略痴颊，Ribbon以輪詢的?式選擇服務(wù)器赏迟，這個(gè)是默認(rèn)值。所以示例中所啟動(dòng)的兩個(gè)服務(wù)會(huì)被循環(huán)訪問;

RandomRule:隨機(jī)選擇蠢棱，也就是說Ribbon會(huì)隨機(jī)從服務(wù)器列表中選擇?個(gè)進(jìn)?訪問;

BestAvailableRule:最?可?策略锌杀，即先過濾出故障服務(wù)器后甩栈，選擇?個(gè)當(dāng)前并發(fā)請求數(shù)最?的;

WeightedResponseTimeRule:帶有加權(quán)的輪詢策略，對各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)?加權(quán)處理糕再，然后在采?輪詢的?式來獲取相應(yīng)的服務(wù)器;

AvailabilityFilteringRule:可?過濾策略谤职，先過濾出故障的或并發(fā)請求?于閾值?部分服務(wù)實(shí)例，然后再以線性輪詢的?式從過濾后的實(shí)例清單中選出?個(gè);

ZoneAvoidanceRule:區(qū)域感知策略亿鲜，先使?主過濾條件（區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域）對所有實(shí)例過濾并返回過濾后的實(shí)例清單冤吨，依次使?次過濾條件列表中的過濾條件對主過濾條件的結(jié)果進(jìn)?過濾蒿柳，判斷最?過濾數(shù)（默認(rèn)1）和最?過濾百分?（默認(rèn)0），最后對滿?條件的服務(wù)器則使?RoundRobinRule(輪詢?式)選擇?個(gè)服務(wù)器實(shí)例漩蟆。

20. 接?限流?法垒探？

限制 總并發(fā)數(shù)（?如 數(shù)據(jù)庫連接池、線程池）

限制 瞬時(shí)并發(fā)數(shù)（如 nginx 的 limit_conn 模塊怠李，?來限制 瞬時(shí)并發(fā)連接數(shù)）

限制 時(shí)間窗?內(nèi)的平均速率（如 Guava 的 RateLimiter圾叼、nginx 的 limit_req模塊，限制每秒的平均速率）

限制 遠(yuǎn)程接? 調(diào)?速率

限制 MQ 的消費(fèi)速率

可以根據(jù)?絡(luò)連接數(shù)捺癞、?絡(luò)流量夷蚊、CPU或內(nèi)存負(fù)載等來限流

喜歡這篇文章的可以給筆者點(diǎn)個(gè)贊，關(guān)注一下髓介，每天都會(huì)分享Java相關(guān)文章惕鼓！還有不定時(shí)的福利贈(zèng)送，包括整理的學(xué)習(xí)資料唐础，面試題箱歧，源碼等~