花了三天整理，Spring Cloud微服务如何设计异常处理机制？还看不懂算我输

前言

首先说一下为什么发这篇文章，是这样的、之前和粉丝聊天的时候有聊到在采用Spring Cloud进行微服务架构设计时，微服务之间调用时异常处理机制应该如何设计的问题。我们知道在进行微服务架构设计时，一个微服务一般来说不可避免地会同时面向内部和外部提供相应的功能服务接口。面向外部提供的服务接口，会通过服务网关（如使用Zuul提供的apiGateway）面向公网提供服务，如给App客户端提供的用户登陆、注册等服务接口。

而面向内部的服务接口，则是在进行微服务拆分后由于各个微服务系统的边界划定问题所导致的功能逻辑分散，而需要微服务之间彼此提供内部调用接口，从而实现一个完整的功能逻辑，它是之前单体应用中本地代码接口调用的服务化升级拆分。例如，需要在团购系统中，从下单到完成一次支付，需要交易系统在调用订单系统完成下单后再调用支付系统，从而完成一次团购下单流程，这个时候由于交易系统、订单系统及支付系统是三个不同的微服务，所以为了完成这次用户订单，需要App调用交易系统提供的外部下单接口后，由交易系统以内部服务调用的方式再调用订单系统和支付系统，以完成整个交易流程。如下图所示：

这里需要说明的是，在基于SpringCloud的微服务架构中，所有服务都是通过如consul或eureka这样的服务中间件来实现的服务注册与发现后来进行服务调用的，只是面向外部的服务接口会通过网关服务进行暴露，面向内部的服务接口则在服务网关进行屏蔽，避免直接暴露给公网。而内部微服务间的调用还是可以直接通过consul或eureka进行服务发现调用，这二者并不冲突，只是外部客户端是通过调用服务网关，服务网关通过consul再具体路由到对应的微服务接口，而内部微服务则是直接通过consul或者eureka发现服务后直接进行调用。

异常处理的差异

面向外部的服务接口，我们一般会将接口的报文形式以JSON的方式进行响应，除了正常的数据报文外，我们一般会在报文格式中冗余一个响应码和响应信息的字段，如正常的接口成功返回：

{
    "code": "0",
    "msg": "success",
    "data": {
        "userId": "zhangsan",
        "balance": 5000
    }
}

而如果出现异常或者错误，则会相应地返回错误码和错误信息，如：

{
    "code": "-1",
    "msg": "请求参数错误",
    "data": null
}

在编写面向外部的服务接口时，服务端所有的异常处理我们都要进行相应地捕获，并在controller层映射成相应地错误码和错误信息，因为面向外部的是直接暴露给用户的，是需要进行比较友好的展示和提示的，即便系统出现了异常也要坚决向用户进行友好输出，千万不能输出代码级别的异常信息，否则用户会一头雾水。对于客户端而言，只需要按照约定的报文格式进行报文解析及逻辑处理即可，一般我们在开发中调用的第三方开放服务接口也都会进行类似的设计，错误码及错误信息分类得也是非常清晰！

而微服务间彼此的调用在异常处理方面，我们则是希望更直截了当一些，就像调用本地接口一样方便，在基于Spring Cloud的微服务体系中，微服务提供方会提供相应的客户端SDK代码，而客户端SDK代码则是通过FeignClient的方式进行服务调用，如：而微服务间彼此的调用在异常处理方面，我们则是希望更直截了当一些，就像调用本地接口一样方便，在基于Spring Cloud的微服务体系中，微服务提供方会提供相应的客户端SDK代码，而客户端SDK代码则是通过FeignClient的方式进行服务调用，如：

@FeignClient(value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class)
public interface OrderClient {
    //订单(内)
    @RequestMapping(value = "/order/createOrder", method = RequestMethod.POST)
    OrderCostDetailVo orderCost(@RequestParam(value = "orderId") String orderId,
            @RequestParam(value = "userId") long userId,
            @RequestParam(value = "orderType") String orderType,
            @RequestParam(value = "orderCost") int orderCost,
            @RequestParam(value = "currency") String currency,
            @RequestParam(value = "tradeTime") String tradeTime)
}

而服务的调用方在拿到这样的SDK后就可以忽略具体的调用细节，实现像本地接口一样调用其他微服务的内部接口了，当然这个是FeignClient框架提供的功能，它内部会集成像Ribbon和Hystrix这样的框架来实现客户端服务调用的负载均衡和服务熔断功能（注解上会指定熔断触发后的处理代码类），由于本文的主题是讨论异常处理，这里暂时就不作展开了。

现在的问题是，虽然FeignClient向服务调用方提供了类似于本地代码调用的服务对接体验，但服务调用方却是不希望调用时发生错误的，即便发生错误，如何进行错误处理也是服务调用方希望知道的事情。另一方面，我们在设计内部接口时，又不希望将报文形式搞得类似于外部接口那样复杂，因为大多数场景下，我们是希望服务的调用方可以直截了的获取到数据，从而直接利用FeignClient客户端的封装，将其转化为本地对象使用。

