Adaptive service encapsulation method, apparatus and electronic device

Abstract

The application provides an adaptive service packaging method and device and electronic equipment, and belongs to the technical field of distribution. The adaptive service packaging method comprises the following steps: determining at least one service type according to preset business requirements of a target system, and packaging business logic corresponding to the at least one service type in at least one service module respectively; determining a service packaging strategy corresponding to a preset business scale of the target system according to the preset business scale; and packaging the at least one service module in at least one service process according to the service packaging strategy. The application realizes the unbundling between a service process and business logic, and then can flexibly configure the number of service modules and corresponding service types packaged in one service process according to different service scale requirements of a target system, so as to flexibly adapt to systems of different sizes and effectively improve the universality of a service system architecture.

Description

Technical Field

[0001] This application belongs to the field of distributed technology, and in particular relates to an adaptive service encapsulation method, apparatus and electronic device. Background Technology

[0002] In fields such as energy storage monitoring, system optimization and scheduling, and intelligent operation and maintenance, a complex back-end service system is typically required to support data acquisition, data storage, and predictive and early warning calculations based on massive amounts of data. Taking energy storage power stations as an example, the system scale spans multiple orders of magnitude from MWh to GWh, and the corresponding data processing volume also spans multiple orders of magnitude from tens of thousands to tens of millions of data points.

[0003] The current main approach is to design different service system architectures for systems of different sizes.

[0004] However, because systems of different sizes have different main problems to solve and different system complexities, different service system architectures need to be designed and developed independently, resulting in poor generality of service system architectures. Summary of the Invention

[0005] In view of the above-mentioned technical problems, the embodiments of this application provide an adaptive service encapsulation method, apparatus and electronic device, which realizes the debinding between service process and business logic. Then, according to the different service scale requirements of the target system, the number of service modules encapsulated in a service process and the corresponding service types can be flexibly configured to adapt to systems of different sizes, effectively improving the versatility of service system architecture.

[0006] In a first aspect, embodiments of this application provide an adaptive service encapsulation method, the method comprising:

[0007] Based on the preset business requirements of the target system, at least one service type is determined, and the business logic corresponding to the at least one service type is encapsulated in at least one service module respectively;

[0008] Based on the preset business scale of the target system, determine the service encapsulation strategy corresponding to the preset business scale;

[0009] According to the service encapsulation strategy, the at least one service module is encapsulated in at least one service process.

[0010] In this embodiment, at least one service type is first determined based on the preset business requirements of the target system, such as different service types like data collection and historical data storage. The business logic corresponding to these service types is then encapsulated in different service modules, enabling the service modules to support providing data collection services or historical data storage services. Compared to related technologies that develop corresponding service processes for different service types, resulting in a binding relationship between the service process and the business logic corresponding to the service type, leading to poor versatility of the service system architecture, this application encapsulates the business logic corresponding to the service type in the service module. The service process itself has no business characteristics; it merely provides a general operating environment and a standard interface for the service module, thus debinding the service process from the business logic. This allows for flexible configuration of the number of service modules encapsulated in a service process and the corresponding service types, based on the different service scale requirements of the target system, to flexibly adapt to systems of different sizes and effectively improve the versatility of the service system architecture.

[0011] In some embodiments, the preset service scale of the target system is represented by the number of nodes in the target system; determining the service encapsulation strategy corresponding to the preset service scale based on the preset service scale of the target system includes:

[0012] If the number of points in the target system is determined to be less than the first value, the service encapsulation strategy is determined to be a single-machine deployment strategy.

[0013] If the number of points in the target system is determined to be greater than or equal to the first value and less than the second value, the service encapsulation strategy is determined to be a distributed deployment strategy.

[0014] If the number of points in the target system is determined to be greater than or equal to the second value, the service encapsulation strategy is determined to be a distributed cluster deployment strategy.

[0015] Wherein, the first value is less than the second value.

[0016] This application provides a specific implementation of a service encapsulation strategy for determining a preset business scale. Specifically, the business scale is characterized by the number of nodes in the target system. If the number of nodes in the target system is less than a first value, the target system is considered a small-to-medium scale system, and its corresponding service encapsulation strategy is determined to be a single-machine deployment strategy, typically deploying only one physical server, corresponding to one service process. If the number of nodes in the target system is greater than or equal to the first value but less than a second value, the target system is considered a large-scale system, and its corresponding service encapsulation strategy is determined to be a distributed deployment strategy, deploying multiple physical servers, each corresponding to one service process. If the number of nodes in the target system is greater than or equal to the second value, the target system is considered a very large-scale system, and its corresponding service encapsulation strategy is determined to be a distributed cluster deployment strategy, deploying even more physical servers, each corresponding to one service process, among which some service processes support the same service type.

[0017] In some embodiments, encapsulating the at least one service module in at least one service process according to the service encapsulation strategy includes:

[0018] When the service encapsulation strategy is a single-machine deployment strategy, the at least one service module is encapsulated in a service process;

[0019] When the service encapsulation strategy is a distributed deployment strategy, at least one service module of different service types is encapsulated in a different service process.

[0020] When the service encapsulation strategy is a distributed cluster deployment strategy, at least one service module of different service types is encapsulated in at least two different service processes.

[0021] This application provides a specific implementation of service encapsulation based on a service encapsulation strategy. Specifically, under a single-machine deployment strategy corresponding to a small business scale, at least one service module can be encapsulated and deployed in a single service process. Under a distributed deployment strategy corresponding to a large business scale, at least one service module of different service types needs to be encapsulated in different service processes. For example, service process 1 can uniformly encapsulate service module 1, which provides data collection services, and service process 2 can uniformly encapsulate service module 2, which provides historical data storage services, so that different service processes provide different services. Under a distributed cluster deployment strategy corresponding to a very large business scale, at least one service module of different service types can be encapsulated in at least two different service processes. For example, service processes 1-5 can uniformly encapsulate service module 1, which provides data collection services, and service processes 6-10 can uniformly encapsulate service module 2, which provides historical data storage services, so that there are multiple service processes providing different services to support very large-scale systems.

[0022] In some embodiments, each of the service processes further includes a service management module;

[0023] The step of encapsulating the at least one service module in at least one service process includes:

[0024] For each of the at least one service process, the service interface of at least one service module to be encapsulated is registered on the service management module within the service process, and the service management module performs standardized packaging on the registered service interface.

[0025] The standardized service interface can be called by other service modules in the target system.

[0026] This application provides a specific implementation method for encapsulating service modules within service processes. Each service process also encapsulates a service management module. Specifically, the service management module registers the service interfaces of at least one service module to be encapsulated, and then standardizes and packages the registered service interfaces so that other service modules in the target system can call them normally. For example, it transparently supports other service modules to make local interface calls and remote RPC interface calls.

[0027] In some embodiments, the target system further includes service configuration files corresponding to each of the service processes, wherein the service configuration files include at least one of the service encapsulation strategy, service loading strategy, and service configuration parameters;

