1.springcloud與dubbo的區別？
https://jingyan.baidu.com/article/b0b63dbf3784294a483070fa.html
1.1 springcloud與dubbo支持技術棧比較
1.2 springcloud和dubbo的最大區別：springcloud拋棄了dubbo的rpc通信，采用的是基於http的rest方式。
1.3 springboot與dubbo就相當於品牌機與組裝機的區別。
1.4 springcloud與dubbo的社區活躍度對比。
二、整體比較 1、dubbo由於是二進制的傳輸，占用帶寬會更少 2、springCloud是http協議傳輸，帶寬會比較多，同時使用http協議一般會使用JSON報文，消耗會更大 3、dubbo的開發難度較大，原因是dubbo的jar包依賴問題很多大型工程無法解決 4、springcloud的接口協議約定比較自由且松散，需要有強有力的行政措施來限制接口無序升級 5、dubbo的注冊中心可以選擇zk,redis等多種，springcloud的注冊中心只能用eureka或者自研
2.ribbon的負載均衡策略
2.1 RoundRobinRule: 輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。所以示例中所啟動的兩個服務會被循環訪問;
2.2 RandomRule: 隨機策略，也就是說Ribbon會隨機從服務器列表中選擇一個進行訪問;
2.3 BestAvailableRule: 最大可用策略，即先過濾出故障服務器后，選擇一個當前並發請求數最小的;
2.4 WeightedResponseTimeRule: 帶有加權的輪詢策略，對各個服務器響應時間進行加權處理，然后在采用輪詢的方式來獲取相應的服務器;
2.5 AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或並發請求大於閾值的一部分服務實例，然后再以線性輪詢的方式從過濾后的實例清單中選出一個;
2.6 ZoneAvoidanceRule: 區域感知策略，先使用主過濾條件（區域負載器，選擇最優區域）對所有實例過濾並返回過濾后的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認1）和最小過濾百分比（默認0），最后對滿足條件的服務器則使用RoundRobinRule(輪詢方式)選擇一個服務器實例。
3.ribbon和feign的區別
3.1 啟動類使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
3.2 服務的指定位置不同，Ribbon是在@RibbonClient注解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
3.3 調用方式不同，Ribbon需要自己構建http請求，模擬http請求然后使用RestTemplate發送給其他服務，步驟相當繁瑣。
Feign則是在Ribbon的基礎上進行了一次改進，采用接口的方式，將需要調用的其他服務的方法定義成抽象方法即可，
不需要自己構建http請求。不過要注意的是抽象方法的注解、方法簽名要和提供服務的方法完全一致。
4.ribbon、feign以及hystrix的超時、重試設置
參考：https://blog.csdn.net/hsz2568952354/article/details/89508707
https://blog.csdn.net/hsz2568952354/article/details/89466511
4.1 ribbon的設置：
默認是沒有超時，需開啟，把ribbon.http.client.enabled設置為true。開啟后，而如果不配超時時間，默認超時時間是1秒，超時后默認會重試一次。
做如下配置，以上配置最多會調用6次（（MaxAutoRetries+1）*（MaxAutoRetriesNextServer+1）），也就是最多會重試5次。
ribbon:
ReadTimeout: 2000
ConnectionTimeout: 2000
OkToRetryOnAllOperations: true
MaxAutoRetriesNextServer: 1 # 當前實例全部失敗后可以換1個實例再重試
MaxAutoRetries: 2 # 在當前實例只重試2次
http:
client:
enabled: true
4.2 feign設置
feign默認的超時時間是1秒，重試1次。
4.3 hystrix設置
配置如下：
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
當超時並且重試也超時時，會執行降級邏輯，而不會報錯。這里，斷路器的超時時間需要大於ribbon的超時時間，不然重試沒有意義。比如將一下設置去掉（默認值是1秒）或設置較低。
可以看到，第一次超時了並重試一次，第二次沒有超時，但是頁面已經顯示error，執行降級邏輯，是因為遠程調用的超時時間已經超過了斷路器的超時時間，意思是第一次還沒執行完就已經執行降級邏輯返回，雖然后台還在重試。
5.hystrix的隔離策略
5.1 隔離策略有兩種：
線程隔離、信號量隔離。
5.2 隔離策略的區別
詳見：https://blog.csdn.net/dengqiang123456/article/details/75935122
6.hystrix功能實現的具體方式
6.1 服務降級，設置超時時間
6.2 服務限流，通過隔離策略進行限流按制。
6.3 服務熔斷：
6.3.1 熔斷的三種狀態：
正常狀態下，電路處於關閉狀態(Closed)，如果調用持續出錯或者超時，電路被打開進入熔斷狀態(Open)，后續一段時間內的所有調用都會被拒絕(Fail Fast)，
這個拒絕時間withCircuitBreakerSleepWindowInMilliseconds控制默認是5s 一段時間以后，保護器會嘗試進入半熔斷狀態(Half-Open)，允許少量請求進來嘗試，如果調用仍然失敗，則回到熔斷狀態，如果調用成功，則回到電路閉合狀態;
斷路器
（1）hystrix.command.default.circuitBreaker.requestVolumeThreshold（當在配置時間窗口內達到此數量的失敗后，進行短路。默認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內請求失敗數量達到20個，斷路器開。
（2）hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds（短路多久以后開始嘗試是否恢復，默認5s）
（3）hystrix.command.default.circuitBreaker.errorThresholdPercentage（出錯百分比閾值，當達到此閾值后，開始短路。默認50%）
6.3.2 熔斷機制簡述：
當出現問題時，Hystrix會檢查一個一定時長（圖中為10s）的一個時間窗（window），在這個時間窗內是否有足夠多的請求，如果有足夠多的請求，是否錯誤率已經達到閾值，
如果達到則啟動斷路器熔斷機制，這時再有請求過來就會直接到fallback路徑。在斷路器打開之后，
會有一個sleep window（圖中為5s），每經過一個sleep window，當有請求過來的時候，斷路器會放掉一個請求給remote 服務，
讓它去試探下游服務是否已經恢復，如果成功，斷路器會恢復到正常狀態，讓后續請求重新請求到remote 服務，否則，保持熔斷狀態。
參考自：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.項目中zuul常用的功能
7.1 提供動態路由
7.2 提供安全、鑒權處理
7.3 跨域處理
7.4 全局動態路由的hystrix(熔斷、降級、限流)處理