1.现在的微服务存在哪些问题?
在大型的微服务项目中,肯定少不了服务之间多条链路调用,如果调用中有一个服务出现了问题,如果不做任何的处理,就会造成大量的阻塞,可能会导致整个服务雪崩。
2.要解决的问题
3.服务降级(fallback)
什么情况下需要服务降级:
-
程序运行异常或者宕机。
-
超时。
-
服务熔断触发服务降级(断路器打开)。
-
线程池/信号量打满也会导致服务降级(利用Jmeter进行了压测,tomcat的默认的工作线程数被打满了,没有多余的线程来分解压力和处理,其他的接口也会卡顿)。
如果出现问题,要返回一个提示或者状态,不要傻等,一般最好在订单服务800处配置兜底方法。
3.1服务降级的配置
我们要在服务方法上面@HystrixCommand设置一个最长的执行时间,还要设置一个超时或异常之后要执行的兜底的方法。
但是这样会产生一个新的问题,每个业务方法对应一个兜底的方法,会导致代码膨胀,我们的优化思路是统一的和自定义的分开。在800端的controller层定义全局的服务降级(DefaultProperties)。
为了防止8001端宕机异常,我们的在所有的方法处配置降级,这样也会和业务逻辑混乱在一起,我们可以在800端的Service层的Feign调用处配置通配的服务降级(FeignFallback)。
注意:
OpenFeign的服务调用默认只等待1秒钟,这里的等待和在controller的方法上配置的timeoutInMilliseconds是不一样的,比如timeoutInMilliseconds=5秒,意思是从我调用到返回到我controller时,我能等待5s,但是人家Service层的OpenFeign还是默认只能等1s。
4.服务熔断
需要注意的是服务熔断和服务降级完全是两个不同的概念。
4.1熔断机制概述
熔断机制是应对雪崩效应的一种微服务链路保护机制。当调用链路中的某个微服务出异常或者响应时间太长时,会进行服务降级执行兜底方法,然后可通过其机制判断可能会熔断该节点微服务的调用,等到检测到该节点微服务调用响应正常后,恢复调用链路。
4.2对开启熔断机制过程的梳理
首先在一定的时间窗口期(默认10s)内,只有当请求的个数满足一定的阈值(默认20个)后,并且其请求失败率超过一定的阈值(默认50%),此时断路器将会开启(open),调用此接口的主逻辑都不能正常执行,会服务降级去调用兜底方法, 一段时间之后(默认5s),会暂时信任一下(openhalf),让一个请求进行执行主逻辑,如果成功,则断路器会关闭(close),如果失败,则断路器继续开启,等待下一次信任。
5.服务限流(后面使用Sentinel解决)
秒杀高并发等操作时,严禁一窝蜂的过来拥挤,大家排队,一个一个来。
6.HystrixDashboard图形监控的使用