记一次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也许能解决，但技术的取舍有时候是没有正确答案，有的只是在当下做了最符合业务发展规律的决定