HSF 2.2: Architecture and Optimizations that Powered Alibaba’s Double‑11

Architecture Upgrade

HSF 2.2 redesigns layer boundaries, clarifies component responsibilities, and embeds a replaceable‑extension philosophy. The system is split into three domains—framework, application, and service—allowing natural multi‑application (or multi‑module) deployment.

The framework domain provides thread and connection resources; the application domain manages a set of services; the service domain represents an interface that can provide or consume services.

Pure Asynchronous Call Interceptor

HSF’s async future calls were hard to measure because EagleEye reported only default values. HSF 2.2 adds an InvocationHandler with both invoke and onResponse phases, enabling accurate latency measurement and custom interceptors for monitoring without modifying application code.

Multi‑Application Support

HSF 2.2 treats each application (or module) as a core domain, solving serialization challenges at the application layer and supporting multiple applications deployed together.

Performance Optimizations

Optimization 1: Metadata Sharing

HSF moves Hessian metadata handling out of the per‑request HessianOutput / HessianInput objects, caching class metadata across requests. Tests on a core online service showed about a 10% CPU reduction and ~17% network traffic decrease.

Optimization 2: UTF‑8 Decode Improvement

The original UTF‑8 parser decoded each byte individually. The new implementation reads eight bytes at once using unsafe.getLong and fast‑paths ASCII characters, yielding roughly a 17% performance gain (e.g., 981 ms → 810 ms in tests).

private int parseUTF8Char() throws IOException { … }

Optimization 3: Exception Flow Improvements

Hessian’s handling of UnmodifiableSet and similar collections caused frequent exceptions that, while not breaking business logic, hurt performance. HSF now skips constructor logic for these types, reducing overhead.

Optimization 4: Map Operation Array‑ification

Frequent Map<String,Object> accesses were replaced with a custom DefaultAttributeMap that uses an array indexed by a pre‑assigned AttributeKey id. Benchmarks show about 30% faster put/get operations compared with standard HashMap.

Operational Enhancements for Double‑11

HSF 2.2 also added service authentication, single‑machine operations, and connection pre‑warming. The pre‑warming feature let applications establish connections to providers ahead of traffic spikes, increasing total connection counts by over 50% and in some cases by 40‑fold.

Conclusion

The architectural overhaul, performance tweaks, and operational improvements in HSF 2.2 equipped Alibaba’s service framework to comfortably handle the massive load of Double‑11 2017 and set a foundation for the next decade of service‑oriented development.