×
Community Blog Start Your Cloud-Native Applications with the Open-Source Platform "Nacos"

Start Your Cloud-Native Applications with the Open-Source Platform "Nacos"

This article discusses Nacos, an open-source platform that makes it easier to build cloud-native applications.

By Wangtao

The open-source microservices field in China has ushered in a new member, Nacos. In the process of building the microservice registry and configuration center, a new trustworthy option became available for developers in China.

Nacos is an open-source platform by Alibaba that makes it easier to build cloud-native applications and supports dynamic service discovery, configuration management, and service management. It represents the best practices of Alibaba over the past decade. It can be used in core scenarios, such as microservice registries and configuration centers. Like other open-source microservices projects of Alibaba, Nacos is a typical example of something that started at Alibaba and matured in the community.

Why Did Nacos Need to Be Open-Source?

In the field of large-scale service discovery and governance, the existing open-source solutions have not been perfect. During the evolution from the IOE centralized application architecture to the Internet distributed service architecture, Alibaba has accumulated a lot of practical experience with service registration and service configuration, which can be reused on a large scale in various industries. More importantly, we hope to work with developers in the community, so Nacos can help enterprises in China build dynamic service discovery, configuration, and management capabilities for cloud-native applications more flexibly.

Compared with other service registration and configuration center open-source solutions, Nacos provides dynamic service discovery, sharing, and management functions, despite starting late. Nacos provides better performance, ease of use, and flexible distributed deployment in large-scale scenarios. The following table compares Nacos with Consul, Eureka, and ZooKeeper. This information was taken from "Analysis and Comparison of Mainstream Microservice Registries " [1]

Nacos Eureka Consul Core DNS ZooKeeper
Consensus Protocol CP+AP AP CP N/A CP
Health Check TCP, HTTP, MySQL, and Client Beat Client Beat TCP, HTTP, gRPC, and Cmd N/A Keep Alive
Load Balancing Weight, metadata, and selector Ribbon Fabio Round Robin N/A
Avalanche Protection Supported Supported Not Supported Not Supported Not Supported
Auto Instance Deregister Supported Supported Not Supported Not Supported Supported
Access Protocol HTTP and DNS HTTP HTTP and DNS DNS TCP
Listener Supported Supported Supported Not Supported Supported
Multi-Data Center Supported Supported Supported Not Supported Not Supported
Cross-Registry Synchronization Supported Not Supported Supported Not Supported Not supported
Spring Cloud Integration Supported Supported Supported Not Supported Not Supported
Dubbo Integration Supported Not Supported Not Supported Not Supported Supported
Kubernetes Integration Supported Not Supported Supported Supported Not Supported

Nacos supports multiple startup modes. You can choose to deploy functional modules, such as the registry and the configuration center separately or in combination, based on your business scenarios. This can fully support the evolution of the full lifecycle of microservices and the growth of small start-up companies into large enterprises.

In the "Who is Using Nacos" community survey, there were 140 messages from senders, such as Industrial and Commercial Bank of China (ICBC), iQIYI, Hikvision, APUS, and Shanghai Shizhuang Information Technology, but the amount of enterprises that use Nacos to build registries and configuration centers is a lot deeper. Huya.com is a typical client of the first client group to introduce Nacos on a large scale to the production environment.

Zhang Bo, Head of the Middleware Team of the Basic Security Department at Huya, shared thoughts at a developer event, "Huya paid attention to Nacos from Nacos v0.2. We also participated in the construction of the community, which made us a relatively early enterprise user. Before we introduced Nacos, we also compared Spring Cloud Config Server, ZooKeeper, and ectd, and conducted an overall evaluation. Based on the current microservices system situation and business scenarios, we decided to use Nacos as the solution for service registration and discovery during service-oriented transformation. When using Nacos, we found that with the continuous updates of the community version and the in-depth practice of Huya, Nacos has far more advantages than the others we researched."

From Open-Source to Business Value-Added

It seems that added business value has emerged since the birth of open-source Nacos. It is for enterprises that build businesses based on open-source but suffer from efficiency, time, cost, and stability issues. This provides more compatible options, which makes the open-source ecosystem develop healthily.

Alibaba Cloud Microservice Engine (MSE) is an open-source registration and configuration center service. MSE is a fully managed service. It provides clusters, such as ZooKeeper, Nacos, and Eureka, with high usability and free O&M. MSE is fully compatible with standard APIs of open-source products, which is out-of-the-box and needs no code modification. It provides customers with corresponding monitoring and O&M tools.

