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

前言

之前业务部门有 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 兴许能解决，但技术的取舍有时候是没有正确答案，有的只是在当下做了最合乎业务倒退法则的决定