Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Nacos series 2: introduction to the structure of the Nacos project

2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

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

Today, we analyze the Nacos project package module structure, are responsible for what functions, from the overall look at the entire project, from the overall to the details, have not downloaded the source code students, hurry up! https://github.com/alibaba/nacos, This is the github code address, Start before you start to pay attention, Add watch, Follow-up Nacos mailing list will also notify you, You can pay attention to the latest real-time news of Nacos, And the wonderful discussion between the Daniel.

As of this article, the latest code is version 0.2.0 on the master branch. The new open source version iterates more frequently. It is likely that a certain class or module dependency will be different in the next version. Please do not doubt.

By analyzing the pom module dependencies in the Nacos source code project, the following dependencies of each module are drawn. Each component corresponds to a maven module in the project. We focus on the dependencies of modules related to the project code. The dependencies are from top to bottom. The right part of the figure below:

cdn.nlark.com/lark/0/2018/png/4232/1537615415981-071b6819-6643-49c3-94fa-68a7e54908fd.png">

Next, we will describe the responsibilities and dependencies of each module in the Nacos project.

Console module:

Currently it is empty. According to the version plan of Nacos, it is expected that in version 0.3.0, Nacos console related code and front-end resources will be placed in this module. It depends on config and naming modules. It can be seen from this that the api that the consumer front-end depends on will be directly provided by these two modules.

config module:

As you know, Nacos currently has three core functions, one of which is dynamic configuration discovery. In this package, the code of the configuration center is placed. Open the module. The internal package structure is as follows:

Basically, you can guess from the name, so I won't explain the specific implementation in detail here, and there will be chapters later. The project is built based on spring boot, so there will be an entry class Config, which opens the spring boot loading entry method familiar to Spring boot players, SpringApplication.run(Config.class, args)

naming:

This is another core function of Nacos code module, dynamic service discovery, the internal package structure is as follows:

Similar to config module, NamingApp is the entry class of spring boot, the others are isolated by packages, the names of each package, you can guess what function it is responsible for.

core module

As can be seen from the above figure, it is directly dependent on config, which is empty at present. It seems that it is still under planning. From the core, some core services may be extracted here for use by multiple functional modules, such as data layer and consistency protocol.

common module

At present, it is indirectly dependent on config through core. Open the code inside. It is some common tool classes, as shown in the following figure:

At present, there are only these tool classes, naming is not currently dependent on, but when the subsequent integration with the config module, some classes that are commonly dependent will be placed in it later, such as request objects, exceptions, protocol structures, etc.

client module

This is the Nacos client code, service discovery and configuration management of the two functions of the client, currently in the engineering module has been unified, but, in the code package above, or separated, you can see from the package structure, as follows:

Obviously, it is divided into two modules, configuration and naming. Later, as the integration deepens, these will be merged one after another to truly achieve unification.

API module

This is mainly to extract the api of naming and config. From the structure, it is clearer. The specific implementation of api is still in the client module. Its package structure is as follows:

In the Nacos manual, the factory class used, NacosFactory, when building the corresponding instance, calls the api inside, according to different methods, and then constructs the corresponding instance through reflection:

public static ConfigService createConfigService(String serverAddr) throws NacosException { Properties properties = new Properties(); properties.put(PropertyKeyConst.SERVER_ADDR, serverAddr); try { Class driverImplClass = Class.forName("com.alibaba.nacos.client.config.NacosConfigService"); Constructor constructor = driverImplClass.getConstructor(Properties.class); ConfigService vendorImpl = (ConfigService) constructor.newInstance(properties); return vendorImpl; } catch (Throwable e) { throw new NacosException(-400, e.getMessage()); }}

Other non-engineering source code modules are used to put test cases, documents, packaging files, startup scripts, this will not be discussed in detail, we are interested in opening to see.

summary

Nacos project, contains the Nacos Server and Nacos Client2 project code, the subsequent console code will also be put into the total project, these codes are put together, for the use and learners, is very convenient, among them, Nacos Server, by configuration and service discovery of 2 major functions, respectively, by config and naming bearer, client and naming module code, there is no common dependency class, it can be seen that the protocol between client and server, is not related to language, There is no private application layer protocol involved. In this case, the access of multi-language clients will be much simpler. In the client module, these two functions are unified into the NacosClient module. The server is still a different module at present. The subsequent one needs to see the architecture fusion evolution of Nacos.

In general, the current Nacos project, the framework is set up, but some integration and optimization, are not clear, several packages are empty, functional and system architecture, is still in the planning, so we participate more, there are many opportunities and space for you to play, your proposal is likely to become Nacos standards, service for world-class engineering applications!

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report