Flowchart
Last updated
Was this helpful?
Last updated
Was this helpful?
Upon start, send registration information to registry center according to config file (e.g. server.xml)
Upon running, regularly report heartbeat information to the server.
Upon start, subscribe to registry center according to config file and cache the response from registry center inside cache.
Upon running, based on some load balancing algorithm, connect with RPC servers.
Local cache: Need local cache to improve performance.
Snapshot: This snapshot in disk is needed because the network between consumers and registry center are not always good. If consumers restart and connection is not good, then consumers could still read from snapshot (there is no cache so far).
When RPC servers have changes, registry center will notify RPC clients on these changes.
Service providers report heartbeat messages to service registry.
Take the example of Zookeeper:
Upon connection establishment, a long connection will be established between service providers and Zookeeper with a unique SESSION_ID and SESSION_TIMEOUT period.
Clients will regularly report heartbeat messages to the Zookeeper.
If Zookeeper does not receive heartbeat messages within SESSION_TIMEOUT period, it will consider that the service provider is not healthy and remove it fromm the pool.
Multiple registration center deployed
Different gateways/business logic units are connected to different registration center
What if a pushdown instruction arrives at the wrong registration center
Gossip protocol to discover between different registration centers
Cons: Long message delay / Forward redundancy
Pros: Suitable for large number of clusters. Used in P2P, Redis cluster, Consul
Administrative functionalities:
Update a service provider's information
Blacklist and whitelist service providers
e.g. Service providers in production environments should not register inside register center of test environments.
An open source implementation for Gossip
