CN106789308B - GIS service device with micro-service architecture capable of automatically stretching and retracting and control method thereof - Google Patents

Abstract

The invention provides a GIS service device with a micro-service architecture capable of automatically stretching and retracting and a control method thereof, wherein the device comprises: the system comprises a Master process module, a Daemon process module and one or more Worker process modules; the Master process module is used for starting a Master process to serve as a uniform access entrance of the GIS service in the whole GIS service device, providing a GIS service management function and providing a Worker process management function; the Daemon process module is used for running a Daemon process and carrying out background monitoring on a Master process; receiving a Master status report, checking the running condition of a Master process according to the report, and automatically starting a new Master process by the Daemon process when the Master process exits abnormally; the one or more Worker process modules are used for running a Worker process, are started and managed by the Master process, receive the instruction of the Master, perform service issuing, deleting or updating operation, and periodically report the state information of the Master.

Description

GIS service device with micro-service architecture capable of automatically stretching and retracting and control method thereof

Technical Field

The invention relates to a GIS service device with a micro-service architecture capable of automatically stretching and retracting. In addition, the invention also relates to a control method for automatic expansion and contraction based on the GIS service device.

Background

The GIS (Geographic Information System) application server is used as a core component of the WebGIS (web Geographic Information System) and is responsible for publishing various GIS resources, such as GIS data, maps, three-dimensional scenes and the like, into corresponding GIS services, such as map services, data services, three-dimensional services, spatial analysis services, network analysis services, bus transfer services, geocoding services and the like. Meanwhile, the GIS server is also responsible for receiving GIS service requests and completing responses according to request parameters.

Because a complete GIS application system often needs to release a plurality of GIS resources and provide various GIS functions. To this end, a fully functional GIS server typically contains multiple GIS services. As the GIS application is introduced into the public, the number of users served by the GIS service application system is more and more, and thus the corresponding GIS service load is high.

The traditional GIS application server is a classical single application program, various GIS services including different data sources are deployed in a process, and different types of services are deployed in the process. This mode of deployment can provide some convenience in the implementation of the project, but also provides the following problems. First, the number of services that can be deployed in a GIS application server is limited. Operating system resources (such as file handle number, virtual memory and the like) which can be used by a single process are limited, so that the maximum number of openable GIS resources (such as maps, symbol libraries and the like) in a single process is also limited, and further, the number of services which can be issued in the single process is also limited, and generally cannot exceed 100 services.

When the GIS service responds to the request, a large amount of operations are often required, and some resources, such as CPU time, Http threads, and the like, are occupied in the operation process. For a monolithic GIS server, all GIS services are deployed in one process and share these resources. When the load of a certain GIS service is high, because more shared resources are occupied, other GIS services cannot be distributed with insufficient resources, and further, the performance of other GIS services is reduced or even suspended. Therefore, GIS services are mutually influenced, and the reliability of the services is not high. When a GIS service has a serious error, the process is abnormally quitted, and other irrelevant services are also unavailable.

