一、簡介
最近在忙項目，差不多半個月沒有寫博客，今天正逢週末，整理一些常見的SpringCloud面試題。前不久已經總結過一篇關於SpringCloud的面試題，沒有學習的小夥伴可以【SpringCloud常見面試題總結一】https://mp.csdn.net/console/editor/html/105620968進去總結一下。
二、面試題
【a】SpringCloud 和Dubbo區別?
| 區別 | SpringCloud | Dubbo |
| 服務調用方式 | Rest Api | RPC |
| 註冊中心 | 可以是eureka，也可以是zookeeper | zookeeper |
| 網關 | 服務網關,dubbo本身沒有實現，只能通過其他第三方技術整合 | springcloud有Zuul路由網關，作爲路由服務器，進行消費者的請求分發,springcloud支持斷路器，與git完美集成配置文件支持版本控制，事物總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素 |
【b】REST 和RPC對比
- RPC主要的缺陷是服務提供方和調用方式之間的依賴太強，需要對每一個微服務進行接口的定義，並通過持續繼承發佈，嚴格版本控制纔不會出現衝突。
- REST是輕量級的接口，服務的提供和調用不存在代碼之間的耦合，只需要一個約定進行規範。
【c】微服務之間是如何獨立通訊的?
- 遠程調用，比如feign調用，直接通過遠程過程調用來訪問別的service。
- 消息中間件
【d】Eureka和Zookeeper區別
| 區別 | Eureka | Zookeeper |
| CAP原理 | Eureka保證了AP（A：高可用 P：分區容錯性） | Zookeeper保證了CP（C：一致性，P：分區容錯性） |
| 是否產生服務癱瘓 | Eureka存在自我保護機制，不存在服務癱瘓現象 (Eureka的自我保護機制，會導致一個結果就是不會再從註冊列表移除因長時間沒收到心跳而過期的服務。依然能接受新服務的註冊和查詢請求，但不會被同步到其他節點) | 在選舉期間註冊服務癱瘓，雖然服務最終會恢復，但選舉期間不可用 |
| 節點是否平等 | Eureka各個節點平等 | 存在Leader和Follower角色 |
| 分區問題 | Eureka採用自我保護機制解決分區問題 | Zookeeper採用過半數存活原則 |
| 本質 | Eureka本質是一個工程 | Zookeeper只是一個進程 |
【e】Eureka自我保護機制是什麼?
當Eureka Server 節點在短時間內丟失了過多實例的連接時（比如網絡故障或頻繁啓動關閉客戶端）節點會進入自我保護模式，保護註冊信息，不再刪除註冊數據，故障恢復時，自動退出自我保護模式。
【f】什麼是Feigin？它的優點是什麼？
Feign指的是遠程服務調用。優點：
- Feign採用的是基於接口的註解
- Feign整合了ribbon，具有負載均衡的能力
- Feign整合了Hystrix，具有熔斷的能力
【g】什麼是Spring Cloud Bus?
Spring Cloud Bus指的是消息總線，提供了跨多個實例刷新配置的功能，方便各個微服務統一刷新配置，各個微服務通過監聽統一的消息總線，如RabbitMQ, 當某個服務的配置發生變化時，依賴的所有服務的配置都會自動刷新。（通過將所有微服務連接到單個消息代理來實現）
【h】負載平衡的意義什麼？
優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一微服務的過載。
【i】說說 RPC 的實現原理？
- 需要有處理網絡連接通訊的模塊，負責連接建立、管理和消息的傳輸；
- 需要有編解碼的模塊，因爲網絡通訊都是傳輸的字節碼，需要將我們使用的對象序列化和反序列化；
- 服務器端暴露要開放的服務接口，客戶調用服務接口的一個代理實現；
【j】Ribbon負載均衡能幹什麼?
- 將用戶的請求平攤的分配到多個服務上；
- 集中式LB即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬件，如F5, 也可以是軟件，如nginx), 由該設施負責把訪問請求通過某種策略轉發至服務的提供方；
- 進程內LB將LB邏輯集成到消費方，消費方從服務註冊中心獲知有哪些地址可用，然後自己再從這些地址中選擇出一個合適的服務器；
- Ribbon就屬於進程內LB，它只是一個類庫，集成於消費方進程，消費方用它來獲取到服務提供方的地址；
【k】什麼是 zuul路由網關？
- 對請求的路由和過濾；
- Zuul和Eureka進行整合，將Zuul自身註冊爲Eureka服務治理下的應用，同時從Eureka中獲得其他微服務的消息，也即以後的訪問微服務都是通過Zuul跳轉到具體微服務；
- 總體功能就是：代理 + 路由 + 過濾；
【l】分佈式配置中心能幹嘛？
- 集中管理配置文件不同環境不同配置，動態化的配置更新，分環境部署比如</p><p>dev/test/prod/beta/release；
- 運行期間動態調整配置；
- 當配置發生變動時，服務不需要重啓即可感知到配置的變化並應用新的配置將配置信息以REST接口的形式暴露；
【j】SpringBoot和SpringCloud,請你談談對他們的理解？
- SpringBoot是一個快速整合第三方框架 ，指的是快速方便的開發單個個體的服務；
- SpringCloud指的全局的微服務協調整理治理框架，將spring boot 開發的一個個單體服務整合並管理起來；
- SpringBoot依賴SpringBoot,SpringCloud離不開SpringBoot；
【k】Eureka比Zookeeper好在哪裏?
- Eureka保證的是可用性和分區容錯性，Zookeeper 保證的是一致性和分區容錯性 。
- Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障。而不會像zookeeper那樣使整個註冊服務癱瘓。
【l】SpringCloud 的核心組件有哪些？
- Eureka：服務註冊於發現；
- Feign：基於動態代理機制，根據註解和選擇的機器，拼接請求 url 地址，發起請求；
- Ribbon：實現負載均衡，從一個服務的多臺機器中選擇一臺；
- Hystrix：提供線程池，不同的服務走不同的線程池，實現了不同服務調用的隔離，避免了服務雪崩的問題；
- Zuul：網關管理，由 Zuul 網關轉發請求給對應的服務；
- Config：分佈式配置中心，提供統一管理各個微服務配置的功能；
- Bus：消息總線，配合消息中間件實現各個微服務動態刷新配置的功能；