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

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

来源：花匠小妙招时间：2025-05-03 10:21

前言

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

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

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

异常处理的差异

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

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

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

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

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

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

@FeignClient(value = "order", configuration = OrderClientConfiguration.class, fallback = OrderClientFallback.class) public interface OrderClient { 12