Furthermore, GIS services do not perform well in high concurrency scenarios, and service performance drops dramatically as request load increases. At present, a GIS server clustering technology is widely adopted, wherein the GIS server clustering technology is to extend the capability of GIS services by copying a plurality of GIS application servers, each GIS application server independently operates in a respective process, and the services of each GIS application server are scheduled and load balanced through an independent load balancing module. The GIS server clustering technology is easy to realize, and can effectively improve the service capacity of the whole GIS server, but the GIS server clustering technology has the disadvantage of inconvenient GIS service expansion. Because the GIS service can be extended only by copying the whole GIS server, a large amount of deployment, configuration and debugging work needs to be carried out by implementing personnel in the extension process, which is not only inconvenient but also easy to make mistakes. Second, implementing different levels of expansion for different services cannot be achieved. In an actual application scenario, loads of different GIS services are significantly different, and therefore, different extension levels need to be implemented for different GIS services. The GIS server clustering technology is characterized in that the whole GIS server is expanded, the expanded granularity is too coarse, and the expansion level of specific service cannot be accurately controlled. Third, the GIS service cannot do automatic scaling. There is some fluctuation in the load of the GIS service over a period of time, such as a day. Such fluctuations are sometimes regularly recurring (e.g. after 24 o' clock, the load gradually decreases), sometimes to the extent that it is irregular. Due to the fluctuation characteristic of the GIS service load, the expansion level of the GIS service is positively correlated with the load of the service under ideal conditions, namely, when the load is increased, the number of instances of the GIS service is required to be automatically increased to improve the processing capacity of the GIS service. When the load is reduced, the number of instances of the GIS service needs to be automatically reduced to release resources, thereby reducing resource occupation. However, GIS server clustering technology cannot meet this demand.

Aiming at the problems, the invention creates a GIS service device with a micro-service architecture capable of automatically stretching. The limitation of the number of services of a single GIS server is broken through, different expansion levels are set for different GIS services, the GIS services are automatically expanded, the expansion levels of the GIS services can be automatically adjusted according to the load condition of the GIS services, and the GIS services are automatically expanded and contracted.

Disclosure of Invention

The invention provides a GIS service device with a micro-service architecture capable of automatically stretching and retracting, which is used for solving the disadvantages in the prior art. The GIS service device comprises a Master process module, a Daemon process module and one or more Worker process modules.

And the Master process module is used for starting a Master process to serve as a uniform access entrance of the GIS service in the whole GIS service device and is used for GIS service management and Worker process management. The Daemon process module is used for operating a Daemon process, carrying out background monitoring on the Master process, receiving a state report of the Master process, and checking the operating condition of the Master process according to the report. And when the Master process exits abnormally, the Daemon process automatically starts a new Master process. The one or more Worker process modules are constructed and used for running a Worker process, are started and managed by a Master process, receive an instruction of the Master process to perform service issuing, deleting and/or updating operations, and report the state of the one or more Work processes to the Master process periodically.

According to a preferred embodiment of the invention, the Master process module comprises the following sub-modules:

-a Worker process management submodule structured for management of one or more Worker processes, implementing operations for adding, deleting and/or modifying said one or more Worker processes.

A state keeping submodule configured to collect state information of the Master process and/or the one or more Worker processes, report the state information to the Daemon process, and monitor the health of the Daemon process. And when the monitoring condition of the Daemon process is detected to be abnormal, restarting the Daemon process, receiving the state information reported by one or more Worker processes, and judging the monitoring condition of the one or more Worker processes according to the state information. When one or more Worker processes are found to be abnormal in operation, the Worker process management submodule and the service management deployment submodule are informed, the Worker process is restarted, and GIS service is redeployed.

-a service management deployment submodule, configured for management of said GIS services, managing GIS services for the whole device, comprising: and releasing, deleting and/or modifying the GIS service, and deploying the GIS service to each Worker process. The service management deployment sub-module is also used for constructing automatic expansion and contraction of the GIS service, and the GIS service is automatically expanded and contracted by monitoring the load condition and the request response condition of each GIS service.

The service scheduling submodule is used for integrating all services of each Worker process and forwarding the service request, integrating the GIS service of each Worker process, generating a service directory, providing a uniform service access entrance, and scheduling the received service request to an available Worker process for processing.

-a support submodule configured to implement operations of security control, admission control and/or operation and maintenance monitoring;

-a configuration management submodule configured to read, save and/or modify said Master process configuration information, and further configured to read, save and/or modify configuration information of a GIS service.

According to a preferred embodiment of the present invention, the Daemon process module comprises the following sub-modules:

a Master process management submodule configured to start, stop and/or restart the Master process.

-an exit listening submodule configured to listen for exit events of the GIS service device. And when a quit event is monitored, informing the Master process management submodule to implement the operation of stopping the Master process and stopping the running of the current Daemon process, so that the current process is normally quitted.

-a health check sub-module configured to receive the status report of the Master process, analyze the health of the Master process, and according to the health of the Master process: if the fact that the resource occupation of the Master process exceeds a set threshold value is monitored, a Master management process module is informed to implement the operation of restarting the Master process; and if the Master process is monitored to be abnormally exited, informing the Master management process module to implement the operation of starting the Master process.

According to a preferred embodiment of the present invention, one or more Worker process modules include the following sub-modules:

the service management submodule is used for managing the GIS service, and issuing, deleting and/or modifying the GIS service of the Worker process.

A GIS services sub-module configured to provide GIS services functionality by receiving GIS requests and selecting a particular GIS service to respond to the request and returning a response result.

A status reporting submodule configured to report the status of the Worker process and the service status on the Worker process to the Master process periodically.

According to another aspect of the present invention, there is provided a control method based on automatic scaling according to the GIS service device, the control method comprising the following workflows:

-initiating a workflow of the GIS service device;

-stopping the work flow of the GIS service device;

-issuing a workflow of a GIS service through a Master process;

-Master process processing the work flow of the GIS service request;

-a Master process automatically scaling the GIS service;

the Master process judges whether the GIS service needs an automatic scaling workflow.

According to a preferred embodiment of the present invention, the work flow of starting the GIS service device includes the following steps:

-initiating a Daemon process, for example by a system administrator by means of a command line or automatically.

Initializing Daemon process, and initializing each internal sub-module until each sub-module is initialized.

A Master process management submodule in the Daemon process starts the Master process and judges whether the Master process is started successfully. If the Master process is started successfully, the Master process is initialized. And if the Master process fails to start, giving prompt information in a console and a log file, and exiting the Daemon process.

-after the initialization is completed, determining whether the GIS service device has started successfully. And if the GIS service device is started successfully and initialized, giving prompt information in the console and the log file. If the GIS service device fails to start, prompt information is also given in the console and log files.

According to a preferred embodiment of the present invention, stopping the work flow of the GIS service device includes:

-sending an exit command to the Daemon process, for example by a system administrator by means of a command line or in an automated manner.

After the exit monitoring submodule of the Daemon process receives the exit command, the exit monitoring submodule forwards the received exit command to the Master process management submodule.

The Master process management submodule of the Daemon process issues an exit command to the Master process via the pipeline.

After the Master process receives the quit command, the Master process and the related Worker processes managed by the Master process are destroyed.

After each submodule of the Master process has been stopped and destroyed, the Master process exits.

After monitoring the event that the Master process completely exits, the Daemon process starts to stop and destroy the submodules of the Daemon process in sequence until all the submodules are destroyed, and the Daemon process exits.

All relevant processes of the GIS service device are normally exited and the GIS service device is normally stopped.

According to a preferred embodiment of the present invention, the work flow of issuing GIS service through Master process includes the following steps:

-sending a request to the Master process to publish GIS services, for example by means of REST API or automatically by a system administrator.

The service management deployment submodule of the Master process receives the request and responds to the request.

And calculating the number of instances to be deployed of the service by a service management deployment submodule of the Master process according to the service configuration information. If N, it means that the service needs to be deployed in N Worker.

The service management deployment submodule of the Master process inquires the number of the currently started Worker processes, such as M, from the Worker process management submodule. And if the number M of the currently started Worker processes is less than the number N of the to-be-deployed instances of the service, informing a Worker process management submodule of newly starting (N-M) Worker processes. And if M is larger than or equal to N, the service management deployment submodule of the Master process inquires N Worker processes with the minimum deployment service for the Worker process management submodule to obtain the proxy objects of the N Worker processes.

Traversing the proxy objects of the N Worker processes, and sequentially deploying the current GIS service to the corresponding Worker process through the proxy objects of the Worker processes.

According to a preferred embodiment of the present invention, the workflow of the Master process for processing the GIS service request includes the following steps:

the generic user of the GIS service device sends a GIS request to the Master process.

The service scheduling submodule of the Master process receives the request, analyzes the request, and calculates to obtain a corresponding service name of the current GIS request.

The service scheduling submodule of the Master process inquires the service management deployment submodule about which Worker processes deploy the service according to the service name, and returns a name list of the Worker processes.

The service scheduling submodule of the Master process inquires the Worker process management submodule according to the name list of the Worker process and returns a list of the Worker process proxy objects with specified names.

The service scheduling submodule of the Master process obtains a Worker process proxy object from the list of Worker process proxy objects according to the load balancing algorithm.

The service scheduling submodule of the Master process processes the request through the Worker process proxy object.

The service scheduling submodule of the Master process judges the status flag in the response returned by the broker process proxy object. If the flag is temporarily unavailable for service, a retry is made to obtain a Worker process proxy object from the list of Worker process proxy objects, for a maximum of a predetermined number of attempts, e.g., 3. Otherwise, the request is responded, the response information returned by the Worker process proxy object is written back to the request response received by the service scheduling submodule, and the request processing is completed.

According to a preferred embodiment of the present invention, the workflow of automatic scaling of the GIS service by the Master process includes the following steps:

the support submodule of the Master process comprises a monitoring and statistics unit, and the monitoring and statistics unit is used for monitoring the service load of each GIS, the time consumption of request processing and the use condition of hardware resources.

The service management deployment submodule of the Master process periodically inquires the load and the hardware resource use condition of each GIS service from the monitoring and counting unit of the support submodule to determine whether the GIS service needs to be automatically expanded or contracted, and the method comprises the steps of obtaining the mark of whether all GIS services need to be expanded or contracted and the number of the instances to be expanded or contracted of each GIS service, and sequentially judging the marks. And if the number of the GIS service instances needs to be expanded to obtain the number E of the service instances to be expanded, the expansion of the service instances is started, and if the number of the GIS service instances needs to be contracted to obtain the number S of the service instances to be contracted, the contraction of the service instances is started.

After the current GIS service is newly deployed into E Worker processes, the service management deployment submodule of the Master process obtains a name list (L1) of the Worker processes deployed with the GIS service according to the current GIS service name query, selects S Worker process names from the name list, obtains a name list (L2) of the Worker processes to be uninstalled with the GIS service, and accordingly obtains a list (L3) of the agent objects of the S Worker processes from the Worker process management submodule query.

The service management deployment submodule of the Master process traverses the list of the agent objects of the S Worker processes, obtains the agent object of the current Worker process in each traversal process, and unloads the current GIS service through the agent object.

Preferably, in the starting extended service instance, the service management deployment submodule of the Master process queries the number N of currently deployed instances of the GIS service according to the service name, the service management deployment submodule queries the number M of currently started Worker processes from the Worker process management submodule, if N + E is less than or equal to M, the current number of Worker processes is sufficient, the current GIS service is newly deployed into E Worker processes, and if N + E > M, the current number of Worker processes is insufficient, the (N + E-M) Worker processes are restarted.

Preferably, in the step of newly deploying the current GIS service to the E Worker processes, the service management deployment submodule of the Master process obtains a list of Worker process names where the GIS service is deployed according to the current GIS service name query, then queries all the lists of the Worker process names to the Worker process management submodule, and according to the two lists, can obtain a list of the E Worker names where the current GIS service is not deployed, and according to the list, queries the Worker process management submodule to obtain the E Worker process proxy object, and then sequentially calls the E Worker process proxy objects to deploy the current GIS service to the corresponding Worker processes.

According to a preferred embodiment of the present invention, the work flow of judging whether the GIS service needs to be automatically scaled by the Master process includes the following steps:

and inquiring by a service management deployment submodule of the Master process from a monitoring and counting unit of a support submodule according to the service name to obtain the current hardware resource use condition and the average number R of concurrent requests received by the GIS service in the latest one minute per second.

And the service management deployment submodule of the Master process queries according to the service name to obtain the number N of the currently deployed instances of the GIS service.

And inquiring by a service management deployment submodule of the Master process from a configuration management submodule according to the service name to obtain the maximum processing concurrent request number RP of each service instance of the GIS service.

-calculating the number of service instances E to be scaled by means of the formula E = (N-R/RP). Depending on the calculation results, there are different cases:

a) if E >1, the current number of the service instances is enough, obvious redundancy exists, the number of the service instances needs to be shrunk, the mark that the service needs to be shrunk is returned, and the number of the shrunk service instances is E.