What is the difference between an MSE-hosted registry and a user-created open-source registry? The following table compares them:

Items for Comparison User-Created Registry MSE-Hosted Registry
Cost Resource Cost Elastic Compute Service (ECS) Cost MSE supports both pay-as-you-go and subscription billing methods, and the total costs are almost the same for configuring ECS instances.
Labor Costs Dedicated manual maintenance required MSE provides easy-to-use automated O&M with low requirements.
High Availability Disaster Recovery Not Supported MSE provides a multi-data center and multi-region disaster recovery.
Downtime Handling Manual Handling Automatic Detection and Recovery
Liveness Detection Not Supported MSE supports process liveness detection and automatic recovery for failures.
Features Data Management Command Line Interface (CLI) You can add, remove, query, and modify data in the MSE console.
Access Method You can directly access the user-created registry by using the IP address of the machine where the registry is deployed. The code modification is required if the machine changes. You can access an MSE-hosted registry by using the domain name. No code modification is required if the instance where the registry is deployed changes.
Business Alert Not Supported MSE provides multi-dimensional alert configuration for core business metrics, such as connection quantity.
Networking Local Network Virtual Private Cloud (VPC) network and public network
Service Management Not Supported MSE allows you to modify the service providers and subscribers in the MSE console.
Cluster Permission Management Not Supported MSE allows you to customize the permissions of Resource Access Management (RAM) users.
TPS and QPS Statistics Not Supported TPS and QPS monitoring views are provided.
O&M Cluster Observation Not Supported You can check the health status of nodes and roles in the MSE console.
Monitoring Charts Not Supported MSE provides various metrics, such as Znode, and the graphical view of the number of connections.
O&M Configuration Manual Modification and Restart You can modify the O&M settings in the MSE console and restart the MSE instance with one-click for the modification to take effect immediately.
Node Scaling Manual Scaling and Restart You can perform scaling on the MSE console with one-click.
Performance Scaling Not Supported You can perform scaling in the MSE console in one click.

From Understanding to Practice

How Can Dubbo Applications Be Seamlessly Migrated to MSE Without Service Downtime?

The following section uses a Dubbo application built in Spring Boot as an example to describe how to migrate the application.

Step 1: Introduce a Custom Registry Dependency for Migration

Although Dubbo provides the ability to configure multiple registries, it has great limitations. When multiple registries are configured for a consumer, Dubbo's policy is to preferentially select the address of the first registry. If the address is empty, Dubbo reads the address from the second registry, and so on. The ideal model is to randomly select the addresses of multiple registries after merging. For this reason, MSE provides a dedicated registry extension to solve this problem:

<dependency>
  <groupId>com.alibaba.edas</groupId>
  <artifactId>edas-dubbo-migration-bom</artifactId>
  <version>2.6.5.1</version>
  <type>pom</type>
</dependency>

edas-dubbo-migration-bom has two versions, 2.6.5.1 and 2.7.5, which correspond to Dubbo 2.6.x and Dubbo 2.7.x, respectively.

Step 2: Purchase an MSE Nacos Instance and Configure the Nacos Server Address

Purchase an MSE Nacos instance in the same VPC in the MSE console, and add the following content to the application.properties configuration file:

dubbo.registry.address = edas-migration://30.5.124.15:9999? service-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848&reference-registry=consul://${consulAddress}:8500,nacos://${nacosAddress}:8848

Notes:

edas-migration://30.5.124.15:9999

The header information of multiple registries is listed above. You can keep the default value. Enter the IP address and port number as needed to ensure the compatibility with Dubbo validation. During startup, if the log level is WARN or below, a warning log might be generated, which can be ignored.

service-registry

The address of the service registry is listed above. Enter multiple registry addresses. Each registry address is in the standard format of a Dubbo registry address. Separate multiple registry addresses with commas (,).

reference-registry

The address of the registry where the consumer subscribes to is listed above. Each registry address is in the standard format of a Dubbo registry address. Separate multiple registry addresses with commas (,).

Step 3: Check Whether the Dual-Registry Solution Is Successful

Start the application and you will find that the provider and consumer are registered on the Service Management page of the MSE Nacos instance.

1

Meanwhile, the relevant information is also displayed in the Consul console:

2

Check whether the application is accessible. So far, the migration of the first application is completed.

Step 4: Migrate the Rest Applications Based on the Steps of the First Application

