Introducing Nacos: Alibaba’s Open Source Solution for Cloud-native Development

What is Nacos? What problems can it help solve for cloud-based applications?

This article is part of the Alibaba Open Source series.

As a recent addition to the Alibaba ecosystem, open source platform Nacos (short for Naming Configuration Service) offers developers an easy-to-use framework for service discovery, management, and configuration in cloud-native applications. Since its July 2018 debut, the system has gained attention for its numerous advantages in a variety of key areas, generating interest in the fundamentals of what it is, how it works, and what kind of problems it can solve, as well as best practices.

In this series, we explore these themes in detail, highlighting takeaways developers and technical audiences can apply to their own work. This first article focuses on defining what Nacos is and the problems it can help solve, with focus on its configuration management capabilities.

Before Nacos: Configuration Pain Points

In application development, configurations are an inseparable aspect of the codes they are deployed with, playing a key role throughout an application’s entire lifecycle. Traditionally, three types of configuration methods have offered competing advantages and drawbacks for developers to balance — namely hard coding, configuration files, and database configuration tables.

As a novel framework, Nacos avoids these inherent drawbacks with solutions designed for ease of use. The following sections examine the previous approaches and their problems individually before exploring the improvements introduced by Nacos.

The hard-coding approach

Of conventional methods, hard coding generally presents the most problems for configuration. In hard-coded configurations, configuration items exist as the fields in a class, as shown in the following image.

This approach presents three major problems.

First, applications must expose their corresponding interfaces in order to achiever dynamic configuration modification, whether they are the Controller’s API or JMX.

Second, all configuration modifications are non-persistent, as they are done in memory. This means that an application’s configuration will be restored to default values whenever the application restarts, introducing a host of problems for developers.

Finally, hard coding introduces considerable maintenance cost issues. With this approach, machines must be reconfigured one by one, which becomes labor-intensive when a number of machines are involved.

The configuration file approach

An alternative but similarly flawed approach to configuration is the use of configuration files. In Spring — a framework Nacos is specifically designed to support — typical configuration files include properties, yml, and self-defined files with a *.conf suffix.

Using configuration files effectively avoids the problem of default value restoration that plagues hard-coded configurations, but leaves the other two issues unresolved. As with the hard-coding approach, configuration files allow for dynamic configuration modification by way of exposing the corresponding interfaces, with the one difference being that configuration files introduce a persistence logic. Nevertheless, reconfiguration remains possible by logging in to the machine, modifying its configuration, and then restarting the machine. To avoid restarting, a scheduled task can be added, such as reading the configuration file every 10 seconds.

Compared with hard coding, using configuration files presents a step forward in terms of its persistence logic and task scheduling aspects.

The database configuration table approach

With database configuration methods — the last of the conventional methods used for configuration — the database can be a relational database such as MySQL or a non-relational one such as Redis. The following table shows one such example.

Database configuration tables manage configurations after separating them from their applications, which greatly reduces the costs of maintenance. Some may wonder how a database configuration table can realize dynamic configuration updates, for which there are two possible answers.

As with the use of configuration files, one solution using database configuration tables is to expose interfaces and add persistence logic. However, instead of creating a configuration file, database configuration tables use databases to store the configuration, which is then read by programs periodically. This allows for updating the configuration of an entire cluster of machines simply by calling the configuration management interfaces of one of the machines, which significantly reduces maintenance costs.

The second possible solution is to modify the configuration in the database directly. The modified configuration is then read by programs through a scheduled task.

While database configuration tables are able to address the main problems present in the hard-coding and configuration file approaches, it is nevertheless heavy and inelegant, leaving much room for improvement.

Configuration Management in Nacos

As an alternative to the above methods, Nacos offers an elegant solution to the issues of dynamic modification, persistence, and maintenance costs by managing configurations centrally after first separating them from their applications.

Nacos eliminates any need to add configuration management interfaces, realize configuration persistence, or introduce scheduled tasks, instead of handling these functions on its own. This is possible through configuration management features that bring together all of the logic related to configuration while providing an SDK for easy application management in Nacos.

Putting Nacos to work in Spring

Requiring just three steps, applying Nacos in the Spring framework offers a strong illustration of its advantages.

First, users should add the Nacos Spring dependency, as shown below.

Next, users should add the @EnableNacosConfig annotation to enable the configuration service. In the example code below, @NacosPropertySource is used to load the configuration source with “dataId” as “example”, and autorefresh is enabled.

Finally, users should specify the property value through Spring’s @Value annotation, as shown below. It is important to note that a Setter method is needed to enable autorefresh of configuration updates.

As well as being simple and brief, the above steps involve almost no intrusion into the application itself. With the addition of just one dependency and two annotations, Nacos can successfully assume configuration management.

For Nacos Spring users, achieving dynamic configuration updates simply requires setting “autoRefreshed” as a Boolean value in their applications. To modify configurations, they can call the Nacos API or use the Nacos console. After configurations have been updated, Nacos will then push the latest configuration to all machines involved with the application, vastly simplifying the entire process.

Looking Ahead

Nacos’ configuration management features are some of its most impressive, offering an efficient and elegant solution to labor-intensive issues at the heart of application development. As well as functions discussed in this article, technical audiences may wonder about gray release, version management, fast rollback, listening query, push track, access control, and encryption, among others. Some of these functions are already supported in the open source Nacos project, while others are provided in Alicloud’s Application Configuration Management (ACM) service, currently free of charge.

Ahead, this series will look more deeply into the technical fundamentals enabling the simple but powerful Nacos framework, as well as more of the problems it can help to solve and its developmental origins.

As an open source project, the Nacos community invites interested readers to learn more by becoming involved.

(Original story by Huang Xiaoyu黄晓禹)

Alibaba Tech

First hand and in-depth information about Alibaba’s latest technology → Facebook: “Alibaba Tech”. Twitter: “AlibabaTech”.