SpringCloud面試題
一.SpringCloud面試題口述
1.SpringCloud和Dubbo
SpringCloud和Dubbo都是現在主流的微服務架構
SpringCloud是Apache旗下的Spring體系下的微服務解決方案
Dubbo是阿里系的分散式服務治理框架
從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及有21個子專案以後還會更多
所以其實很多人都會說Dubbo和SpringCloud是不公平的
但是由於RPC以及註冊中心元資料等原因,在技術選型的時候我們只能二者選其一,所以我們常常為用他倆來對比
服務的呼叫方式Dubbo使用的是RPC遠端呼叫,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
服務的註冊中心來看,Dubbo使用了第三方的ZooKeeper作為其底層的註冊中心,實現服務的註冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現註冊中心,當然SpringCloud也可以使用ZooKeeper實現,但一般我們不會這樣做
服務閘道器,Dubbo並沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由閘道器,作為路由伺服器,進行消費者的請求分發,SpringCloud還支援斷路器,與git完美整合分散式配置檔案支援版本控制,事務匯流排實現配置檔案的更新與服務自動裝配等等一系列的微服務架構要素
2.技術選型
目前國內的分散式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,並且Dubbo在其他維度上的缺陷可以由其他第三方框架進行整合進行彌補
而SpringCloud目前是國外比較流行,當然我覺得國內的市場也會慢慢的偏向SpringCloud,就連劉軍作為Dubbo重啟的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並不是起衝突
3.Rest和RPC對比
其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通訊機制就是Http Rest
RPC最主要的缺陷就是服務提供方和呼叫方式之間依賴太強,我們需要為每一個微服務進行介面的定義,並通過持續繼承釋出,需要嚴格的版本控制才不會出現服務提供和呼叫之間因為版本不同而產生的衝突
而REST是輕量級的介面,服務的提供和呼叫不存在程式碼之間的耦合,只是通過一個約定進行規範,但也有可能出現文件和介面不一致而導致的服務整合問題,但可以通過swagger工具整合,是程式碼和文件一體化解決,所以REST在分散式環境下比RPC更加靈活
這也是為什麼噹噹網的DubboX在對Dubbo的增強中增加了對REST的支援的原因
4.文件質量和社群活躍度
SpringCloud社群活躍度遠高於Dubbo,畢竟由於樑飛團隊的原因導致Dubbo停止更新迭代五年,而中小型公司無法承擔技術開發的成本導致Dubbo社群嚴重低落,而SpringCloud異軍突起,迅速佔領了微服務的市場,背靠Spring混的風生水起
Dubbo經過多年的積累文件相當成熟,對於微服務的架構體系各個公司也有穩定的現狀
二.SpringBoot和SpringCloud
SpringBoot是Spring推出用於解決傳統框架配置檔案冗餘,裝配元件繁雜的基於Maven的解決方案,旨在快速搭建單個微服務
而SpringCloud專注於解決各個微服務之間的協調與配置,服務之間的通訊,熔斷,負載均衡等
技術維度並相同,並且SpringCloud是依賴於SpringBoot的,而SpringBoot並不是依賴與SpringCloud,甚至還可以和Dubbo進行優秀的整合開發
總結:
- SpringBoot專注於快速方便的開發單個個體的微服務
- SpringCloud是關注全域性的微服務協調整理治理框架,整合並管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件匯流排等整合服務
- SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關係
- SpringBoot專注於快速,方便的開發單個的微服務個體,SpringCloud關注全域性的服務治理框架
三.Eureka和ZooKeeper都可以提供服務註冊與發現的功能,請說說兩個的區別
1.ZooKeeper保證的是CP,Eureka保證的是AP
ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的
Eureka各個節點是平等關係,只要有一臺Eureka就可以保證服務可用,而查詢到的資料並不是最新的
自我保護機制會導致
- Eureka不再從註冊列表移除因長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其他節點(高可用)
- 當網路穩定時,當前例項新的註冊資訊會被同步到其他節點中(最終一致性)
Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況,而不會像ZooKeeper一樣使得整個註冊系統癱瘓
2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3.ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分割槽問題
4.Eureka本質上是一個工程,而ZooKeeper只是一個程序
四.微服務之間是如何獨立通訊的
- 遠端過程呼叫（Remote Procedure Invocation）
也就是我們常說的服務的註冊與發現
直接通過遠端過程呼叫來訪問別的service。
優點：- 簡單，常見,因為沒有中介軟體代理，系統更簡單
缺點： - 只支援請求/響應的模式，不支援別的，比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應
- 降低了可用性，因為客戶端和服務端在請求過程中必須都是可用的
二、訊息
使用非同步訊息來做服務間通訊。服務間通過訊息管道來交換訊息，從而通訊。
優點: - 把客戶端和服務端解耦，更鬆耦合
提高可用性，因為訊息中介軟體快取了訊息，直到消費者可以消費
支援很多通訊機制比如通知、請求/非同步響應、釋出/訂閱、釋出/非同步響應
缺點: - 訊息中介軟體有額外的複雜性
- 簡單，常見,因為沒有中介軟體代理，系統更簡單
20.什麼是服務熔斷?什麼是服務降級
在複雜的分散式系統中,微服務之間的相互呼叫,有可能出現各種各樣的原因導致服務的阻塞,在高併發場景下,服務的阻塞意味著執行緒的阻塞,導致當前執行緒不可用,伺服器的執行緒全部阻塞,導致伺服器崩潰,由於服務之間的呼叫關係是同步的,會對整個微服務系統造成服務雪崩
為了解決某個微服務的呼叫響應時間過長或者不可用進而佔用越來越多的系統資源引起雪崩效應就需要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一起類似顯示世界中的“保險絲"當某個異常條件被觸發就直接熔斷整個服務，而不是一直等到此服務超時。
服務熔斷就是相當於我們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,通過維護一個自己的執行緒池,當執行緒達到閾值的時候就啟動服務降級,如果其他請求繼續訪問就直接返回fallback的預設值
21.微服務的優缺點分別是什麼?說下你在專案開發中碰到的坑
- 優點
- 每一個服務足夠內聚,程式碼容易理解
- 開發效率提高,一個服務只做一件事
- 微服務能夠被小團隊單獨開發
- 微服務是鬆耦合的,是有功能意義的服務
- 可以用不同的語言開發,面向介面程式設計
- 易於與第三方整合
- 微服務只是業務邏輯的程式碼,不會和HTML,CSS或者其他介面組合
- 開發中,兩種開發模式
- 前後端分離
- 全棧工程師
- 開發中,兩種開發模式
- 可以靈活搭配,連線公共庫/連線獨立庫
- 缺點
- 分散式系統的負責性
- 多服務運維難度,隨著服務的增加,運維的壓力也在增大
- 系統部署依賴
- 服務間通訊成本
- 資料一致性
- 系統整合測試
- 效能監控
22.你所知道的微服務技術棧有哪些?請列舉一二
多種技術的集合體
我們在討論一個分散式的微服務架構的話,需要哪些維度
- 維度(SpringCloud)
- 服務開發
- SpringBoot
- Spring
- SpringMVC
- 服務配置與管理
- Netfilx公司的Archaiusm,阿里的Diamond
- 服務註冊與發現
- Eureka,ZooKeeper
- 服務呼叫
- Rest,RPC,gRPC
- 服務熔斷器
- Hystrix
- 服務負載均衡
- Ribbon,Nginx
- 服務介面呼叫
- Feign
- 訊息佇列
- Kafka,RabbitMq,ActiveMq
- 服務配置中心管理
- SpringCloudConfing
- 服務路由(API閘道器)
- Zuul
- 事件訊息匯流排
- SpringCloud Bus
- …
- 服務開發
23.Eureka和ZooKeeper都可以提供服務註冊與發現的功能,請說說兩個的區別
1.ZooKeeper保證的是CP,Eureka保證的是AP
ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,但是選舉期間不可用的
Eureka各個節點是平等關係,只要有一臺Eureka就可以保證服務可用,而查詢到的資料並不是最新的
自我保護機制會導致
- Eureka不再從註冊列表移除因長時間沒收到心跳而應該過期的服務
- Eureka仍然能夠接受新服務的註冊和查詢請求,但是不會被同步到其他節點(高可用)
- 當網路穩定時,當前例項新的註冊資訊會被同步到其他節點中(最終一致性)
Eureka可以很好的應對因網路故障導致部分節點失去聯絡的情況,而不會像ZooKeeper一樣使得整個註冊系統癱瘓
2.ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3.ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分割槽問題
4.Eureka本質上是一個工程,而ZooKeeper只是一個程序