在SpringCloud体系结构系统中，Micro -Service之间的通信基于假呼叫。在Feign的实际使用过程中，我们可能会遇到以下问题：
我们将一起讨论这些问题。我希望阅读后，我可以为您提供帮助。
首先，让我们看一下如何选择Feign的呼唤？
总体而言，Feig的调用方法分为两类：
如上所述，消费者服务直接取决于生产方提供的API软件包，然后通过注释进行注入，并且可以直接调用生产者提供的接口。
这样的优点是：简单且方便，消费者可以直接使用生产者提供的假装接口。
这一点的缺点也很明显：消费者端获得的接口是生产者为所有服务提供的接口列表。当某个生产者界面很多时，它将是混乱的。而且保险丝和降级类别也在生产方面，消费者一方位于生产方面的消费者方面，消费者侧在消费方面。由于包装路径在打电话时可能与生产者不同，因此有必要扫描假装的路径。当消费者需要介绍许多生产商假装时，需要扫描许多接口路径。
此呼叫方法在前两篇文章中有详细的解释。那些感兴趣的人可以通过以下链接直接到达：
SpringCloud Alibaba Micro Services Real Warrior -Service致电
SpringCloud Alibaba Micro-服务实际战斗20 -Interad
仍然有必要独立公共API接口层。生产方面的消费者需要将其引入此JAR包装。同时，在消费者方面编写假装客户端和保险丝。
这样做的优点是客户可以编写您需要的接口，并且保险丝和降级由消费者控制；不需要其他扫描解决方案来添加额外的扫描。
这样做的缺点是：消费者代码是多余的，每个消费者都需要写作feign客户端；服务的耦合相对较小，必须修改三个接口。
因此，问题出现了：既然有两种电话，那么更合理的是什么？
我在这里建议将第二种方法优先考虑，并且客户端自定义了假装客户端本身。
从职责的角度来看，只有消费者才能清楚地知道您需要调用的界面以及需要调用的界面。，并且保险丝处理逻辑还应通过消耗侧自定义保险丝逻辑。尽管降低了代码，责任是明确的，并且无法扫描接口路径的问题。
当然，这只是一个个人建议。如果您认为我错了，则可以遵循自己的想法。
接下来，让我们看一下是否应该封装假装接口的问题。
在前后分离项目中，当后端将接口数据返回前端时，通常返回格式。目前，我们的控制器可能会写下：
Feign接口的定义必须与实现类一致，因此现在订单服务还需要在获取订单详细信息时返回用户信息。目前，我们将访问服务接口通过假装来写：
在这里，我们需要先获取包装类，然后通过判断返回结果来求解特定对象，很明显，此代码中有两个问题：
如果有许多这样的接口调用，那么...
当然，我们需要优化这种丑陋的代码，并且优化目标也很明确：当我们通过假装调用它时，您可以直接获得物理对象而无需额外的装饰。直接通过网关调用前端，统一返回包装主体。
在这里，我们可以使用它来增强控制器的返回主体。如果它识别假装的呼叫，它将直接返回到对象，否则我们将向我们添加统一的包装结构。
至于为什么前端需要返回格式以及如何实现它，我的旧鸟类系列Springboot中的Springboot如何回到后端格式？有兴趣的人可以移动的描述。
现在的问题是：如何确定是Feig的呼叫还是直接呼叫网关？
基于自定义注释和假装拦截器，还有另外两种方法。
基于自定义注释实现
定制评论，例如，标记了FEIG界面的注释，以便在使用ResponseBodyAdvice匹配时可以匹配此注释。
但是，这种方法是不利的，即前端和假装不能公开可用。例如，可以通过假装调用接口，也可以直接调用网关。使用此方法，需要编写两个不同的路径接口。
基于假拦截器的实施
对于假电话，将特殊标志添加到假拦截器中。转换对象时，如果发现对象被调用，则会返回该对象。
在这里，我们使用第二种方法来实现（第一个方法也很简单，您可以自己尝试）
如果您要求假装，您将不会转换，否则将通过resultdata包装。
无需返回接口上的封装结果，并通过响应BodyAdvice自动增强它。
在上述四个步骤之后，我们在正常情况下实现了我们的优化目标，直接通过假装呼叫返回物理对象，并通过网关呼叫返回统一的包装机构。它看起来很完美，但实际上是不好的，这导致了第三个问题。假石如何处理异常？
生产者将检查提供的接口方法的业务规则。为了呼叫不符合业务规则的请求，他们将抛出业务异常。在正常情况下，该项目将有一个全球异常处理器。他将捕获业务异常。将统一的包装机构返回呼叫派对，让我们模拟这种业务情况：
当用户名是“ Javadaily”时，业务异常将直接抛弃。
捕获baseexception，Bizexception属于basexception的子类，也将被捕获。
调用该方法时，将“ Javadaily”传递以触发生产者的业务异常规则。
目前，当我们调用该方法时，我们会发现呼叫方无法捕获异常。所有的Acountdto都设置为null，如下所示：
设置Feign的日志级别以完整查看返回结果：
通过日志，您可以看到假装实际上是由全局异常处理器结果的统一对象获得的，并且响应代码为200，正常响应是正常的。，所有这些都被视为零值。
显然，这与我们的普通业务逻辑不符。我们应该直接返回生产者抛出的异常。那么您如何处理呢？
这很简单。我们只需要在整体异常拦截器中为业务异常设置非-200响应代码，例如：
这样，消费者可以捕获生产者正常抛出的业务异常，如下图所示：
尽管可以获得例外，但假装捕获了异常，然后根据业务异常封装。
原因是，当假呼叫结果是非-200响应代码时，触发了假词的异常分析。Feign的异常解析器会将其包装到Feignexception中，也就是说，它将根据我们的业务异常包装。
您可以使用断点来观察执行结果如下：如下：
显然，包装后我们不需要异常。我们应该直接将被俘虏的生产商的业务异常投入到前端。那么如何解决呢？
这很简单。我们只需要重写假装的异常解析器即可重新实现解码逻辑并返回正常的bizexception，然后全局异常的拦截器将捕获bizexception！（感觉有点无限无限的婴儿）
代码显示如下：
此时，通过定制假装异常解码器，生产者的业务异常信息直接被抛出以完成目标。
本文对使用期间遇到的问题进行了小摘要，并提出可能不成熟。当然，由于我的水平是有限的，因此提出的解决方案不一定是最好的。如果您有更好的解决方案，请留言告诉我，谢谢！
公共帐户：Java Nikko记录