All Products
Document Center

Product Architecture

Last Updated: Aug 17, 2020


SOFARegistry has four roles: Client, SessionServer, DataServer, and MetaServer, each with unique capabilities and responsibilities. They are combined to provide services to external users. The relationships and structures of them are explained as follows:


The main components of SOFARegistry are:

  • Client: provides basic API capabilities to allow app systems to access SOFARegistry. The app systems that depend on the client JAR package can call the service subscription and publishing features of SOFARegistry through programming.
  • SessionServer: grants clients access to SessionServer, and accepts service publishing and subscription requests from clients. It also serves as an intermediate layer to forward the published data to DataServer for storage. The SessionServer can be infinitely scaled up to support connection with large amounts of clients.
  • DataServer: is responsible for storing data published by clients. It stores data by data ID through consistent hashing. DataServer supports multi-replica backup to ensure high availability of the data. DataServer can also be infinitely scaled up to support large amounts of data.
  • MetaServer: is responsible for maintaining the consistency lists of SessionServer and DataServer within the cluster, and immediately notifies other nodes when a node change occurs. MetaServer ensures high availability and consistency based on SOFAJRaft.


The following figure shows the current RPC framework.


It mainly consists of the following two parts:

  • core and core-impl are the core functions, including APIs and some extension mechanisms.
  • extension-impl contains different implementation and extension, such as integration and extension of HTTP, REST, Metrics and other registries. For example, when integrated with Bootstrap, extension-impl supports protocols; when integrated with remoting, it supports network transmission; when integrated with registry, it supports registries.


DRM3 architecture design

In DRM3, configuration item values are not pushed through SOFARegistry. Instead, the data storage system zdrmdata is added, which stores the values to the database. When the value of a configuration item is updated, a command is pushed through SOFARegistry in a specific format to notify the app. Then the app initiates an HTTP request to zdrmdata to read the updated value. The following figure shows the process.


The interaction process in the preceding figure is applicable to DRM Client versions earlier than 3.7.0. In DRM Client 3.7.0 or later versions, the registration model is simplified. That is, DRM implements the push logic internally instead of through Confreg. The following figure shows the push logic in DRM Client 3.7.0 or later versions.


In the simplified interaction process, the intermediate node sofaops is reserved to remain compatible with clients of earlier versions, which use Confreg to subscribe to configurations. This intermediate node will be removed in the final state. The data pushed each time is allocated with a version number, which automatically increments. To obtain data from zdrmdata, the client needs to initiate a request that carries the version number parameter, ensuring that the obtained data is effective.

In the entire model of DRM, when the value of a configuration value changes, a command containing the value version number is pushed to the client and the command only serves as a notification. Then the client needs to initiate an HTTP request to pull the updated value. To improve the data reading efficiency, zdrmdata uses a multi-level cache mechanism. In this mechanism, the HTTP request is first sent to Nginx of zdrmdata. If the request hits in the shared memory of Nginx, the HTTP request is converted to the one to read the persisted configuration file on the disk. Otherwise, the HTTP request is transparently transmitted to Java Server. If the request still fails to hit in the memory of Java Server, it is transmitted to the database.


DRM3 architecture and push process

The following figure shows the DRM3 architecture.


The complete push process of DRM3 is as follows:

  1. A user logs on to the console and click Push.
  2. dsrconsole writes the latest push data into the DB and the DB returns the latest version number of the key.
  3. dsrconsole delivers the push message to a drmdata machine in the same data center. The message content includes: the key, value and version.
  4. After receiving the push message, the drmdata machine broadcast pushes a message to all the drmdata machines in all data centers.
  5. After receiving the broadcast push message, each drmdata machine queries the information of persistent connections established by clients based on the key, and sends the latest version of the key to clients through the persistent connections.After receiving the push message, clients use the latest version number of the key as notified by the drmdata to randomly call HTTP APIs for configuration pulling that are provided by drmdata machines in the same data center to pull the latest configuration.


The following figure shows the architecture of Guardian.


Guardian works in the following two processes:

  1. The Guardian console pushes the throttling rules
    When your business apps have integrated with Guardian, you need to edit the throttling rules in the Guardian console and push the edited rules to clients before the throttling rules take effect.
  2. Match traffic with throttling rules and determine whether to throttle the traffic.
    Traffic flowing into a business app is first intercepted by Guardian, which judges whether the current traffic matches the throttling rules. If the traffic matches the throttling rules and reaches the preset limit value, it will be throttled.