來源

在對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

原文連結​

本文為雲棲社群原創內容，未經