[0028] The service loading strategy is used to indicate at least one of the loading order of at least one service module to be loaded and at least two service modules to be loaded in the at least one service module to be encapsulated in the service process. The service configuration parameters include at least one of the initialization parameters and dynamic configuration parameters of the service module. The at least one loaded service module supports registration on the service management module.

[0029] In this embodiment, the target system also sets a corresponding service configuration file for each service process. For example, the above-mentioned service encapsulation strategy can be set therein, and the service process determines which service modules need to be encapsulated in the service process according to the service configuration file. The service configuration file can also include a service loading strategy, which can indicate the service modules that need to be loaded in the service modules to be encapsulated in the service process. If there are multiple service modules that need to be loaded, the loading order of these service modules can also be indicated. At least one service module after loading supports registration on the service management module. In addition, the service configuration file can also include service configuration parameters to provide at least one of initialization parameters and dynamic configuration parameters for the service modules, so that the service modules can be more adapted to actual needs, thereby enabling the entire target system to be as adapted to actual needs as possible.

[0030] In some embodiments, the method further includes:

[0031] For each of the at least one service process, the following query and invocation steps are performed using the service management module within that service process:

[0032] Receive an interface query request from the first service module within the service process; wherein the interface query request is used to query the call interface information of the second service module;

[0033] Check if the second service module exists in the local service process; wherein, the local service process is the service process in which the service management module is located;

[0034] If the second service module is found in the local service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the local wrapper interface in the call interface information of the second service module.

[0035] If the second service module is not found in the local service process, the second service module is queried through the service management module in other service processes; wherein, the other service processes are service processes in the target system other than the local service process;

[0036] If the second service module is found through the service management module in the other service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the remote procedure call (RPC) wrapper interface in the call interface information of the second service module.

[0037] If the second service module cannot be found through the service management module within the other service process, a message indicating query failure is sent to the first service module.

[0038] In this embodiment, a service management module within a service process can be used to query and invoke the calling interface information of other service modules. Specifically, after receiving an interface query request from the first service module within the service process, the service management module can first check in the local service process whether the requested second service module exists. If it exists, it obtains and sends the calling interface information of the second service module to the first service module. Since the second service module is in the local service process at this time, the first service module can call the second service module through the local wrapper interface in the calling interface information of the second service module. If it does not exist, the service management module can further query through the service management modules in other service processes whether the second service module exists. If it exists, it obtains and sends the calling interface information of the second service module to the first service module. At this time, since the second service module and the first service module are not in the same service process, the first service module can remotely call the second service module through the RPC wrapper interface in the calling interface information of the second service module. If the second service module is not found in other service processes, it returns information indicating query failure to the first service module.

[0039] In some embodiments, the service interface of the at least one service module includes: a management interface and an access interface;

[0040] The management interface is the interface used by each service module to interface with the service management module, and the access interface is the interface used by each service module to provide business access functions. The interface description rules of the access interface are fixed, and the access interface is different depending on the business logic encapsulated in the service module. The service management module obtains the interface description rules of the access interface through the management interface, parses and calls the business logic corresponding to the access interface through the interface description rules.

[0041] In this embodiment, for a service module, the service interface connecting it to the service management module can include two parts: a management interface and an access interface. The management interface is used to interface with the service management module, and the access interface is used to provide business access functions. For the access interface, its interface description rules are fixed, but they will vary depending on the business logic encapsulated within the service module. It supports arbitrary forms of business function call expressions, thereby supporting arbitrary expansion of business functions of different service modules. Since its interface description rules are fixed, the service management module can first obtain the interface description rules corresponding to the access interface through the management interface, and then parse and call the access interface through the interface description rules. The interface form is fixed and uniform, which makes it easy for the service management module to load and manage different service modules in the same way. In addition, each type of service can be encapsulated into an access interface in the form of this interface description rule. The interface description rules enable the access interface to be represented by a common text, which can easily realize the serialization and deserialization of the call process to achieve RPC calls.

[0042] Secondly, embodiments of this application also provide an adaptive service encapsulation apparatus, the apparatus comprising:

[0043] The first encapsulation module is used to determine at least one service type according to the preset business requirements of the target system, and encapsulate the business logic corresponding to the at least one service type into at least one service module respectively;

[0044] The determination module is used to determine a service encapsulation strategy corresponding to the preset business scale of the target system.

[0045] The second encapsulation module is used to encapsulate the at least one service module in at least one service process according to the service encapsulation strategy.

[0046] Thirdly, embodiments of this application also provide an adaptive service encapsulation system, including: a processor, at least one service process, and at least one service module; the processor executes the adaptive service encapsulation method as described in the first aspect.

[0047] Fourthly, embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the adaptive service encapsulation method as described in the first aspect.

[0048] Fifthly, embodiments of this application also provide a computer-readable storage medium storing computer instructions that, when executed on a computer, cause the computer to perform the adaptive service encapsulation method as described in the first aspect.

[0049] Sixthly, embodiments of this application also provide a computer program product, the computer program product including a computer program, which, when run on a computer, implements the adaptive service encapsulation method as described in the first aspect. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is one of the flowcharts illustrating an adaptive service encapsulation method proposed in an embodiment of this application;

[0052] Figure 2 This is a second flowchart illustrating an adaptive service encapsulation method proposed in an embodiment of this application;

[0053] Figure 3 This is a schematic diagram of a service process model in an adaptive service encapsulation method proposed in an embodiment of this application;

[0054] Figure 4 This is a schematic diagram of a service module model in an adaptive service encapsulation method proposed in an embodiment of this application;

[0055] Figure 5 This is a schematic diagram of the service management module in an adaptive service encapsulation method proposed in an embodiment of this application;

[0056] Figure 6 This is a schematic diagram of the service query and invocation process in an adaptive service encapsulation method proposed in an embodiment of this application;

[0057] Figure 7 This is the third flowchart illustrating an adaptive service encapsulation method proposed in this application embodiment;

[0058] Figure 8 This is a schematic diagram of the architecture of a data acquisition service system for small and medium-sized businesses in an adaptive service encapsulation method proposed in an embodiment of this application;

[0059] Figure 9 This is a schematic diagram of a large-scale distributed data acquisition service system architecture in an adaptive service encapsulation method proposed in an embodiment of this application;

[0060] Figure 10 This is a schematic diagram of the architecture of a large-scale distributed cluster data acquisition service system in an adaptive service encapsulation method proposed in an embodiment of this application;

[0061] Figure 11 This is a schematic diagram of the structure of an adaptive service encapsulation device proposed in an embodiment of this application. Detailed Implementation

[0062] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0063] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0064] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0065] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0066] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0067] In related technologies, different service system architectures are typically designed for systems of different sizes. Specifically:

[0068] 1) For small-scale systems, related functions are usually encapsulated in a service process. This makes the system compact and easy to deploy, which is sufficient to handle systems with a scale of less than 100,000 points.

[0069] 2) For systems with millions of points, different functions are usually encapsulated into different service processes. These different service processes are distributed and deployed on different physical nodes (servers) to form a distributed system. This can give full play to the high performance advantage of distributed systems.

