Shulou(Shulou.com)06/02 Report--

Walk with you, look up is the starry sky.

This article is sorted out from the live sharing of Nacos Committer Zhang long, and Alibaba middleware is authorized to release.

With the release of Nacos 1.0.0 stable release, more and more enterprises are gradually deploying Nacos in test / rehearsal / production environments. At present, except that some enterprises are already in the process of transforming the distributed architecture, they will consider using Nacos production directly, but there are still many enterprises will consider some more practical problems:

How do stock users migrate registries to Nacos? How to synchronize between multi-regional registries? How do existing registries and Nacos coexist?

Here, I will answer these three questions through an introduction to Nacos Sync.

What is Nacos Sync?

Nacos Sync is a synchronous component that supports a variety of registries, based on the SpringBoot development framework, the data layer uses Spring Data JPA, follows the standard JPA access specifications, supports multiple data source storage, and is implemented by default using Hibernate, which is more convenient to support automatic table creation and update.

The following figure is a conceptual map of the Nacos Sync system. Nacos Sync synchronizes the data of registered service instances to Nacos by pulling from each registry. There are different registries on the left and right. Green represents bidirectional synchronization, while blue represents only one-way synchronization.

Component characteristic

Nacos Sync uses an efficient event asynchronous drive model and supports a variety of custom events, so that a stand-alone machine with a delay control of 3smai 8C16G can support 6K synchronous tasks.

In addition to stand-alone deployment, Nacos Sync also provides a highly available cluster deployment model. As a stateless design, it supports the migration of tasks and other state data to the database, which makes cluster expansion very convenient.

System module architecture

The following picture is the current system architecture diagram of Nacos Sync, which is relatively simple, but only describes some of the more important modules.

Web Console: provides users with registry and synchronization tasks for related interface operations

Processor Frame: business processing logic for registries and tasks

Timer Manager: regularly polling the database to get synchronization tasks for processing

Event Frame: asynchronous events to synchronize and delete synchronous tasks

Extension: an extended implementation of docking various registry clients

Overall call flow

Let's take a look at the complete call flow of Nacos Sync:

To add relevant registries through the Web console, it is generally necessary to configure two registries, one for the source registry and the other for the target registry. The registry-related data will be written to the database.

After adding the registry, add a synchronous task and add services that need to be synchronized (RPC interface for Dubbo and application name for Spring Cloud); Nacos Sync fetches synchronous tasks from the database every 3 seconds and publishes them through asynchronous events; synchronous service management listens for events published by scheduled tasks, and there are two kinds of events: synchronization / deletion Synchronization service management selects relevant synchronization services according to different policies for real synchronization logic processing; synchronization types are already supported

The following table describes several types of synchronization currently supported and whether synchronization is supported under Dubbo and Spring Cloud. Several registries listed in the table interact with Nacos, whether one-way or two-way synchronization.

Working with scenarios and Demo

Sharing services among multiple network interconnected Region, breaking the service invocation restriction between Region

Bi-directional synchronization to support smooth migration of Dubbo+ZooKeeper services to Dubbo+Nacos

Two Demo are provided here to demonstrate the two classic usage scenarios above. Detailed steps can be accessed through the link below.

One-way synchronization scenario, in Spring Cloud ecology, Eureka synchronization to Nacos example

Https:// os-sync-example/tree/master/one-way-sync https:// os-sync-example/tree/master/two-way-sync

Version evolution

Nacos Sync has so far released three small versions, and through the figure below, we can see some of the work that has been done by each version, as well as some of the things that will be done in the next version.

0.4.0 Planning introduction

Functional robustness

Synchronization data consistency check, before version 0.4.0, after the synchronization task is executed, the two-end data consistency is not checked.

Registry health check

User experience

The real-time status of synchronization data is revealed. Before version 0.4.0, the task status of the console was the task execution status of the database, and users had no way to know the current data status.

Batch deletion of tasks

Multi-dimensional task synchronization is added, optimization only supports service granularity, and users can only add user experience one by one.

Perfect function

Supports two-way synchronization between Eureka/Consul and Nacos

Original text link

This article is the original content of Yunqi community and may not be reproduced without permission.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.