异常处理不仅仅是狭义上遇到了 Exception 怎么去处理,还有各种业务逻辑遇 到错误的时候我们怎么去处理。service 服务层捕获的异常主要包括 BusinessException( 业务异常 )、RetriableException ( 可重试异常 ) 到 common-api,定义一 个公共异常拦截器,对业务异常、重试异常进行统一处理,对于可重试的异常调用的 服务接口需要保证其幂等性。 另外其他业务层有些特殊异常不需要拦截器统一处理,内部可以进行自我消化处 理掉,根据场景对应的处理原则主要包括: ● 直接返回 ● 抛出异常 ● 重试处理 ● 熔断处理 ● 降级处理 这又涉及到了弹力设计的话题,我们的系统往往会对接各种依赖外部服务、Api, 大部分服务都不会有 SLA,即使有在大并发下我们也需要考虑外部服务不可用对自 己的影响,会不会把自己拖死。我们总是希望: ● 尽可能以小的代价通过尝试让业务可以完成; ● 如果外部服务基本不可用,而我们又同步调用外部服务的话,我们需要进行自 我保护直接熔断,否则在持续的并发的情况下自己就会垮了; ● 如果外部服务特别重要,我们往往会考虑引入多个同类型的服务,根据价格、 服务标准做路由,在出现问题的时候自动降级。 推荐使用 Netflix 开源的 hystrix 容灾框架,主要解决当外部依赖出现故障时拖垮 业务系统、甚至引起雪崩的问题。目前我团队也在使用,能够很好的解决异常熔断、 超时熔断、基于并发数限流熔断的降级处理。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。