[0070] 3) For systems with data scales of tens of millions or more, it is usually necessary to transform traditional distributed services into distributed cluster services. One service cluster supports a certain service capability of the large system, and multiple service clusters together constitute the entire system.

[0071] However, the above design method has the following problems: because the main contradictions and system complexities to be solved by designing different service system architectures are different, the backend services in the above three scenarios need to be designed and developed independently. Service system architectures of different business scales are difficult to be universal, and the universality of service system architectures is poor.

[0072] For example, a single service is simple and compact, but it is difficult to meet the performance requirements of large-scale systems; while distributed services and distributed cluster services have powerful encapsulation, but they are complex to deploy, have low efficiency in calling between services, and have a high probability of errors, making them too bloated and complex for small-scale business systems.

[0073] To address the aforementioned issues, this application provides an adaptive service encapsulation method. This method encapsulates the business logic corresponding to different service types within different service modules. The service process itself has no business characteristics; it merely provides a general operating environment and a standard interface for service modules, enabling the decoupling of business logic from the service process. This allows for flexible configuration of the number of service modules encapsulated within a single service process and their corresponding service types, based on the different service scale requirements of the target system. This adapts to systems of varying sizes without requiring independent redesign and development of corresponding service system architectures for systems of different business scales, effectively improving the versatility of the service system architecture.

[0074] The adaptive service encapsulation method, apparatus, and electronic device provided in the embodiments of this application will be described in detail below.

[0075] Figure 1 This is one of the flowcharts illustrating an adaptive service encapsulation method proposed in this application. Figure 1 As shown, the adaptive service encapsulation method includes S101-S103;

[0076] S101, determine at least one service type according to the preset business requirements of the target system, and encapsulate the business logic corresponding to the at least one service type in at least one service module.

[0077] Specifically, the first step is to analyze and sort out the pre-defined business requirements of the target system, and then divide the target system into several service types based on this.

[0078] For example, the background data acquisition business of a monitoring system can be broken down into two types of services: real-time data acquisition and historical data storage. In other words, the service types can include real-time data acquisition and historical data storage.

[0079] After identifying at least one service type, the business logic corresponding to these service types is encapsulated in different service modules. For example, the business logic for real-time data acquisition is encapsulated in service module 1 (also known as the data acquisition service module), and the business logic for historical data storage is encapsulated in service module 2 (also known as the historical service module). This allows service module 1 to support providing real-time data acquisition services, and service module 2 to support providing historical data storage services. The former calls the latter to implement the historical data entry of real-time data, while the former and the latter respectively provide the client with the functions of real-time data access and historical data access.

[0080] This application uses service modules as the basic unit for providing services, which is beneficial for flexibly configuring the service types and numbers of the included service modules in the service process according to the needs of business scale.

[0081] S102, determine the service encapsulation strategy corresponding to the preset business scale of the target system.

[0082] It should be noted that the target systems for the preset business scale include, for example, small and medium-sized systems, large systems, and super-large systems. The specific classification of the preset business scale can be set according to the actual situation. For data acquisition business, the system size is usually distinguished according to the number of data points. Systems with less than 1 million data points are considered small and medium-sized systems, systems with 1 million to 10 million data points are considered large systems, and systems with more than 10 million data points are considered super-large systems. This application does not impose any restrictions on this.

[0083] S103, according to the service encapsulation strategy, encapsulate the at least one service module in at least one service process.

[0084] Specifically, firstly, based on the preset business scale of the target system, a corresponding service encapsulation strategy is determined, and then at least one service module is encapsulated in the service process according to the determined service encapsulation strategy. For example, multiple service modules 1 can be encapsulated in one service process, or only one service module 1 can be encapsulated in multiple service processes, or one service module 1 and one service module 2 can be set up in one service process at the same time. This application does not limit the service type and number of service modules encapsulated in the service process.

[0085] It should be noted that there is a pre-set correspondence between business scale and service encapsulation strategy. This correspondence can be set or adjusted according to the actual situation in order to better support the target system in achieving the effect of providing services under the preset business scale.

[0086] In some embodiments, the service process can be encapsulated as an executable file, such as an .exe file. The service process itself has no business characteristics; it simply provides a general operating environment and a standard interface for service modules to interface with and publish.

[0087] In some embodiments, the service module can be encapsulated as a dynamic link library, such as a .dll file. The dynamic link library publishes services to the outside world using a standardized interface that conforms to the service process and is compatible with both in-process local calls and distributed RPC (Remote Procedure Call) calls. At the same time, it can query and call the service interfaces published by other service modules through the query interface provided by the service process.

[0088] In this embodiment, at least one service type is first determined based on the preset business requirements of the target system, such as different service types like data collection and historical data storage. The business logic corresponding to these service types is then encapsulated in different service modules, enabling the service modules to provide data collection services or historical data storage services. Compared to related technologies that develop corresponding service processes for different service types, resulting in a binding relationship between the service process and the business logic corresponding to the service type, leading to poor versatility of the service system architecture, this application encapsulates the business logic corresponding to the service type in the service module. The service process itself has no business characteristics; it merely provides a general operating environment and a standard interface for the service module, thus debinding the service process from the business logic. This allows for flexible configuration of the number of service modules encapsulated in a service process and the corresponding service types, based on the different service scale requirements of the target system, to flexibly adapt to systems of different sizes and effectively improve the versatility of the service system architecture.

[0089] In some embodiments, this application provides a specific implementation of a service encapsulation strategy corresponding to a preset service scale. The preset service scale of the target system can be represented by the number of points in the target system. Specifically, S102 above can be divided into the following cases:

[0090] Case 1: If the number of points in the target system is less than the first value, the service encapsulation strategy is determined to be a single-machine deployment strategy.

[0091] Case 2: If the number of points in the target system is determined to be greater than or equal to the first value and less than the second value, the service encapsulation strategy is determined to be a distributed deployment strategy.

[0092] Case 3: If the number of points in the target system is determined to be greater than or equal to the second value, the service encapsulation strategy is determined to be a distributed cluster deployment strategy.

[0093] Wherein, the first value is less than the second value.

[0094] It should be noted that the first and second values ​​can be set according to the actual situation. The first value can be less than the second value to classify different business scales.

[0095] For example, for data acquisition services, systems with less than 1 million data points are considered small to medium-sized systems, systems with 1 million to 10 million data points are considered large systems, and systems with more than 10 million data points are considered ultra-large systems. That is, the first value mentioned above is set to 1 million, and the second value mentioned above is set to 10 million.

[0096] This application provides a specific implementation of a service encapsulation strategy for determining a preset business scale. Specifically, the business scale is characterized by the number of nodes in the target system. If the number of nodes in the target system is less than a first value, the target system is considered a small-to-medium scale system, and its corresponding service encapsulation strategy is determined to be a single-machine deployment strategy, typically deploying only one physical server, corresponding to one service process. If the number of nodes in the target system is greater than or equal to the first value but less than a second value, the target system is considered a large-scale system, and its corresponding service encapsulation strategy is determined to be a distributed deployment strategy, deploying multiple physical servers, each corresponding to one service process. If the number of nodes in the target system is greater than or equal to the second value, the target system is considered a very large-scale system, and its corresponding service encapsulation strategy is determined to be a distributed cluster deployment strategy, deploying even more physical servers, each corresponding to one service process, among which some service processes support the same service type.

