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等自描述的序列化框架來實現，這一層實際上是缺乏版本識別，從而致使升級起來就異常困難。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。