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解决)
秒杀高并发等操作时，严禁一窝蜂的过来拥挤，大家排队，一个一个来。