From Monolith to Service Mesh: Huolala’s Microservice Governance Journey

Speaker Introduction

Xu Shaomin , Java Technology Expert at Huolala Technology Center, Core Infrastructure Department, leads the design and implementation of Java development frameworks, scaffolding, task scheduling, configuration, SOA, and microservice architectures.

1. Application Architecture Evolution

Enterprise application architecture evolves to deliver value through decoupling, reuse, separation of concerns, faster iteration, delivery, and feedback. The progression includes five major patterns:

Monolithic Architecture : All functionality is packaged in a single process, leading to complex, tightly coupled systems that are hard to maintain and scale.

RPC Architecture : Introduces a service layer to extract reusable business logic, improving code quality and maintainability but still tightly coupled and limited by proprietary TCP protocols.

SOA Architecture : Divided into two stages—ESB‑centered and service‑registry‑centered—offering loose coupling via a message bus but suffering from centralization and limited flexibility.

Microservice Architecture : Uses lightweight HTTP + REST communication, clear service boundaries, and high extensibility, enabling rapid response to business changes.

Service Mesh Architecture : Container‑native, adds sidecar proxies for service discovery, load balancing, circuit breaking, rate limiting, and other governance capabilities, forming a mesh of sidecar nodes.

2. Huolala’s All‑In‑One Web to Microservice Governance

Huolala’s architecture transitioned through three stages:

Monolithic Stage (2014‑2016) : PHP‑based all‑in‑one web.

RPC Stage (2016‑2020) : Extracted core services (dcore, ucore) using HTTP + REST, lacking service governance.

Microservice Stage (2020‑present) : Ongoing microservice transformation.

2.1 Microservice Governance Background

Key pain points driving the migration:

High cost of domain‑based service management (≈500 internal domains).

Inconsistent protocols (GET, POST JSON, FORM) across PHP and Java services.

Absence of service governance (no registry, circuit breaking, or fallback mechanisms).

Need to migrate legacy PHP services to Java gradually.

2.2 Technical Selection

Considering the requirements, the following frameworks were evaluated:

SOA: Dubbo

Microservices: Spring Cloud

Service Mesh: Istio

Due to incomplete containerization, Istio was postponed, leaving Dubbo and Spring Cloud as primary candidates.

2.3 Dubbo 2.x Limitations

Poor cloud‑native support.

Lacks built‑in circuit breaking, rate limiting, or fallback; requires external tools like Sentinel.

Uncertain release timeline for Dubbo 3.x.

No generic invocation capability for cross‑language (PHP/Java) calls.

Interface‑based registration not friendly to future APPID‑based service mesh.

2.4 Spring Cloud Limitations

Heavy and complex; large binaries (>100 MB) and high memory consumption.

HTTP + REST protocol offers weak governance controls.

2.5 Custom Microservice Framework Design

Based on the analysis, a custom framework was designed with the following components:

Standard Service Call Protocol : JSON‑RPC supporting Java ↔ PHP calls.

Registry : Consul.

Service Governance : Hystrix (with PHP support) for circuit breaking.

Generic Invocation : Inspired by FeignClient and jsonrpc4j.

Framework Design : Adopt Dubbo’s layered architecture (dubbo‑common, dubbo‑config, dubbo‑filter, etc.).

2.6 Generic Invocation Implementation

Three approaches were demonstrated: @FeignClient(value = "XC-SERVICE-MANAGE-CMS") where XC-SERVICE-MANAGE-CMS is the downstream APPID discovered via Spring Cloud.

@JsonRpcService("/path/to/MyService")
interface MyService {
    ... service methods ...
}

Additional diagrams illustrate the interface definitions and JSON‑RPC standards.

2.7 Service Governance Capabilities

Circuit Breaking : Integrated Hystrix.

Configuration Management : Leveraged internal configuration center.

Monitoring : Integrated internal monitoring platform.

Governance Console : Developed soa‑admin for management.

2.8 Java Agent for Governance

Governance logic is offloaded to a Java Agent with modular plugins (Metric, Trace, SOA) supporting dynamic and gray‑scale upgrades.

2.9 Future Planning

Huolala aims to evolve toward a full Service Mesh architecture, acknowledging challenges such as increased operational complexity, required expertise in Kubernetes and Istio, added latency, and platform dependency.

Conclusion

The evolution of Huolala’s application architecture demonstrates that each architectural shift is driven by business needs and technical constraints, with the ultimate goal of achieving agility, low investment, and rapid fulfillment of business requirements.