How to Design a Service Registry

1. What Is a Service Registry

• It records the service name <-> IP address + Port mapping. In essence, it is no different from DNS.
• 

2. Why a Service Registry Is Needed

Without a service registry, when A calls B it can only hard-code the IP address, which is inflexible.

3. How to Implement a Service Registry

3.1. Server Side

3.1.1. Service Registry Table

2. Centralized, strongly consistent storage middleware, such as ZooKeeper (ZAB algorithm) and etcd (Raft algorithm).
3. Decentralized, weakly consistent implementations, such as Eureka, Consul, and Nacos.

3.1.2. Infrastructure

1. Use infrastructure (DNS) to implement service discovery, such as SkyDNS and CoreDNS.

3.2. Client Side

3.2.1. Service Provider

3.2.1.1. Service Registration

• After the service provider finishes starting, call the service-registry API and write the service name + IP address + Port + status.

3.2.1.2. Service Deregistration

• The service provider periodically reports heartbeats to the registry. If no heartbeat is received for a period of time, remove it from the list.
• When the service provider shuts down, it actively calls the registry API to go offline.

3.2.1.3. Service Load Balancing

• How to Design a Load-Balancing Component.md

3.2.2. Service Consumer

3.2.2.1. Service Discovery

• poll: the service consumer periodically requests the registry.
• push: the registry pushes to the service consumer, using a long-lived connection to maintain heartbeats.
• long polling: the service consumer requests the registry, and the registry holds the request for a period of time and returns when there is data.

3.2.2.2. Service Routing

• The service consumer gets a list of nodes from the registry using the service provider’s name. If it needs to filter and select these nodes, that is service routing.

There are several routing rules:

3.2.2.2.1. IP

• Access a specified IP, which is convenient for testing and locating problems.

3.2.2.2.2. Proximity Routing

• Proximity routing: prefer calls within the same Zone to reduce network latency. The service provider needs to write the data-center identifier into the registry when registering, so the service consumer can decide how to route based on its own data-center information.

3.2.2.2.3. Service Grouping

• It may be necessary to deploy multiple groups of services for different consumers.

3.2.2.2.4. Service Version

• Versioning to support canary rollout.

3.2.2.2.5. Other Optional Rules

• Fault injection, circuit breaking, traffic mirroring, etc.

4. Service-Registry Components

4.1. Eureka

Eureka.md

4.2. Consul

consul.md

4.3. ETCD

etcd.md

4.4. ZooKeeper

ZooKeeper Service Registry.md

4.5. Kubernetes DNS

5. Selection

5.1. ZooKeeper vs. Eureka

	ZooKeeper	Eureka
Cluster mode	leader, follower (only the leader writes)	p2p (every node can write)
Consistency guarantee	CP	AP
Timeliness	A few seconds by default	1 minute by default

6. References

• Service Discovery - Service Registry Design
• Building a Service Registry in Go | rauljordan
• GitHub - jaypipes/gsr: Golang Service Registry library
• Understand Service Routing and Load Balancing, and Get Microservices Going - 51CTO.COM
• Service Routing | dapeng-soa
• A Deep Look at Eureka Architecture Principles and Implementation - Zhihu