Nacos, an open source project of Alibaba micro-services, recently released version v0.5.0, which mainly includes DNS-BasedService Discovery, support for Java 11, and continuous optimization of user experience of Nacos products. More in-depth gateway integration with the Spring Cloud architecture has evolved.

Publish dnS-f

In order to further reduce the cost of service registration and discovery in multi-language ecosystem, heterogeneous system and Kubernetes system, Nacos V0.5.0 released a DNS-F client to support exposing endpoints of services registered in Nacos in the form of domain names, so that third-party applications can easily search and discover.



Different from the Client SDK service discovery mode of Nacos, DNS-F provides Agent independent of application process. By intercepting domain name resolution requests of applications, Nacos provides dynamic domain name data push update, health check, abnormal node offline, and unified domain name management view for applications.

Nacos provides DNS protocol-based service discovery capabilities designed to help users solve three problems:

  • Service discovery in Kubernetes architecture

There is no doubt that the service discovery solution of Kubernetes architecture has always been based on DNS. Nacos DNS-F is currently available in open source. CoreDNS provides a plugin for Nacos Nacos-coredns-plugin, thus connecting coreDNS and NACOS services, which provides a path for further connecting service discovery and application service discovery (such as SpringCloud) within Kubernetes cluster in the future. It provides a foundation for Nacos to help applications manage Kubernetes internal and application services and domain names in a unified view in the future, thus helping users to simplify the construction and management of micro-service platform based on Kubernetes system.

  • There is still no standard protocol for service discovery

So far, there are many solutions found in the market services. Zookeeper, Consul, Eureka, Nacos and other solutions are found in JavaSpring ecology alone, not to mention in other languages and frameworks, Nacos provides DNS-F, It makes it easier for users to implement dnS-BASED service discovery (DNS-SD), which is a mature standard protocol and can effectively help users eliminate the risk of coupling to vendor proprietary service discovery apis.

  • Service discovery in heterogeneous and multilingual systems

In a medium and large enterprise, to upgrade the traditional enterprise architecture to the cloud native microservice architecture, the service registration and discovery of the legacy system and heterogeneous system is undoubtedly the first problem that must be solved. Another big promise of microservices architecture is that each microservice can choose its own language stack independently, but so far no single service discovery product has been able to provide 100% coverage of clients in various languages.

Take Zookeeper as an example. The clients with good quality of Zookeeper are only Java and C clients, so it is difficult for services and systems other than these two language systems to register and discover through Zookeeper. DNS is naturally supported by all languages, so it is very easy to use DNS for service discovery. Ideal for migrating applications to new microservices platforms.

Take Alibaba as an example, service discovery based on DNS-F mode has been one of the most important methods in alibaba’s production environment, which plays a pivotal role in discovering and opening up services provided by non-Java language business systems such as Ali Mom, Autonavi, Youku and Search. It has been five years since alibaba released the first Python version of DNS-F client, and the total installed usage of DNS-F has accounted for more than 40% of all internal VIPServer language clients, indicating its wide application. Not being tied to the proprietary VIPServerAPI is also the primary reason many lines of business prefer dns-f clients.

DNS protocol itself was born for WWW, not for service discovery. Therefore, in terms of protocol, DNS used in service discovery scenarios still has many minor flaws that need to be solved from the protocol level in the future, such as the problem of DNS cache TTL convergence. For example, the operating system and various languages support SRV Record field,DNS packet size limit and so on. But with the in-depth application of Kubernetes and microservice system in various industries, it can be said that DNS protocol has been necessary for further evolution of service discovery scenarios. Alibaba &Nacos will continue to explore and promote this aspect.

Support for Java 11



On September 25, Oracle officially announced the release of Java11, the first long-term support release since Java 8. Java11 features features such as ZGC, TLS 1.3, new algorithm-key protocol support, Lambda local variable syntax support, Taichichuan contains some improvements in the HTTPClient API, which is worthy of attention.

Focus ~ Submitting an issue to Nacos on Github is the best way to implement your needs and ideas!Copy the code

Nacos supports Java 11 in two main ways:

  • Nacos supports running on Java11
  • Upgrade the Nacos source development and build environment to Java11

Therefore, the status is now supported.

Implement dynamic routing of Spring CloudGateway

In order to realize the microservice architecture, the microservice gateway is essential. Nacos community is currently trying to make more connections and integration with Spring Cloud’s microservice gateway. @Xu Jinyu, founder of Spring Cloud Chinese community and author of redefining Spring Cloud Combat, recently contributed an example of how to implement dynamic routing capability based on Spring Cloud Gateway and Nacos. No doubt, Spring Cloud Gateway serves as the entrance of all request traffic. In the actual production environment, in order to ensure high reliability and high availability, and avoid restarts as much as possible, Spring Cloud Gateway dynamic routing configuration needs to be implemented. When this part is mature enough, it will be included in the official recommended implementation of Nacos.

4, TTL & Health Status Aggregation

In previous versions of Nacos, users often wondered why a registered instance could still be seen on the Nacos console when it went offline (down). This comes from services such as SpringCloud and Dubbo, where Eureka or Zookeeper have the ability to automatically unregister instances as the default behavior in the registry. However, when an instance of a service goes offline (down), the registry has two possible actions: one is to remove the instance from the list of instances under the service, or the other is to keep the instance and only make the instance state unhealthy. Registries such as Eureka and Zookeeper actually support persistent instance registrations, while Nacos simply makes this persistent registration the default behavior.

