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之前，基本是经过java.util.Date来描述日期和时刻，java.util.Calendar来作时间相关的计算处理。JDK8引入了更加方便的时间类，包括Instant，LocalDateTime、OffsetDateTime、ZonedDateTime等等，总的说来，时间处理由于这些类的引入而更加直接方便。

Instant存的是UTC的时间戳，提供面向机器时间视图，适合用于数据库存储、业务逻辑、数据交换、序列化。LocalDateTime、OffsetDateTime、ZonedDateTime等类结合了时区或时令信息，提供了面向人类的时间视图，用于向用户输入输出，同一个时间面向不一样用户时，其值是不一样的。好比说订单的支付、发货时间买卖双方都用本地时区显示。能够把这3个类看做是一个面向外部的工具类，而不是应用程序内部的工做部分。

简单说来，Instant适用于后端服务和数据库存储，而LocalDateTime等等适用于前台门面系统和前端展现，两者能够自由转换。这方面，国际化业务的同窗有至关多的体感和经验。

在HSF/Dubbo的服务集成中，不管是Date属性仍是Instant属性确定是广泛的一种场景。

问题复现

• Instant等类的性能优点

以常见的格式化场景举例

@Benchmark
    @BenchmarkMode(Mode.Throughput)
    public String date_format() {
        Date date = new Date();
        return new SimpleDateFormat("yyyyMMddhhmmss").format(date);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public String instant_format() {
        return Instant.now().atZone(ZoneId.systemDefault()).format(DateTimeFormatter.ofPattern(
                "yyyyMMddhhmmss"));
    }

在本地经过4个线程来并发运行30秒作压测，结果以下。

Benchmark                            Mode  Cnt        Score   Error  Units
DateBenchmark.date_format           thrpt       4101298.589          ops/s
DateBenchmark.instant_format        thrpt       6816922.578          ops/s

可见，Instant在format时性能方面是有优点的，事实上在其余操做方面（包括日期时间相加减等）都是有性能优点，你们能够自行搜索或写代码测试来求解。

• Instant等类在序列化时的陷阱

针对Java自带，Hessian(淘宝优化版本)两种序列化方案，压测序列化和反序列化的处理性能。

Hessian是集团内应用的HSF2.2和开源的Dubbo中默认的序列化方案。

@Benchmark
    @BenchmarkMode(Mode.Throughput)
    public Date date_Hessian() throws Exception {
        Date date = new Date();
        byte[] bytes = dateSerializer.serialize(date);
        return dateSerializer.deserialize(bytes);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public Instant instant_Hessian() throws Exception {
        Instant instant = Instant.now();
        byte[] bytes = instantSerializer.serialize(instant);
        return instantSerializer.deserialize(bytes);
    }

    @Benchmark
    @BenchmarkMode(Mode.Throughput)
    public LocalDateTime localDate_Hessian() throws Exception {
        LocalDateTime date = LocalDateTime.now();
        byte[] bytes = localDateTimeSerializer.serialize(date);
        return localDateTimeSerializer.deserialize(bytes);
    }

结果以下。能够看出，在Hessian方案下，不管仍是Instant仍是LocalDateTime，吞吐量相比较Date，都出现“大跌眼镜”的下滑，相差100多倍；经过经过分析，每一次把Date序列化为字节流是6个字节，而LocalDateTime则是256个字节，这个放到网络带宽中的传输代价也是会被放大。 在Java内置的序列化方案下，有稍微下滑，但没有本质区别。

Benchmark                         Mode  Cnt        Score   Error  Units
DateBenchmark.date_Hessian       thrpt       2084363.861          ops/s
DateBenchmark.localDate_Hessian  thrpt         17827.662          ops/s
DateBenchmark.instant_Hessian    thrpt         22492.539          ops/s
DateBenchmark.instant_Java       thrpt       1484884.452          ops/s
DateBenchmark.date_Java          thrpt       1500580.192          ops/s
DateBenchmark.localDate_Java     thrpt       1389041.578          ops/s

分析解释

Hession中实际上是有针对Date类作特殊处理，遇到Date属性，都是直接获取long类型的相对来作处理。

经过分析Hessian对Instant类的处理，不管是序列化仍是反序列化，都须要Class.forName这个耗时的过程。。。，怪不得throughput急剧降低。

延展思考

1） 能够经过扩展实现Instant等类的com.alibaba.com.caucho.hessian.io.Serializer，并注册到SerializerFactory，来升级优化Hessian。但会有先后兼容性上，这个是大问题，在集团内这种上下游依赖比较复杂的场景下，极高的风险也会让此不可行。从这个角度看，只有建议你们都用Date来作个TO类的首选的时间属性。

2） HSF的RPC协议从严格意义上讲是 Session握手层的协议定义，其中的版本识别也是这个层面的行为，而业务数据的presentation展现层是经过Hessian等自描述的序列化框架来实现，这一层实际上是缺乏版本识别，从而致使升级起来就异常困难。

---

本文做者：renchie

阅读原文

本文为云栖社区原创内容，未经容许不得转载。