[0097] In some embodiments, based on the previous embodiment, this application provides a specific implementation of service encapsulation according to a service encapsulation strategy. Corresponding to situations 1-3 above, service encapsulation also includes situations 1-3, specifically:

[0098] Case 1: When the service encapsulation strategy is a single-machine deployment strategy, the at least one service module is encapsulated in a service process.

[0099] Scenario 2: When the service encapsulation strategy is a distributed deployment strategy, at least one service module of different service types is encapsulated in a different service process.

[0100] Case 3: When the service encapsulation strategy is a distributed cluster deployment strategy, at least one service module of different service types is encapsulated in at least two different service processes.

[0101] For example, for small to medium-sized data collection business scales (e.g., the number of data points in the system is less than 1 million), a single-machine deployment strategy can be adopted to encapsulate the data collection service module and the historical service module into a single service process.

[0102] For large-scale data acquisition operations (e.g., the number of data points in the system is between 1 million and 10 million), a distributed deployment strategy can be adopted. The data acquisition service module and the historical service module are encapsulated in different service processes and deployed on different physical nodes to form a distributed data acquisition system.

[0103] For ultra-large-scale data collection operations (e.g., the number of data points in the system is greater than 10 million), a distributed cluster deployment strategy can be adopted. The data collection service module and the historical service module are encapsulated in different service processes, and the service processes corresponding to each service type are deployed on multiple physical nodes to form a distributed cluster data collection system.

[0104] This application provides a specific implementation of service encapsulation based on a service encapsulation strategy. Specifically, under a single-machine deployment strategy corresponding to a small business scale, at least one service module can be encapsulated and deployed within a single service process. Under a distributed deployment strategy corresponding to a large business scale, at least one service module of different service types needs to be encapsulated in different service processes. For example, service process 1 can uniformly encapsulate service module 1 providing data acquisition services, while service process 2 can uniformly encapsulate service module 2 providing historical data storage services, so that different service processes provide different services. Under a distributed cluster deployment strategy corresponding to a very large business scale, at least one service module of different service types can be encapsulated in at least two different service processes. For example, service processes 1-5 can uniformly encapsulate service module 1 providing data acquisition services, while service processes 6-10 can uniformly encapsulate service module 2 providing historical data storage services, so that multiple service processes provide different services to support very large-scale systems.

[0105] In some embodiments, this application provides a specific implementation method for encapsulating service modules within service processes. Each service process also encapsulates a service management module. The specific implementation method for encapsulating at least one service module within at least one service process may include:

[0106] For each of the at least one service process, the service interface of at least one service module to be encapsulated is registered on the service management module within the service process, and the service management module performs standardized packaging on the registered service interface.

[0107] The standardized service interface can be called by other service modules in the target system.

[0108] It should be noted that, for each service module, the standardized packaged service interface is set on the service management module, which can include local packaged interfaces and RPC packaged interfaces; the local packaged interface is used to support service module calls within the local service process, while the RPC packaged interface is used to support service module calls outside the local service process.

[0109] For example, suppose that service module X needs to call service module Z. If service module Z is within the local service process, service module X can call service module Z through the local wrapper interface Z set on the service management module within the local service process. If service module Z is outside the local service process, service module X needs to call service module Z through the RPC wrapper interface Z set on the service management module within the service process where service module Z is located.

[0110] In some embodiments, the service management module can receive service registrations from service modules using standardized, compatible interfaces. It also supports service modules querying service interfaces published by other service modules through the service management module's query interface. These service interfaces include those of other service modules within the local service process, as well as those of service modules within other service processes in the distributed target system. The service management module can perform dual wrapping on registered service interfaces: firstly, wrapping them as internal local wrapper interfaces for other service modules within the local service process to call; and secondly, wrapping them as external RPC wrapper interfaces for service modules within other distributed service processes to call.

[0111] This application provides a specific implementation method for encapsulating service modules within service processes. Each service process also encapsulates a service management module. Specifically, the service management module registers the service interfaces of at least one service module to be encapsulated, and then standardizes and packages the registered service interfaces so that other service modules in the target system can call them normally. For example, it transparently supports other service modules to make local interface calls and remote RPC interface calls.

[0112] In some embodiments, the target system may further include service configuration files corresponding to each of the service processes, wherein the service configuration files include at least one of the service encapsulation strategy, service loading strategy, and service configuration parameters;

[0113] The service loading strategy is used to indicate at least one of the loading order of at least one service module to be loaded and at least two service modules to be loaded in the at least one service module to be encapsulated in the service process. The service configuration parameters include at least one of the initialization parameters and dynamic configuration parameters of the service module. The at least one loaded service module supports registration on the service management module.

[0114] Specifically, the service configuration file can be considered as the basis for the service process to load service modules. In addition to the service encapsulation strategy mentioned above, its content may also include the service loading strategy and service configuration parameters.

[0115] In some embodiments, the service loading strategy includes at least two aspects: which service modules to load and the loading order. The service configuration parameters need to include the initialization parameters of the service modules and other configuration data. The initialization parameters can be understood as some common configuration parameters of the service modules. Other configuration data may include, for example, dynamic configuration parameters. Dynamic configuration parameters can be understood as some parameters that can be configured in a personalized way, so as to dynamically configure the service modules according to the actual situation.

[0116] It should be noted that for at least one service module to be encapsulated, the service process needs to load these service modules first. After loading is completed, these service modules can initiate registration with the service management module to register the service interface of at least one service module to be encapsulated on the service management module within the service process. The service management module then performs standardized packaging on the registered service interface to achieve the encapsulation of the service module.

[0117] In this embodiment, the target system also sets a corresponding service configuration file for each service process. For example, the aforementioned service encapsulation strategy can be set therein, and the service process determines which service modules need to be encapsulated in the service process according to the service configuration file. The service configuration file can also include a service loading strategy, which can indicate the service modules that need to be loaded in the service modules to be encapsulated in the service process. If there are multiple service modules that need to be loaded, the loading order of these service modules can also be indicated. At least one service module after loading supports registration on the service management module. In addition, the service configuration file can also include service configuration parameters to provide at least one of initialization parameters and dynamic configuration parameters for the service modules, so that the service modules can be more adapted to actual needs, thereby enabling the entire target system to be as adapted to actual needs as possible.

[0118] In some embodiments, this application may utilize the service management module in the service process to query and invoke the calling interface information of other service modules. Figure 2 This is a second flowchart illustrating an adaptive service encapsulation method proposed in an embodiment of this application, as shown below. Figure 2 As shown, for each of the at least one service process, the following query and invocation steps S201-S206 are executed using the service management module within the service process:

[0119] S201, Receive an interface query request from the first service module within the service process;

[0120] The interface query request is used to query the call interface information of the second service module.

[0121] S202, Check if the second service module exists in the local service process;

[0122] The local service process is the service process in which the service management module resides.

[0123] S203, if the second service module is found in the local service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the local wrapper interface in the call interface information of the second service module.

