springcloud

（微服務）

註冊服務（eureka）
負責提供註冊服務，使用者訪問時可以通過它來找，相當於一箇中介
依賴只要springcloud-eureka-server

配置
spring/application/name：eureka-server
eureka/cilent/service-url/defalutZone：http://127.0.0.1:10086/ 註冊自己，其實它本身也是一個sevice
至於註冊自己與否，預設是註冊的，看情況而定，如果是多叢集，就要註冊自己
#register-with-eureka: false # 不註冊自己
#fetch-registry: false #不拉取

啟動器方面：
只要在類上多加個EnableEurekaServer就行

註冊服務的叢集是通過相互註冊實現的，以前是自己註冊自己，現在要註冊到其它上，客戶端在註冊是要都寫上註冊
defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka

呼叫者
依賴按需匯入，比如springboot-starter-web 客戶端依賴springcloud-eureka-cilent

配置
和伺服器的差不多，具體看情況

啟動器
在類上多個客戶端註解EnableDiscoveryCilent，還有就是bean注入restTemplate,這是用於請求的轉發，在方法上面
還要加上loadbalanced，用於負載均衡

controller
最終都是使用restTemplate的getForObject(url,User.class);返回對應實體類物件
方法一: 是寫死地址 String url = “http://localhost:8081/user/” + id;此時還沒用客戶端註解
方法二: 也不太好，因為使用了客戶端註解，所以此時要通過eureka來找，注入discoverycilent，通過服務id來拉取服務

List<ServiceInstance> instances = discoveryClient.getInstances("user-service");
 ServiceInstance instance = instances.get(0);
 String url = String.format("http://%s:%s/user/%s", instance.getHost(), instance.getPort(), id.toString())
 

方法三：因為在restTemplate上加上了負載均衡，所以此時可以直接在url裡面加入服務id
String url=“http://user-service/user/”+id,原理大概就是使用者請求，通過eureka的伺服器，幫你找到對用提供方，
然後將提供方的ip加埠返回給restTemplate
最後都走String user = restTemplate.getForObject(url, String.class);

服務者
依賴按需，比如springboot-starter-web mysql-connector-java mapper-springboot-starter
還有就是springcloud-starter-netflix-eureka-cilent

配置：
在伺服器的配置基礎上，按需配置，如spring/datasource/url logging/level/包名:debug 埠也可以配置

啟動器
類上多加個enablediscoverycilent就行，mapperscan也要匯入對

controller
正常操作

Hystrix

（服務保護機制）
問題：出現雪崩問題，現在一業務會呼叫多個服務介面，如果一服務出現問題，就會造成堵塞，原本執行緒有限，
但那問題服務會因為每次請求失敗而累加堵塞最終會導致所有執行緒都被佔據，這就是問題所在
解決優化：執行緒隔離與服務降級
所謂執行緒隔離及時每個服務介面提前分好執行緒，就那麼多，超出了也不會佔用其它服務
而服務降級就是指在服務出問題後不是讓使用者乾等，而是返回一個友好的反饋資訊，而作出反饋就是熔斷機制
操作:
匯入依賴：
spring-cloud-starter-netflix-hystrix
啟動器：
在起動器上多配置個@EnableCiruitBreaker，其實可以直接配置個@SpringCloudApplication，它已經包含下面三個了
@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
Controller:
編寫降級邏輯，有區域性和全域性預設
區域性就是在要處理的方法上加@HystrixComand（fallbackMethod=“”）
@HystrixCommand(fallbackMethod = “queryByIdFallBack”)
public String queryById(@PathVariable(“id”) Long id){
String url = “http://user-service/user/” + id;
String user = restTemplate.getForObject(url, String.class);
return user;
}
public String queryByIdFallBack(Long id){
log.error(“查詢使用者資訊失敗，id：{}”, id);
return “對不起，網路太擁擠了！”;
}
注意：這反饋方法是有條件，就是是引數和返回型別和主方法一致

全域性預設：

@DefaultProperties(defaultFallback = "defaultFallBack")
public class ConsumerController {

 public String defaultFallBack(){
@Autowired
    private RestTemplate restTemplate;

@GetMapping("{id}")
@HystrixCommand
public String queryById(@PathVariable("id") Long id){
    String url = "http://user-service/user/" + id;
    String user = restTemplate.getForObject(url, String.class);
    return user;
}
    return "預設提示：對不起，網路太擁擠了！";
}

}
此時就沒有什麼限制了，畢竟要對所有方法處理，而不可能統一，但是所有方法必須和預設反饋方法返回屬性一致

配置
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 2000//將超時時間延長下，預設一秒就會服務降級

服務熔斷：
所謂熔斷就是在降級服務多的情況下，一般是大於20或多餘總次數50%以上的請求出錯才會觸發，
最明顯的區別就是反饋錯誤資訊更快了，之前的錯誤反饋是有一小點處理時間的，現在直接反饋，幾乎不處理。
而且熔斷後會關停服務5秒，5秒後再半開執行緒，放進一個，請求，如果仍然失敗，就繼續關停5秒，依次迴圈，
直到半開時請求成功，就會開啟服務

• requestVolumeThreshold：觸發熔斷的最小請求次數，預設20

• errorThresholdPercentage：觸發熔斷的失敗請求最小佔比，預設50%

• sleepWindowInMilliseconds：休眠時長，預設是5000毫秒