springcloud面試題【第一期】

全文目錄

1：談一談你對微服務的理解？

2：微服務之間是如何獨立進行通訊的？

3：springcloud和dubbo有哪些區別？

4：springboot和spring cloud得區別？

5：Eureka和ZooKeeper都可以提供服務注冊與發現的功能,說說二者的區別？

6：什么是熔斷？ 什么是服務降級？

7：說一下你所知道的微服務技術堆疊？

8：說一下CAP定理

1：談一談你對微服務的理解？

最初我們學習Java的時候接觸的都是單機專案,會把各種業務需求，資料庫鏈接，頁面展示等都會糅合在一個專案中，如果說這個專案越來越大，功能模塊越來越多，無論是部署還是維護都是比較麻煩的事情，針對這么情況就慢慢衍生出了微服務，簡單的來說微服務架構的核心目標是把復雜問題簡單化，通過模塊劃分，把一個完整的系統拆分成多個高內聚、低耦合的小的子系統，使得每個子系統可以獨立的運行、升級和測驗，然后再通過一些集成手段將這些子系統組合在一起，對外提供完整功能的程序，

2：微服務之間是如何獨立進行通訊的？

• 同步：通過HTTP協議進行呼叫，介面使用restful風格的，資料格式采用json格式，dubbo采用的協議是rpc協議，
• 異步：mq,kafka

3：springcloud和dubbo有哪些區別？

• 采用的協議不同：springcloud采用HTTP協議，dubbo采用的是rpc協議，
• 兩者的模塊組成：Dubbo主要分為服務注冊中心，服務提供者，服務消費者，還有管控中心；而SpringCloud則是一個完整的分布式一站式框架，他也有服務注冊中心，服務提供者，服務消費者，管控臺，斷路器，分布式配置服務，訊息總線，以及服務追蹤等；

4：springboot和spring cloud得區別？

• SpringBoot是Spring推出用于解決傳統框架組態檔冗余,簡化Spring應用的初始搭建以及開發程序,可以快速搭建web應用;
• 而SpringCloud專注于解決各個微服務之間的協調與配置,服務之間的通信,熔斷,負載均衡等技術維度,并且SpringCloud是依賴于SpringBoot的,而SpringBoot并不是依賴與SpringCloud,甚至還可以和Dubbo進行優秀的整合開發

總結:SpringBoot專注于快速方便的開發單個個體服務,SpringCloud是關注全域的微服務協調整理治理框架,整合并管理各個微服務,為各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務SpringBoot不依賴于SpringCloud,SpringCloud依賴于SpringBoot，屬于依賴關系SpringBoot專注于快速,方便的開發單個的微服務個體,SpringCloud關注全域的服務治理框架

5：Eureka和ZooKeeper都可以提供服務注冊與發現的功能,請說說兩個的區別

Eureka和ZooKeeper作為注冊中心都可以給客戶端提供可供呼叫的服務串列，客戶端在進行遠程呼叫時，根據服務提供方的服務地址從服務串列選擇可被呼叫的服務，二者的區別在于zookeeper當節點出現故障的時候，它會在剩余的節點中重新選擇主節點，但這個程序消耗時間會相對長，雖然最后也能恢復正常，但是選取主節點的程序中會導致服務不可用，這是不可容忍的，相比eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的作業，剩余的節點依然可以提供注冊和查詢服務，而Eureka的客戶端在向某個Eureka注冊或如果發現連接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證注冊服務可用(保證可用性)，但是缺點就是查到的資訊可能不是最新的(不保證強一致性)，

著名的CAP理論指出，一個分布式系統不可能同時滿足C(一致性)、A(可用性)和P(磁區容錯性)，由于磁區容錯性在是分布式系統中必須要保證的，因此我們只能在A和C之間進行權衡，Zookeeper保證的是CP, 而Eureka則是AP，

6：什么是熔斷？ 什么是服務降級？

首先決議一下熔斷出現的情景：假設系統中有A，B，C三個服務，服務A是上游，服務B是中游，服務C是下游,一旦下游服務C由于某些原因變得不可用，積壓了大量請求，服務B的請求執行緒也隨之阻塞，執行緒資源逐漸耗盡，使得服務B也變得不可用，緊接著，服務A也變為不可用，整個呼叫鏈路則被拖垮，進而引起系統崩潰這種情況就是所謂的“雪崩效應”，

在這種時候，就需要熔斷機制來挽救整個系統，當某個微服務不可用或者回應時間太長時，會進行服務降級，進而熔斷該節點微服務的呼叫，快速回傳“錯誤”的回應資訊，當檢測到該節點微服務呼叫回應正常后恢復呼叫鏈路，在SpringCloud框架里熔斷機制通過Hystrix實作，Hystrix會監控微服務間呼叫的狀況，當失敗的呼叫到一定閾值，預設是10秒內呼叫20次，如果失敗，就會啟動熔斷機制，熔斷機制的注解是@HystrixCommand，

服務降級，一般是從整體負荷考慮，就是當某個服務熔斷之后，服務器將不再被呼叫，此時客戶端可以自己準備一個本地的fallback回呼，回傳一個預設值，這樣做，雖然水平下降，但好歹可用，比直接掛掉強，

7：說一下你所知道的微服務技術堆疊？

• 服務注冊與發現：Eureka、Consul、Zookeeper等
• 服務呼叫：Rest、RPC、Feign
• 服務熔斷器:Hystrix、Envoy等
• 負載均衡:Ribbon、Nginx等
• 訊息佇列：Kafka、RabbitMQ、ActiveMQ等
• 服務配置中心管理：SpringCloudConfig、Chef等
• 服務路由：（API網關）gateway、Zuul等
• 服務監控：Zabbix、Nagios、Metrics、Spectator等
• 全鏈路追蹤:Zipkin，Brave、Dapper等
• 服務部署：Docker、OpenStack、Kubernetes等
• 資料流操作開發包：SpringCloud Stream（封裝與Redis,Rabbit、Kafka等發送接收訊息）
• 事件訊息總線：Spring Cloud Bus

8：說一下CAP定理

CAP:指的是在一個分布式系統中，一致性（Consistency）、可用性（Availability）、磁區容錯性（Partition tolerance），

一致性：在分布式系統中的所有資料備份，在同一刻是同樣的值（等同于在訪問所以的節點的時候，主副資料一致），

可用性：在集群中一部分的節點故障后，集群整體是否還能回應客戶端的讀寫請求（對資料更新具有高可用），

磁區容錯性：系統如果不能在時限內達成資料的一致性，就意味著發生了磁區的情況，必須就當前的操作在C和A之前作出選擇，

這三個要素最多只能同時實作兩點，要是AP,要么CP,不可能三者兼顧(AC一般不考慮)，

歡迎關注公眾號！公眾號回復:入群 ，掃碼加入交流群！