关于openfeign:记一次openfeign反序列化异常复盘

8次阅读

共计 1110 个字符,预计需要花费 3 分钟才能阅读完成。

前言

之前业务部门有 2 个通用响应类,一个是负责和前端交互的响应类 AjaxResult, 一个是负责和后端 RPC 接口交互的响应类 RpcResult。一开始这两个响应类的值字段都一样,形如下

    private Boolean success;
    private String message;
    private Integer code;
    private T data;

因为前端和后端部署在不同的服务器上,某次因为前端和后端的工夫不统一,导致呈现业务异样,前面业务的架构师说,业务对立当前端的工夫为准。于是 AjaxResult 新增了一个工夫字段 nowDateTime,而 RpcResult 维持不变。明天的要解说的故事就是由此拉开序幕

注释

一开始因为职能划分比较清楚,前端和后端都是对立用 AjaxResult 交互,后端与后端对立通过 RpcResult 交互,后边随着工夫的推移和人员的流动,这个边界就被突破了。AjaxResult 和 RpcResult 混着用,终于在某次 openfeign 反序列化调用,呈现了

org.codehaus.jackson.map.exc.UnrecognizedPropertyException: Unrecognized field "nowDateTime"(Class com.xx.xx.RpcResult)

异样,过后业务提出的解决思路也是很简略,就是在 RpcResult 这类中,也加上 nowDateTime 字段。这样的确能够解决问题,然而某个研发提了一个疑难,因为 AjaxResult 没在他们那边保护,AjaxResult 对他们就是一个黑盒子,哪天 AjaxResult 又加了新增字段,如果没告诉到位,岂不是依然报错。有没有一劳永逸的解法,答案是有的,就是在 RpcResult 这个类上,加上如下注解

@JsonIgnoreProperties(ignoreUnknown = true)

该注解的意思是疏忽 RpcResult 无奈辨认的属性

总结

尽管问题解决了,然而我在加入他们业务复盘的时候,我脑海中始终有 2 种声音,一种是分成 2 种响应值,职责更清晰,2 个响应值类能够各自倒退,然而遇到全局异样解决,如果是业务异样是好办,如果是呈现零碎级异样,如果响应值是以 AjaxResult 序列化进来,而被 RpcResult 反序列回来,是不是也会有再次出问题。

其次在我看来,AjaxResult 和 RpcResult 实质上就是同个货色,分成 2 种不同类,是不是适度设计了,是不是减少问题的复杂度,如果响应值都对立改成 AjaxResult,是不是就能够防止下面的反序列问题

Bug 兴许能解决,但技术的取舍有时候是没有正确答案,有的只是在当下做了最合乎业务倒退法则的决定

正文完
 0