JP6564067B2 - Service management method and apparatus - Google Patents

Description

  The present invention relates to the field of network technology, and more particularly, to a method and apparatus for service management.

  A distributed system is a computer system composed of a plurality of interconnected processing resources that perform the same task in a collaborative manner controlled by the overall system. Task execution may involve various service units in multiple application systems, and information is exchanged between these small service units, primarily through remote calls. However, remote paging results in a large amount of time being consumed, and when a distributed system grows to a certain scale, this consumption can greatly reduce the response efficiency of the system. become. According to the related art, application analysis may be performed to save time consumed by remote calls, and an application system having a service-dependent relationship can be obtained in a physically centralized manner. Can be deployed, but such methods have relatively poor flexibility and adaptability, and require analysis and deployment to be performed again when changes to the application exist. As a result, the cost of the service increases and its performance is affected.

  In view of the foregoing, the present invention provides a method and apparatus for service management in order to improve the response efficiency and adaptability of a distributed system.

Specifically, the present invention is implemented through the following technical solutions.
According to a first aspect, a method for service management is provided, the method comprising:
Detecting the popularity of the application's use of remote target services;
Loading the target service locally into the application when popularity reaches a preset first threshold;
Have

According to a second aspect, an apparatus for service management is provided, the apparatus comprising:
A popularity detection module configured to detect the popularity of the application's use of remote target services;
A mobility control module configured to load the target service locally into the application when the popularity detection module detects that the popularity has reached a preset first threshold;
Have

  In accordance with the method and apparatus for service management according to the present invention, when the popularity of a service reaches a preset threshold, the service is downloaded locally to the application and consequently distributed in relation to the remote call. The response efficiency and adaptive capacity of the system are improved.