b) If E < -1, the current number of the service instances is insufficient, a larger gap exists, the number of the service instances needs to be expanded, an indication that the service needs to be expanded is returned, and the expanded number of the service instances is-E.

c) If E is more than or equal to-1 and E is less than or equal to 1, the number of the current service instances is just enough, and the number of the service instances does not need to be scaled.

According to an advantageous embodiment of the invention, the GIS service means can be implemented in hardware or in software. They may have interfaces which may be constructed in hardware and/or in software. When constructed in hardware, the interface may be part of a so-called ASIC system, for example, which contains the different functions of the above-described device. However, the interface may also be a separate integrated circuit or be at least partly composed of discrete components. When configured in software, the interface may be a software module that co-exists with other software modules in a database or microcontroller, for example.

The dependent claims are advantageous embodiments of the invention. Although the present invention has been described by means of preferred embodiments, it is not limited thereto but can be modified in many ways.

Drawings

The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:

FIG. 1: the micro-service architecture diagram of the GIS service device capable of automatically stretching and retracting;

FIG. 2: master process module structure diagram;

FIG. 3: daemon process module structure diagram;

FIG. 4: a Worker process module structure diagram;

FIG. 5: starting a work flow of the GIS service device;

FIG. 6: initializing a Master process;

FIG. 7: starting each Worker process;

FIG. 8: deploying all GIS services;

FIG. 9: stopping the work flow of the GIS device;

FIG. 10: destroying the Master process and the relevant Worker process managed by the Master process;

FIG. 11: issuing a GIS service workflow through a Master process;

FIG. 12: responding to the request for issuing GIS service;

FIG. 13: deploying the GIS service to a Worker process;

FIG. 14: a Master process processes a GIS request work flow;

FIG. 15: a specific method step that a service scheduling submodule of a Master process processes a GIS request through a Worker process proxy object;

FIG. 16: a Master process carries out automatic expansion and contraction work flow on the GIS service;

FIG. 17: a method step of unloading GIS service by the Worker agent object;

FIG. 18: and judging whether the GIS service needs an automatic telescopic work flow by the Master process.

Detailed Description

In order to make the aforementioned objects, features and advantages of the present application more comprehensible, the present application is described in further detail with reference to the accompanying drawings and the detailed description.

In the description of the present application, it is to be understood that the meaning of "a plurality" is two or more unless specifically limited otherwise. The terms "comprising," including, "and the like are to be construed as open-ended terms, i.e.," including/including but not limited to. The term "based on" is "based, at least in part, on". Relevant definitions for other terms will be given in the following description.

Fig. 1 shows a microservice architecture diagram of an automatically scalable GIS service device, which is composed of a Master process module (also called GIS server Master process module), a Daemon process module (also called GIS server backup process module), and one or more Worker process modules (also called GIS service Worker process module).

The Master process module is constructed as a uniform access entrance of all GIS services of the whole GIS service device. The Master process module is used for providing GIS service management capability, including releasing and deleting services, modifying the number of GIS service instances and the like. The Master process module is also used for providing Worker process management capacity, including adding and reducing work processes.

The Daemon process module is constructed as a background monitoring process module of a Master process. The Daemon process module is configured to receive a status report of the Master and check the health of the Master process accordingly. When the Master process exits abnormally, the Daemon process automatically starts a new Master process.

One or more Worker process modules are constructed as GIS service work process modules. The Worker process module is started and managed by a Master process, and is constructed to receive an instruction of the Master to perform service issuing, deleting and updating operations. The Worker process module is also used for reporting own state information including own monitoring condition, deployed service availability condition and the like to the Master periodically.

Fig. 2 shows a Master process block diagram. The Master process module comprises:

