A microservice architecture involves service registration, service administration, dynamic configuration, and Remote Procedure Call (RPC). This topic describes the component architecture that provides these services.
SOFARegistry
SOFARegistry is the service registry that handles service registration and discovery. Its architecture is as follows:
Client: Provides the basic API for applications to connect to the service registry. Applications use the client JAR package to programmatically subscribe to and publish services.
SessionServer: Accepts client connections and receives service publishing and subscription requests from clients. It then forwards the published data to the DataServer for storage. You can scale out the SessionServer to support many client connections.
DataServer: Stores data published by clients. Data is sharded and stored based on the data ID using a custom slot allocation algorithm. The DataServer supports multiple replicas for backup to ensure high availability (HA). You can scale out the DataServer to support large amounts of data.
MetaServer: Maintains a consistent list of SessionServers and DataServers in the cluster. When a node changes, the MetaServer promptly notifies the other nodes. The MetaServer ensures HA and consistency through SOFAJRaft.
SOFARPC
SOFARPC is a distributed service framework that provides applications with a high-performance, transparent, and peer-to-peer solution for remote service invocation. Its architecture is as follows:
Core features: Includes the `core` and `core-impl` components, which contain the API and various extension mechanisms.
Extensions and implementations: This is the `extension-impl` component, which contains various implementations and extensions. These include integrations for HTTP, REST, metrics, and other registries. For example, `bootstrap` supports protocols, `remoting` supports network transport, and `registry` supports service registries.
DRM
DRM configuration values are not pushed through the service registry. DRM consists of two components: dsrconsole and drmdata. The dsrconsole component persists real-time push configurations and synchronizes them with drmdata. The drmdata component maintains registration links with various applications, caches the configuration when it receives a push notification from dsrconsole, and notifies subscribed applications to pull the configuration. After an application receives this instruction, it sends an HTTP request to drmdata to read the actual configuration value. The process is shown in the figure below:
In the DRM model, a configuration change push is only a notification. It pushes a version number, not the actual configuration value. The client pulls the actual value using an HTTP request after it receives the notification. To improve read performance, `drmdata` uses a cache. Requests are sent to the Java Server and filtered by its memory cache. Only a cache miss results in a request to the database (DB). The push flow is as follows:
The complete DRM push flow is as follows:
On the page, click the Push button.
`dsrconsole` writes the latest push data to the DB. The DB returns the latest version number for this key.
`dsrconsole` sends a push notification message to a `drmdata` machine in the same data center. The message includes the key, value, and version.
After `drmdata` receives the push message, it broadcasts the notification message to all `drmdata` machines in all data centers.
After each `drmdata` machine receives the push message, it queries the persistent connection information for all clients based on the key. It then sends the latest version number of the key to the clients over the persistent connections.
After the client receives the push message, it uses the latest version number from `drmdata` to call the HTTP API of a random `drmdata` machine in the same data center to pull the latest configuration.
Guardian
Guardian is primarily used for service throttling. Its architecture is as follows:
The Guardian workflow consists of the following four parts:
Component integration: The business application must first integrate Guardian.
Rule push: Edit throttling rules in the Guardian Console and push them to the client to take effect.
Traffic matching: When traffic enters the business application, the Guardian component intercepts it. Guardian then determines whether the current traffic matches a throttling rule.
Throttling activation: If the traffic matches a throttling rule and reaches the preset threshold, the traffic is throttled.
Service circuit breaking
Service circuit breaking prevents cascading failures. If a service fails or becomes abnormal, the circuit breaker trips. This stops other callers from waiting for the failed service, which prevents timeouts and system-wide failures. Its architecture is as follows:
Provider App: The service provider that publishes a service and registers it with the service registry.
Consumer App: The service consumer that pulls information from the service registry to use a service.
Service registry: This is SOFARegistry, a core component of the SOFA middleware. It stores the address information of all service providers and the subscription information of all service consumers. It establishes persistent connections with both consumers and providers to dynamically detect changes in service addresses and notify consumers.
The service circuit breaking process involves the following four parts:
Subscribe to configuration: The Provider App must first subscribe to the circuit breaker configuration.
Activate configuration: You can edit and push circuit breaker configuration values in the microservice console. Dynamic configuration (DRM) is used for dynamic adjustments. After the configuration is pushed, it takes effect for the subscribed Provider App.
Trip the circuit breaker: The Consumer App calls a service using an RPC. If the number of errors within a specified time window exceeds a threshold, the server-side circuit breaker is triggered.
Automatic recovery: When the circuit breaker is tripped, RPC calls will fail fast for a set time window. After this time window passes, the system allows a single request to pass through to check if the service has recovered. If the service has recovered, the circuit breaker closes automatically. If it has not recovered, the circuit breaker remains open, and the system waits for the next time window.
Service degradation
Service degradation helps manage high server load. When server pressure increases, non-critical services are either not processed or are handled in a simpler way. This frees up server resources to ensure that core services operate correctly and efficiently. Its architecture is as follows:
Consumer App: The service consumer that pulls information from the service registry to use a service.
Service registry: This is SOFARegistry, a core component of the SOFA middleware. It stores the address information of all service providers and the subscription information of all service consumers. It establishes persistent connections with both consumers and providers to dynamically detect changes in service addresses and notify consumers.
The service degradation process involves the following three parts:
Subscribe to configuration: The Consumer App must first subscribe to the degradation configuration.
Activate configuration: You can edit and push degradation configuration values in the microservice console. Dynamic configuration is used for dynamic adjustments. After the configuration is pushed, it takes effect for the subscribed Consumer App.
Trigger degradation: When the Consumer App triggers service degradation, it can no longer use the service and instead experiences fast failures. The business logic must then handle the effects of this degradation.