The high availability features of MSE Microservices Registry help you build more resilient applications. These best practices are categorized by scope: instance high availability, service discovery high availability, and configuration management high availability. This topic uses the Professional Edition of MSE Microservices Registry as an example.
Recommended versions
spring-cloud-alibaba: 2.2.6.RELEASE or later.Dubbo: 2.7.12 or later.spring-boot: 2.3.x or earlier. We do not recommend using 2.4.x versions due to compatibility issues.
High availability for Microservices Registry instances
High-availability architecture
No service is 100% available. For high reliability and data security, deploy your instance with at least three nodes. If a node fails, traffic is rerouted to another node within seconds, and the faulty node is automatically removed from the cluster.
The Professional Edition of Microservices Registry is built on the Nacos 2.0 architecture. This design enhances disaster recovery capabilities and reduces reliance on underlying infrastructure for high availability. For more information, see Instance edition selection.
Multi-zone deployment
Each MSE region contains multiple zones. Applications in different zones within the same region experience low network latency (under 3 ms) while benefiting from fault isolation. A multi-zone instance deploys physical servers across different zones. If a failure occurs in Zone A, traffic is quickly redirected to Zone B. This process is seamless and requires no changes to your application code. Simply configure the node count, and MSE automatically handles the deployment across multiple zones.
Figure 1. MSE three-node active-active architecture
Figure 2. Multi-tiered disaster recovery architecture
Service discovery high availability
In service discovery, consumers and providers have distinct high availability features: consumers offer Push-through protection, while providers support disaster recovery.
Consumers
A consumer subscribes to a list of provider instances from the registry. When the registry undergoes changes, such as scaling or upgrades, or encounters unexpected events, such as a zone-wide network outage or power failure, subscriptions can fail, impacting consumer availability.
Configure empty list protection on the consumer side to prevent it from receiving an empty instance list during an outage.
Without empty list protection: If a consumer receives an empty list, your service is interrupted and reports an error.
With empty list protection: If a consumer receives an empty list, the protection mechanism activates, discards the update, and helps maintain service availability.
Configuration
This feature is only supported in nacos-java-client 1.4.1 and later. For compatible Spring Cloud and Dubbo versions, see Recommended versions.
Spring Cloud applications
Add the following property to your configuration:
spring.cloud.nacos.discovery.namingPushEmptyProtection=trueDubbo applications
Add the following parameter to the registry.url:
namingPushEmptyProtection=true
Persistent caching
When empty list protection is enabled, the cache directory may be lost if the application's container restarts. To prevent this, make the cache directory persistent, for example, by mounting a volume.
The cache directory is located at: ${user.home}/nacos/naming/${namespaceId}.
Providers
The disaster recovery feature for providers helps prevent cascading failures in your cluster during traffic surges.
Providers registered using nacos-java-client 2.x versions do not support the provider-side disaster recovery feature.
Without disaster recovery
When a sudden increase in consumer requests pushes providers to high utilization, some may fail:
The registry removes the failed node and redirects all of its traffic to the remaining nodes.
The load on the remaining provider nodes increases, making them more likely to fail as well.
Eventually, all provider nodes may fail, causing a complete service outage.
With disaster recovery
When a sudden increase in consumer requests pushes providers to high utilization, some may fail:
The registry marks the failed node as unhealthy.
If the percentage of unhealthy nodes exceeds the protection threshold, disaster recovery activates. The registry then returns all registered nodes (both healthy and unhealthy) to consumers.
This strategy prevents a complete service outage by distributing traffic across all registered nodes, even if some are unhealthy.
Enable disaster recovery
Supported instance types
Persistent instances: Fully supported.
Non-persistent instances:
nacos-java-client1.x: By default, unhealthy instances are removed after 30 seconds. A removed instance is not counted toward the protection threshold, preventing the disaster recovery policy from activating.nacos-java-client2.x: Not supported. Instances are taken offline immediately after the persistent connection is lost, so the disaster recovery policy cannot be triggered.
Configure by using the command line
Update the threshold for a specific service
curl -X PUT "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider&protectThreshold=0.6"${nacos.address}: The address of the Microservices Registry.namespaceId: The namespace ID. Default value: public.serviceName: The service name for a Spring Cloud application or the interface name for a Dubbo application.
Query the threshold configuration
curl -X GET "${nacos.address}/nacos/v1/ns/service?namespaceId=public&serviceName=my-provider"Response
{"namespaceId":"public","groupName":"DEFAULT_GROUP","name":"my-provider","protectThreshold":0.7,"metadata":{},"selector":{"type":"none"},"clusters":[]}
Microservices Governance high availability configuration
Improve application availability further by using Microservices Governance features such as graceful startup and shutdown, outlier instance removal, and service degradation.
Configuration management high availability
The high availability of configuration management relies on two main aspects: the client-side cache and backup directories, and the multi-layered throttling capabilities of the configuration center.
The following high availability capabilities for configuration management are enabled by default in the Professional Edition of Microservices Registry. No action is required.
Client
Cache directory: Each time the client retrieves data from the configuration center, it saves the latest configuration to a local cache directory. If the server becomes unavailable, the client falls back to this local cache.
Backup directory: If the server is unavailable, you can manually update files in the local backup directory. The client prioritizes loading from this directory, simulating a server-pushed configuration update.
Configuration Center
In addition to high availability at the infrastructure level, the configuration center service implements multi-dimensional rate limiting to enhance stability. This includes limits on the maximum connections per node and connections per client IP. It also includes rate limiting for configuration publications per second and per minute, and provides fine-grained throttling for individual configurations. These measures help mitigate the risk of server downtime caused by abnormal traffic.