a Worker process management submodule arranged to be responsible for the management of the Worker process. The Worker process can be added, deleted and modified through the Worker process management submodule;

a state keeping submodule arranged to be responsible for collecting the health of the Master process, for example reporting the resource occupancy, the status information of the GIS services and the Worker process to the Daemon process. The status holding submodule is also arranged to monitor the health of the Daemon process. And when the monitoring condition of the Daemon process is detected to be bad, restarting the Daemon process in time. In addition, the state keeping submodule is arranged for receiving the state information reported by the Worker process and judging the monitoring state of the Worker process according to the state information. When the fact that the Worker process is abnormally operated is found, the Worker process management submodule and the service management deployment submodule are timely notified to restart the Worker process and redeploy GIS service;

-a service management deployment sub-module arranged to be responsible for the management of GIS services. The GIS service of the whole device can be managed through the service management deployment sub-module, including releasing, deleting or modifying the GIS service and deploying the GIS service to each Worker process. The service management deployment submodule is also set to be in charge of automatic scaling of the GIS service. And automatically stretching the GIS service by monitoring the load condition and the request response condition of each GIS service.

A service scheduling sub-module arranged to be responsible for integrating all services of each Worker process and the forwarding of service requests. And integrating the GIS service of each Worker process through a service scheduling submodule, and providing a service directory so as to provide a uniform service access entry. The service scheduling submodule is also used for scheduling the received service request to a corresponding Worker process for processing.

A support submodule arranged to support normal operation of the entire GIS service device, such as security control, admission control, operation and maintenance monitoring, etc.

A configuration management submodule arranged to read, save and modify configuration information of the Master process, GIS services, etc.

Fig. 3 shows a structure diagram of a Daemon process module, which includes:

a Master process management submodule arranged to be responsible for starting, stopping and restarting the Master process.

An exit listening submodule arranged to be responsible for listening to exit events (e.g. semaphores delivered from sockets) of the GIS service device. The quit monitoring submodule is also used for informing the Master process management submodule to implement the operation of stopping the Master process and stopping the running of the current Daemon process when a quit event is monitored, so that the current process is normally quitted.

A health check sub-module arranged to receive status reports of the Master process and to analyze the health of the Master. The health examination sub-module is also arranged for performing targeted processing according to the health condition of the Master. For example, if the resource occupation of the Master process is found to exceed a certain threshold, the Master management process is informed to implement the operation of restarting the Master process. And if the Master process is found to be abnormally exited, informing the Master management process to perform the operation of starting the Master process, and the like.

Fig. 4 shows a structure diagram of a Worker process module, and the Worker process module includes:

-a service management submodule arranged to be responsible for the management of GIS services. The GIS service of the Worker process can be managed through the service management submodule, and the GIS service can be issued, deleted or modified.

A GIS services sub-module arranged to be responsible for providing GIS services capabilities. The GIS request is received, a specific GIS service is selected to respond to the request, and a response result is returned.

A status reporting submodule configured to periodically report the status of the Worker and the service status on the Worker to the Master process.

The workflow of the above-described modules is described below with the aid of fig. 5-18. Fig. 5 shows a work flow of starting the GIS service device (flow one).

In step 1-1, the system administrator initiates the Daemon process via the command line.

In step 1-2, the Daemon process is initialized, and each internal sub-module is initialized until each sub-module is initialized.

In step 1-3, the Master process management submodule in the Daemon process starts the Master process and judges whether the Master process is started successfully. And if the Master process is started successfully, jumping to the step 1-4. And if the Master process fails to start, jumping to the step 1-7, and exiting the Daemon process.

In steps 1-4, the Master process initializes. Step 5 is entered after the initialization is completed.

In step 1-5, it is determined whether the GIS service device is successfully started. If the GIS service device is successfully started and initialized, prompt information is given in the console and log files in steps 1-6. If the GIS service device fails to boot, a prompt is given in the console and log files in step 1-7.

Specifically, referring to fig. 6, the Master process initialization in the above steps 1-4 is implemented by the following steps:

in step 1-4-a, a configuration management submodule of the Master process is initialized, and configuration information of the Master process is read in the initialization process.

In step 1-4-b, the service support submodule of the Master process obtains configuration information, initializes the service support submodule, and initializes the support functions of safety control, logging, operation and maintenance, monitoring and the like in the initialization process.

In step 1-4-c, the Worker process management submodule of the Master process obtains configuration information. And the Worker process management submodule obtains detailed configuration information of each Worker process according to the global configuration of the Worker process in the configuration information, the service configuration and the hardware information of the GIS service device. And initializing a Worker process management submodule, and starting each Worker process by the Master process in the initialization process. And after the initialization of each Worker process is finished, entering the step 1-4-d.

In the step 1-4-d, the service management deployment submodule of the Master process obtains the configuration information, and the service management deployment submodule starts to initialize. And in the initialization process, deploying related GIS services, and entering the steps 1-4-e after all GIS services are deployed.

In step 1-4-e, the service scheduling submodule of the Master process obtains the configuration information, and the service scheduling submodule starts initialization until the initialization is completed.

In step 1-4-f, the state holding submodule of the Master process obtains the configuration information, and the state holding submodule starts initialization until the initialization is completed. And starting the asynchronous task after the state keeping submodule is initialized. The asynchronous task performs the following operations: start collecting the health of the current Master process and report the collected information to Daemon. And starting to monitor the monitoring condition of the Daemon process, and judging whether the Daemon process needs to be restarted or not according to the monitoring information. Starting to accept the status information reported by all the Worker processes and according to the status information, determining whether to restart some Worker processes.

In steps 1-4-g, the Master process is initialized, the state of the Master process is set to be a ready state, and a flag indicating that the Master initialization is successful is returned.

Specifically, referring to fig. 7, the initiation of each Worker process in steps 1-4-c is achieved by:

in the step 1-4-c-1, a configuration information list of the Worker process to be started is obtained.

In the step 1-4-c-2, the configuration information of a Worker process to be started is selected, and the Worker process is started. If the starting fails, the system retries until the Worker process is successfully started. If the start is successful, step 1-4-c-3 is entered.

In the step 1-4-c-3, the configuration information of the Worker process which is started successfully is deleted from the configuration information list of the Worker process to be started.

In step 1-4-c-4, the number of elements in the configuration information list of the Worker process to be started is checked. And if the number of the list elements is larger than zero, jumping to the step 1-4-c-1. If the number of the list elements is equal to zero, the startup of each Worker process is successful, and the steps 1-4-c-5 are carried out.

In step 1-4-c-5, a success flag is returned.

