一、SpringCloud常見組件有哪些？
1.1 問題說明
這個題目主要考察對SpringCloud的組件基本了解
1.2 難易程度
簡單
1.3 參考話術(shù)
SpringCloud包含的組件很多，有很多功能是重復的。
其中最常用組件包括：
注冊中心組件：Eureka、Nacos等
負載均衡組件：Ribbon
遠程調(diào)用組件：OpenFeign
網(wǎng)關(guān)組件：Zuul、Gateway
服務保護組件：Hystrix、Sentinel
服務配置管理組件：SpringCloudConfig、Nacos
二、Nacos的服務注冊表結(jié)構(gòu)是怎樣的？
2.1 問題解析
要了解Nacos的服務注冊表結(jié)構(gòu)，需要從兩方面入手：
一是Nacos的分級存儲模型
二是Nacos的服務端源碼
2.2?問題說明
考察對Nacos數(shù)據(jù)分級結(jié)構(gòu)的了解，以及Nacos源碼的掌握情況
2.3 難易程度
一般
2.4 參考話術(shù)
Nacos采用了數(shù)據(jù)的分級存儲模型。
最外層是Namespace，用來隔離環(huán)境。
然后是Group，用來對服務分組。
接下來就是服務（Service）了，一個服務包含多個實例，但是可能處于不同機房，因此Service下有多個集群（Cluster），Cluster下是不同的實例（Instance）。
對應到Java代碼中，Nacos采用了一個多層的Map來表示。結(jié)構(gòu)為Map<String, Map<String, Service>>，其中最外層Map的key就是namespaceId，值是一個Map。內(nèi)層Map的key是group拼接serviceName，值是Service對象。
Service對象內(nèi)部又是一個Map，key是集群名稱，值是Cluster對象。而Cluster對象內(nèi)部維護了Instance的集合。
三、Nacos如何支撐數(shù)十萬服務注冊壓力？
3.1 問題說明
考察對Nacos源碼的掌握情況
3.2 難易程度
難
3.3 參考話術(shù)
Nacos內(nèi)部接收到注冊的請求時，不會立即寫數(shù)據(jù)，而是將服務注冊的任務放入一個阻塞隊列就立即響應給客戶端。然后利用線程池讀取阻塞隊列中的任務，異步來完成實例更新，從而提高并發(fā)寫能力。
四、Nacos如何避免并發(fā)讀寫沖突問題？
4.1 問題說明
考察對Nacos源碼的掌握情況
4.2 難易程度
難
4.3 參考話術(shù)
Nacos在更新實例列表時，會采用CopyOnWrite技術(shù)，首先將舊的實例列表拷貝一份，然后更新拷貝的實例列表，再用更新后的實例列表來覆蓋舊的實例列表。
這樣在更新的過程中，就不會對讀實例列表的請求產(chǎn)生影響，也不會出現(xiàn)臟讀問題了。
五、Nacos與Eureka的區(qū)別有哪些？
5.1 問題說明
考察對Nacos、Eureka的底層實現(xiàn)的掌握情況
5.2 難易程度
難
5.3 參考話術(shù)
Nacos與Eureka有相同點，也有不同之處，可以從以下幾點來描述：
接口方式：Nacos與Eureka都對外暴露了Rest風格的API接口，用來實現(xiàn)服務注冊、發(fā)現(xiàn)等功能
實例類型：Nacos的實例有永久和臨時實例之分；而Eureka只支持臨時實例
健康檢測：Nacos對臨時實例采用心跳模式檢測，對永久實例采用主動請求來檢測；Eureka只支持心跳模式
服務發(fā)現(xiàn)：Nacos支持定時拉取和訂閱推送兩種模式；Eureka只支持定時拉取模式
六、Sentinel的限流與Gateway的限流有什么差別？
6.1 問題說明
考察對線程隔離方案的掌握情況
6.2 難易程度
一般
6.3 參考話術(shù)
Hystix默認是基于線程池實現(xiàn)的線程隔離，每一個被隔離的業(yè)務都要創(chuàng)建一個獨立的線程池，線程過多會帶來額外的CPU開銷，性能一般，但是隔離性更強。
Sentinel是基于信號量（計數(shù)器）實現(xiàn)的線程隔離，不用創(chuàng)建線程池，性能較好，但是隔離性一般。
七、Sentinel的線程隔離與Hystix的線程隔離有什么差別?
?7.1 問題解析
限流：對應用服務器的請求做限制，避免因過多請求而導致服務器過載甚至宕機。
限流算法常見的包括兩種：
- 計數(shù)器算法，又包括窗口計數(shù)器算法、滑動窗口計數(shù)器算法
- 令牌桶算法（Token Bucket）
- 漏桶算法（Leaky Bucket)
?7.1.1 固定窗口計數(shù)器算法
- 將時間劃分為多個窗口，窗口時間跨度稱為Interval，本例中為1000ms；
- 每個窗口維護一個計數(shù)器，每有一次請求就將計數(shù)器加一，限流就是設置計數(shù)器閾值，本例為3
- 如果計數(shù)器超過了限流閾值，則超出閾值的請求都被丟棄。
?
?7.1.2 滑動窗口計數(shù)器算法
滑動窗口計數(shù)器算法會將一個窗口劃分為n個更小的區(qū)間，例如
- 窗口時間跨度Interval為1秒；區(qū)間數(shù)量 n = 2 ，則每個小區(qū)間時間跨度為500ms
- 限流閾值依然為3，時間窗口（1秒）內(nèi)請求超過閾值時，超出的請求被限流
- 窗口會根據(jù)當前請求所在時間（currentTime）移動，窗口范圍是從（currentTime-Interval）之后的第一個時區(qū)開始，到currentTime所在時區(qū)結(jié)束。
7.1.3 令牌桶算法
令牌桶算法說明：
- 以固定的速率生成令牌，存入令牌桶中，如果令牌桶滿了以后，多余令牌丟棄
- 請求進入后，必須先嘗試從桶中獲取令牌，獲取到令牌后才可以被處理
- 如果令牌桶中沒有令牌，則請求等待或丟棄
?
?7.1.4?漏桶算法?
漏桶算法說明：
- 將每個請求視作"水滴"放入"漏桶"進行存儲；
- "漏桶"以固定速率向外"漏"出請求來執(zhí)行，如果"漏桶"空了則停止"漏水”；
- 如果"漏桶"滿了則多余的"水滴"會被直接丟棄，可以理解成請求在桶內(nèi)排隊等待
Sentinel在實現(xiàn)漏桶時，采用了排隊等待模式：
讓所有請求進入一個隊列中，然后按照閾值允許的時間間隔依次執(zhí)行。并發(fā)的多個請求必須等待，預期的等待時長 = 最近一次請求的預期等待時間 + ?允許的間隔。
如果請求預期的等待時間超出最大時長，則會被拒絕。
例如：
QPS = 5，意味著每200ms處理一個隊列中的請求；
timeout = 2000，意味著預期等待超過2000ms的請求會被拒絕并拋出異常
?7.1.5?限流算法對比
7.2 問題說明
考察對限流算法的掌握情況
7.3 難易程度
難
7.4 參考話術(shù)
限流算法常見的有三種實現(xiàn)：
滑動時間窗口、令牌桶算法、漏桶算法。
Gateway則采用了基于Redis實現(xiàn)的令牌桶算法。文章來源：http://www.zghlxwxcb.cn/news/detail-830368.html
而Sentinel內(nèi)部卻比較復雜：文章來源地址http://www.zghlxwxcb.cn/news/detail-830368.html
- 默認限流模式是基于滑動時間窗口算法
- 排隊等待的限流模式則基于漏桶算法
- 而熱點參數(shù)限流則是基于令牌桶算法
到了這里，關(guān)于微服務常見面試題解析、問題說明及參考話術(shù)，實用干貨的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