[0124] S204, if the second service module is not found in the local service process, the second service module is queried through the service management module in other service processes;

[0125] The other service processes are those in the target system other than the local service processes.

[0126] It should be noted that S203 and S204 are executed selectively during actual execution. The choice between S203 and S204 depends on whether the second service module is found in the local service process.

[0127] S205, if the second service module is found through the service management module in the other service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the RPC wrapper interface in the call interface information of the second service module.

[0128] S206, if the second service module is not found through the service management module in the other service process, a message indicating query failure is sent to the first service module.

[0129] It should be noted that S205 and S206 are executed selectively during actual execution. The specific choice between S205 and S206 depends on whether the second service module can be found through the service management module within other service processes.

[0130] For example, for service management module 1 within service process 1, after receiving an interface query request sent by service module X (i.e., the first service module mentioned above) within service process 1, it can parse that the interface query request requests service module Y (i.e., the second service module mentioned above). At this time, service management module 1 needs to query service module Y and assist service module X in making the call. Specifically, service management module 1 can execute the following query process:

[0131] First, the service management module 1 checks whether service module Y exists in the service modules within service process 1. If service module Y exists, the local wrapping interface Y set on the service management module 1 can be returned to service module X, so that service module X can call service module Y through the local wrapping interface Y.

[0132] If service module Y is not found within service process 1, service management module 1 can further query service module Y through service management modules within other service processes.

[0133] It should be noted that service management modules within different service processes can interconnect with each other through a distributed collaboration mechanism, thereby enabling distributed service query functionality.

[0134] If service management module 1 fails to find service module Y through service management modules in other service processes, it can return information indicating query failure to service module X.

[0135] If service management module 1 finds service module Y through service management module 2 within service process 2, it can obtain the RPC wrapper interface Y set by service module Y on service management module 2 and return it to service module X, so that service module X can call service module Y through the RPC wrapper interface Y.

[0136] In some embodiments, after determining that there is information indicating a failed query, the designer can add a service module that was not found in the target system according to the actual situation, such as adding the aforementioned service module Y. This application does not limit whether it is added to service process 1, service process 2 or other service processes.

[0137] In this embodiment, a service management module within a service process can be used to query and invoke the calling interface information of other service modules. Specifically, after receiving an interface query request from the first service module within the service process, the service management module can first check in the local service process whether the requested second service module exists. If it exists, it obtains and sends the calling interface information of the second service module to the first service module. Since the second service module is in the local service process at this time, the first service module can call the second service module through the local wrapper interface in the calling interface information of the second service module. If it does not exist, the service management module can further query through the service management modules in other service processes whether the second service module exists. If it exists, it obtains and sends the calling interface information of the second service module to the first service module. At this time, since the second service module and the first service module are not in the same service process, the first service module can remotely call the second service module through the RPC wrapper interface in the calling interface information of the second service module. If the second service module is not found in other service processes, it returns information indicating query failure to the first service module.

[0138] In some embodiments, the service interface of the at least one service module may include: a management interface and an access interface;

[0139] The management interface is the interface used by each service module to interface with the service management module, and the access interface is the interface used by each service module to provide business access functions. The interface description rules of the access interface are fixed, and the access interface is different depending on the business logic encapsulated in the service module. The service management module obtains the interface description rules of the access interface through the management interface, parses and calls the business logic corresponding to the access interface through the interface description rules.

[0140] Specifically, a service module encapsulates specific business functions into a dynamic link library, which is loaded and run by the service process, providing services to the outside world through a standardized interface. This service interface is a compatible interface agreed upon by the service management module and the service modules. It can be further wrapped by the service management module, thereby simultaneously supporting local calls from other service modules within the local service process, as well as remote RPC calls from service modules within other distributed service processes.

[0141] It should be noted that standardized and compatible service interfaces must meet the following three conditions:

[0142] 1) Easy to serialize and deserialize for enabling RPC calls;

[0143] 2) The interface format is fixed and uniform, which makes it easy for the service management module to load and manage different service modules in the same way;

[0144] 3) Supports any form of business function call expression, thereby supporting arbitrary expansion of business functions of different service modules.

[0145] To address the above three requirements, this application provides a specific implementation of the service interface for the service module. Specifically, this application divides the service interface into two parts:

[0146] One part is the management interface (interface 1) that interfaces with the service management module. This interface is a fixed interface defined by the native programming language, such as a pure virtual interface class in C++.

[0147] The other part is the access interface (interface 2) that actually provides business access functions. This interface is a descriptive interface that can be interpreted and executed. It varies depending on the business, but the interface description rules are fixed, such as an interface that uses JSON as the medium for description and expression.

[0148] The service module can obtain the description model of the interface 2 through the interface 1, parse any interface 2 according to fixed rules, and call any interface 2 in a fixed way.

[0149] For example, Interface 1 specifies the following general interface call member function: const Result&CallService(const string&interfaceName,const string&functionName,const Json&input,Json&output);

[0150] Here, interfaceName is the name of interface 2 to be called; functionName is the member function of interface 2 to be called; input is the input parameter for this call, which can be expressed as an arbitrarily complex data structure through JSON; output is the output data generated by this call, which can also be stored in an arbitrarily complex output data format through a JSON object; the return value of CallService is a Result structure, which stores the result of the interface call, indicating whether the call was successful, and if it failed, the reason.

[0151] It should be noted that Interface 2 is an interface description file, which details the interface name, the member functions that make up the interface, and the input and output parameter structure of each member function. The main rules for interface description are: an interface consists of several member functions, each member function has only one Json type input object and one Json type output object, and the rich semantic expressiveness of Json can be used to express input and output data of any form.

[0152] It should also be noted that each business logic can be encapsulated into an interface of type Interface 2. Furthermore, Interface 2 is a generic text representation, which easily enables the serialization and deserialization of the call process to facilitate RPC calls.

[0153] In this embodiment, for a service module, the service interface connecting it to the service management module can include two parts: a management interface and an access interface. The management interface is used to interface with the service management module, and the access interface is used to provide business access functions. For the access interface, its interface description rules are fixed, but they will vary depending on the business logic encapsulated within the service module. It supports arbitrary forms of business function call expressions, thereby supporting arbitrary expansion of business functions of different service modules. Since its interface description rules are fixed, the service management module can first obtain the interface description rules corresponding to the access interface through the management interface, and then parse and call the access interface through the interface description rules. The interface form is fixed and uniform, which makes it easy for the service management module to load and manage different service modules in the same way. In addition, each type of service can be encapsulated into an access interface in the form of this interface description rule. The interface description rules enable the access interface to be represented by a common text, which can easily realize the serialization and deserialization of the call process to achieve RPC calls.

[0154] The following example illustrates the adaptive service encapsulation method provided in this application, which belongs to the field of distributed system construction technology. This method can flexibly adapt to a wide range of business scales. Under the premise of ensuring system functionality and reliability and optimal deployment cost, it enables a single service software to flexibly adapt to business systems of any scale through different system configurations. Through different system configurations, service capabilities can be encapsulated into various forms such as single service processes, distributed service systems, and distributed cluster service systems.