Specifically, referring to fig. 8, the deployment of all GIS services in the above steps 1-4-d is implemented by the following steps:

in step 1-4-d-1, a configuration information list of the GIS service to be deployed is obtained.

In the step 1-4-d-2, selecting configuration information of a GIS service to be deployed, obtaining the number of instances of the GIS service to be deployed according to the configuration of the GIS service, and if the number is N, indicating that the GIS service needs to be deployed in N Worker processes. The detailed process of deploying the current GIS service to the N Worker processes is shown in step 3-4 of the third process. And after the current GIS service deployment is finished, the step 1-4-d-3 is carried out.

In the step 1-4-d-3, the configuration information of the GIS service which is successfully deployed at present is deleted from the configuration information list of the GIS service to be deployed.

In step 1-4-d-4, the number of elements in the configuration information list of the GIS service to be deployed is checked. And if the number of the list elements is larger than zero, jumping to the step 1-4-d-1. And if the number of the list elements is equal to zero, indicating that the GIS services are successfully deployed, and entering the steps 1-4-d-5.

In step 1-4-d-5, a success flag is returned.

Fig. 9 shows a flow of stopping the GIS service device (flow two).

In step 2-1, the system administrator sends an exit command to the Daemon process via the command line.

In step 2-2, after the exit monitoring submodule of the Daemon process receives the exit command, the exit monitoring submodule forwards the received exit command to the Master process management submodule.

In step 2-3, the Master process management submodule of the Daemon process sends an exit command to the Master process through the pipeline.

In step 2-4, after the Master process receives the quit command, the Master process and the related Worker processes managed by the Master process start to be destroyed. And after the destruction work is finished, the step 2-5 is carried out.

In step 2-5, after all the submodules of the Master process are stopped and destroyed, the Master process exits and enters step 2-6.

In step 2-6, after the Daemon process monitors the event that the Master process completely exits, the Daemon process starts to stop and destroy all the sub-modules of the Daemon process in sequence until all the sub-modules are destroyed, and the Daemon process exits.

In step 2-7, all relevant processes of the GIS service device are normally exited, and the GIS service device is normally stopped.

Specifically, referring to fig. 10, in the above step 2-4, the detailed steps of the Master process and the related breaker process destruction managed by the Master process are as follows:

in step 2-4-a, the Master process sets the state of the Master process to be an unavailable state, stops receiving a new GIS request, and informs all sub-modules to orderly quit.

In step 2-4-b, the configuration management submodule of the Master process receives the exit event, persists the current configuration state, then the configuration management submodule starts to stop, and destroys the relevant resources held by the module.

In step 2-4-c, the state holding submodule of the Master process receives the exit event, the state holding submodule starts to stop, and related resources held by the module, such as a timer, a cache and the like, are destroyed.

In step 2-4-d, the service scheduling submodule of the Master process receives the exit event and checks whether the currently scheduled service request queue is empty. If the service request queue is not empty, a jump is made to step 2-4-e. And if the service request queue is empty, the service scheduling submodule starts to stop, destroys the relevant resources held by the module and enters the step 2-4-f.

In step 2-4-e, wait for a period of time (the specific time is configurable) until the queue is empty.

In step 2-4-f, the service management deployment submodule of the Master process receives the quit event, the service management deployment submodule starts to quit, and related resources held by the module are destroyed.

In step 2-4-g, the Worker process management submodule of the Master process receives the exit event and checks whether the currently started Worker process queue is empty. And if the Worker process queue is not empty, jumping to the step 2-4-h. And if the Worker process queue is empty, entering the step 2-4-i.

And in the steps 2-4-h, stopping the Worker processes in sequence until all the Worker processes are stopped and normally pushed out.

In step 2-4-i, the Worker process management submodule starts to exit and destroys the relevant resources held by the module.

In step 2-4-j, the support submodule of the Master process receives the exit event, the support submodule starts to exit, and related resources held by the module are destroyed.

Fig. 11 shows a workflow of publishing GIS services through a Master process (flow three).

In step 3-1, a system administrator sends a request for issuing a GIS service to a Master process through a REST API.

In step 3-2, the service management deployment submodule of the Master process receives the request and responds to the request.

In step 3-3, the service management deployment submodule of the Master process calculates the number of instances to be deployed of the service according to the service configuration information. If N, it means that the service needs to be deployed in N Worker.

In step 3-4, the service management deployment submodule of the Master process queries the number of the currently started Worker processes, such as M, from the Worker process management submodule. And if the number m of the currently started Worker processes is less than the number N of the instances to be deployed of the service, entering the step 3-5. And if M is larger than or equal to N, directly entering the step 3-6.

In step 3-5, the Worker process management submodule is notified to newly start (N-M) Worker processes.

In step 3-6, the service management deployment submodule of the Master process queries the Worker process management submodule for N Worker processes with minimum deployment service, and proxy objects of the N Worker processes are obtained.

In step 3-7, the proxy objects of the N Worker processes are traversed, and the current GIS service is deployed to the corresponding Worker process through the proxy objects of the Worker processes in sequence. The detailed procedure for deploying GIS services to a Worker process is as follows (see fig. 13):

in step 3-7-a, the service management deployment submodule of the Master process sends a deployment service request to the Worker process through the Worker process proxy object.

In step 3-7-b, the service management submodule of the Worker process receives the request, analyzes the request, obtains the service configuration information to be deployed, and starts to deploy the service.

In step 3-7-c, it is determined whether the service deployment was successful. If the service deployment is successful, a success flag is returned. If the service deployment fails, a failure flag is returned and the step 3-7-a is skipped back for redeployment. And the service management deployment submodule of the Master process obtains a sign of whether the GIS service deployment is successful or not through the Worker process proxy object.

It should be noted that, in the process of deploying the GIS service to a Worker process through the service management deployment submodule of the Master process, if a Worker fails to deploy the GIS service, the Worker is redeployed for 1 time. If the GIS service deployment of the Worker still fails after the deployment is carried out for a predetermined number of times (for example, 3 times), the whole deployment process is exited, and a log of the GIS service deployment failure is added. And if all Worker processes are successful in deploying the service, the GIS service is successfully deployed, and a log of the GIS service which is successfully deployed is added.

Specifically, referring to fig. 12, responding to the request for issuing the GIS service in step 3-2 includes the steps of:

in step 3-2-a, the request is parsed to obtain GIS service configuration information.

In step 3-2-b, the configuration management submodule is informed of adding a new GIS service, and the configuration management submodule makes the newly added GIS service configuration persistent.

In step 3-2-c, an asynchronous task is started, and the process of deploying GIS service to each Worker is started, wherein the detailed process is shown in step 3-3.

