一、Eureka的高可用性Eureka下面的服务实例默认每隔30秒会发送一个HTTP心跳给Eureka,来告诉Eureka服务还活着,每个服务实例每隔30秒也会通过HTTP请求向Eureka获取服务列表,这就相当于一个服务实例一分钟会与Eureka进行四次请求,当服务实例多了以后,就要考虑Eureka的压力,如果我们有1000个服务实例,一分钟就会有4000次请求,平均每秒70次请求,不过Eureka内部是通过内存建立一个HashMap来维护服务实例列表的,并且还做了读写分离,所以保证多个实例的心跳是没有问题的,要注意的是保证Eureka的高可用,生产环境中如果Eureka挂掉,相当于所有实例之间都没办法联系了,我们可以在多台机器上部署Eureka(尽量不要同时在一台机器上部署,因为出问题时,一般整个机器的资源都不能正常使用了),可以部署三个Eureka实例,然后将每个服务实例同时注册到三台Eureka上面,这样即使某个Eureka挂掉了,也不会影响整个系统的运行。 配置的方式也很简单,部署好多台Eureka实例后,只需要将每个服务实例分别注册到每个Eureka上面即可 eureka: client: serviceUrl: defaultZone: http://eureka1:80/eureka/, http://eureka2:80/eureka/ 二、服务熔断和服务降级微服务之间的调用两种情况,网关与服务之间的调用,服务与服务之间的调用,当某个服务的响应时间过长,调用链就会等待,当请求量多了,就会引起雪崩,所以就需要用到服务熔断组件hystrix,当调用超时时直接返回,并且设置服务降级策略,当发生熔断时的补救措施,比如监控告警,记录SQL日志后续进行数据恢复等 1、服务降级配置 当出现服务熔断时,我们需要配置服务熔断的处理策略,服务降级有两种情况,网关层面做降级和服务之间做降级 (1)网关层面降级:只需要重写ZuulFallbackProvider的方法,即可定制返回值 @Component public class GatewayFallback implements ZuulFallbackProvider { @Override public String getRoute() { // 这里配置服务降级是针对哪个服务实例的,可以填写服务id,如果返回null则是针对所有服务 return null; } @Override public ClientHttpResponse fallbackResponse() { // 服务熔断后,返回的内容 return new ClientHttpResponse() { @Override public InputStream getBody() throws IOException { JSONObject result = new JSONObject(); result.put("error_code", -1); result.put("error_info", "网络繁忙"); return new ByteArrayInputStream(result.toString().getBytes("UTF-8")); } @Override public HttpHeaders getHeaders() { // 返回Json格式的数据 HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON_UTF8); return headers; } @Override public HttpStatus getStatusCode() throws IOException { // 返回的HTTP错误码 return HttpStatus.OK; } @Override public int getRawStatusCode() throws IOException { return HttpStatus.OK.value(); } @Override public String getStatusText() throws IOException { return HttpStatus.OK.getReasonPhrase(); } @Override public void close() { // 进行一些自定义的处理,比如监控告警 } }; } } (2)服务之间降级:服务之间的调用一般是使用Feign组件,我们需要为Feign接口声明的每个方法编写处理的逻辑,通过注解的fallback属性来指定服务降级的实现类 @FeignClient(value = "clientService", fallback = ClientServiceFallback.class) public interface ClientService { @RequestMapping(method = RequestMethod.POST, value = "/test", produces = MediaType.APPLICATION_JSON_VALUE) String queryClientById(@RequestParam("id") String id); } public class ClientServiceFallback implements ClientService { @Override public String queryClientById(String id) { // 进行一些自定义的处理 return null; } } 2、服务熔断配置 服务熔断的参数配置非常重要,合理的参数配置才能更好地利用好机器资源,既不会浪费,也能合理对服务进行熔断防止雪崩 (1)熔断超时时间设置:这个时间一定要根据情况合理选择,不能太高也不能太低,如果设置太高,当服务出现问题时,每个线程都要等待很久,所有线程卡死就会导致用户根本无法正常使用,如果太小,出现网络波动就会影响服务质量,合理的设置一般是比如你的接口处理时间是200ms,那你可以设置300ms,比正常的响应时间大一点点,防止网络波动出现熔断 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 300 (2)Hystrix线程池大小设置:首先评估你的服务压力,比如你的服务每秒需要处理100个请求,每个请求的处理时间是200ms,相当于1个线程1秒可以处理5个请求,100/5=20,可以算出20个线程就可以处理请求,我们设置就可以设置25个线程,多给5个线程用来留些后路,防止一些特点时间点有大量的请求 hystrix.threadpool.default.coreSize: 25 三、最后应对高并发,最重要还是先要保证业务逻辑的处理速度,才能从根本上优化,比如进行SQL查询时,尽量避免多表关联,SQL语句越简单越好,数据表加索引,不要使用外键,外键会在一定程度上影响性能,且不容易维护,我个人建议通过增加其他表的id字段来维护表之间的关系 来源:http://www./content-4-162401.html |
|