[0155] The adaptive service encapsulation method in this application mainly involves the following parts:

[0156] 1) Defined the encapsulation form and model of the service process.

[0157] The service process can be encapsulated as an executable file (e.g., .exe). The service process itself has no business characteristics; it merely provides a general runtime environment and a standard interface for service modules, facilitating their deployment and publishing. A service process consists of an executable file, a service management module, a service configuration file, and several dynamic link libraries for the service modules. When the service process starts, the executable file loads the specified service modules according to the strategy specified in the service configuration file, provides them with a runtime environment, and registers their service interfaces with the service management module to achieve service publishing and inter-service interface integration.

[0158] 2) Defined the encapsulation form and model of the service module.

[0159] The service module can be encapsulated as a dynamic link library. The dynamic link library publishes services to the outside world through a standardized interface that conforms to the service process and is compatible with both in-process local calls and distributed RPC calls. At the same time, it can query and call the service interfaces published by other service modules through the query interface provided by the service process.

[0160] 3) The model for the service management module was defined.

[0161] The service management module receives service registrations from service modules using standardized and compatible interfaces. It also supports service modules in querying service interfaces published by other service modules. These service interfaces include interfaces from other service modules within the same process, as well as interfaces from service modules within other processes in the distributed system.

[0162] In addition, the service management module can double-package the registered service interfaces. On the one hand, it can be packaged into an internal local package interface for other service modules within the local service process to call; on the other hand, it can be packaged into an external RPC package interface for service modules within other distributed service processes to call.

[0163] The following sections will elaborate on the three parts mentioned above:

[0164] <1> Regarding service process models and encapsulation:

[0165] Figure 3 This is a schematic diagram of a service process model in an adaptive service encapsulation method proposed in an embodiment of this application, as shown below. Figure 3 As shown, the service process model in this embodiment includes three parts: a service module dynamic library (service module), a service process executable file (service process container), and a service configuration file. Their functions are divided as follows:

[0166] 1> Service Module: The service module encapsulates the implementation logic of specific business functions. The encapsulation form is a dynamic link library (shown as .dll / .so in the figure). It can be loaded and managed by the service process. Different service modules can call each other through standardized interfaces.

[0167] 2. Service Process Container: A service process container is a general-purpose service module runtime container (shown in the diagram as an example of .exe / .so files). It lacks specific business characteristics and loads and initializes service modules according to the strategy specified in the service configuration file, providing the runtime environment for the service modules. Internally, the service process encapsulates a service management module. This module supports service interface registration for service modules and also supports service interface querying. It can query not only service interfaces published by local service modules but also service interfaces published by service modules distributed across service processes on other physical nodes. A single service process container can load and manage several service modules.

[0168] 3> Service Configuration File: The service configuration file is the basis for the service process to load service modules. Its contents include service loading strategy and service configuration parameters. The service loading strategy includes at least two aspects: which service modules to load and what the loading order is. The service configuration parameters include the initialization parameters of the service modules and other configuration data.

[0169] <2> Regarding service module models and encapsulation:

[0170] Figure 4 This is a schematic diagram of a service module model in an adaptive service encapsulation method proposed in an embodiment of this application, as shown below. Figure 4 As shown, the service module is used to encapsulate specific business functions into a dynamic link library (shown as an example in the figure), which is loaded and run by the service process and provides services to the outside world through standardized interfaces.

[0171] Taking service module X as an example in the diagram, service interface X is a compatible interface agreed upon by the service management module and the service module. It can be wrapped by the service management module to support local calls from other service modules within the local service process, as well as remote RPC calls from other distributed in-process service modules.

[0172] The aforementioned service interface X can be divided into two parts. One part is the management interface (interface 1) that interfaces with the service management module. This interface is a fixed interface defined by the native programming language, such as a pure virtual interface class in C++. The other part is the access interface (interface 2) that actually provides business access functions. This interface is a descriptive interface that can be interpreted and executed. It varies depending on the business, but the interface description rules are fixed, such as an interface that uses JSON as a medium for description and expression.

[0173] <3> For the service management module model:

[0174] The service management module is a built-in core module of the service process, providing three core capabilities for service modules: interface registration, interface packaging, and interface integration.

[0175] 1> Interface Registration: Supports the registration of service interfaces for several service modules within the local service process. The service interfaces can be in the form of the standardized compatible interfaces mentioned above.

[0176] Figure 5 This is a schematic diagram of the service management module in an adaptive service encapsulation method proposed in an embodiment of this application, as shown below. Figure 5 As shown, service module X and service module Y registered service interface X and service interface Y with the service management module in service process 1, and service module Z registered service interface Z with the service management module in service process 2.

[0177] 2> Interface Packaging: The service management module will standardize and package the registered service interfaces according to the configuration, so as to support other service modules to make local calls and remote RPC calls in a transparent manner.

[0178] like Figure 5 As shown, service interfaces X, Y, and Z are wrapped by their respective service management modules to generate RPC wrapper interfaces X, Y, and Z, as well as local wrapper interfaces X, Y, and Z. The RPC wrapper interfaces and local wrapper interfaces are completely identical to the caller; the differences in their internal execution processes are entirely transparent to the caller.

[0179] 3. Interface Integration: The service management module provides query functionality for existing service interfaces through a service query interface. The query scope includes both local service modules within the local service process and distributed service modules within other service processes. Service management modules within different service processes interconnect with each other through a distributed collaboration mechanism, thereby achieving distributed service query functionality. The caller first checks the service interface of interest to see if it exists. If it exists, it can directly call it through the corresponding wrapper interface, thus achieving interface integration between service modules.

[0180] like Figure 5 As shown, service module X finds and calls the local wrapper interface Y through the local service query interface; service module Y finds and calls the distributed RPC wrapper interface Z through the local service query interface.

[0181] The service query and invocation process provided in the embodiments of this application is as follows: Figure 5 This explanation will use the example of service module Y calling interface Z to illustrate the process. Figure 6 This is a flowchart illustrating the service query and invocation process in an adaptive service encapsulation method proposed in this application, as shown in the embodiment. Figure 6 As shown, it includes the following steps:

[0182] S601, Begin.

[0183] S602, Service module Y calls the service query interface of service process 1 to query interface Z;

[0184] S603, the service management module of service process 1 determines whether interface Z exists in service process 1. If yes, proceed to S604; otherwise, proceed to S605.

[0185] S604, return the local wrapper interface of interface Z to service module Y, and enter S609;

[0186] S605, the service management module of service process 1 uses a distributed coordination mechanism to check whether there are other processes in the distributed system. If so, proceed to S606; otherwise, proceed to S6010.

[0187] S606, the service management module of service process 1 uses RPC to traverse and call the service query interface of each service process to query interface Z;

[0188] S607, determine if interface Z exists. If it does, proceed to S608; otherwise, proceed to S6010.

[0189] S608, returns the RPC wrapper interface of interface Z to service module Y;

[0190] S609, Service module Y calls interface Z;

[0191] S6010, return information indicating query failure to service module Y;

