微服務面試題#
** 面試官：**Spring Cloud 5 大組件有哪些？
候選人：
早期我們一般認為的 Spring Cloud 五大組件是
- Eureka : 註冊中心
- Ribbon : 負載均衡
- Feign : 遠程調用
- Hystrix : 服務熔斷
- Zuul/Gateway : 網關
隨著 SpringCloudAlibba 在國內興起，我們項目中使用了一些阿里巴巴的組件
註冊中心 / 配置中心 Nacos
負載均衡 Ribbon
服務調用 Feign
服務保護 sentinel
服務網關 Gateway
** 面試官：** 服務註冊和發現是什麼意思？Spring Cloud 如何實現服務註冊發現？
候選人：
我理解的是主要三塊大功能，分別是服務註冊 、服務發現、服務狀態監控
我們當時項目採用的 eureka 作為註冊中心，這個也是 spring cloud 體系中的一個核心組件
服務註冊：服務提供者需要把自己的信息註冊到 eureka，由 eureka 來保存這些信息，比如服務名稱、ip、端口等等
服務發現：消費者向 eureka 拉取服務列表信息，如果服務提供者有集群，則消費者會利用負載均衡算法，選擇一個發起調用
服務監控：服務提供者會每隔 30 秒向 eureka 發送心跳，報告健康狀態，如果 eureka 服務 90 秒沒接收到心跳，從 eureka 中剔除
** 面試官：** 我看你之前也用過 nacos、你能說下 nacos 與 eureka 的區別？
候選人：
我們當時 xx 項目就是採用的 nacos 作為註冊中心，選擇 nacos 還要一個重要原因就是它支持配置中心，不過 nacos 作為註冊中心，也比 eureka 要方便好用一些，主要相同不同點在於幾點：
- 共同點
Nacos 與 eureka 都支持服務註冊和服務拉取，都支持服務提供者心跳方式做健康檢測
- Nacos 與 Eureka 的區別
①Nacos 支持服務端主動檢測提供者狀態：臨時實例採用心跳模式，非臨時實例採用主動檢測模式
②臨時實例心跳不正常會被剔除，非臨時實例則不會被剔除
③Nacos 支持服務列表變更的消息推送模式，服務列表更新更及時
④Nacos 集群默認採用 AP 方式，當集群中存在非臨時實例時，採用 CP 模式；Eureka 採用 AP 方式
** 面試官：** 你們項目負載均衡如何實現的？
候選人：
是這樣～～
在服務調用過程中的負載均衡一般使用 SpringCloud 的 Ribbon 組件實現，Feign 的底層已經自動集成了 Ribbon , 使用起來非常簡單
當發起遠程調用時，ribbon 先從註冊中心拉取服務地址列表，然後按照一定的路由策略選擇一個發起遠程調用，一般的調用策略是輪詢
** 面試官：**Ribbon 負載均衡策略有哪些？
候選人：
我想想啊，有很多種，我記得幾個：
RoundRobinRule：簡單輪詢服務列表來選擇伺服器
WeightedResponseTimeRule：按照權重來選擇伺服器，響應時間越長，權重越小
RandomRule：隨機選擇一個可用的伺服器
ZoneAvoidanceRule：區域敏感策略，以區域可用的伺服器為基礎進行伺服器的選擇。使用 Zone 對伺服器進行分類，這個 Zone 可以理解為一個機房、一個機架等。而後再對 Zone 內的多個服務做輪詢 (默認)
** 面試官：** 如果想自定義負載均衡策略如何實現？
候選人：
提供了兩種方式：
1，創建類實現 IRule 接口，可以指定負載均衡策略，這個是全局的，對所有的遠程調用都起作用
2，在客戶端的配置文件中，可以配置某一個服務調用的負載均衡策略，只是對配置的這個服務生效遠程調用
** 面試官：** 什麼是服務雪崩，怎麼解決這個問題？
候選人：
服務雪崩是指一個服務失敗，導致整條鏈路的服務都失敗的情形，一般我們在項目解決的話就是兩種方案，第一個是服務降級，第二個是服務熔斷，如果流量太大的話，可以考慮限流
服務降級：服務自我保護的一種方式，或者保護下游服務的一種方式，用於確保服務不會受請求突增影響變得不可用，確保服務不會崩潰，一般在實際開發中與 feign 接口整合，編寫降級邏輯
服務熔斷：默認關閉，需要手動打開，如果檢測到 10 秒內請求的失敗率超過 50%，就觸發熔斷機制。之後每隔 5 秒重新嘗試請求微服務，如果微服務不能響應，繼續走熔斷機制。如果微服務可達，則關閉熔斷機制，恢復正常請求
** 面試官：** 你們的微服務是怎麼監控的？
候選人：
我們項目中採用的 skywalking 進行監控的
1，skywalking 主要可以監控接口、服務、物理實例的一些狀態。特別是在壓測的時候可以看到眾多服務中哪些服務和接口比較慢，我們可以針對性的分析和優化。
2，我們還在 skywalking 設置了告警規則，特別是在項目上線以後，如果報錯，我們分別設置了可以給相關負責人發短信和發郵件，第一時間知道項目的 bug 情況，第一時間修復
** 面試官：** 你們項目中有沒有做過限流？怎麼做的？
候選人：
我當時做的 xx 項目，採用就是微服務的架構，因為 xx 因為，應該會有突發流量，最大 QPS 可以達到 2000，但是服務支撐不住，我們項目都通過壓測最多可以支撐 1200QPS。因為我們平時的 QPS 也就不到 100，為了解決這些突發流量，所以採用了限流。
【版本 1】
我們當時採用的 nginx 限流操作，nginx 使用的漏桶算法來實現過濾，讓請求以固定的速率處理請求，可以應對突發流量，我們控制的速率是按照 ip 進行限流，限制的流量是每秒 20
【版本 2】
我們當時採用的是 spring cloud gateway 中支持局部過濾器 RequestRateLimiter 來做限流，使用的是令牌桶算法，可以根據 ip 或路徑進行限流，可以設置每秒填充平均速率，和令牌桶總容量
** 面試官：** 限流常見的算法有哪些呢？
候選人：
比較常見的限流算法有漏桶算法和令牌桶算法
漏桶算法是把請求存入到桶中，以固定速率從桶中流出，可以讓我們的服務做到絕對的平均，起到很好的限流效果
令牌桶算法在桶中存儲的是令牌，按照一定的速率生成令牌，每個請求都要先申請令牌，申請到令牌以後才能正常請求，也可以起到很好的限流作用
它們的區別是，漏桶和令牌桶都可以處理突發流量，其中漏桶可以做到絕對的平滑，令牌桶有可能會產生突發大量請求的情況，一般 nginx 限流採用的漏桶，spring cloud gateway 中可以支持令牌桶算法
面試官：什麼是 CAP 理論？
候選人：
CAP 主要是在分佈式項目下的一個理論。包含了三項，一致性、可用性、分區容錯性
一致性 (Consistency) 是指更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致 (強一致性)，不能存在中間狀態。
可用性 (Availability) 是指系統提供的服務必須一直處於可用的狀態，對於用戶的每一個操作請求總是能夠在有限的時間內返回結果。
分區容錯性 (Partition tolerance) 是指分佈式系統在遇到任何網絡分區故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務，除非是整個網絡環境都發生了故障。
面試官：為什麼分佈式系統中無法同時保證一致性和可用性？
候選人：
嗯，是這樣～～
首先一個前提，對於分佈式系統而言，分區容錯性是一個最基本的要求，因此基本上我們在設計分佈式系統的時候只能從一致性（C）和可用性（A）之間進行取舍。
如果保證了一致性（C）：對於節點 N1 和 N2，當往 N1 裡寫數據時，N2 上的操作必須被暫停，只有當 N1 同步數據到 N2 時才能對 N2 進行讀寫請求，在 N2 被暫停操作期間客戶端提交的請求會收到失敗或超時。顯然，這與可用性是相悖的。
如果保證了可用性（A）：那就不能暫停 N2 的讀寫操作，但同時 N1 在寫數據的話，這就違背了一致性的要求。
面試官：什麼是 BASE 理論？
候選人：
嗯，這個也是 CAP 分佈式系統設計理論
BASE 是 CAP 理論中 AP 方案的延伸，核心思想是即使無法做到強一致性（StrongConsistency，CAP 的一致性就是強一致性），但應用可以採用適合的方式達到最終一致性（Eventual Consitency）。它的思想包含三方面：
1、Basically Available（基本可用）：基本可用是指分佈式系統在出現不可預知的故障的時候，允許損失部分可用性，但不等於系統不可用。
2、Soft state（軟狀態）：即是指允許系統中的數據存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
3、Eventually consistent（最終一致性）：強調系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。其本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
** 面試官：** 你們採用哪種分佈式事務解決方案？
候選人：
我們當時是 xx 項目，主要使用到的 seata 的 at 模式解決的分佈式事務
seata 的 AT 模型分為兩個階段：
1、階段一 RM 的工作：① 註冊分支事務 ② 記錄 undo-log（數據快照）③ 執行業務 sql 並提交 ④報告事務狀態
2、階段二提交時 RM 的工作：刪除 undo-log 即可
3、階段二回滾時 RM 的工作：根據 undo-log 恢復數據到更新前
at 模式犧牲了一致性，保證了可用性，不過，它保證的是最終一致性
** 面試官：** 分佈式服務的接口幂等性如何設計？
候選人：
嗯，我們當時有一個 xx 項目的下單操作，採用的 token+redis 實現的，流程是這樣的
第一次請求，也就是用戶打開了商品詳情頁面，我們會發起一個請求，在後台生成一個唯一 token 存入 redis，key 就是用戶的 id，value 就是這個 token，同時把這個 token 返回前端
第二次請求，當用戶點擊了下單操作會後，會攜帶之前的 token，後台先到 redis 進行驗證，如果存在 token，可以執行業務，同時刪除 token；如果不存在，則直接返回，不處理業務，就保證了同一個 token 只處理一次業務，就保證了幂等性
** 面試官：**xxl-job 路由策略有哪些？
候選人：
xxl-job 提供了很多的路由策略，我們平時用的較多就是：輪詢、故障轉移、分片廣播…
** 面試官：**xxl-job 任務執行失敗怎麼解決？
候選人：
有這麼幾個操作
第一：路由策略選擇故障轉移，優先使用健康的實例來執行任務
第二，如果還有失敗的，我們在創建任務時，可以設置重試次數
第三，如果還有失敗的，就可以查看日誌或者配置郵件告警來通知相關負責人解決
** 面試官：** 如果有大數據量的任務同時都需要執行，怎麼解決？
候選人：
我們會讓部署多個實例，共同去執行這些批量的任務，其中任務的路由策略是分片廣播
在任務執行的代碼中可以獲取分片總數和當前分片，按照取模的方式分攤到各個實例執行就可以了