1.springcloud與dubbo的區(qū)別？

　　https://jingyan.baidu.com/article/b0b63dbf3784294a483070fa.html

　　1.1springcloud與dubbo支持技術(shù)棧比較

　　1.2springcloud和dubbo的最大區(qū)別：springcloud拋棄了dubbo的rpc通信，采用的是基于http的rest方式。

　　1.3springboot與dubbo就相當(dāng)于品牌機(jī)與組裝機(jī)的區(qū)別。

　　1.4springcloud與dubbo的社區(qū)活躍度對比。

　　

二、整體比較

1、dubbo由于是二進(jìn)制的傳輸，占用帶寬會更少

2、springCloud是http協(xié)議傳輸，帶寬會比較多，同時使用http協(xié)議一般會使用JSON報(bào)文，消耗會更大

3、dubbo的開發(fā)難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決

4、springcloud的接口協(xié)議約定比較自由且松散，需要有強(qiáng)有力的行政措施來限制接口無序升級

5、dubbo的注冊中心可以選擇zk,redis等多種，springcloud的注冊中心只能用eureka或者自研

2.ribbon的負(fù)載均衡策略

　　2.1RoundRobinRule: 輪詢策略，Ribbon以輪詢的方式選擇服務(wù)器，這個是默認(rèn)值。所以示例中所啟動的兩個服務(wù)會被循環(huán)訪問;

　　2.2 RandomRule: 隨機(jī)策略，也就是說Ribbon會隨機(jī)從服務(wù)器列表中選擇一個進(jìn)行訪問;

　　2.3 BestAvailableRule: 最大可用策略，即先過濾出故障服務(wù)器后，選擇一個當(dāng)前并發(fā)請求數(shù)最小的;

　　2.4 WeightedResponseTimeRule: 帶有加權(quán)的輪詢策略，對各個服務(wù)器響應(yīng)時間進(jìn)行加權(quán)處理，然后在采用輪詢的方式來獲取相應(yīng)的服務(wù)器;

　　2.5 AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或并發(fā)請求大于閾值的一部分服務(wù)實(shí)例，然后再以線性輪詢的方式從過濾后的實(shí)例清單中選出一個;

　　2.6 ZoneAvoidanceRule: 區(qū)域感知策略，先使用主過濾條件（區(qū)域負(fù)載器，選擇最優(yōu)區(qū)域）對所有實(shí)例過濾并返回過濾后的實(shí)例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結(jié)果進(jìn)行過濾，判斷最小過濾數(shù)（默認(rèn)1）和最小過濾百分比（默認(rèn)0），最后對滿足條件的服務(wù)器則使用RoundRobinRule(輪詢方式)選擇一個服務(wù)器實(shí)例。

3.ribbon和feign的區(qū)別

　　3.1 啟動類使用的注解不同，Ribbon用的是@RibbonClient，F(xiàn)eign用的是@EnableFeignClients。

　　3.2 服務(wù)的指定位置不同，Ribbon是在@RibbonClient注解上聲明，F(xiàn)eign則是在定義抽象方法的接口中使用@FeignClient聲明。

　　3.3 調(diào)用方式不同，Ribbon需要自己構(gòu)建http請求，模擬http請求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當(dāng)繁瑣。

Feign則是在Ribbon的基礎(chǔ)上進(jìn)行了一次改進(jìn)，采用接口的方式，將需要調(diào)用的其他服務(wù)的方法定義成抽象方法即可，

不需要自己構(gòu)建http請求。不過要注意的是抽象方法的注解、方法簽名要和提供服務(wù)的方法完全一致。

4.ribbon、feign以及hystrix的超時、重試設(shè)置

　　參考：https://blog.csdn.net/hsz2568952354/article/details/89508707

　　　　　https://blog.csdn.net/hsz2568952354/article/details/89466511

　　4.1ribbon的設(shè)置：

　　　　默認(rèn)是沒有超時，需開啟，把ribbon.http.client.enabled設(shè)置為true。開啟后，而如果不配超時時間，默認(rèn)超時時間是1秒，超時后默認(rèn)會重試一次。

　　　　做如下配置，以上配置最多會調(diào)用6次（（MaxAutoRetries+1）*（MaxAutoRetriesNextServer+1）），也就是最多會重試5次。

ribbon:
  ReadTimeout: 2000
  ConnectionTimeout: 2000
  OkToRetryOnAllOperations: true
  MaxAutoRetriesNextServer: 1 # 當(dāng)前實(shí)例全部失敗后可以換1個實(shí)例再重試
  MaxAutoRetries: 2 # 在當(dāng)前實(shí)例只重試2次
  http:
    client:
      enabled: true

　　4.2feign設(shè)置

　　　　feign默認(rèn)的超時時間是1秒，重試1次。

　　4.3hystrix設(shè)置

　　　　配置如下：

