Shulou(Shulou.com)05/31 Report--

This article mainly explains "how Ignite defines a data node". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how Ignite defines a data node".

As a system, a possible architecture consists of the following levels:

Ignite cluster layer

Persistent storage layer

External application layer

In this article, we will focus on the first layer (Ignite cluster layer). You can refer to a GitHub project, which contains the building blocks necessary to implement the proposed micro-service architecture on a daily basis, especially to cover the following parts:

Configure and start the data node

A typical service implementation of a service using Ignite API

Configure and start a service node that hosts Ignite services

A virtual application that connects to the cluster and triggers service execution.

Data nodes when microservices are located on top of the in-memory data grid architecture

A data node is a server node that holds part of the data of a dataset, and the application logic side performs queries and calculations on the dataset. In general, this type of node is transparent to the application logic because these nodes simply store the dataset and then process it efficiently when the application accesses the data.

You can download the GitHub project and find data-node-config.xml, which will be used to create a new data node that contains a set of paragraphs and parameters related to the data node.

First, you need to configure a specific node filter for each Ignite cache to be deployed to the cluster. This filter is called when the cache is started, and it defines a subset of the cluster nodes where the cached data is to be stored-the data node. The same filter is called when the network topology changes, such as when a new node joins the cluster or the old node leaves the cluster. The implementation of the filter needs to be added to each node's classpath, regardless of whether the node becomes a data node or not.

...

Second, implement the filter, in this case, using a very explicit implementation, DataNodeFilter, which checks the data.node parameter to determine whether a node is considered a data node. If a node is configured with this parameter in the attribute mapping, it will become a data node and the data will reside there, otherwise the node will be ignored.

Public boolean apply (ClusterNode node) {Boolean dataNode = node.attribute ("data.node"); return dataNode! = null & & dataNode;}

Third, data-node-config.xml adds a data.node attribute to the attribute mapping of each node started with this configuration, like this:

Finally, start an instance of a data node by using the DataNodeStartup file in the example, or by passing the data-node-config.xml to the ignite.sh/bat script of Ignite. If you choose the latter, be sure to build all the class files in the java/app/common directory into a jar package, and then add this jar file to the classpath of each data node.

The service node when the microservice is on top of the in-memory data grid architecture

At the implementation level, the definition of a service node is not much different from the use of the aforementioned data node. Basically, you need to establish a way to specify which nodes a particular microservice will be deployed on, which will be a subset of the entire cluster.

Initially, you need to implement a micro service using the service grid API, and for later purposes, you can review the existing service implementation in that GitHub example, Maintenance Service.

This service can schedule a vehicle maintenance service and view the list of maintenance done. It implements all the necessary methods of the service grid, including init (...), execute (...). And cancel (...), and add new methods to this interface:

Public interface MaintenanceService extends Service {public Date scheduleVehicleMaintenance (int vehicleId); public List getMaintenanceRecords (int vehicleId);}

There are several ways to configure and deploy this maintenance service to a specific Ignite node (service node). In this example, each node started through maintenance-service-node-config.xml can consider the deployment of maintenance services, and you can take a look at the configuration below.

First, make sure that the instance of the maintenance service is only deployed to the node where the node filter is specified:

Second, the filters used by the maintenance service are only deployed to nodes that have maintenance.service.node configured in the attribute map:

Public boolean apply (ClusterNode node) {Boolean dataNode = node.attribute ("maintenance.service.node"); return dataNode! = null & & dataNode;}

Finally, with the following XML snippet, each node started with maintenance-service-node-config.xml contains this attribute in the map:

That's it, using the MaintenanceServiceNodeStartup file, or the ignite.sh/bat script that passes maintenance-service-node-config.xml to Ignite, you can start one or more instances of the maintenance service node, and if you select the latter, be sure to package all the files in the java/app/common and java/services/maintenance directories into a jar file, and then add the jar file to the classpath of the node where each service will be deployed.

The example contains another Ignite service related to vehicle management. You can start at least one service node deployed with this service using VehicleServiceNodeStartup file or ignite.sh/bat configured by vehicle-service-node-config.xml. If you choose ignite.sh/bat mode, don't forget to assemble a jar file and add it to the classpath of the relevant node.

A sample application for running a micro-service on an in-memory data grid

Once the data node is ready and the maintenance service and vehicle service nodes are up and running, you can run the first sample application to access the distributed micro-service.

In the example, TestAppStartup is found and launched, and the application accesses the cluster, injects virtual data into the predefined cache, and then interacts with the service.

MaintenanceService maintenanceService = ignite.services (). ServiceProxy (MaintenanceService.SERVICE_NAME,MaintenanceService.class, false); int vehicleId = rand.nextInt (maxVehicles); Date date = maintenanceService.scheduleVehicleMaintenance (vehicleId)

If you note that the application uses the service proxy to interact with the service, the advantage of the proxy is that the node that starts the application does not need to hold the implementation of the service in the local classpath or deploy a service locally.

Thank you for reading, the above is the content of "how Ignite defines a data node". After the study of this article, I believe you have a deeper understanding of how Ignite defines a data node, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.