FIG. 1 illustrates a distributed system architecture according to one embodiment of the present invention. FIG. 2 is a flowchart of a method for service management according to an embodiment of the present invention. FIG. 3 is a structural diagram of an apparatus for service management according to an embodiment of the present invention. FIG. 4 shows a structural diagram of another apparatus for service management according to an embodiment of the present invention.

  FIG. 1 illustrates an optional distributed system architecture. The system has a plurality of processing resources, and these processing resources may be, for example, a data storage server or a JAVA virtual machine. Various application system services and data are distributed within the processing resources described above. Hereinafter, some concepts used in the method for service management according to the present embodiment will be briefly described.

  Services and Applications: Taking account opening by a user at a bank as an example (note that this application is only an example), the overall account opening process includes: 1. verification of user ID information; 2. verify whether there is a record of bad credit status; The three steps of setting up new account information are considered necessary. Then, each of “verification of ID information”, “verification of record of credit status”, and “setup of new account information” may be referred to as “service”, and the service of “verification of ID information” Perhaps it may be provided by the “application” system of a public security agency, but the “credit record verification” and “new account information setup” services are provided by the bank's “application” system. . In relation to the account opening request by the user, the bank application system accepts this request and then provides services provided by the public security agency application system to perform the first verification step. It can be simply described that the second step and the third step are called locally to call remotely and then finally complete the overall account opening process. According to this solution, we can simply interpret an “application” as a way to split the deployment of services and “services”, where an “application” “Services” can be provided to users or other “applications”. In the process for implementing a user request, the service dependency between application systems is referred to as an “application that uses a service” or an “application that calls a service” in this embodiment.

  Services that access data sources: Service implementation processes usually involve data access. For example, the verification of ID information in the above example is whether the database stores the ID information to be verified. To use the ID database, which is accompanied by access to the “ID database” data source by the “ID information verification” service. The service can be executed normally only when the data access is normal. As shown in FIG. 1, the data source may come from a “data source” called a database, a “file system” called a file system, or a “cache” called a high-speed cache.

  Local service and remote service: related to local and remote, these two concepts may be interpreted in terms of their physical meaning, ie, a service invoked by an application, the service is deployed to the application A remote service when not present on a resource that is present, otherwise it is a local service, and in the example above, a bank application system is deployed on processing resource A, If an application system of a public security authority is deployed on the processing resource B, the “identification information verification” service is a remote service for the bank application system, and the other two services are The bank Since belonging to application system, a local service. In other words, when the bank application system calls the "Set up new account information" service, this service logic is deployed on processing resource A and is called and executed directly on resource A Can result in this being a local service. On the other hand, the public security application system to which the “verification of ID information” service to be called belongs is deployed on another processing resource B, and as a result, the bank application system is connected to the service via the network. It is necessary to send a call request to the application on the processing resource B, and to wait for a return of the execution result by the “verification of ID information” service which is a remote service call.

  It is clear that remote service calls result in time consumption for network transmission and waiting. When an application calls remote services frequently, the execution efficiency of the application will be greatly affected, and this is implemented to improve the response efficiency of the distributed system and reduce the service call time consumption. The method for service management in the form will be used. Furthermore, in the conventional method, in order to deploy an application system, it is necessary to manually analyze a service on an important service path and a service on a dependency destination. , Physically located in the vicinity. As a result, the requirements for service analysis personnel are relatively rigorous, and the complexity, deployment, operation, and maintenance of the overall system has increased, critical service paths have changed, or dependency relationships have increased. When changed, redeployment will be required, which will affect service stability. Furthermore, it is very inflexible and has poor compatibility. The method for service management in this embodiment further improves the adaptability of the distributed system to adapt flexibly to service calls by applications. Furthermore, in the context of physical proximity deployment, this embodiment reduces the granularity of “service” movement, which is preferred to reduce equipment costs.

  As shown in FIG. 1, this embodiment adds a device for service management in a distributed system, and the device includes a popularity detection module and a mobility control module. In addition, the apparatus for service management can execute the flow of the method for service management shown in FIG. 2, and the method includes the following steps:

  201. Detect the popularity of remote target service usage by applications.

  For example, in this step, this could be that the popularity detection module detects the popularity of the use of the remote target service by the application. Note that a device for service management can be considered a global management device that can summarize and record a large amount of information in an actual implementation. Table 1 below exemplarily lists some optional recording information.

  Hereinafter, the information in the above-described Table 1 will be described, but the application and service have been described above, and thus detailed description thereof will be omitted. The execution of a service may depend on multiple services for assistance. The service management method in the present embodiment involves movement of services, but not all services can be moved.

  Service Transfer: Referring to the example of FIG. 1, the application Y1 on the processing resource A needs to use the service S3, and the logic of the service S3 is stored on the processing resource B. When the application Y1 calls the service S3 on the processing resource B, this is a service remote call. The service S3 may be moved from the processing resource B to the processing resource A. In this case, the movement means movement of the service logic. As mentioned above, execution of a service may possibly involve access to a data source. As a result, the complete execution of the service can be viewed as having two parts, “logic” and “data”. The movement of the service in this embodiment means the movement of the logic, and the copy of the logic segment of the target service is moved. That is, the logic of service S3 is simultaneously saved on processing resource A so that processing resource A also saves a copy of the logic of service S3. As a result, the logical flow of the service S3 can be executed locally in the processing resource A. In addition to this, it should be noted that service S3 belongs to Y2 and is used only by Y1. Even if a move (move is a process of copying service logic and a copy of service logic is moved), service S3 still belongs to Y2, which does not change.

  Moveable services: As mentioned above, moving services only means moving logic, ie, the logic of the processing flow defined by the service. Therefore, when a service is moved to an application (moved to a processing resource corresponding to the application), the application needs to be able to access resources on which the normal execution of the service depends. For example, suppose normal execution of service S5 requires access to a data source (MySQL and Memcache), but application Y1 cannot access this data source. As a result, the service S5 cannot be normally executed after the service S5 is moved to the application Y1, and therefore the service S5 is not movable in relation to the application Y1.

  In order for a service to be a mobile service in relation to the application, the application needs to be able to access the data source required by the service, and it is understood that other conditions exist. It may be imposed. For example, a service is an independent service with a clear logical boundary, does not have complex interdependencies with other services, and, moreover, the service moves easily. As complete and small as possible. Furthermore, the service may be required to be a stateless service that does not have interdependent state. These are all for making the service easy to move. Furthermore, it may be considered whether the accessibility of the service is affected after the service is moved to the application. For example, the service has high efficiency in accessing the data source before the move, but after the move, for various reasons, to the extent that the service requirements of the application are no longer met. Service execution efficiency decreases. As a result, this service will not be considered suitable for travel. Furthermore, it should be noted that a moveable service is usually a remote service for an application, since mobility is not necessary for local services.

  A distributed system can have many applications. In this step, the service management device can globally manage which services can be moved to which applications, and manage the data sources accessible to each application. And the name of the data source can be integrated to facilitate the determination of whether the application has the data source required by the service. In addition, the service management device further summarizes information such as the popularity of the use of the movable service by the application, whether the service has been loaded into the application, and whether the service has been updated. You can also

  Popularity of use of mobile services by applications: “Popularity” is mainly used to inform the frequency of use of services by applications. For example, a service is called 50 times by an application within an hour, but of course, what type of metric is specifically used to signal popularity depends on the actual situation. It may be determined flexibly. In the present embodiment, the first threshold value and the second threshold value may be set for popularity, the first threshold value exceeds the second threshold value, and the first threshold value mainly includes the popularity value. Used to notify that when the threshold is reached or exceeded, the use of the service by the application is very frequent and that the execution limit of the application has been affected. Service movement can be performed, so when the service is loaded into the application, the second threshold is mainly determined when the application reaches the current value when the popularity value reaches or falls below this threshold. In order to save the processing resources, a service unloading may be performed to notify that the service is hardly used.

  Furthermore, an intermediate value may be set between the first threshold value and the second threshold value in order to avoid frequent reading and reverse reading. For example, when the first threshold value is 100 times and the second threshold value is 20 times, an intermediate value of 80 times is set between these two threshold values. Such a scheme will prevent over-reading or reverse-reading that would make the system unstable.

  Loading a service into an application: Reading a service into an application means that the remote service has been moved locally to the application. For example, as shown in FIG. 1, the service S3 in the processing resource B has been moved to the processing resource A in which the application Y1 is arranged, which means that the service S3 has been read into the application Y1. Is informed.

  Service update: The service logic in the distributed system may generate different versions of the service, for example, and the service management device in this embodiment may monitor whether the service has been updated, and May only monitor the remote service loaded into the application to reduce resource consumption by the service management device. This is because the purpose of monitoring service updates is as follows. In other words, when the service loaded into the application is updated, the current service on the application becomes an old service that is unavailable, and the reverse loading of the old service is performed quickly, and the new service is again executed. It is necessary to read. As a result, the service management device may only monitor the status of the service read into the application.

  In certain implementations, a status monitoring module may be added to the service management device to monitor whether the target service loaded into the application has been updated. Referring to FIG. 3, in such a case, the service management device may include a popularity detection module 31, a movement control module 32, and a state monitoring module 33.

  In this step, the popularity detection module of the device for service management will detect the popularity of the use of the remote target service by the application and in particular monitor the popularity of the use of the remote service by the respective application. And proceed to 202 according to the detected popularity.

  202. When the popularity reaches a preset first threshold, the target service is read locally into the application.

  For example, in this step, when the popularity detection module detects that the popularity of use of the target service by the application has reached a preset first threshold, the mobility control module makes the target service local to the application. Reading. Optionally, the mobility control module moves service S3 from processing resource B to processing resource A when the popularity of use of service S3 on processing resource B by application Y1 on processing resource A reaches a first threshold. It is thought that it can be done. Furthermore, the mobility control module may be arranged on the processing resource A, or may be a module dedicated to executing reading or reverse reading of the remote service. In other words, two modules may be provided on processing resource A, one of which is a module dedicated to managing local services, and the other is a remote service read or reverse read. A module dedicated to execution (eg, a remote class loader on JAVA virtual machine JVM). According to such a configuration, remote service management is relatively easy. When there is a need to perform remote service reading or reverse reading, the mobility control module only requires notification by the popularity detection module.

  In addition, the service reading and reverse reading in the present embodiment may be executed in an asynchronous state with respect to the application. For example, suppose that an application is currently in the process of remotely invoking a service, but it has been determined that the popularity of use of the service by the application has reached a first threshold. As a result, the movement control module performs the movement of the service, but the movement does not affect the current execution by the application. The application will still remain in the remote service invocation mode this time and will use the locally loaded service only on the next execution by the application.

  Furthermore, as described above, the popularity detection module continues to detect the popularity of use of the target service by the application even after the target service has been loaded locally into the application. If it is detected that the popularity has reached a second threshold, i.e., if the application then has a relatively low frequency of use of the target service, the mobility control module will allocate processing resources. To save, local reverse loading of the target service from the application may be performed.

  In addition, after the target service is loaded locally into the application, when the status monitoring module of the service management device detects an update to the target service, the mobility control module may The mobility control module may be notified to execute the reading and to read the updated target service.

  After the remote service is loaded locally into the application, the service management device can further include a service call module 34. As shown in FIG. 4, when used to execute an application, the service invocation module 34 determines whether the application stores the read target service locally, and the determination result is If the target service is stored locally, it is preferable to use the local target service to execute the application and reduce the time consumed by remote invocation. If the target service is not stored locally, a normal remote call is used.

  From the above-described embodiment, it is understood that by adding a service management device to the distributed system, the device can implement the service management method in the above-described embodiment. When the popularity of the use of the remote target service by the application reaches the frequency threshold, the remote service is moved locally to the application. In relation to the conventional system, according to such a configuration, the service management apparatus can automatically determine the frequency of use of the service, and automatically moves the service. As a result, costs for manual analysis and deployment are saved, and service deployment efficiency is improved. Such an automatic service determination and movement configuration has a relatively good flexibility and can quickly adapt to the actual situation of application execution. Also, by moving the remote service locally to the application, time consumption due to remote calls is avoided and the response efficiency of the distributed system is improved. In addition to this, the method in this embodiment uses services as the granularity of analysis, and as a result, relatively accurate mobility in the context of a traditional centralized deployment with application granularity. Granularity is achieved and processing efficiency is improved.

  The above description is only one preferred embodiment of the present invention and should not be used to limit the present invention. All changes, equivalent substitutions, or improvements implemented without departing from the spirit and principle of the present invention are encompassed by the present invention.