@Data
@Builder
public class OrderCostDetailVo implements Serializable {

    private String orderId;
    private String userId;
    private int status;   //1:欠费状态；2:扣费成功
    private int orderCost;
    private String currency;
    private int payCost;
    private int oweCost;

    public OrderCostDetailVo(String orderId, String userId, int status, int orderCost, String currency, int payCost,
            int oweCost) {
        this.orderId = orderId;
        this.userId = userId;
        this.status = status;
        this.orderCost = orderCost;
        this.currency = currency;
        this.payCost = payCost;
        this.oweCost = oweCost;
    }
}

如我们在把返回数据就是设计成了一个正常的VO/BO对象的这种形式，而不是向外部接口那么样额外设计错误码或者错误信息之类的字段，当然，也并不是说那样的设计方式不可以，只是感觉会让内部正常的逻辑调用，变得比较啰嗦和冗余，毕竟对于内部微服务调用来说，要么对，要么错，错了就Fallback逻辑就好了。

不过，话虽说如此，可毕竟服务是不可避免的会有异常情况的。如果内部服务在调用时发生了错误，调用方还是应该知道具体的错误信息的，只是这种错误信息的提示需要以异常的方式被集成了FeignClient的服务调用方捕获，并且不影响正常逻辑下的返回对象设计，也就是说我不想额外在每个对象中都增加两个冗余的错误信息字段，因为这样看起来不是那么优雅！

既然如此，那么应该如何设计呢？

最佳实践设计

首先，无论是内部还是外部的微服务，在服务端我们都应该设计一个全局异常处理类，用来统一封装系统在抛出异常时面向调用方的返回信息。而实现这样一个机制，我们可以利用Spring提供的注解@ControllerAdvice来实现异常的全局拦截和统一处理功能。如：

@Slf4j
@RestController
@ControllerAdvice
public class GlobalExceptionHandler {

    @Resource
    MessageSource messageSource;

    @ExceptionHandler({org.springframework.web.bind.MissingServletRequestParameterException.class})
    @ResponseBody
    public APIResponse processRequestParameterException(HttpServletRequest request,
            HttpServletResponse response,
            MissingServletRequestParameterException e) {

        response.setStatus(HttpStatus.FORBIDDEN.value());
        response.setContentType("application/json;charset=UTF-8");
        APIResponse result = new APIResponse();
        result.setCode(ApiResultStatus.BAD_REQUEST.getApiResultStatus());
        result.setMessage(
                messageSource.getMessage(ApiResultStatus.BAD_REQUEST.getMessageResourceName(),
                        null, LocaleContextHolder.getLocale()) + e.getParameterName());
        return result;
    }

    @ExceptionHandler(Exception.class)
    @ResponseBody
    public APIResponse processDefaultException(HttpServletResponse response,
            Exception e) {
        //log.error("Server exception", e);
        response.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
        response.setContentType("application/json;charset=UTF-8");
        APIResponse result = new APIResponse();
        result.setCode(ApiResultStatus.INTERNAL_SERVER_ERROR.getApiResultStatus());
        result.setMessage(messageSource.getMessage(ApiResultStatus.INTERNAL_SERVER_ERROR.getMessageResourceName(), null,
                LocaleContextHolder.getLocale()));
        return result;
    }

    @ExceptionHandler(ApiException.class)
    @ResponseBody
    public APIResponse processApiException(HttpServletResponse response,
            ApiException e) {
        APIResponse result = new APIResponse();
        response.setStatus(e.getApiResultStatus().getHttpStatus());
        response.setContentType("application/json;charset=UTF-8");
        result.setCode(e.getApiResultStatus().getApiResultStatus());
        String message = messageSource.getMessage(e.getApiResultStatus().getMessageResourceName(),
                null, LocaleContextHolder.getLocale());
        result.setMessage(message);
        //log.error("Knowned exception", e.getMessage(), e);
        return result;
    }

    /**
     * 内部微服务异常统一处理方法
     */
    @ExceptionHandler(InternalApiException.class)
    @ResponseBody
    public APIResponse processMicroServiceException(HttpServletResponse response,
            InternalApiException e) {
        response.setStatus(HttpStatus.OK.value());
        response.setContentType("application/json;charset=UTF-8");
        APIResponse result = new APIResponse();
        result.setCode(e.getCode());
        result.setMessage(e.getMessage());
        return result;
    }
}

如上述代码，我们在全局异常中针对内部统一异常及外部统一异常分别作了全局处理，这样只要服务接口抛出了这样的异常就会被全局处理类进行拦截并统一处理错误的返回信息。

