springCloud 面試題
阿新 • • 發佈：2019-04-25
mon detail ribbon cloud 討論 觸發 顯示 代理 常見
服務網關,Dubbo並沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作為路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分布式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素
2.技術選型
目前國內的分布式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,並且Dubbo在其他維度上的缺陷可以由其他第三方框架進行集成進行彌補
3.Rest和RPC對比
其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要為每一個微服務進行接口的定義,並通過持續繼承發布,需要嚴格的版本控制才不會出現服務提供和調用之間因為版本不同而產生的沖突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是通過一個約定進行規範,但也有可能出現文檔和接口不一致而導致的服務集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以REST在分布式環境下比RPC更加靈活
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只是一個進程
---------------------
作者：流放Oo
來源：CSDN
原文：https://blog.csdn.net/qq_42629110/article/details/84963815
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
1.SpringCloud和Dubbo
SpringCloud和Dubbo都是現在主流的微服務架構
SpringCloud是Apache旗下的Spring體系下的微服務解決方案
Dubbo是阿裏系的分布式服務治理框架
從技術維度上,其實SpringCloud遠遠的超過Dubbo,Dubbo本身只是實現了服務治理,而SpringCloud現在以及有21個子項目以後還會更多
所以其實很多人都會說Dubbo和SpringCloud是不公平的
但是由於RPC以及註冊中心元數據等原因,在技術選型的時候我們只能二者選其一,所以我們常常為用他倆來對比
服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
服務網關,Dubbo並沒有本身的實現,只能通過其他第三方技術的整合,而SpringCloud有Zuul路由網關,作為路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分布式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素
2.技術選型
目前國內的分布式系統選型主要還是Dubbo畢竟國產,而且國內工程師的技術熟練程度高,並且Dubbo在其他維度上的缺陷可以由其他第三方框架進行集成進行彌補
3.Rest和RPC對比
其實如果仔細閱讀過微服務提出者馬丁福勒的論文的話可以發現其定義的服務間通信機制就是Http Rest
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,我們需要為每一個微服務進行接口的定義,並通過持續繼承發布,需要嚴格的版本控制才不會出現服務提供和調用之間因為版本不同而產生的沖突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是通過一個約定進行規範,但也有可能出現文檔和接口不一致而導致的服務集成問題,但可以通過swagger工具整合,是代碼和文檔一體化解決,所以REST在分布式環境下比RPC更加靈活
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只是一個進程
---------------------
作者：流放Oo
來源：CSDN
原文：https://blog.csdn.net/qq_42629110/article/details/84963815
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！
springCloud 面試題