server:
  port: 8002

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:5000/eureka/
spring:
  application:
    name: service-hystrix
feign:
  hystrix:
    enabled: true # 開啟
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 10000 # 斷路器的超時時間需要大于ribbon的超時時間，不然重試沒有意義
ribbon:
  ReadTimeout: 2000
  ConnectionTimeout: 2000
  OkToRetryOnAllOperations: true
  MaxAutoRetriesNextServer: 1
  MaxAutoRetries: 0

　　當(dāng)超時并且重試也超時時，會執(zhí)行降級邏輯，而不會報(bào)錯。這里，斷路器的超時時間需要大于ribbon的超時時間，不然重試沒有意義。比如將一下設(shè)置去掉（默認(rèn)值是1秒）或設(shè)置較低。

　　可以看到，第一次超時了并重試一次，第二次沒有超時，但是頁面已經(jīng)顯示error，執(zhí)行降級邏輯，是因?yàn)檫h(yuǎn)程調(diào)用的超時時間已經(jīng)超過了斷路器的超時時間，意思是第一次還沒執(zhí)行完就已經(jīng)執(zhí)行降級邏輯返回，雖然后臺還在重試。

5.hystrix的隔離策略

　　5.1隔離策略有兩種：

　　　　線程隔離、信號量隔離。

　　5.2隔離策略的區(qū)別

　　　　詳見：https://blog.csdn.net/dengqiang123456/article/details/75935122

6.hystrix功能實(shí)現(xiàn)的具體方式

　　6.1服務(wù)降級，設(shè)置超時時間

　　6.2服務(wù)限流，通過隔離策略進(jìn)行限流按制。

　　6.3服務(wù)熔斷：

　　　　6.3.1 熔斷的三種狀態(tài)：

   正常狀態(tài)下，電路處于關(guān)閉狀態(tài)(Closed)，如果調(diào)用持續(xù)出錯或者超時，電路被打開進(jìn)入熔斷狀態(tài)(Open)，后續(xù)一段時間內(nèi)的所有調(diào)用都會被拒絕(Fail Fast)，
這個拒絕時間withCircuitBreakerSleepWindowInMilliseconds控制默認(rèn)是5s
一段時間以后，保護(hù)器會嘗試進(jìn)入半熔斷狀態(tài)(Half-Open)，允許少量請求進(jìn)來嘗試，如果調(diào)用仍然失敗，則回到熔斷狀態(tài)，如果調(diào)用成功，則回到電路閉合狀態(tài);

斷路器

（1）hystrix.command.default.circuitBreaker.requestVolumeThreshold（當(dāng)在配置時間窗口內(nèi)達(dá)到此數(shù)量的失敗后，進(jìn)行短路。默認(rèn)20個）

　　 For example, if the value is 20, then if only 19 requests are received in the rolling window (say a window of 10 seconds) the circuit will not trip open even if all 19 failed.

　　 簡言之，10s內(nèi)請求失敗數(shù)量達(dá)到20個，斷路器開。

（2）hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds（短路多久以后開始嘗試是否恢復(fù)，默認(rèn)5s）

（3）hystrix.command.default.circuitBreaker.errorThresholdPercentage（出錯百分比閾值，當(dāng)達(dá)到此閾值后，開始短路。默認(rèn)50%）
　　　　6.3.2熔斷機(jī)制簡述：

      當(dāng)出現(xiàn)問題時，Hystrix會檢查一個一定時長（圖中為10s）的一個時間窗（window），在這個時間窗內(nèi)是否有足夠多的請求，如果有足夠多的請求，是否錯誤率已經(jīng)達(dá)到閾值，
如果達(dá)到則啟動斷路器熔斷機(jī)制，這時再有請求過來就會直接到fallback路徑。在斷路器打開之后，
會有一個sleep window（圖中為5s），每經(jīng)過一個sleep window，當(dāng)有請求過來的時候，斷路器會放掉一個請求給remote 服務(wù)，
讓它去試探下游服務(wù)是否已經(jīng)恢復(fù)，如果成功，斷路器會恢復(fù)到正常狀態(tài)，讓后續(xù)請求重新請求到remote 服務(wù)，否則，保持熔斷狀態(tài)。

　　參考自：https://www.cnblogs.com/amazement/p/8445294.html

　　　　　　https://www.jianshu.com/p/6e9619cbdfc3?tdsourcetag=s_pctim_aiomsg

　　　　　　https://blog.csdn.net/tongtong_use/article/details/78611225

7.項(xiàng)目中zuul常用的功能

　　7.1提供動態(tài)路由

　　7.2提供安全、鑒權(quán)處理

　　7.3 跨域處理

　　7.4全局動態(tài)路由的hystrix(熔斷、降級、限流)處理

總結(jié)

以上是生活随笔為你收集整理的【springcloud】常见面试题总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。