preface

NacosAP schema source code analysis directory

  • How to choose a registry under microservices
  • Nacos use and registration part of the source code
  • Nacos service heartbeat and health check source code introduction
  • Nacos service discovery

Nacos source code structure introduction

Nacos version is based on version 1.4.0, and the overall project structure is as follows:


See directory, the first feeling is clear responsibilities, master the sense that gives a person is, on source part I has not seen it all, just finished watching the registry related at present, the center of the configuration is looked slightly, I first to introduce the function of the key modules, then we combine the above a few articles to understand the source code:

  1. Address module: mainly queries the number of nodes and IP list in nacOS cluster;
  2. API module: mainly to the client call API interface abstraction;
  3. Client module: mainly to rely on THE API module and the common module, the implementation of the API interface, for nacOS client use;
  4. CMDB module: operation data is mainly stored in memory, this module provides an interface to query data labels;
  5. Config module: mainly manages service configuration, provides API to pull configuration information to the client, and provides updated configuration. The client updates configuration information through long polling. The data store is Mysql;
  6. Naming module: mainly serving as the implementation module of the service registry, with functions of service registration and service discovery;
  7. Console module: Mainly implements interaction with the front end. It has functions such as permission verification, service status and health check.
  8. Core module: main initialization property loading, listener related content, used to load the default configuration information of nacOS, config and naming are dependent on this package;

I think the above 8 modules are relatively important and must be mastered for everyone to study the source code of Nacos. The dependencies between the relationships are as follows:


The call relationship between modules is as follows:



See the call relationship can feel out, overall source code is not too difficult, the patience to see or can understand.


Nacos AP mode source code core part of the introduction

The service registry

Nacos Client registers service information (including service name, IP address, port, status, etc.) in the Nacos Server registry through the/Nacos /v1/ NS /instance interface. The internal object Map> serviceMap is stored in the Class ServiceManager. This is a nested structure of two layers of maps. The first layer Key is the Namesapce name, and the second layer Key is the Group name and Service name. The Value of the second layer is the object of the Service.

Service is the heart

After the user service and order service are registered, each client will continuously notify Nacos Server by maintaining a scheduled heartbeat through a scheduled task. By default, the heartbeat will be sent once every 5s.

Service health check

Nacos Server checks the health of registered service instances through scheduled tasks. It sets its healthy attribute to false for instances that have not received a client heartbeat for more than 15 seconds (the client service does not detect it). If an instance has not received a heartbeat for more than 30 seconds, Reject the instance directly (the deleted instance will be re-registered if heartbeat is resumed);

Service synchronization

Synchronization service I think mainly divided into two aspects, one is the synchronization between Nacos Server cluster, will be/Nacos/v1 / ns/instance/distro/datum synchronization service instance information to each other, Second, the service consumer synchronizes the change to the Client. The service consumer (Nacos Client) will receive the service change information pushed by UDP from the server (when abnormal service is detected, the service changes) and timely update it to the local cache. This is the highlight of Nacos and other registries. When the interview can chat with the interviewer, will let the interviewer in front of a bright, because UDP itself is not reliable, can not ensure that all changes of information can be synchronized to the client, so consumers have a scheduled task to the bottom mechanism;

Talk about the harvest

After reading this part of the source code harvest I think there are mainly two aspects of the harvest:

Technical aspects

Technical aspects of the harvest is the most, here are a few simple examples:

  1. From the design of the overall framework, or to the class implements the design of the module, single streaming principles embody all, below is the overall framework design, reflect on the code is responsibilities clear, each module dependencies is clear, the other plug-in framework level do thoughts, thoughts of high availability, and we can learn;


  2. Many technical details of the implementation is very subtle, such as service changes when the asynchronous queue design, CopyOnWrite ideas, the application of Spring event mechanism and so on, these are in my blog source analysis details, we can spend a little effort to see;
writing

In fact, this part has not formed a complete idea, just a preliminary thinking, about this source code analysis, the following will be used later:

  1. Framework selection thinking, analysis of similar middleware comparison;
  2. Framework building and application introduction;
  3. Source code module description and framework module functional description, similar is to do a whole function;
  4. Analysis of the source code of each module function, along with the sequence diagram and class diagram relationship, I will carry out a transformation of the content of the Nacos series of articles later;
  5. After completing the introduction of each module will be unified to do the overall key steps of the code source analysis diagram and summary;

The end of the

Welcome everyone little attention, little praise!