[0192] S6011, End.

[0193] The following describes the implementation steps of the adaptive service encapsulation method for systems with different business scales based on embodiments of this application. Figure 7 This is the third flowchart illustrating an adaptive service encapsulation method proposed in this application. Figure 7 As shown, it includes S701-S704:

[0194] S701 classifies system service types based on business characteristics.

[0195] Specifically, the business requirements of the system are analyzed and sorted out, and based on this, the system is divided into several service types.

[0196] For example, the backend data acquisition business of a monitoring system can be broken down into two types of services: real-time data acquisition and historical data storage.

[0197] S702 encapsulates each type of system service into a service module.

[0198] Specifically, the service types decomposed from S701 are designed and encapsulated into a service module. During this process, reasonable service interfaces and dependencies between service modules must be designed.

[0199] For example, real-time data acquisition can be encapsulated as a data acquisition service module, and historical data storage can be encapsulated as a historical service module. The former calls the latter to realize the historical entry of real-time data into the database, while the former and the latter respectively provide the client with the functions of real-time data access and historical data access.

[0200] S703, Analyze the business scale of the target system.

[0201] Specifically, for data acquisition services, the scale of a system is usually distinguished by the number of data points. Systems with less than 1 million data points are considered small to medium-sized systems, systems with 1 million to 10 million data points are considered large systems, and systems with more than 10 million data points are considered ultra-large systems.

[0202] S704: Select the appropriate packaging strategy and deployment scheme according to the business scale.

[0203] Specifically, for small and medium-sized data acquisition businesses, Figure 8 This is a schematic diagram of the data acquisition service system architecture for small and medium-sized businesses in an adaptive service encapsulation method proposed in this application embodiment, as shown below. Figure 8As shown, the data acquisition service module and the historical service module are encapsulated into a single service process and deployed on a single machine.

[0204] For large-scale data acquisition operations Figure 9 This is a schematic diagram of a large-scale distributed data acquisition service system architecture in an adaptive service encapsulation method proposed in an embodiment of this application, as shown below. Figure 9 As shown, the data acquisition service module and the historical service module are encapsulated as different service processes and deployed on different physical nodes to form a distributed data acquisition system.

[0205] For ultra-large-scale data collection operations Figure 10 This is a schematic diagram of the architecture of a large-scale distributed cluster data acquisition service system in an adaptive service encapsulation method proposed in this application embodiment, as shown below. Figure 10 As shown, the data acquisition service module and the historical service module are encapsulated as different service processes, and each service process is deployed on multiple physical nodes to form a distributed cluster data acquisition system.

[0206] In the embodiments of this application, at least the following beneficial effects exist:

[0207] 1) This application supports flexible process-level encapsulation of distributed services. Under the premise of ensuring the reusability of the service module as a black box, by modifying the service configuration file, any number of service modules can be encapsulated into a service process. Then, multiple such service processes constitute a complete distributed system or a distributed cluster system. The granularity of the service process splitting depends on the needs of the system's business scale.

[0208] 2) This application supports flexible deployment across large business scales. When the business scale is relatively small, all service modules can be encapsulated into a single service process and deployed on a single server to form a lightweight single-machine service system. When the business scale is large, different service modules can be encapsulated into different service processes and deployed on different servers to form a distributed service system. When the business scale is extremely large, each service can be encapsulated into a single service process, and multiple service processes of the same service type can be deployed on multiple physical servers to form a service cluster. Different service clusters together constitute the entire distributed cluster system.

[0209] The adaptive service encapsulation method proposed in the embodiments of this application has been described above. The related devices and electronic equipment are described below.

[0210] Figure 11 This is a schematic diagram of the structure of an adaptive service encapsulation device proposed in an embodiment of this application, as shown below. Figure 11 As shown, the adaptive service encapsulation device 1100 includes:

[0211] The first encapsulation module 1101 is used to determine at least one service type according to the preset business requirements of the target system, and encapsulate the business logic corresponding to the at least one service type into at least one service module respectively;

[0212] The determining module 1102 is used to determine a service encapsulation strategy corresponding to the preset business scale of the target system.

[0213] The second encapsulation module 1103 is used to encapsulate the at least one service module in at least one service process according to the service encapsulation strategy.

[0214] In some embodiments, the preset business scale of the target system is represented by the number of nodes in the target system; the determining module 1102 is specifically used for:

[0215] If the number of points in the target system is determined to be less than the first value, the service encapsulation strategy is determined to be a single-machine deployment strategy.

[0216] If the number of points in the target system is determined to be greater than or equal to the first value and less than the second value, the service encapsulation strategy is determined to be a distributed deployment strategy.

[0217] If the number of points in the target system is determined to be greater than or equal to the second value, the service encapsulation strategy is determined to be a distributed cluster deployment strategy.

[0218] Wherein, the first value is less than the second value.

[0219] In some embodiments, the second encapsulation module 1103 is specifically used for:

[0220] When the service encapsulation strategy is a single-machine deployment strategy, the at least one service module is encapsulated in a service process;

[0221] When the service encapsulation strategy is a distributed deployment strategy, at least one service module of different service types is encapsulated in a different service process.

[0222] When the service encapsulation strategy is a distributed cluster deployment strategy, at least one service module of different service types is encapsulated in at least two different service processes.

[0223] In some embodiments, each of the service processes further encapsulates a service management module; the second encapsulation module 1103 is further specifically used for:

[0224] For each of the at least one service process, the service interface of at least one service module to be encapsulated is registered on the service management module within the service process, and the service management module performs standardized packaging on the registered service interface.

[0225] The standardized service interface can be called by other service modules in the target system.

[0226] In some embodiments, the target system further includes service configuration files corresponding to each of the service processes, wherein the service configuration files include at least one of the service encapsulation strategy, service loading strategy, and service configuration parameters;

[0227] The service loading strategy is used to indicate at least one of the loading order of at least one service module to be loaded and at least two service modules to be loaded in the at least one service module to be encapsulated in the service process. The service configuration parameters include at least one of the initialization parameters and dynamic configuration parameters of the service module. The at least one loaded service module supports registration on the service management module.

[0228] In some embodiments, the adaptive service encapsulation apparatus 1100 further includes: a processing module, configured to:

[0229] For each of the at least one service process, the following query and invocation steps are performed using the service management module within that service process:

[0230] Receive an interface query request from the first service module within the service process; wherein the interface query request is used to query the call interface information of the second service module;

[0231] Check if the second service module exists in the local service process; wherein, the local service process is the service process in which the service management module is located;

[0232] If the second service module is found in the local service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the local wrapper interface in the call interface information of the second service module.

[0233] If the second service module is not found in the local service process, the second service module is queried through the service management module in other service processes; wherein, the other service processes are service processes in the target system other than the local service process;

[0234] If the second service module is found through the service management module in the other service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the remote procedure call (RPC) wrapper interface in the call interface information of the second service module.

[0235] If the second service module cannot be found through the service management module within the other service process, a message indicating query failure is sent to the first service module.

[0236] In some embodiments, the service interface of the at least one service module includes: a management interface and an access interface;

