最近团队从dubbo切换到springcloud，自己碰到的一些问题，特别是这个很常见的调用异常，做一些分析。

springcloud 微服务框架有各种组件，可以搭建一个完整的微服务应用。包括

注册  中心：eureka 或者 consul

服务提供者：各种 provider

服务消费者：各种 consumer

网          关：zuul

这里一定会碰到的问题就是, consumer 调用 provider, provider 内部出现异常了，consumer 如何拿到具体的异常信息并且返回给页面。

为什么要返回具体的异常信息？

异常不具体的话，什么都是提示服务器异常，那说了等于没说，谁特么不知道是服务器异常。如果提示具体信息的话，比如订单号已存在，订单不存在，扣费失败，sku不存在，一眼就可以定位到问题在哪里，不用去翻日志找半天。

现成的方案就是使用 hystrix 断路器的功能

Feign的最新发布版本open-feign已经集成了Hystrix：

断路器的使用 :

第一步：设置 fallback

CommentService 是服务消费者

save 方法没有返回值说明:

对于这种可以没有返回值的方法调用，有些人认为要加上返回值 response, 然后在消费者的代码里面来判断返回值是否成功。其实大可不必，微服务之间的调用也是服务调用，相当于调用一个方法而已，没有抛出异常就可以认为是执行成功的，有异常的话都程序停止执行，事务回滚了。为什么还要加 response, 在里面搞一个所谓的 状态码来判断呢，它是微服务，你却把它当成 http rest 接口来使用,它有的功能你不用，这完全就是没有领会微服务的概念。

第二步：编写 fallback 类

消费者CommentService的方法中出现调用异常时就会进入这个类里面的方法

第三步：尝试捕获 BizException(message)

这是消费者的全局的异常捕获

第四步：服务提供者里面直接抛异常

服务提供者里面直接抛异常

经过测试，CommentServiceFallbackFactory 的 save 方法抛出的异常是无法被捕获器捕获到的，这样就没法通过 fallback 方法去控制异常的展示，返回。

消费者无法捕获断路器里面抛出的异常是因为这是2个不同的线程，不同线程之间的异常是不会互相影响的，上面那个是断路器处理回滚的线程，下面那个是很典型的 servlet 线程

如果按照上面的方式来使用断路器的话，这种使用方式完全是不可用的，一个是 每个服务类里面要配置 fallbackFactory ，有多少个服务类就要对应的写多少个回滚类，写到你吐血。第二个是断路器里面拿到的 provider 的异常信息，如何传递给消费者，可以考虑用线程的等待通知机制，但是这么玩就不是微服务了。

现在有2种方式可以让具体的异常信息逐级上报，返回给页面

第一种 :

全局异常处理里面解析捕获到的异常信息，直接返回到页面

第二种：配置 feign 的 ErrorDecoder

在这里解析 response 的结果并返回的异常信息可以被全局异常处理捕获到

最终的效果就是这样,调用消费者的接口，消费者再去调用 提供者的接口，提供者处理时出现异常(参考上面第四部那个图)

把异常信息作为结果返回