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毫秒

《俗人笔记》之《微服务个人小结二》

springcloud

Hystrix

猜你喜欢