SpringCloud 的一些配置信息
使用版本
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.1.RELEASE</version>
<relativePath/>
</parent>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Finchley.RC1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
高可用的 Eureak Server
所謂高可用的註冊中心，其實是把 Eureka Server 自己作爲一個服務進行註冊，這多個 EurekaServer 之間就可以相互發現對方，從而形成集羣。
- 刪除 register-with-eureka = false 和 fetch-registry = false 因爲默認是 true，這樣可以把自己註冊到註冊中心
- 把 service-url 的值改成另一臺 EurekaServer 地址
服務提供者
服務註冊，檢測配置信息中的 ： eureka.client.register-with-eureka=true ，此時向註冊中心發送 Rest 請求並攜帶自己的元數據信息，雙層 Map 結構，第一層 key 就是服務名稱，第二層 key 是服務的實例 id
服務續約，註冊完成後爲了維持 心跳，會定時向註冊中心發起 Rest 請求
YML 配置信息：
eureka.instance.lease-expiration-duration-in-seconds: 90 服務失效時間，默認 90 s
eureka.instance.lease-renewal-interval-in-seconds: 30 服務續約的間隔，默認 30 s
意思就是默認情況下，每隔 30 s 服務向註冊中心發送一次請求，如果超過 90 s 沒有發送，EurekaServer 會認爲該服務宕機，會從服務列表中移除，這連個值在生產環境中不要修改，默認即可，測試環境可以小一些。
失效剔除：
可以通過 eureka.server.eviction-interval-time-in-ms 設置剔除失效服務的時間間隔，單位是 毫秒，默認是 60 秒對失效（超過 90 秒未響應）服務進行剔除處理。
自我保護
Eureka 默認會把心跳失敗實例（可能是網絡延遲，並沒有宕機，也可能真的宕機了）的註冊信息保護起來，不予以剔除，生產環境有效，可以保證大多數服務依然可用。開發環境比較麻煩：
eureka.server.enable-self-preservation: false # 關閉自我保護
eureka.server.server.eviction-interval-timer-in-ms: 1000 掃描失效服務時間間隔（默認 60 * 1000）
修改負載均衡規則的配置入口 Ribbon
Ribbon
可以通過在 啓動類 @RibbonClient 註解中指明負載均衡算法的類
比如 @RibbonClient(name = “MICROSERVICECLOUD”, configuration = MySelfRule.class)
也可以通過配置文件：
{ 服務名稱 }.ribbon.NFLoadBalancerRuleClassName: className 值就是 IRule 的實現類
比如：userservice.NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
設置負載均衡算法爲 隨機
重試機制
SpringCloud 整合了 Spring Retry 來增強 RestTemplate 的重試能力
spring.cloud.loadbalancer.retry.enabled=true # 開啓重試功能userservice.ribbon.ConnetTimeout=250 # Ribbon 的連接超時時間
userservice.ribbon.ReadTimeout=1000 #Ribbon 的數據讀取超時時間
userservice.ribbion.OkToRetryOnAllOperations=true # 對所有操作都進行重試
userservice.ribbon.MaxAuto.RetriesNextServer=2 # 切換實例的重試次數
userservice.ribbon.MaxAutoRetries=1 # 當前實例的重試次數
導入的依賴
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
Hystrix 的優化
當我們在設置 Ribbon 重試的讀取數據的超時時間爲 1000 ms 的時候，因爲 Hystrix 的差事時間默認也是 1000ms ，因爲重試機制還沒有出發，就先觸發了熔斷，那麼重試機制將無效。因此 Ribbon 的超時時間一定要小於 Hystrix 的超時時間，下面設置 hystrix 的超時時間：
hystrix.command.default.execution.thread.timeoutInMillisecond: 600 # 設置爲 600 ms
再談 負載均衡 Feign
Feign 中集成了 Ribbon，所以不需要添加多餘的依賴，也不需要在配置中註冊 RestTemplate
仍然可以像上面的那樣去配置 Ribbon ，通過 服務名.ribbon.xxx 來指定服務配置，也可以直接使用 ribbon.xxx 進行全局配置。
Feign 中也默認對 Hystrix 的集成，默認關閉：
feign.hystrix.enable: true # 開啓 Feign 的熔斷功能
Zuul 中的負載均衡和熔斷
Zuul 中默認集成了 Ribbon 負載均衡和 Hystrix 熔斷機制，但是所有超時策略都是默認值，比如：熔斷超時時間爲 1s，建議自定義：
zuul.retryable: true
zuul.ribbon.ConnectTime: 250
zuul.ribbon.ReadTimeout: 2000
zuul.ribbon.OkToRetryOnAllOperation: true
zuul.ribbon.MaxAutoRetriedNextServer: 2
zuul.ribbon.MaxAutoRetries: 1
zuul.hystrix.command.default.execution.isolation.thread.timeoutInMillisecond: 600