springcloud入門demo：https://gitee.com/Linging241/springcloud-demo.git
其他

1. Eureka原理

• Eureka作為微服務中的注冊中心，其服務注冊與發現的原理如下：
  首先有兩個角色，一個服務端和客戶端，服務端就是Eureka本身，客戶端就是服務提供者和消費者，當服務提供者啟動會將自己的信息注冊到Eureka去，消費者啟動會去注冊中心拉取服務列表緩存到本地，消費者就可以遠程調用服務提供者。客戶端會與注冊中心保持心跳來證明自己存活，每隔30s客戶端會發送心跳給注冊中心，默認情況下，每隔90s注冊中心會檢查是否有收到心跳，如果沒有收到心跳會將客戶端從服務列表剔除。
• 但是由于服務之間的調用常常會受網絡延遲的影響導致心跳沒有及時的收到，從而誤將客戶端剔除，所以Eureka會有自我保護機制來應對這種情況。
• 默認情況下，Eureka的自我保護機制是開啟的。
• 自我保護機制的觸發：在15分鐘內，Eureka收到的心跳總數低于總數的85%，就會開啟。
• 自我保護機制的退出：當收到心跳數達到閾值之后，會自動退出自我保護機制。

面試題：
1.Eureka與Zookeeper的區別在哪？

• zookeeper保證的是CP，在Zookeeper集群中，當發生網絡故障導致master節點和slave節點失聯時，剩余的slave節點會進行leader選舉，而在選舉的過程中，zookeeper集群不可用，不能對外提供注冊和查詢的服務。主從節點數據同步的時候不能對外提供服務。
• Eureka保證的是AP，在Eureka集群中，某些節點掛掉，只要有一個Eureka節點存在，就可以對外提供注冊和查詢服務，但是可能注冊信息不是最新的(不保證強一致性)。

2 .Eureka與Nacos的區別？

• Nacos既支持AP也支持CP，默認使用AP和Eureka一樣。

https://blog.csdn.net/weixin_43776652/article/details/120874245

2.Ribbon與Feign

• Ribbon是一個Http和Tcp的客戶端負載均衡工具，它可以在客戶端配置服務端列表，，它使用RestTemplate模擬客戶端請求，過程相對繁瑣。
• Feign繼承了Ribbon，使用接口的方式進行服務調用。

面試題：
1.負載均衡算法有哪些？
隨機、輪詢、響應時間權重、重試等，還可以實現IRule接口，自定義負載均衡算法。

2.Ribbon和Feign的區別？

• 啟動類上加的注解不同，Ribbon用的是@RibbonClients；Feign用的是@EnableFeignClients
• 服務的指定位置不同，Ribbon是在@RibbonClient上指定服務名稱；Feign是在接上的@FeignClient上指定。
• 調用方式不同，Ribbon需要自己構建http請求，模擬http請求，然后使用RestTempate進行調用；Feign采用接口的方式調用。

3.Ribbon原理
先去本地獲取從Eureka緩存下來的服務列表，然后使用負載均衡算法選取一個服務，使用HttpClient進行調用。

4.Feign的原理
在配置類上，加上@EnableFeginClients，那么該注解是基于@Import注解，注冊有關Fegin的解析注冊類，這個類是實現 ImportBeanDefinitionRegistrar 這個接口，重寫registryBeanDefinition 方法。他會掃描所有加了@FeginClient 的接口，然后針對這個注解的接口生成動態代理，然后你針對fegin的動態代理去調用他方法的時候，此時會在底層生成http協議格式的請求，使用HttpURLConnection進行調用。

5.Feign和OpenFeign的區別？
OpenFeign在feign的基礎上支持了SpringMVC的注解，如@RequestMapping等等，OpenFeign的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通過動態代理的方式產生實現類，實現類中做負載均衡并調用其他服務。

3.Hystix

Hystix是分布式系統的一個延遲和容錯的開源庫，它可以進行熔斷、降級、限流、監控，可以避免分布式系統的級聯故障和雪崩效應。

服務熔斷：熔斷是直接調用降級方法。不調用目標方法，無需等待接口調用超時才返回結果。
服務降級：降級是調用目標方法，由于目標方法調用超時或者異常，才調用降級方法。
使用：服務降級是在消費端和feign一起使用，默認降級的配置不是開啟的(feign.hystrix.enabled=false)，服務熔斷是在服務端使用，對服務端的controller進行熔斷，默認熔斷的配置是開啟的(spring.cloud.circuit.breaker.enabled=true)。

面試題：
1、什么是服務雪崩？
服務雪崩就是服務A調用服務B，服務B調用服務C，服務C掛掉了，導致服務B、C超時受影響，導致服務A也超時，對服務造成級聯的影響。即下游服務掛掉或者超時，導致上游調用服務大面積受到影響，阻塞、超時，進而導致雪崩效應。

2、Hystix和Sentinel的區別？

3、Hystix的限流兩種方式
線程池和信號量，信號量沒有timeout機制。

4、限流算法有幾種？
計數器、滑動窗口計數器、漏桶法、令牌桶

4.Zuul

Zuul作為微服務的網關，對微服務的訪問進行控制，它可以進行路由、過濾、鑒權、代理請求，

面試題：
1、Zuul和gateway的區別？

• Zuul1.0是阻塞式的api，不支持長連接，而gateway支持異步。
• Zuul沒有提供限流、負載均衡等支持，而gateway支持。
• 它們都是web網關，處理http請求，底層都是servlet。

5.Config

SpringcloudConfig是微服務中的配置中心，對微服務中多個自服務的配置進行統一的管理，可以對配置的讀取、加密、解密等操作。

面試題：
1、Config和Nacos的區別？

• Config大部分集合git使用，配置動態變更需要依賴SpringCloudBus消息總線來通知所有Client變化；并且沒有可視化界面。
• Nacos采用長連接，一旦配置變更，會迅速通知Client進行變更，速度較快；提供可視化界面。

6.SpringCloud升級對比圖

7.分布式理論CAP及base理論

C（Consistence）：一致性，集群節點數據的一致。
A（Availability）：可用性，集群節點只要存在一個節點就能對外提供服務，那就是可用。
P（Partition tolerance）：分區容錯性，即當分布式系統發生網絡分區故障時，依然能對外提供一致性或者可用性的服務。
分布式系統多個服務節點部署在網絡中的不同機器上，通過網絡連接在一起，那么由于網絡不穩定，所以一定會存在分區故障，導致網絡分區，形成多個不連通的區域，那么不連通的區域，分布式系統中的節點就不能進行數據同步，就會導致數據的不一致，但是系統還要對外提供服務，對外提供服務有兩種方式，要么等待網絡恢復正常，數據同步完之后再對外提供服務，一致性，要么只要存在一個節點就可以對外提供服務，雖然節點間可能數據不一致，可用性。

Base理論是CAP理論的延伸，它拋棄強一致性，來了個最終一致性。

• 基本可用(Basically Available)： 基本可用是指分布式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。電商大促時，為了應對訪問量激增，部分用戶可能會被引導到降級頁面，服務層也可能只提供降級服務。這就是損失部分可用性的體現。
• 軟狀態(Soft State)： 軟狀態是指允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。分布式存儲中一般一份數據至少會有三個副本，允許不同節點間副本同步的延時就是軟狀態的體現。MySQL Replication 的異步復制也是一種體現。
• 最終一致性(Eventual Consistency)： 最終一致性是指系統中的所有數據副本經過一定時間后，最終能夠達到一致的狀態。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

總結

以上是生活随笔為你收集整理的SpringCloud五大组件原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。