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ū)活躍度對(duì)比。

　　

二、整體比較

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

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

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

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

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

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

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

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

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

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

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

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

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

　　3.1 啟動(dòng)類使用的注解不同，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請(qǐng)求，模擬http請(qǐng)求然后使用RestTemplate發(fā)送給其他服務(wù)，步驟相當(dāng)繁瑣。

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

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

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

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

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

　　4.1ribbon的設(shè)置：

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

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

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

　　4.2feign設(shè)置

　　　　feign默認(rèn)的超時(shí)時(shí)間是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 # 斷路器的超時(shí)時(shí)間需要大于ribbon的超時(shí)時(shí)間，不然重試沒(méi)有意義
ribbon:
  ReadTimeout: 2000
  ConnectionTimeout: 2000
  OkToRetryOnAllOperations: true
  MaxAutoRetriesNextServer: 1
  MaxAutoRetries: 0

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

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

5.hystrix的隔離策略

　　5.1隔離策略有兩種：

　　　　線程隔離、信號(hào)量隔離。

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

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

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

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

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

　　6.3服務(wù)熔斷：

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

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

斷路器

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

　　 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.

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

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

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

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

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

　　7.3 跨域處理

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

總結(jié)

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

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