Claims (8)

A method for service management,
Detecting the popularity of the application's use of remote target services;
Reading the target service locally into the application when the popularity reaches a preset first threshold;
Equipped with,
Prior to the step of loading the target service locally into the application, the method comprises:
Determining that the target service satisfies a move condition, wherein the move condition is such that the application includes a data source required by the target service, and the target service. Is an independent service, step,
The method further comprising : After the step of reading the target service locally into the application, the method comprises:
Performing a local reverse reading of the target service from the application when the popularity reaches a preset second threshold;
The method of claim 1, further comprising: After the step of reading the target service locally into the application, the method comprises:
Performing a local reverse reading of the target service from the application when it is determined that the target service has been updated;
The method of claim 1, further comprising: After the step of loading the target service locally into the application, the method comprises:
Determining whether the application stores the read target service locally when executing the application;
Using the target service to execute the application if the determination result is that the target service is stored locally;
The method of claim 1, further comprising: A device for service management,
A popularity detection module configured to detect the popularity of the application's use of remote target services;
A mobility control module configured to read the target service locally into the application when the popularity detection module detects that the popularity has reached a preset first threshold;
Equipped with,
The popularity detection module is further configured to determine that the target service satisfies a move condition, wherein the move condition includes a data source required by the application for the application. And an apparatus comprising: the target service is an independent service . The mobility control module is further configured to perform a local reverse reading of the target service from the application when the popularity detection module detects that the popularity has reached a preset second threshold. 6. The apparatus of claim 5 , wherein the apparatus is configured. The apparatus further comprises a state monitoring module,
The status monitoring module is further configured to monitor updates to the target service; and
The mobility control module is further configured to perform a local reverse reading of the target service from the application when the state monitoring module determines that the target service has been updated.
The apparatus according to claim 5 . The device is
When executing the application, the application determines whether the read target service is stored locally, and the determination result is that the target service is stored locally A service invocation module configured to use the target service to execute the application;
6. The apparatus of claim 5 , further comprising:

Images