How Huolala’s Multi‑Group Architecture Revolutionizes Microservice Routing

Background

Huolala provides multiple service‑discovery and routing capabilities for its microservice architecture. By early 2023 it supports Consul and domain‑fallback discovery, as well as gray release, multi‑lane routing, and other routing features. Business growth created new demands for more flexible discovery and routing, including publishing services in multiple groups, running different code versions per group, varying stability requirements, caller‑side group selection, and custom routing policies.

Basic Principles

Architecture basic principle

How to deploy services in multiple groups?

How to perform multi‑group service discovery and routing?

How to satisfy different business scenarios with routing strategies?

Multi‑group deployment

The multi‑group architecture supports deploying different groups under the same appid, allowing each group to have distinct release configurations and enabling processes to be aware of their own group.

Multi‑group service discovery and routing

The SOA SDK tags services with a Consul tag (hll.group) to provide a unified multi‑group discovery and routing mechanism.

Routing strategy

The architecture offers two ways to provide flexible routing strategies:

Built‑in strategies: static routing, protocol‑header routing, switches, black‑/white‑list, downgrade, etc., covering most multi‑group needs.

Extension mechanism: business‑customizable strategies via SOA’s SPI, such as SOA SPI extensions and LAPIGateway plugins.

Other issues

Unified standards for environment and metadata.

Observability design for multi‑group architecture.

Configuration center support for differentiated group configurations.

Open related capabilities for business‑side custom scenarios.

Architecture Design

Multi‑group service registration

When a service registers, SOA writes the group identifier as a Consul tag (hll.group). Empty values are omitted. The group metadata is accessed via environment variables such as hll_group.

Multi‑group routing

Routing rules rely on the Consul tag for discovery and provide one‑level routing (A → B) without protocol‑header or transparent link capabilities. Built‑in static routing and extension points are supported.

Routing extension mechanism

The SOA framework requires a routing‑strategy extension mechanism to satisfy custom business policies. Extensions have higher priority than built‑in strategies and affect only the current request’s group selection. Multiple SPI implementations are evaluated in order, with the first successful decision blocking subsequent SPIs.

Key inputs include service information, protocol headers, registration data, downstream node list ( List<Invoker<T>> invokers), and invocation context ( Invocation invocation).

Extension is implemented via SOA’s SPI:

@SPI(internal = false)
public interface GroupRouterExt {
    Optional<PinnedGroup> getGroup(List<Invoker<T>> invokers, Invocation i);
}

public class PinnedGroup {
    // group identifier
    private String group;
    // allow cross‑group calls when no match (default false)
    private boolean cross;
}

Application Scenarios

4.1 Function module partition

Services are divided by functional modules, each forming a separate group, improving decoupling, maintainability, and testability.

4.2 Business domain partition

Services are grouped by business domains (e.g., user vs. driver token providers) to optimize resource utilization and throughput.

4.3 Service SLA partition

Instances with similar SLA requirements (e.g., QPS, latency) are placed in the same group for isolation and optimization.

4.4 Technology stack partition

Different technology stacks (frontend‑facing services, internal backend services, data services) are assigned to distinct groups, allowing tailored instance counts and resource usage.

4.5 Security and permission management

Services with similar security or permission requirements are grouped together to enable unified security policies and access control.

ps: High code similarity or shared appid can be maintained without splitting services by using the SOA multi‑group approach.