In step 3-2-c, a response of the current request is returned, and the response body contains the state of the service to be deployed (being deployed), the access address information of the service to be deployed and the like.

Fig. 14 shows a workflow of the Master process to process GIS requests (flow four).

In step 4-1, the regular user of the GIS service device sends a GIS request to the Master process.

In step 4-2, the service scheduling submodule of the Master process receives the request, analyzes the request, and calculates to obtain a corresponding service name of the current GIS request.

In step 4-3, the service scheduling submodule of the Master process inquires the service management deployment submodule about which Worker processes deploy the service according to the service name, and returns a name list of the Worker processes.

In step 4-4, the service scheduling submodule of the Master process inquires the Worker process management submodule according to the name list of the Worker process and returns a list of the Worker process proxy objects with specified names.

In step 4-5, the service scheduling submodule of the Master process obtains a Worker process proxy object from the list of Worker process proxy objects according to a certain load balancing algorithm, such as a polling, weighting or consistent hash algorithm.

In step 4-6, the service scheduling submodule of the Master process processes the request through the Worker process proxy object.

In step 4-7, the service scheduling submodule of the Master process judges the status flag in the response returned by the Worker process proxy object. If the flag is that service is temporarily unavailable, then return to step 4-5 to retry for a maximum of a predetermined number of attempts, e.g., 3. Otherwise, indicating that the request has been responded, step 4-8 is entered.

In step 4-8, response information returned by the Worker process proxy object is written back to the request response received by the service scheduling submodule, and the request processing is completed.

Specifically, referring to fig. 15, processing the request by the Worker process proxy object in step 4-6 includes the steps of:

in step 4-6-a, the Worker process proxy object forwards the request to the corresponding Worker process.

In step 4-6-b, after receiving the request, the service management submodule of the Worker process analyzes the request to obtain the requested service name.

In step 4-6-c, the service management submodule of the Worker process obtains the corresponding service object according to the request name, and judges whether the current service object is available. If so, the service object is invoked to process the request and return a response result. If not, a flag is set in the response that the service is temporarily unavailable.

Fig. 16 shows the workflow of automatic scaling of the GIS service by the Master process (flow five). The workflow comprises the following steps:

in step 5-1, the support submodule of the Master process includes a monitoring and statistics unit. The sub-module is configured to monitor service load of each GIS, time consumed for request processing, and usage of hardware resources, such as CPU usage, memory usage, and the like.

In step 5-2, the service management deployment submodule of the Master process periodically queries the monitoring and counting unit of the support submodule about the load of each GIS service and the use condition of hardware resources to determine whether automatic expansion and contraction are required. And obtaining the marks of whether all GIS services need to be expanded or contracted and the number of the instances to be expanded or contracted of each GIS service, sequentially judging the marks, and then automatically expanding and contracting the GIS services. If the number of the instances of a certain GIS service needs to be expanded to obtain the number E of the service instances to be expanded, jumping to the step 5-3 to begin to expand the service instances; and if the number of the GIS service instances needs to be shrunk to obtain the number S of the service instances to be shrunk, jumping to the step 5-6 to shrink the service instances. The detailed process of judging whether a certain GIS service needs to be stretched or not is shown in the sixth flow.

In step 5-3, the service management deployment submodule of the Master process queries the number of currently deployed instances of the GIS service, for example, N, according to the service name. And the service management deployment submodule inquires the number of the currently started Worker processes, such as M, from the Worker process management submodule. And if the N + E is less than or equal to M, the number of the current Worker is enough, and the step 5-5 is skipped to start to newly deploy the current GIS service to E Worker processes. And if the N + E > M indicates that the current number of the Worker is insufficient, jumping to the step 5-4.

In step 5-4, (N + E-M) Worker processes are restarted. And if the required Worker process fails to start, writing a log and prompting that the service expansion service instance fails, and ending the service expansion process. And if the required Worker processes are successfully started, jumping to the step 5-5 to newly deploy the current GIS service to the E Worker processes.

In step 5-5, the service management deployment submodule of the Master process queries according to the current GIS service name to obtain a Worker process name list deployed with the GIS service, and then queries all the Worker process name lists from the Worker process management submodule. According to the two lists, a list of the E Worker names which do not deploy the current GIS service can be obtained. And inquiring the Worker process management submodule according to the list to obtain the E Worker process proxy object. And then, the E Worker process proxy objects are sequentially called to deploy the current GIS service into the corresponding Worker process, and the detailed steps are shown as steps 3-7 of the third flow.

In step 5-6, the service management deployment submodule of the Master process queries according to the current GIS service name to obtain a name list L1 of the Worker process deployed with the GIS service, and selects S Worker process names from L1 to obtain a name list L2 of the Worker process to be uninstalled with the GIS service. And obtaining a list L3 of the agent objects of the S Worker processes from the query of the Worker process management submodule according to L2.

In step 5-7, the service management deployment submodule of the Master process traverses the list L3, obtains a proxy object of the current Worker process in each traversal process, and unloads the current GIS service through the proxy object.

Specifically, referring to fig. 17, the Worker proxy object uninstalling the GIS service includes the following steps:

in step 5-7-a, a Worker process proxy object is called by a service management deployment submodule of the Master process to send a command for unloading a certain GIS service.

In step 5-7-b, the service management submodule of the Worker process receives the command, analyzes the command and obtains the name of the GIS service to be unloaded.

In the step 5-7-c, the service management submodule of the Worker process starts to unload the GIS service until the GIS service is unloaded, and returns a message of an unloading result.

In the step 5-7-d, after the Worker process proxy object obtains the information that the unloading of the GIS service is completed, the process that the current Worker process unloads the current GIS service is completed.

And the process is circulated until all Worker process proxy objects in the third flow finish the process of unloading the current GIS service, and the process of contracting the service instance of the current GIS service is finished.

Fig. 18 shows a workflow of the Master process to determine whether a GIS service needs to be automatically scaled, the workflow having the following steps:

in step 6-1, the service management deployment submodule of the Master process queries from the monitoring and counting unit of the support submodule according to the service name to obtain the current hardware resource use condition and the average number of concurrent requests, such as R, received by the GIS service in the latest minute per second.

In step 6-2, the service management deployment submodule of the Master process queries according to the service name to obtain the number of currently deployed instances of the GIS service, for example, N.

In step 6-3, the service management deployment submodule of the Master process queries from the configuration management submodule according to the service name to obtain the maximum processing concurrency request number of each service instance of the GIS service, and obtain the RP.

