Scenarios

Microservice Registry and Discovery

The microservice architecture should solve the communication problem between microservices. Compared with the traditional communication bus and LB solutions, the registry and discovery mechanism implements load balancing on clients and has advantages in communication efficiency and elasticity. CSE provides a highly available, stable, and O&M-free service registration center for development frameworks such as Spring Cloud, Dubbo, and ServiceComb.

The microservice registry and discovery mechanism is implemented through the service registration center.

• Service registration: When a microservice instance starts, it sends a registration request to the service registration center to register its metadata (such as the service name, IP address, port number, and version number) with the registration center. The registration center stores the information in an internal data structure for subsequent query. The service provider sends heartbeat messages containing health information such as the service running status, workload, and resource consumption to the registration center at a fixed interval to notify the registration center that the service provider is active. The registration center receives and records heartbeat messages, and determines the service availability based on the message status and content. If no heartbeat message is received within a specified period, the registration center marks the service instance as unhealthy. If no heartbeat message is received after the timeout period, the registration center removes the instance from the available service list. When the service instance resumes sending heartbeat messages, it can be re-registered.
• Service discovery: Service consumers directly interact with the registration center to obtain service provider's instance information and implement load balancing locally. In the microservice architecture, service provider instances may change due to various reasons (such as scale-in, scale-out, and faults). Service consumers can listen to the registration center to detect these changes in real time and update the local service instance list in a timely manner to ensure that available service providers can be accurately found during subsequent service calling.

Dynamic Configuration Management

The configuration center provides centralized configuration management to implement differentiated configuration for different environments, clusters, and instances. Configuration changes are dynamically made during running, which is more efficient and standard than those made through the traditional configuration file mode.

The configuration center can be used in the following ways based on its usage:

• As a deployed environment configuration, it is integrated with the deployment delivery service, for example, the application.yaml file of the common Spring Cloud service to carry configuration information such as the application data source and access private key.
• As an O&M parameter configuration, it is integrated with the O&M service, for example, to dynamically adjust the log level and the number of connection pools.
• As a service parameter configuration, for example, it dynamically changes the product price discount, bulletin, and winning rate.

During startup, a microservice sends a request to the configuration center to obtain its configuration information. The configuration center reads the corresponding configuration data from the storage based on the microservice request and returns the data to the microservice. Then, the microservice parses the received configuration information and loads it to the memory for the application to use.

In the configuration center, administrators define dedicated dark launch configuration items based on dark launch requirements. These configuration items are distinguished from normal production configurations and can be associated with specific identifiers (such as dark launch version numbers and user group identifiers).

1. Upon startup, the microservice pulls basic configurations from the configuration center and carries its own identifier (such as the service name and version number) and dark launch identifier (if the dark launch group to which the microservice belongs has been determined).
2. After receiving the microservice request, the configuration center determines whether the microservice is in the dark launch range based on the identifier carried. If yes, the configuration center searches the dark launch configuration storage area for the corresponding dark launch configuration and returns the configuration. If no, the configuration center returns the normal production configuration.
3. During running, the microservice dynamically pulls the updated dark launch configurations based on the notification mechanism (such as persistent connection push and scheduled polling) of the configuration center. When the dark launch configuration changes, the configuration center notifies related microservices in a timely manner. The microservices pull and apply the new dark launch configurations.