[0237] The management interface is the interface used by each service module to interface with the service management module, and the access interface is the interface used by each service module to provide business access functions. The interface description rules of the access interface are fixed, and the access interface is different depending on the business logic encapsulated in the service module. The service management module obtains the interface description rules of the access interface through the management interface, parses and calls the business logic corresponding to the access interface through the interface description rules.

[0238] It should be understood that the adaptive service packaging device 1100 of this application embodiment can be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The aforementioned method can also be implemented in software; the adaptive service packaging device 1100 and its various modules can also be software modules.

[0239] This application also provides an adaptive service encapsulation system, including: a processor, at least one service process, and at least one service module; wherein, the processor executes the adaptive service encapsulation method described in any of the above embodiments, specifically performing the following steps:

[0240] Based on the preset business requirements of the target system, at least one service type is determined, and the business logic corresponding to the at least one service type is encapsulated in at least one service module respectively;

[0241] Based on the preset business scale of the target system, determine the service encapsulation strategy corresponding to the preset business scale;

[0242] According to the service encapsulation strategy, the at least one service module is encapsulated in at least one service process.

[0243] This application also provides an electronic device, including: a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned adaptive service encapsulation method.

[0244] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive (SSD).

[0245] This application also provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the adaptive service encapsulation method in the above embodiments.

[0246] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0247] The aforementioned computer-readable storage medium may be included in an electronic device or may exist independently without being assembled into an electronic device.

[0248] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an electronic device, cause the electronic device to perform the following steps:

[0249] Based on the preset business requirements of the target system, at least one service type is determined, and the business logic corresponding to the at least one service type is encapsulated in at least one service module respectively;

[0250] Based on the preset business scale of the target system, determine the service encapsulation strategy corresponding to the preset business scale;

[0251] According to the service encapsulation strategy, the at least one service module is encapsulated in at least one service process.

[0252] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0253] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0254] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0255] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described adaptive service encapsulation method. This solves the technical problem that different service system architectures require independent design and development, resulting in poor versatility of service system architectures. Compared with related technologies, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the adaptive service encapsulation method provided in the above embodiments, and will not be elaborated upon here.

[0256] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the adaptive service encapsulation method described above.

[0257] The computer program product provided in this application can solve the technical problem that different service system architectures require independent design and development, resulting in poor versatility of service system architectures. Compared with related technologies, the beneficial effects of the computer program product provided in this application are the same as those of the adaptive service encapsulation method provided in the above embodiments, and will not be elaborated here.

[0258] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An adaptive service encapsulation method, characterized in that, The method includes: Based on the preset business requirements of the target system, at least one service type is determined, and the business logic corresponding to the at least one service type is encapsulated in at least one service module respectively; Based on the preset business scale of the target system, determine the service encapsulation strategy corresponding to the preset business scale; According to the service encapsulation strategy, the at least one service module is encapsulated in at least one service process.

2. The adaptive service encapsulation method according to claim 1, characterized in that, The preset business scale of the target system is represented by the number of nodes in the target system; determining the service encapsulation strategy corresponding to the preset business scale based on the preset business scale of the target system includes: If the number of points in the target system is determined to be less than the first value, the service encapsulation strategy is determined to be a single-machine deployment strategy. If the number of points in the target system is determined to be greater than or equal to the first value and less than the second value, the service encapsulation strategy is determined to be a distributed deployment strategy. If the number of points in the target system is determined to be greater than or equal to the second value, the service encapsulation strategy is determined to be a distributed cluster deployment strategy. Wherein, the first value is less than the second value.

3. The adaptive service encapsulation method according to claim 2, characterized in that, The step of encapsulating the at least one service module in at least one service process according to the service encapsulation strategy includes: When the service encapsulation strategy is a single-machine deployment strategy, the at least one service module is encapsulated in a service process; When the service encapsulation strategy is a distributed deployment strategy, at least one service module of different service types is encapsulated in a different service process. When the service encapsulation strategy is a distributed cluster deployment strategy, at least one service module of different service types is encapsulated in at least two different service processes.

4. The adaptive service encapsulation method according to any one of claims 1 to 3, characterized in that, Each of the aforementioned service processes also encapsulates a service management module; The step of encapsulating the at least one service module in at least one service process includes: For each of the at least one service process, the service interface of at least one service module to be encapsulated is registered on the service management module within the service process, and the service management module performs standardized packaging on the registered service interface. The standardized service interface can be called by other service modules in the target system.

5. The adaptive service encapsulation method according to claim 4, characterized in that, The target system also includes service configuration files corresponding to each of the service processes, and the service configuration files include at least one of the service encapsulation strategy, service loading strategy and service configuration parameters. The service loading strategy is used to indicate at least one of the loading order of at least one service module to be loaded and at least two service modules to be loaded in the at least one service module to be encapsulated in the service process. The service configuration parameters include at least one of the initialization parameters and dynamic configuration parameters of the service module. The at least one loaded service module supports registration on the service management module.

6. The adaptive service encapsulation method according to claim 4, characterized in that, The method further includes: For each of the at least one service process, the following query and invocation steps are performed using the service management module within that service process: Receive an interface query request from the first service module within the service process; wherein the interface query request is used to query the call interface information of the second service module; Check if the second service module exists in the local service process; wherein, the local service process is the service process in which the service management module is located; If the second service module is found in the local service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the local wrapper interface in the call interface information of the second service module. If the second service module is not found in the local service process, the second service module is queried through the service management module in other service processes; wherein, the other service processes are service processes in the target system other than the local service process. If the second service module is found through the service management module in the other service process, the call interface information of the second service module is obtained and sent to the first service module so that the first service module can call the second service module through the remote procedure call (RPC) wrapper interface in the call interface information of the second service module. If the second service module cannot be found through the service management module within the other service process, a message indicating query failure is sent to the first service module.

7. The adaptive service encapsulation method according to claim 6, characterized in that, The service interfaces of the at least one service module include: a management interface and an access interface; The management interface is the interface used by each service module to interface with the service management module, and the access interface is the interface used by each service module to provide business access functions. The interface description rules of the access interface are fixed, and the access interface is different depending on the business logic encapsulated in the service module. The service management module obtains the interface description rules of the access interface through the management interface, parses and calls the business logic corresponding to the access interface through the interface description rules.

8. An adaptive service encapsulation device, characterized in that, include: The first encapsulation module is used to determine at least one service type according to the preset business requirements of the target system, and encapsulate the business logic corresponding to the at least one service type into at least one service module respectively; The determination module is used to determine a service encapsulation strategy corresponding to the preset business scale of the target system. The second encapsulation module is used to encapsulate the at least one service module in at least one service process according to the service encapsulation strategy.

9. An adaptive service encapsulation system, characterized in that, include: A processor, at least one service process, and at least one service module; The processor executes the adaptive service encapsulation method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the adaptive service encapsulation method as described in any one of claims 1 to 7.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed on a computer, cause the computer to perform the adaptive service encapsulation method as described in any one of claims 1 to 7.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the adaptive service encapsulation method as described in any one of claims 1 to 7.

Images