In step 6-4, the number of service instances E to be extended is calculated by means of the formula E = (N-R/RP). Depending on the calculation results, there are different cases:

a) if E >1, the current service instance number is enough, and obvious redundancy exists, the service instance number needs to be shrunk. And returning the mark that the service needs to be shrunk, wherein the number of the shrunk service instances is E.

b) If E < -1, the current service instance number is not enough, and a larger gap exists, the service instance number needs to be expanded. And returning the mark that the service needs to be expanded, wherein the number of the expanded service instances is-E.

c) If E is more than or equal to-1 and E is less than or equal to 1, the number of the current service instances is just enough, and the number of the service instances does not need to be scaled.

For simplicity of description, the foregoing method embodiments are described as a series of acts or combination of acts, but those skilled in the art will appreciate that the present application is not limited by the order of acts described, as some steps may, in accordance with the present application, occur in other orders and concurrently; further, those skilled in the art should also appreciate that the above-described method embodiments are preferred embodiments and that the acts and modules involved are not necessarily required for the application.

It should be noted that the above device embodiments belong to preferred embodiments, and the units and modules involved are not necessarily essential to the present application.

The embodiments in the present specification are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other. For the device embodiments of the present application, since they are substantially similar to the method embodiments, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiments.

The above provides a GIS service device with a micro service architecture capable of automatic expansion and contraction and a control method based on automatic expansion and contraction according to the GIS service device, detailed descriptions are given, specific examples are applied in this document to explain the principle and implementation of the present application, and the description of the above embodiments is only used to help understand the control method and core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims (10)

1. A GIS service device with automatically scalable micro-service architecture, comprising: the system comprises a Master process module, a Daemon process module and one or more Worker process modules;

the Master process module is used for starting a Master process as a uniform access entrance of the GIS service in the whole GIS service device and is used for GIS service management and Worker process management;

the Daemon process module is used for running a Daemon process, carrying out background monitoring on the Master process, receiving a state report of the Master process, checking the running condition of the Master process according to the report, and automatically starting a new Master process by the Daemon process when the Master process is abnormally quitted;

the one or more Worker process modules are used for running a Worker process, starting and managing by the Master process, receiving an instruction of the Master process to perform service issuing, deleting and/or updating operations, and reporting the state of the one or more Worker processes to the Master process periodically;

the Master process module comprises a support submodule and a service management deployment submodule, and the Worker process module comprises a Worker process management submodule; and the number of the first and second electrodes,

the support submodule of the Master process comprises a monitoring and counting unit, and the monitoring and counting unit is used for monitoring the service load of each GIS, the time consumption of request processing and the use condition of hardware resources;

the service management deployment submodule of the Master process periodically inquires the load and the hardware resource use condition of each GIS service from the monitoring and counting unit of the support submodule to determine whether the GIS service needs to be automatically expanded or not, the method is that a mark of whether all GIS services need to expand or contract examples and the number of the examples to be expanded or contracted of each GIS service are obtained, the marks are sequentially judged, wherein if a certain GIS service needs to expand the number of the examples and obtain the number E of the examples to be expanded, the service examples begin to be expanded, and if the number of the GIS service examples needs to be contracted and obtain the number S of the examples to be contracted, the service examples begin to be contracted;

after the current GIS service is newly deployed in the E Worker processes, the service management deployment submodule of the Master process obtains a name list L1 of the Worker processes deployed with the GIS service according to the query of the current GIS service name, S Worker process names are selected from the name list, a name list L2 of the Worker processes to be unloaded with the GIS service is obtained, and accordingly a list L3 of agent objects of the S Worker processes is obtained through the query of the Worker process management submodule;

the service management deployment submodule of the Master process traverses the list of the agent objects of the S Worker processes, obtains the agent object of the current Worker process in each traversal process, unloads the current GIS service through the agent object,

in the starting expansion service instance, a service management deployment submodule of a Master process inquires the number N of currently deployed instances of the GIS service according to a service name, the service management deployment submodule inquires the number M of currently started Worker processes from a Worker process management submodule, if N + E is less than or equal to M, the current number of the Worker processes is enough, the current GIS service is newly deployed into E Worker processes, if N + E > M, the current number of the Worker processes is not enough, the (N + E-M) Worker processes are restarted,

the method comprises the steps that when a current GIS service is newly deployed in E Worker processes, a service management deployment submodule of a Master process obtains a Worker process name list where the GIS service is deployed according to the query of a current GIS service name, then queries all the Worker process name lists to a Worker process management submodule, according to the two lists, a list of E Worker names where the current GIS service is not deployed can be obtained, according to the list, the Worker process management submodule queries the Worker process management submodule to obtain an E Worker process proxy object, and then sequentially calls the E Worker process proxy object to deploy the current GIS service into a corresponding Worker process.

2. The GIS service apparatus with automatically scalable microservice architecture according to claim 1, wherein the Master process module comprises the following sub-modules:

-a Worker process management submodule, configured for management of said one or more Worker processes, implementing operations for adding, deleting and/or modifying said one or more Worker processes;

a state maintaining submodule configured to collect a health condition of the Master process and/or state information of the one or more Worker processes, report the health condition to the Daemon process, and monitor the health condition of the Daemon process, wherein when the monitoring condition of the Daemon process is detected to be abnormal, the Daemon process is restarted, the state information reported by the one or more Worker processes is received, and the monitoring condition of the one or more Worker processes is judged according to the state information, wherein when the one or more Worker processes are found to be abnormal in operation, the Worker process management submodule and the service management deployment submodule are notified, the Worker process is restarted, and GIS service is redeployed;

-a service management deployment submodule, configured for management of said GIS services, managing GIS services for the whole device, comprising: releasing, deleting and/or modifying the GIS service, deploying the GIS service to each Worker process, constructing automatic expansion for the GIS service, and automatically expanding the GIS service by monitoring the load condition and the request response condition of each GIS service;

the service scheduling submodule is used for integrating all services of each Worker process and forwarding the service request, integrating the GIS service of each Worker process, generating a service directory, providing a uniform service access entrance, and scheduling the received service request to an available Worker process for processing;

-a support submodule configured to implement operations of security control, admission control and/or operation and maintenance monitoring;

-a configuration management submodule configured to read, save and/or modify said Master process configuration information, and further configured to read, save and/or modify configuration information of a GIS service.

3. The micro-service architecture automatically scalable GIS service device according to claim 1, wherein the Daemon process module comprises the following sub-modules:

-a Master process management submodule configured to start, stop and/or restart the Master process;

an exit monitoring submodule configured to monitor an exit event of the GIS service device, wherein when the exit event is monitored, the Master process management submodule is notified to perform an operation of stopping the Master process and stop the running of the current Daemon process, so that the current process normally exits;

