點(diǎn)贊再看，養(yǎng)成習(xí)慣，微信搜一搜 【碼農(nóng)清風(fēng)】 共勉進(jìn)階之路！
本文 GitHub https://github.com/ThinkingHan/Java-review-gudie 已收錄， 有一線大廠面試完整考點(diǎn)、資料以及我的學(xué)習(xí)筆記。
前言
來分享一下面試必備的Spring Cloud問題解析！用XMind畫了一張導(dǎo)圖記錄Spring Cloud的學(xué)習(xí)筆記和一些面試解析（源文件對(duì)部分節(jié)點(diǎn)有詳細(xì)備注和參考資料，已經(jīng)完善更新）：
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ò)展、升級(jí)和可替換）。
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)下，注冊(cè)中?對(duì)等集群，并會(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ù)使用的。所以，對(duì)于類似于電商等同步調(diào)?場(chǎng)景多并且能?撐搭建Dubbo 這套?較復(fù)雜環(huán)境的成本的產(chǎn)品??，Dubbo 確實(shí)是一個(gè)可以考慮的選擇。但如果產(chǎn)品業(yè)務(wù)中由于后臺(tái)業(yè)務(wù)邏輯復(fù)雜、時(shí)間??導(dǎo)致異步邏輯?較多的話，可能Dubbo 并不合適。同時(shí)，對(duì)于??不?的初創(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)?配置中?，對(duì)配置進(jìn)?統(tǒng)?管理；使?Spring Cloud Netflix 可以實(shí)現(xiàn)Netflix 組件的功能 - 服務(wù)發(fā)現(xiàn)（Eureka）、智能路由（Zuul）、客戶端負(fù)載均衡（Ribbon）。
Dubbo 提供了各種 Filter，對(duì)于上述中“?”的要素，可以通過擴(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ù)降級(jí)
服務(wù)熔斷：
如果檢查出來頻繁超時(shí)，就把consumer調(diào)?provider的請(qǐng)求，直接短路掉，不實(shí)際調(diào)?，?是直接返回?個(gè)mock的值。
服務(wù)降級(jí)：
consumer 端：consumer 如果發(fā)現(xiàn)某個(gè)provider出現(xiàn)異常情況，?如，經(jīng)常超時(shí)(可能是熔斷引起的降級(jí))，數(shù)據(jù)錯(cuò)誤，這時(shí)，consumer可以采取?定的策略，降級(jí)provider的邏輯，基本的有直接返回固定的數(shù)據(jù)。
provider 端：當(dāng)provider 發(fā)現(xiàn)流量激增的時(shí)候，為了保護(hù)?身的穩(wěn)定性，也可能考慮降級(jí)服務(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ú)?部署、升級(jí)，服務(wù)與服務(wù)之間通過REST等形式的標(biāo)準(zhǔn)接?進(jìn)?通信，并且?個(gè)微服務(wù)實(shí)例可以被替換成另?種實(shí)現(xiàn)，?對(duì)其它的微服務(wù)不產(chǎn)?影響。
邏輯清晰：微服務(wù)單?職責(zé)特性使微服務(wù)看起來邏輯清晰，易于維護(hù)。
簡(jiǎn)化部署：?jiǎn)蜗到y(tǒng)中修改?處需要部署整個(gè)系統(tǒng)，?微服務(wù)中修改?處可單獨(dú)部署?個(gè)服務(wù)
可擴(kuò)展：應(yīng)對(duì)系統(tǒng)業(yè)務(wù)增長(zhǎng)的?法通常采用橫向（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ù)雜；對(duì)于微服務(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)對(duì)各個(gè)微服務(wù)的運(yùn)?狀態(tài)進(jìn)?監(jiān)控。運(yùn)維?員需要對(duì)系統(tǒng)有細(xì)致的了解才對(duì)夠更好的運(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ù)注冊(cè)發(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ù)的注冊(cè)與發(fā)現(xiàn)功能，他們的區(qū)別
Zookeeper保證CP
當(dāng)向注冊(cè)中?查詢服務(wù)列表時(shí)，我們可以容忍注冊(cè)中?返回的是?分鐘以前的注冊(cè)信息，但不能接受服務(wù)直接down掉不可?。也就是說，服務(wù)注冊(cè)功能對(duì)可?性的要求要?于?致性。但是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)致在選舉期間注冊(cè)服務(wù)癱瘓。在云部署的環(huán)境下，因?絡(luò)問題使得zk集群失去master節(jié)點(diǎn)是較?概率會(huì)發(fā)?的事，雖然服務(wù)能夠最終恢復(fù)，但是漫?的選舉時(shí)間導(dǎo)致的注冊(cè)?期不可?是不能容忍的。
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)依然可以提供注冊(cè)和查詢服務(wù)。?Eureka的客戶端在向某個(gè)Eureka注冊(cè)或如果發(fā)現(xiàn)連接失敗，則會(huì)?動(dòng)切換?其它節(jié)點(diǎn)，只要有?臺(tái)Eureka還在，就能保證注冊(cè)服務(wù)可?(保證可?性)，只不過查到的信息可能不是最新的(不保證強(qiáng)?致性)。除此之外，Eureka還有?種?我保護(hù)機(jī)制，如果在15分鐘內(nèi)超過85%的節(jié)點(diǎn)都沒有正常的?跳，那么Eureka就認(rèn)為客戶端與注冊(cè)中?出現(xiàn)了?絡(luò)故障，此時(shí)會(huì)出現(xiàn)以下?種情況：
Eureka不再?gòu)淖?cè)列表中移除因?yàn)?時(shí)間沒收到?跳?應(yīng)該過期的服務(wù)
Eureka仍然能夠接受新服務(wù)的注冊(cè)和查詢請(qǐng)求，但是不會(huì)被同步到其它節(jié)點(diǎn)上(即保證當(dāng)前節(jié)點(diǎn)依然可?)
當(dāng)?絡(luò)穩(wěn)定時(shí)，當(dāng)前實(shí)例新的注冊(cè)信息會(huì)被同步到其它節(jié)點(diǎn)中
因此， Eureka可以很好的應(yīng)對(duì)因?絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，?不會(huì)像zookeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。
10. eureka服務(wù)注冊(cè)與發(fā)現(xiàn)原理
每30s發(fā)送?跳檢測(cè)重新進(jìn)?租約，如果客戶端不能多次更新租約，它將在90s內(nèi)從服務(wù)器注冊(cè)中?移除。
注冊(cè)信息和更新會(huì)被復(fù)制到其他Eureka 節(jié)點(diǎn)，來?任何區(qū)域的客戶端可以查找到注冊(cè)中?信息，每30s發(fā)??次復(fù)制來定位他們的服務(wù)，并進(jìn)?遠(yuǎn)程調(diào)?。
客戶端還可以緩存?些服務(wù)實(shí)例信息，所以即使Eureka全掛掉，客戶端也是可以定位到服務(wù)地址的。
11. dubbo服務(wù)注冊(cè)與發(fā)現(xiàn)原理
調(diào)?關(guān)系說明：
服務(wù)容器負(fù)責(zé)啟動(dòng),加載,運(yùn)?服務(wù)提供者。
服務(wù)提供者在啟動(dòng)時(shí),向注冊(cè)中?注冊(cè)??提供的服務(wù)。
服務(wù)消費(fèi)者在啟動(dòng)時(shí),向注冊(cè)中?訂閱??所需的服務(wù)。
注冊(cè)中?返回服務(wù)提供者地址列表給消費(fèi)者,如果有變更,注冊(cè)中?將基于?連接推送變更數(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è)請(qǐng)求
limit_req_zone $binary_remote_addr zone=req_one:10m rate=1r/s; //這邊burst表示可以瞬間超過20個(gè)請(qǐng)求 由于沒有noDelay參數(shù)因此需要排隊(duì) 如果超過這20個(gè)那么直接返回503
limit_req zone=req_three burst=20;
2、dubbo限流：dubbo提供了多個(gè)和請(qǐng)求相關(guān)的filter：ActiveLimitFilter ExecuteLimitFilter TPSLimiterFilter
1. ActiveLimitFilter：
@Activate(group = Constants.CONSUMER, value = Constants.ACTIVES_KEY)
作?于客戶端，主要作?是控制客戶端?法的并發(fā)度；
當(dāng)超過了指定的active值之后該請(qǐng)求將等待前?的請(qǐng)求完成【何時(shí)結(jié)束呢？依賴于該?法的timeout 如果沒有設(shè)置timeout的話可能就是多個(gè)請(qǐng)求?直被阻塞然后等待隨機(jī)喚醒。
2. ExecuteLimitFilter：
@Activate(group = Constants.PROVIDER, value = Constants.EXECUTES_KEY)
作?于服務(wù)端，?旦超出指定的數(shù)?直接報(bào)錯(cuò) 其實(shí)是指在服務(wù)端的并?度【需要注意這些都是指的是在單臺(tái)服務(wù)上?不是整個(gè)服務(wù)集群】
3. TPSLimiterFilter：
@Activate(group = Constants.PROVIDER, value = Constants.TPS_LIMIT_RATE_KEY)
- 作?于服務(wù)端，控制?段時(shí)間內(nèi)的請(qǐng)求數(shù)；
- 默認(rèn)情況下取得tps.interval字段表示請(qǐng)求間隔 如果?法找到則使?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ū)降級(jí)閾值。
#不設(shè)置緩沖區(qū)，當(dāng)請(qǐng)求數(shù)超過coreSize時(shí)直接降級(jí)
hystrix.threadpool.userThreadPool.maxQueueSize=-1 #超時(shí)時(shí)間?于我們的timeout接?返回時(shí)間
hystrix.command.userCommandKey.execution.isolation.thread.timeoutInMilliseconds=15000
這個(gè)時(shí)候我們連續(xù)多次請(qǐng)求/user/command/timeout接?，在第?個(gè)請(qǐng)求還沒有成功返回時(shí)，查看輸出?志可以發(fā)現(xiàn)只有第?個(gè)請(qǐng)求正常的進(jìn)?到user-service的接?中，其它請(qǐng)求會(huì)直接返回降級(jí)信息。這樣我們就實(shí)現(xiàn)了對(duì)服務(wù)請(qǐng)求的限流。
2.漏桶算法： ?（請(qǐng)求）先進(jìn)?到漏桶?，漏桶以?定的速度出?，當(dāng)?流?速度過?會(huì)直接溢出，可以看出漏桶算法能強(qiáng)?限制數(shù)據(jù)的傳輸速率。
3.令牌桶算法：除了要求能夠限制數(shù)據(jù)的平均傳輸速率外，還要求允許某種程度的突發(fā)傳輸。這時(shí)候漏桶算法可能就不合適了，令牌桶算法更為適合。如圖所示，令牌桶算法的原理是系統(tǒng)會(huì)以?個(gè)恒定的速度往桶?放?令牌，?如果請(qǐng)求需要被處理，則需要先從桶?獲取?個(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ù)注冊(cè)到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊(cè)表，從?知道其他服務(wù)在哪?
Ribbon：服務(wù)間發(fā)起請(qǐng)求的時(shí)候，基于Ribbon做負(fù)載均衡，從?個(gè)服務(wù)的多臺(tái)機(jī)器中選擇?臺(tái)
Feign：基于Feign的動(dòng)態(tài)代理機(jī)制，根據(jù)注解和選擇的機(jī)器，拼接請(qǐng)求URL地址，發(fā)起請(qǐng)求
Hystrix：發(fā)起請(qǐng)求是通過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ā)請(qǐng)求給對(duì)應(yīng)的服務(wù)
14. eureka的缺點(diǎn)：
某個(gè)服務(wù)不可?時(shí)，各個(gè)Eureka Client不能及時(shí)的知道，需要1~3個(gè)?跳周期才能感知，但是，由于基于Netflix的服務(wù)調(diào)?端都會(huì)使?Hystrix來容錯(cuò)和降級(jí)，當(dāng)服務(wù)調(diào)?不可?時(shí)Hystrix也能及時(shí)感知到，通過熔斷機(jī)制來降級(jí)服務(wù)調(diào)?，因此彌補(bǔ)了基于客戶端服務(wù)發(fā)現(xiàn)的時(shí)效性的缺點(diǎn)。
15. eureka緩存機(jī)制：
第?層緩存：readOnlyCacheMap，本質(zhì)上是ConcurrentHashMap：這是?個(gè)JVM的CurrentHashMap只讀緩存，這個(gè)主要是為了供客戶端獲取注冊(cè)信息時(shí)使?，其緩存更新，依賴于定時(shí)器的更新，通過和readWriteCacheMap 的值做對(duì)?，如果數(shù)據(jù)不?致，則以readWriteCacheMap 的數(shù)據(jù)為準(zhǔn)。readOnlyCacheMap 緩存更新的定時(shí)器時(shí)間間隔，默認(rèn)為30秒
第?層緩存：readWriteCacheMap，本質(zhì)上是Guava緩存：此處存放的是最終的緩存， 當(dāng)服務(wù)下線，過期，注冊(cè)，狀態(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ù)端獲取注冊(cè)信息。獲取之后，存?本地內(nèi)存。
16. 熔斷的原理，以及如何恢復(fù)？
a. 服務(wù)的健康狀況 = 請(qǐng)求失敗數(shù) / 請(qǐng)求總數(shù).
熔斷器開關(guān)由關(guān)閉到打開的狀態(tài)轉(zhuǎn)換是通過當(dāng)前服務(wù)健康狀況和設(shè)定閾值?較決定的.
當(dāng)熔斷器開關(guān)關(guān)閉時(shí), 請(qǐng)求被允許通過熔斷器. 如果當(dāng)前健康狀況?于設(shè)定閾值, 開關(guān)繼續(xù)保持關(guān)閉. 如果當(dāng)前健康狀況低于設(shè)定閾值, 開關(guān)則切換為打開狀態(tài).
當(dāng)熔斷器開關(guān)打開時(shí), 請(qǐng)求被禁?通過.
當(dāng)熔斷器開關(guān)處于打開狀態(tài), 經(jīng)過?段時(shí)間后, 熔斷器會(huì)?動(dòng)進(jìn)?半開狀態(tài), 這時(shí)熔斷器只允許?個(gè)請(qǐng)求通過. 當(dāng)該請(qǐng)求調(diào)?成功時(shí), 熔斷器恢復(fù)到關(guān)閉狀態(tài). 若該請(qǐng)求失敗, 熔斷器繼續(xù)保持打開狀態(tài), 接下來的請(qǐng)求被禁?通過.
熔斷器的開關(guān)能保證服務(wù)調(diào)?者在調(diào)?異常服務(wù)時(shí), 快速返回結(jié)果, 避免?量的同步等待. 并且熔斷器能在?段時(shí)間后繼續(xù)偵測(cè)請(qǐng)求執(zhí)?結(jié)果, 提供恢復(fù)服務(wù)調(diào)?的可能。
17. 服務(wù)雪崩？
簡(jiǎn)介：服務(wù)雪崩效應(yīng)是?種因服務(wù)提供者的不可?導(dǎo)致服務(wù)調(diào)?者的不可?,并將不可?逐漸放?的過程.
形成原因：
服務(wù)提供者不可
重試加?流量
服務(wù)調(diào)?者不可?
采?策略：
流量控制
改進(jìn)緩存模式
服務(wù)?動(dòng)擴(kuò)容
服務(wù)調(diào)?者降級(jí)服務(wù)
18. 什么是 Hystrix 斷路器？我們需要它嗎？
由于某些原因，employee-consumer 公開服務(wù)會(huì)引發(fā)異常。在這種情況下使用 Hystrix 我們定義了一個(gè)回退方法。如果在公開服務(wù)中發(fā)生異常，則回退方法返回一些默認(rèn)值
中斷，并且員工使用者將一起跳過 firtsPage 方法，并直接調(diào)用回退方法。 斷路器的目的是給第一頁方法或第一頁方法可能調(diào)用的其他方法留出時(shí)間，并導(dǎo)致異?；謴?fù)?？赡馨l(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ā)請(qǐng)求數(shù)最?的;
WeightedResponseTimeRule:帶有加權(quán)的輪詢策略，對(duì)各個(gè)服務(wù)器響應(yīng)時(shí)間進(jìn)?加權(quán)處理，然后在采?輪詢的?式來獲取相應(yīng)的服務(wù)器;
AvailabilityFilteringRule:可?過濾策略，先過濾出故障的或并發(fā)請(qǐng)求?于閾值?部分服務(wù)實(shí)例，然后再以線性輪詢的?式從過濾后的實(shí)例清單中選出?個(gè);
ZoneAvoidanceRule:區(qū)域感知策略，先使?主過濾條件（區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域）對(duì)所有實(shí)例過濾并返回過濾后的實(shí)例清單，依次使?次過濾條件列表中的過濾條件對(duì)主過濾條件的結(jié)果進(jìn)?過濾，判斷最?過濾數(shù)（默認(rèn)1）和最?過濾百分?（默認(rèn)0），最后對(duì)滿?條件的服務(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ù)載等來限流
最后
本文 GitHub https://github.com/ThinkingHan/Java-review-gudie 已收錄， 有一線大廠面試完整考點(diǎn)、資料以及我的學(xué)習(xí)筆記。
我是清風(fēng)，感謝大佬們的閱讀，同時(shí)感謝各位大佬的：點(diǎn)贊、收藏和評(píng)論支持！