Nacos’s service discovery module is based on the internal VIPServer evolution. In the main scenario of VIPServer, services are registered to VIPServer through the console in the form of domain names, and VIPServer attaches great importance to the flexible “soft load” traffic scheduling capability brought by the definition of service-level metadata information, so the primary choice is the persistent storage of metadata of services and instances. Weakened the ability of the service provider to continuously send heartbeat to the VIPServer server, so the function of VIPServer to report and aggregate instance health status was not released in the early stage. Health checks for previous versions of service instances must be initiated by the VIPServer server. But as planned when Nacos was open source, Nacos will support both modes.

Nacos provides two health check modes, namely heartbeat reporting mode and server active detection mode, for complex cloud environments and network topologies, such as VPCS and edge networks.

So with the release of Nacos 0.5.0, we are pleased to announce that Nacos has officially supported ttL-based automatic logout of service instances. This functionality is partly in response to community demands for TTL functionality, but more importantly, it is a natural evolution of Nacos service discovery.

Since version 0.5.0, user registration by the client SDK examples, will open the default function of TTL, instance every 5 seconds will default to the server sends a heartbeat, if Nacos heartbeat not received within 15 seconds of a service instance, will the instance is not healthy, if not received 30 seconds heartbeat, will directly delete the instance. The TTL function of Nacos complements another behavior of Nacos as a registry in handling instance offline. With flexible and dynamically configurable parameters, users can switch between the two behaviors according to actual application scenarios.

Although the TTL function of Nacos is still experimental, it has the following features:

  • Further seamless integration into SpringCloud ecology and Dubbo ecology

Nacos was originally planned to help existing users migrate seamlessly. In addition to the functional integrity of the registry, the experience, performance, and important recognition can be carried over from the old registry. For example, Eureka, as the main registry in Spring Cloud, automatically unregisters instances after 90 seconds without receiving their heartbeat. Zookeeper, which is commonly used in Dubbo, also uses temporary nodes to implement the TTL function based on Session timeout. In both of these scenarios, the registration of service instances is basically done by the service Provider using the registry client. Nacos currently provides a complete solution for service discovery for the Spring Cloud architecture, and Dubbo adaptation and support will be released in a recent release.

  • Service level metadata is not automatically logged out

Nacos support services, multistage cluster and instance of other metadata information, as opposed to a service instance can be automatically logged off, the service itself of metadata information cannot be lost as the service referrals, because these are usually in creating a service metadata, artificially set up (such as load balancing strategy, weight rules, protect the threshold, etc.). This means that instances of the same service up and down, and then registered, should still retain the metadata information associated with the original service Settings.

Eureka or Consul does not support any meta information for service level Settings, so if an instance is temporarily offline, the entire service cannot be queried. Information and the service level of the yuan as a very important Nacos features, the future will be based on the features of open a series of flow control class, have decided the metadata information of Nacos service itself cannot be lost as the service referrals, instance, registered in the client, on the other hand, are not allowed to submit information service level of the yuan, This also ensures that the registration or unregistration of a single instance does not affect the service level configuration. We provide a console for easy creation and editing of service metadata.

  • Integrate HSF’s registry, ConfigServer, into Nacos

Within Alibaba Group, the well-known HSF registry ConfigServer supports long connection registration mode (renew&TTL), so instances will be automatically cancelled when long connections are disconnected. TTL is also the foundation of Nacos’s gradual incorporation of ConfigServer’s core capabilities into Nacos to support future migration and export of some of HSF’s best features to Dubbo.

At the same time, Nacos attaches great importance to the applicability of the product in the cloud. In the public cloud, the IP that users usually register with the registry is an external IP of the VPC. Due to the limitation of the public cloud security policy, the registry is generally not allowed to initiate the connection to the VPC for health check. The health status can be checked only by the heartbeat reporting mode of the client. The automatic deregistration function can be enabled only in this mode. The TTL function of Nacos this time well connects the needs of public cloud and internal ConfigServer output, making preliminary preparations for the subsequent convergence.

5. Support Spring Cloud Alibaba ecology



As Spring developers @Roy Clarkson and @Ollie Hughes explained in cloud-Native Javawith Spring Cloud Services at the SpringOne Platform Conference, To adopt the microservice design pattern, the first thing is to choose the implementation of “ExternalConfiguration”, “Service Registry” and “Circuite Breaker”. The project of Spring Cloud forAlibaba aims to export Alibaba’s experience in servitizing and distributed micro-services on the Cloud and pack it into a stack, providing you with a one-stop solution to support large-scale micro-services, as described in the project:

“The Spring Cloud Alibaba Project, consisting of Alibaba’s open-source Componentsand several Alibaba Cloud products, aims to implement and expose well knownSpring Framework patterns and abstractions to bring the benefits of Spring Bootand Spring Cloud to Java Developers using Alibaba Products.”

With the release of Spring Cloud for Alibaba 0.2.0, Nacos Config, NacosService Discovery and Sentinel Circuite Breaker have all come together.

Continue to optimize user experience

Improving product usability is always the core focus of the Nacos team. In Nacos 0.5.0, we have made positive fixes to some of the experience issues reported by the community, including front-end UI optimization, startup state display optimization, performance tuning, etc. For example:

177 Consolesupports registering new empty service and delete empty service. 222 printmore nacos server start status info in start.log. 251 ConsoleEditor Optimization. 254 DataIdand group are required in historical version and listener query. 258 Removethe Balloon of DataId/Group.


The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.