How to Assemble a Service Registry: Requirements, Interfaces, and Technical Choices

The author, Wukong, introduces the concept of assembling a service registry instead of building one from scratch, emphasizing reuse of existing components and practical learning.

Requirement Analysis

The registry must support three core capabilities: registration, discovery, and high availability. Three roles are defined: Provider (service provider), Consumer (service consumer), and Registry (the central store of service metadata).

Interface Definition

Three essential APIs are described: register (add a service), unregister (remove a service), and subscribe (consumer subscribes to services). The article discusses required fields, serialization format (JSON), and transport protocols.

Example JSON payloads are provided for service registration, subscription, and discovery:

{
  "application":"provider_test", // application name
  "protocol":"http", // protocol
  "addr":"127.0.0.1:8080", // provider address
  "meta":{
    "cluster":"small",
    "idc":"shanghai",
    "tag":"read"
  }
}

{
    "subscribes":[
        {
            "provider":"test_provider1", // subscribed application
            "protocol":"http",
            "meta":{
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        },
        {
            "provider":"test_provider2",
            "protocol":"http",
            "meta":{
                "cluster":"small",
                "tag":"read"
            }
        }
    ]
}

{
    "version":"23des4f",
    "endpoints":[
        {
            "application":"provider_test",
            "protocol":"http",
            "addr":"127.0.0.1:8080",
            "meta":{
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        },
        {
            "application":"provider_test",
            "protocol":"http",
            "addr":"127.0.0.2:8080",
            "meta":{
                "cluster":"small",
                "idc":"shanghai",
                "tag":"read"
            }
        }
    ]
}

Change Push & Service Health Check

The article compares four push mechanisms—periodic polling, long polling, UDP push, and TCP long‑connection push—evaluating implementation difficulty, real‑time performance, and resource consumption. It recommends discarding simple polling for larger systems.

Health‑check strategies are examined; the author favors registry‑initiated probing and provider‑registry session keep‑alive, noting that long‑connection solutions can address both push and health‑check needs.

Long‑Connection Technology Selection

Four networking libraries are compared (gRPC, Rsocket, Netty, Mina). gRPC is preferred for its strong community, multi‑language support, and stream‑based error handling.

Data Storage

Two storage models are discussed: using external components (MySQL, Redis) versus internal storage within the registry. Consistency models (Raft CP vs. AP) are explained, highlighting the trade‑off between strong consistency and availability.

High Availability

High‑availability considerations permeate the design, requiring failure‑aware architecture, data replication, and caching of service lists to tolerate node failures.

Summary

Assembling a production‑ready service registry involves step‑by‑step decisions from requirement analysis to technology selection, resulting in a clear blueprint that can be implemented with code.