-a health check sub-module configured to receive the status report of the Master process, analyze the health of the Master process, and according to the health of the Master process:

if the fact that the resource occupation of the Master process exceeds a set threshold value is monitored, a Master process management sub-module is notified to implement operation of restarting the Master process;

and if the Master process is monitored to be abnormally exited, informing the Master process management submodule to implement the operation of starting the Master process.

4. The microservice architecture automatically scalable GIS service device of claim 1, wherein the one or more Worker process modules comprise the following sub-modules:

a service management submodule configured to manage the GIS service, and to issue, delete and/or modify the GIS service of the Worker process;

-a GIS services sub-module configured to provide GIS services functionality by receiving GIS requests and selecting a particular GIS service to respond to the request and returning a response;

a status reporting submodule configured to report the status of the Worker process and the service status on the Worker process to the Master process periodically.

5. A control method for automatic scaling of GIS service device according to any of claims 1-4, characterized in that the method includes the following work flow:

-initiating a workflow of the GIS service device;

-stopping the work flow of the GIS service device;

-issuing a workflow of a GIS service through a Master process;

-Master process processing the work flow of the GIS service request;

-a Master process automatically scaling the GIS service;

the Master process judges whether the GIS service needs an automatic scaling workflow.

6. The method for controlling automatic scaling of the GIS service device according to any one of claims 1-4 of claim 5, wherein starting up the work flow of the GIS service device comprises the following steps:

-starting a Daemon process;

initializing a Daemon process, and initializing each internal sub-module until each sub-module is initialized;

a Master process management submodule in the Daemon process starts a Master process and judges whether the Master process is started successfully or not, wherein if the Master process is started successfully, the Master process is initialized, and if the Master process is failed to be started, prompt information is given in a console and a log file, so that the Daemon process is quitted;

-after the initialization is completed, determining whether the start of the GIS service device is successful, wherein if the start of the GIS service device is successful and the initialization is completed, a prompt is given in the console and in the log file, and if the start of the GIS service device fails, a prompt is also given in the console and in the log file.

7. The method for controlling automatic scaling of the GIS service device according to any one of claims 1-4 of claim 5, wherein stopping the work flow of the GIS service device comprises:

-sending an exit command to the Daemon process;

after the exit monitoring submodule of the Daemon process receives the exit command, the exit monitoring submodule forwards the received exit command to the Master process management submodule;

a Master process management submodule of the Daemon process sends an exit command to the Master process through a pipeline;

after receiving the quit command, the Master process destroys the Master process and the relevant Worker process managed by the Master process;

after each submodule of the Master process is stopped and destroyed, the Master process exits;

after monitoring the event that the Master process completely exits, the Daemon process starts to stop and destroy all the submodules of the Daemon process in sequence until all the submodules are destroyed, and the Daemon process exits;

all relevant processes of the GIS service device are normally exited and the GIS service device is normally stopped.

8. The method for controlling automatic scaling of the GIS service device according to any one of claims 1-4 of claim 5, wherein the work flow of issuing GIS service through the Master process includes the following steps:

-sending a request for issuing a GIS service to a Master process;

the service management deployment submodule of the Master process receives the request and responds to the request;

calculating the number of instances to be deployed of the service by a service management deployment submodule of the Master process according to the service configuration information, wherein if the number is N, the service is required to be deployed in N Worker;

the service management deployment submodule of the Master process inquires the number M of the currently started Worker processes from the Worker process management submodule, wherein if the number M of the currently started Worker processes is smaller than the number N of instances to be deployed of the service, the Worker process management submodule is informed to newly start (N-M) Worker processes, and if M is larger than or equal to N, the service management deployment submodule of the Master process inquires the N Worker processes with the minimum deployment service from the Worker process management submodule to obtain proxy objects of the N Worker processes;

traversing the proxy objects of the N Worker processes, and sequentially deploying the current GIS service to the corresponding Worker process through the proxy objects of the Worker processes.

9. The method for controlling automatic scaling of the GIS service device according to any one of claims 1-4 of claim 5, wherein the workflow of the Master process for processing GIS service request includes the following steps:

-a generic user of a GIS service device sends a GIS request to a Master process;

the service scheduling submodule of the Master process receives the request, analyzes the request and calculates to obtain a service name corresponding to the current GIS request;

the service scheduling submodule of the Master process inquires the service management deployment submodule about which Worker processes deploy the service according to the service name and returns a name list of the Worker processes;

the service scheduling submodule of the Master process inquires the Worker process management submodule according to the name list of the Worker process and returns a list of the Worker process proxy objects with specified names;

a service scheduling submodule of the Master process acquires a Worker process proxy object from a list of the Worker process proxy objects according to a load balancing algorithm;

-the service scheduling submodule of the Master process processes the request through the broker object of the Worker process;

the service scheduling submodule of the Master process judges a state mark in a response returned by the Worker process proxy object, wherein if the mark is that the service is temporarily unavailable, a Worker process proxy object is obtained from the list of the Worker process proxy object again, and the number of times of trying is determined at most; otherwise, the request is responded, the response information returned by the Worker process proxy object is written back to the request response received by the service scheduling submodule, and the request processing is completed.

10. The method for controlling automatic scaling of the GIS service device according to any one of claims 1 to 4, wherein the work flow of judging whether the GIS service needs automatic scaling by the Master process comprises the following steps:

the service management deployment submodule of the Master process inquires from the monitoring and counting unit of the support submodule according to the service name to obtain the current hardware resource use condition and the average number R of concurrent requests received by the GIS service in the latest one minute per second;

a service management deployment submodule of the Master process queries according to the service name to obtain the number N of currently deployed instances of the GIS service;

a service management deployment submodule of the Master process inquires from a configuration management submodule according to the service name to obtain the maximum processing concurrent request number RP of each service instance of the GIS service;

calculating the number F of service instances to be scaled by means of the formula F ═ (N-R/RP), and depending on the calculation results, the following different cases exist:

a) if F >1, the number of the current service instances is enough, obvious redundancy exists, the number of the service instances needs to be shrunk, a mark that the service needs to be shrunk is returned, and the number E of the shrunk service instances is equal to F;

b) if F < -1, the number of the current service instances is insufficient, a larger gap exists, the number of the service instances needs to be expanded, a mark that the service needs to be expanded is returned, and the number S of the expanded service instances is equal to-F;

c) if F is more than or equal to-1 and F is less than or equal to 1, the number of the current service instances is just enough, and the number of the service instances does not need to be scaled.

Images