理论上我们可以在这个全局异常处理类中，捕获处理服务接口业务层抛出的所有异常并统一响应，只是那样会让全局异常处理类变得非常臃肿，所以从最佳实践上考虑，我们一般会为内部和外部接口分别设计一个统一面向调用方的异常对象，如外部统一接口异常我们叫ApiException，而内部统一接口异常叫InternalApiException。这样，我们就需要在面向外部的服务接口controller层中，将所有的业务异常转换为ApiException；而在面向内部服务的controller层中将所有的业务异常转化为InternalApiException。如：

@RequestMapping(value = "/creatOrder", method = RequestMethod.POST)
public OrderCostDetailVo orderCost(
         @RequestParam(value = "orderId") String orderId,
         @RequestParam(value = "userId") long userId,
         @RequestParam(value = "orderType") String orderType,
         @RequestParam(value = "orderCost") int orderCost,
         @RequestParam(value = "currency") String currency,
         @RequestParam(value = "tradeTime") String tradeTime)throws InternalApiException {
         OrderCostVo costVo = OrderCostVo.builder().orderId(orderId).userId(userId).busiId(busiId).orderType(orderType)
                .duration(duration).bikeType(bikeType).bikeNo(bikeNo).cityId(cityId).orderCost(orderCost)
                .currency(currency).strategyId(strategyId).tradeTime(tradeTime).countryName(countryName)
                .build();
        OrderCostDetailVo orderCostDetailVo;
        try {
            orderCostDetailVo = orderCostServiceImpl.orderCost(costVo);
            return orderCostDetailVo;
        } catch (VerifyDataException e) {
            log.error(e.toString());
            throw new InternalApiException(e.getCode(), e.getMessage());
        } catch (RepeatDeductException e) {
            log.error(e.toString());
            throw new InternalApiException(e.getCode(), e.getMessage());
        } 
}

如上面的内部服务接口的controller层中将所有的业务异常类型都统一转换成了内部服务统一异常对象InternalApiException了。这样全局异常处理类，就可以针对这个异常进行统一响应处理了。

对于外部服务调用方的处理就不多说了。而对于内部服务调用方而言，为了能够更加优雅和方便地实现异常处理，我们也需要在基于FeignClient的SDK代码中抛出统一内部服务异常对象，如：

@FeignClient(value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class)
public interface OrderClient {
    //订单(内)
    @RequestMapping(value = "/order/createOrder", method = RequestMethod.POST)
    OrderCostDetailVo orderCost(@RequestParam(value = "orderId") String orderId,
            @RequestParam(value = "userId") long userId,
            @RequestParam(value = "orderType") String orderType,
            @RequestParam(value = "orderCost") int orderCost,
            @RequestParam(value = "currency") String currency,
            @RequestParam(value = "tradeTime") String tradeTime)throws InternalApiException};

这样在调用方进行调用时，就会强制要求调用方捕获这个异常，在正常情况下调用方不需要理会这个异常，像本地调用一样处理返回对象数据就可以了。在异常情况下，则会捕获到这个异常的信息，而这个异常信息则一般在服务端全局处理类中会被设计成一个带有错误码和错误信息的json数据，为了避免客户端额外编写这样的解析代码，FeignClient为我们提供了异常解码机制。如：

@Slf4j
@Configuration
public class FeignClientErrorDecoder implements feign.codec.ErrorDecoder {

    private static final Gson gson = new Gson();

    @Override
    public Exception decode(String methodKey, Response response) {
        if (response.status() != HttpStatus.OK.value()) {
            if (response.status() == HttpStatus.SERVICE_UNAVAILABLE.value()) {
                String errorContent;
                try {
                    errorContent = Util.toString(response.body().asReader());
                    InternalApiException internalApiException = gson.fromJson(errorContent, InternalApiException.class);
                    return internalApiException;
                } catch (IOException e) {
                    log.error("handle error exception");
                    return new InternalApiException(500, "unknown error");
                }
            }
        }
        return new InternalApiException(500, "unknown error");
    }
}

我们只需要在服务调用方增加这样一个FeignClient解码器，就可以在解码器中完成错误消息的转换。这样，我们在通过FeignClient调用微服务时就可以直接捕获到异常对象，从而实现向本地一样处理远程服务返回的异常对象了。

最后

以上就是在利用Spring Cloud进行微服务拆分后关于异常处理机制的一点分享了，因为最近发现公司项目在使用Spring Cloud的微服务拆分过程中，这方面的处理比较混乱，所以写一篇文章和大家一起探讨下，如有更好的方式，也欢迎大家给我留言一起讨论！

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,684评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 87,143评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,214评论 0赞 337
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,788评论 1赞 277
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,796评论 5赞 368
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,665评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,027评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,679评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 41,346评论 1赞 299
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1赞 331
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,412评论 4赞 321
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,015评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2赞 350
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2赞 343