Step 5: Delete the Migration Configuration

After migration, delete the old service registry configuration and the edas-sc-migration-bom dependency used by migration and restart applications in batches during idle hours. edas-dubbo-migration-bom is a starter dedicated to migration. Although it has no impact on your service stability, in the long run, it is not upgraded with the Dubbo version upgrade. To avoid compatibility problems during future framework upgrades, we recommend that you clean up after the migration and then restart applications in batches during idle hours.

How Can Spring Cloud Applications Be Seamlessly Migrated to MSE Without Service Downtime?

3

Usually, Spring Cloud supports only one registry by default, so seamless migration without service downtime cannot be completed. This section describes how to support the dual-registry/dual-subscription mode to ensure that your business is migrated without downtime.

Migration Plan: Select the first application to be migrated. We recommend starting the migration from the underlying providers. You can select any application to be migrated first if the trace is complex and difficult to analyze. Refer to the following steps to migrate the selected application:

Step 1: Purchase an MSE Nacos Instance and Configure the Nacos Server Address

Purchase an MSE Nacos instance in the same VPC in the MSE console, and add the following content to the application.properties configuration file:

spring.cloud.nacos.discovery.server-addr={the domain name of the MSE Nacos instance}:8848

Step 2: Add Dependencies to the Application

Add the spring-cloud-starter-alibaba-nacos-discovery dependency to the pom.xml file.

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
     <version>{相应的版本}</version>
 </dependency>

Under Spring Cloud, you can add only one registry to the dependencies in pom.xml by default. An error might be returned when you try to add multiple registries. To support multiple registries under Spring Cloud, add the edas-sc-migration-starter dependency.

<dependency>
     <groupId>com.alibaba.edas</groupId>
     <artifactId>edas-sc-migration-starter</artifactId>
     <version>1.0.2</version>
 </dependency>

To allow an application to subscribe to services from multiple registries, you need to modify the configuration of Ribbon, which is used for load balancing. In the main class of application startup, set the RibbonClients to MigrationRibbonConfiguration by default. Assume that the main class code is written like this:

@SpringBootApplication
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

The modified main class code is written like this:

@SpringBootApplication
 @RibbonClients(defaultConfiguration = MigrationRibbonConfiguration.class)
 public class ConsumerApplication {
     public static void main(String[] args) {
         SpringApplication.run(ConsumerApplication.class, args);
     }
 }

Step 3: Check Whether the Dual-Registry/Dual-Subscription Solution Is Successful

Start the application and you will find that the provider and consumer are registered on the Service Management page of the MSE Nacos instance.

4

The relevant information is also displayed in the Consul console.

5

Check whether the application is accessible. So far, the migration of the first application is completed.

Step 4: Migrate the Rest Applications Based on the Steps of the First Application

Step 5: Delete the Migration Configuration

After migration, delete the old registry configuration and the edas-sc-migration-starter dependency used by migration and restart applications in batches during idle hours. edas-sc-migration-starter is a migration specific starter, which does not affect service stability, but it limits the load balancing effect of Ribbon. We recommend clearing it up after migration.

Dynamically adjust service registries and service subscription policies:

The edas-sc-migration-starter dependency can dynamically adjust the service registration and subscription methods with the configuration center. After the migration is complete, you can modify your configuration to dynamically change the service registration and subscription methods.

The default subscription policy of dynamically adjusted service subscriptions is to subscribe to all registries and aggregate data.

You can modify the spring.cloud.edas.migration.subscribes property to select the registries for data subscription.

spring.cloud.edas.migration.subscribes=nacos,consul # Subscribes services from both Consul and Nacos.
spring.cloud.edas.migration.subscribes=nacos        # Subscribes services only from Nacos.

The default registration policy for dynamically changing service registration is to register with all registries. You can modify the spring.cloud.edas.migration.registry.excludes property to specify the registry you want to disable.

spring.cloud.edas.migration.registry.excludes=   # The default value is NULL, which indicates that services are registered with all registries.
spring.cloud.edas.migration.registry.excludes=consul   # Disables the registration with Consul.
spring.cloud.edas.migration.registry.excludes=nacos,consul   # Disables the registration with Nacos and Consul.

About the Author

Wangtao (GitHub ID @ralf0131) is an Apache Dubbo PPMC Member, an Apache Tomcat PMCMember, and a Senior Technical Expert with Alibaba.

0 0 0
Share on

Aliware

33 posts | 2 followers

You may also like

Comments