HSF/Dubbo序列化时的LocalDateTime, Instant的性能问题

来源

在对Dubbo新版本做性能压测时，无意中发现对用例中某个TO（Transfer Object）类的一属性字段稍作修改，由Date变成LocalDateTime，结果是吞吐量由近5w变成了2w，RT由9ms升指90ms。

在线的系统，拼的从来不仅仅是吞吐量，
而是在保证一定的RT基础上，再去做其他文章的， 也就是说应用的RT是我们服务能力的基石所在， 拿压测来说， 我们能出的qps/tps容量， 必须是应用能接受的RT下的容量，而不是纯理论的数据，在集团云化的过程中计算过，底层服务的RT每增加0.1ms，在应用层就会被放大，

整体的成本就会上升10%以上。

要走向异地，首先要面对的阿喀琉斯之踵：延时，长距离来说每一百公里延时差不多在1ms左右，杭州和上海来回的延迟就在5ms以上，上海到深圳的延迟无疑会更大，延时带来的直接影响也是响应RT变大，
用户体验下降，成本直线上升。 如果一个请求在不同单元对同一行记录进行修改， 即使假定我们能做到一致性和完整性， 那么为此付出的代价也是非常高的，想象一下如果一次请求需要访问
10 次以上的异地 HSF 服务或 10 次以上的异地 DB调用, 服务再被服务调用，延时就形成雪球，越滚越大了。

普遍性

关于时间的处理应该是无处不在，可以说离开了时间属性，99.99%的业务应用都无法支持其意义，特别是像监控类的系统中更是面向时间做针对性的定制处理。

在JDK8以