Cloud Native 19 min read

Evolution of Service Registration and Discovery Architecture at Youzan

Youzan’s service registration and discovery architecture progressed from fine‑grained interface‑level registration on Etcd, through an intermediate application‑level discovery layer using Istio Pilot and the Tether sidecar, to a fully application‑level, sidecar‑driven model with CRD metadata, enabling scalable, cloud‑native multi‑region service mesh.

Youzan Coder
Youzan Coder
Youzan Coder
Evolution of Service Registration and Discovery Architecture at Youzan

In recent years, Youzan's rapid business growth has led to a fast increase in the number and scale of applications. Consequently, the service registration and discovery architecture has been continuously evolving to support this growth. This article introduces the evolution process of Youzan's service registration and discovery architecture, focusing on Dubbo‑based backend services.

The evolution is divided into three stages:

Interface‑level service registration and discovery

Interface‑level registration with application‑level discovery

Application‑level service registration and discovery

Below is a concise description of each stage.

1. Interface‑level Service Registration and Discovery

During 2018‑2019, Youzan used the standard Dubbo 2.7‑era solution where each interface is registered individually. The registration center was Etcd v3. An example of the interface‑level model is shown below:

[
  {
    "interface":"com.youzan.java.demo.api.HelloService",
    "instances":[
      {
        "ip_address":"10.10.10.10",
        "port":5000,
        "protocol":"dubbo",
        "az":"qa",
        "weight":100,
        "labels":{ "version":"stable" },
        "application":"java-demo",
        "methods":["hello"]
      }
    ]
  },
  {
    "interface":"com.youzan.java.demo.api.EchoService",
    "instances":[
      {
        "ip_address":"10.10.10.10",
        "port":5000,
        "protocol":"dubbo",
        "az":"qa",
        "weight":100,
        "labels":{ "version":"stable" },
        "application":"java-demo",
        "methods":["echo"]
      }
    ]
  }
]

The main problems of this model are excessive granularity, high registration/discovery overhead, data redundancy, and limited scalability of Etcd as a CP system.

2. Interface‑level Registration with Application‑level Discovery

From 2020, Youzan kept the registration format but switched discovery to an application‑level model using Istio Pilot as an intermediate discovery layer and a sidecar component called Tether for routing and load balancing.

Key changes:

Istio Pilot abstracts various registration back‑ends, providing a unified discovery model.

All consumers connect through the Tether sidecar, which performs discovery, routing, and load balancing at the application level.

An example of the application‑level model:

{
  "application":"java-demo",
  "instances":[
    {
      "ip_address":"10.10.10.10",
      "port":5000,
      "protocol":"dubbo",
      "az":"qa",
      "weight":100,
      "labels":{ "version":"stable" },
      "dubbo_rpc_metadata":[
        {"interface":"com.youzan.java.demo.api.HelloService","methods":["hello"]},
        {"interface":"com.youzan.java.demo.api.EchoService","methods":["echo"]}
      ]
    }
  ]
}

To map interfaces to applications, an Interface Mapping API was added. Example mapping data:

[
  {"interface":"com.youzan.java.demo.api.HelloService","providers":["java-demo"]},
  {"interface":"com.youzan.java.demo.api.EchoService","providers":["java-demo"]}
]

Optimizations introduced in this stage include delayed push of discovery updates, pre‑loading of frequently used services, local construction of interface‑to‑application mappings, and aggregation of identical metadata across instances.

3. Application‑level Service Registration and Discovery

Since 2021, Youzan adopted a long‑term architecture where registration is performed by the Tether sidecar. For Kubernetes‑deployed services, only metadata is sent; the rest of the instance information is derived from K8s resources.

Service metadata is stored in a custom ResourceDefinition (CRD) called ServiceMetadata. A simplified metadata model:

{
  "subset_metadata":[
    {
      "subset_id":"1",
      "selector":{"pod-template-hash":"f845f5775","app":"java-demo","zone":"qa"},
      "dubbo_rpc_metadata":{"interfaces":[{"name":"com.youzan.java.demo.api.EchoService","methods":["echo"]}]}
    },
    {
      "subset_id":"2",
      "selector":{"pod-template-hash":"67bd5c9db9","app":"java-demo","zone":"qa"},
      "dubbo_rpc_metadata":{"interfaces":[{"name":"com.youzan.java.demo.api.EchoService","methods":["echo"]},{"name":"com.youzan.java.demo.api.HelloService","methods":["hello"]}]}
    }
  ]
}

Multi‑region discovery is achieved by having Tether connect to multiple Istio Pilot instances, defaulting to the local region and falling back to others when needed, thus providing scalable cross‑region service discovery without overloading the registration centers.

Conclusion

The article outlines Youzan's step‑by‑step migration from a fine‑grained interface registration model to a scalable, cloud‑native, application‑level service mesh architecture. While the specific path may not suit every organization, the presented patterns—using Istio Pilot, sidecar‑based discovery, metadata aggregation, and CRD‑based storage—offer valuable guidance for large‑scale backend service discovery evolution.

Cloud NativeKubernetesservice discoveryDubboistioservice meshservice registration
Youzan Coder
Written by

Youzan Coder

Official Youzan tech channel, delivering technical insights and occasional daily updates from the Youzan tech team.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.