SOFARegistry is a production-grade, highly available, open source service registry from Ant Group. It uses an AP architecture, which emphasizes availability in the CAP theorem. SOFARegistry supports pushes that are delivered within seconds and uses a layered architecture for near-unlimited horizontal scalability.
SOFARegistry originated from Taobao's ConfigServer. Over the past decade, as Ant Group's business has grown, the service registry architecture has evolved to its fifth generation. Today, SOFARegistry powers all of Ant Group's internal services and also serves many of its partners. It is also compatible with the open source ecosystem.
Features
High scalability: It uses a layered architecture and data sharding to overcome the performance and capacity bottlenecks of a single machine. This design achieves near-unlimited horizontal scalability. SOFARegistry has been tested in Ant Group's production environment across a massive number of nodes and services.
High timeliness: It uses the SOFABolt communication framework to implement node liveness detection and push-based change notifications over long-lived TCP connections. Service online and offline notifications are delivered in seconds.
High availability: Unlike CP-based service registries such as Zookeeper, Consul, and etcd, which prioritize consistency in the CAP theorem, SOFARegistry uses an AP architecture. This architecture is tailored for service discovery and maximizes availability during network partition failures. It also uses multiple replicas in a cluster to tolerate its own node failures.
Service architecture
The service architecture is as follows:
In the diagram, SessionServer, DataServer, and MetaServer each form a distinct cluster. This allows each server type to be scaled out infinitely.
Client: Provides the APIs that an application uses to connect to the service registry. An application uses the client JAR package to programmatically call the service subscription and publishing features.
SessionServer: Accepts service publishing and subscription requests from clients. It also acts as an intermediary that forwards published data to the DataServer for storage. SessionServer can be scaled out infinitely to support a massive number of client connections.
DataServer: Stores the data published by clients. Data is sharded and stored using consistent hashing based on the data ID. It supports multiple replicas to ensure high data availability. DataServer can be scaled out infinitely to support massive amounts of data.
MetaServer: Maintains a consistent list of SessionServers and DataServers in the cluster. It promptly notifies other nodes in the cluster of any node changes. MetaServer uses SOFAJRaft to ensure high availability and consistency.