Service operation method, service equipment and storage medium

Abstract

The invention provides a service operation method, service equipment and a storage medium. The service operation method comprises the following steps: introducing an integration suite into a code package of a target service, wherein the integration suite is used for providing the integration capability of a plurality of middleware for the target service. And when the service equipment receives and responds to the starting instruction of the target service, determining configuration information of at least one middleware required to be used by the target service through the configuration file of the target service. And the service equipment initializes the client of the at least one middleware based on the integrated suite and the configuration file, and injects the client of the at least one middleware into the target service. In the operation process of the target service, the service device can interact with the target middleware through the client of the target middleware.

Description

Technical Field

[0001] This specification relates to the field of Internet technologies, and in particular, to a method for running a service, a service device, and a storage medium. Background Art

[0002] With the development of Internet technologies, the scale and complexity of applications have been continuously increasing. Therefore, more and more applications adopt a microservices architecture. The microservices architecture allows a complex monolithic application to be decomposed into multiple small and independent services, each of which can be independently deployed, scaled, and updated, thereby improving the maintainability and scalability of the system.

[0003] When a service is running, it usually needs to invoke the functions, resources, or capabilities of one or more middleware. Therefore, when building a service, it is necessary to configure each middleware involved in the service and integrate it into the service so that the built service can use the functions, resources, or capabilities of the middleware.

[0004] However, an application usually includes multiple services, and different services among the above-mentioned multiple services may integrate some identical middleware. In the current building solutions, each service needs to be separately configured, debugged, maintained, and integrated with middleware, which will result in a large amount of repetitive work during the service building process. In addition, the current building solutions have relatively high requirements for service builders, requiring them to have certain professional knowledge and fully understand the integration requirements of each middleware.

[0005] The content in the background art section is only the information known to the inventor personally, and does not mean that the above information has entered the public domain before the filing date of this disclosure, nor does it mean that it can become the prior art of this disclosure. Summary of the Invention

[0006] This specification provides a method for running a service, a service device, and a storage medium. The service device can automatically integrate at least one required middleware based on an integration suite and a configuration file of a target service when starting the target service. Thus, a large amount of repetitive work is not required during the building process of the target service, and relatively high requirements are not imposed on service builders.

[0007] To achieve the above objective, the embodiments of this specification adopt the following technical solutions:

[0008] In a first aspect, this specification provides a method for running a service, including: receiving a startup instruction for a target service, where an integration suite is introduced in the code package of the target service, and the integration suite is used to provide the integration ability of multiple middleware to the target service; in response to the startup instruction, execute the startup process of the target service, and the startup process at least includes: obtaining a configuration file of the target service, where the configuration file includes configuration information of at least one middleware that the target service needs to use; initializing clients of the at least one middleware based on the integration suite and the configuration file, and injecting the clients of the at least one middleware into the target service; and during the running process of the target service, interact with the target middleware through the client of the target middleware, where the target middleware is any one of the at least one middleware.

[0009] In some embodiments, the integration suite includes: configuration classes corresponding to the multiple middleware respectively, and a service class corresponding to the target service. Initializing the clients of the at least one middleware based on the integration suite and the configuration file, and injecting the clients of the at least one middleware into the target service includes: initializing the clients of the at least one middleware based on the configuration file and the configuration classes corresponding to the multiple middleware respectively; and initializing the target service based on the service class corresponding to the target service, and injecting the clients of the at least one middleware into the target service during the initialization process of the target service.

[0010] In some embodiments, initializing the clients of the at least one middleware based on the configuration file and the configuration classes corresponding to the multiple middleware respectively includes: traversing the multiple middleware, and for each current middleware during the traversal: determining whether the current middleware is a middleware that the target service needs to use based on the configuration file, and if so, initializing the client of the current middleware based on the configuration class corresponding to the current middleware.

[0011] In some embodiments, the configuration class corresponding to the current middleware includes initialization conditions; determining whether the current middleware is a middleware that the target service needs to use based on the configuration file includes: determining that the current middleware is a middleware that the target service needs to use when there is configuration information corresponding to the current middleware in the configuration file and the configuration information meets the initialization conditions; or determining that the current middleware is not a middleware that the target service needs to use when there is no configuration information corresponding to the current middleware in the configuration file, or there is configuration information corresponding to the current middleware but the configuration information does not meet the initialization conditions.

[0012] In some embodiments, the integration kit further includes: initialization verification interfaces corresponding to the multiple middleware respectively, which are used to verify whether the clients of the middleware are successfully initialized; after injecting the clients of at least one middleware into the target service, it further includes: based on the initialization verification interface corresponding to the current middleware, verifying whether the client of the current middleware is successfully initialized.

[0013] In some embodiments, the integration kit further includes: call interfaces corresponding to the multiple middleware respectively, and the call interfaces are obtained by encapsulating the original interfaces provided by the middleware; interacting with the target middleware through the client of the target middleware includes: realizing the interaction between the client of the target middleware and the target middleware by calling the call interface corresponding to the target middleware; when the integration kit is introduced by the code packages of multiple services, all the multiple services realize the interaction between the client of the target middleware and the target middleware by calling the call interface corresponding to the target middleware.

[0014] In some embodiments, obtaining the configuration file corresponding to the target service includes: obtaining the configuration file uploaded by the operator from the interaction page, or obtaining the configuration file from a preset storage path.

[0015] In some embodiments, the target service is a service in a service system adopting a microservice architecture, and a configuration center is included in the service system, and the configuration center stores the configuration information of the multiple middleware; obtaining the configuration file corresponding to the target service includes: based on a start instruction, determining at least one middleware required by the target service, obtaining the configuration information of the at least one middleware from the configuration center, and generating the configuration file based on the configuration information of the at least one middleware.

[0016] In some embodiments, after the target service is successfully started, the method further includes: in response to receiving an update instruction corresponding to the target middleware, executing an update process of the target middleware, and the update process at least includes: destroying the client of the target middleware based on the integration kit; obtaining the current configuration information of the target middleware from the configuration file, and executing an initialization process of the target middleware based on the integration kit and the current configuration information to obtain an updated client of the target middleware; and injecting the updated client into the target service.

[0017] In some embodiments, the startup process further includes: generating a monitoring instance based on the integration suite; the method further includes: during the operation of the target service, collecting the operation parameters of the at least one middleware based on the monitoring instance, and generating an operation log of the target service based on the operation parameters.

[0018] In a second aspect, this specification also provides a service device, including: at least one storage medium storing at least one instruction set for running a service; and at least one processor communicatively connected to the at least one storage medium, wherein when the service device runs, the at least one processor reads the at least one instruction set and, according to the instructions of the at least one instruction set, implements the method described in any one of the first aspects.

[0019] In a third aspect, this specification also provides a computer-readable non-volatile storage medium, wherein at least one instruction set is stored in the computer-readable non-volatile storage medium, and when the at least one instruction set is executed by at least one processor, the method described in any one of the first aspects is implemented.

[0020] Other functions of the service running method, service device, and storage medium provided in this specification will be partially listed in the following description. The creative aspects of the service running method, service device, and storage medium provided in this specification can be fully explained through practice or use of the methods, devices, and combinations described in the following detailed examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] To more clearly illustrate the technical solutions in the embodiments of this specification, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1 Shows a schematic diagram of a service system adopting a microservices architecture provided according to an embodiment of this specification;

[0023] Figure 2 Shows a hardware structure diagram of a computing device provided according to an embodiment of this specification;

[0024] Figure 3 Shows a flowchart of a service running method provided according to an embodiment of this specification;

[0025] Figure 4 Shows a schematic diagram of deploying a service in a service device based on an integration suite provided according to an embodiment of this specification; and

[0026] Figure 5 The figure shows a schematic diagram of a startup process of a target service provided according to an embodiment of this specification. Detailed implementation manners

[0027] The following description provides specific application scenarios and requirements of this specification, aiming to enable those skilled in the art to manufacture and use the content in this specification. For those skilled in the art, various partial modifications to the disclosed embodiments are obvious, and without departing from the spirit and scope of this specification, the general principles defined here can be applied to other embodiments and applications. Therefore, this specification is not limited to the shown embodiments, but has the broadest scope consistent with the claims.

[0028] The terms used here are only for the purpose of describing specific example embodiments and are not restrictive. For example, unless the context clearly indicates otherwise, the singular forms "a", "an" and "the" used here may also include the plural forms. When used in this specification, the terms "include", "comprise" and / or "contain" mean that the associated integers, steps, operations, elements and / or components exist, but do not exclude the existence of one or more other features, integers, steps, operations, elements, components and / or groups, or the addition of other features, integers, steps, operations, elements, components and / or groups in the system / method.

[0029] Considering the following description, these features of this specification and other features, as well as the operations and functions of the related elements of the structure, and the economy of the combination and manufacture of the components can be significantly improved. Referring to the accompanying drawings, all of these form a part of this specification. However, it should be clearly understood that the drawings are only for the purpose of illustration and description and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.

[0030] The flowcharts used in this specification illustrate the operations implemented by the system according to some embodiments in this specification. It should be clearly understood that the operations in the flowchart may not be implemented in sequence. On the contrary, the operations may be implemented in reverse order or simultaneously. In addition, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.

[0031] For the convenience of description, the terms that will appear in the following text of this specification are first explained.

[0032] Term 1: Middleware. In this specification, middleware refers to the specific implementation or deployment unit of the actually running middleware service or software. It is usually an independent service or process that provides specific functions, such as message queues, database management, caching, etc.

[0033] Term 2: Client of middleware. In this specification, the client of middleware refers to an instance used to interact with middleware.

[0034] Term 3: Bean. In this specification, a Bean refers to an initialized client of middleware. A Bean can be created through a configuration class and is managed by the Spring container. The life cycle of a Bean can include initialization, dependency injection, usage, and destruction.

[0035] Term 4: Dependency injection. Dependency injection creates and manages instances (i.e., Beans) through an external container (such as the Spring container) and manages the dependencies required by the instances through the external container. During the startup process of the target service, the Spring container can inject these instances into the target service that needs them according to the dependency relationships of these instances.

[0036] Term 5: Spring container. The Spring container is responsible for creating, configuring, and managing the life cycle of Beans and maintaining the dependency relationships between these Beans.

[0037] The application scenario of this specification is introduced below.

[0038] The technical solution provided in this specification is applicable to the scenario of starting the target service of integrated middleware. For example, the running method of the service can be applied to the project construction process of the microservice architecture. In this scenario, each function required to be implemented in the project can be implemented through a service respectively. After each service starts, it can call the required middleware to implement the corresponding function. Therefore, before each service starts, it is necessary to configure and integrate the middleware involved in the target service into the target service.

[0039] Currently, before the target service is started for the first time, operators configure, debug, and integrate each middleware involved in the target service separately. There may be middleware that is the same as that of other services among the middleware involved in the target service. Separately configuring, debugging, maintaining, and integrating the middleware for different services will result in a large amount of repetitive work, reducing the project development efficiency and delaying the project development progress.

[0040] This specification provides a method for running a service, which can be executed by a service device. First, an integration suite is introduced into the code package of the target service. The integration suite is used to provide the integration ability of multiple middleware to the target service. The service device receives and responds to the start instruction of the target service, and determines the configuration information of at least one middleware required by the target service through the configuration file of the target service. The service device initializes the clients of at least one middleware based on the integration suite and the configuration file, and injects the clients of at least one middleware into the target service. During the running process of the target service, the service device can interact with the target middleware through the client of the target middleware.

[0041] In the solution provided in this specification, during the startup process of the target service, the clients of at least one middleware can be initialized based on the integration suite and the configuration file, and the clients of at least one middleware are injected into the target service. Since the integration suite provides the integration ability of multiple middleware, only the configuration data of the middleware needs to be provided, and the middleware client can be injected into the target service through the integration suite. Users do not need to configure, debug, and integrate each middleware separately, reducing repetitive work and improving the development efficiency of the project.

[0042] Figure 1 The schematic diagram of a service system adopting a microservice architecture provided according to an embodiment of this specification is shown. As Figure 1 shown, the service system 100 may include multiple service devices 11, and one or more services may be deployed in each service device 11. For example, Figure 1 shows the case where 3 service devices 11 are deployed with Service A, Service B, and Service C respectively.

[0043] Continue to refer to Figure 1 , the service system 100 may also include multiple middleware (which may also be referred to as instances of middleware or the service side of middleware). During the startup process of each service, the service device 11 initializes the clients of the middleware required by the service, and injects the clients of the middleware into the service. In this way, during the running process of the service, when it is necessary to interact with the middleware, it can interact with the corresponding middleware through the client of the middleware.

[0044] Continue to refer to Figure 1 , in some embodiments, the service system 100 may also include a configuration center 12. The configuration center 12 can manage the configuration information corresponding to multiple middleware, and provide the configuration information of the middleware involved in the request to the service device based on the request of the service device.

[0045] The method provided in this specification can be performed by Figure 1Each service device 11 in it executes. Specifically, a code package corresponding to the service is stored in the service device 11, and an integration suite is introduced in the code package. When the service device 11 receives a start instruction for the target service, it can execute the start process of the target service. During the execution of the start process, the service device 11 can initialize the client of at least one middleware according to the code package of the target service, the integration suite in the code package, and the configuration file of the target service, and inject it into the target service. After the target service is started, during the running process of the target service, the service device can interact with the middleware through the client of the middleware.

[0046] In some embodiments, the service system 100 may be a device or a cluster of devices that provides various services. For example, the service system 100 may be a server, a server cluster, a cloud server, etc. In some embodiments, the service device 11 in the service system device 100 can start and run the target service. These target services may be applications, microservices, or any other type of service developed based on the Spring framework.

[0047] For example, when the target service is a service unit in a microservice, the service system 100 may be a server cluster. The service system 100 may include multiple physical or virtual servers, which are interconnected through a network and configured in a distributed environment. The service device 11 may be a physical or virtual server, or a virtual machine running in the service system 100. The target service may be deployed on one server or distributedly deployed on multiple servers. When the target service is deployed on one server, that server is the service device 11. When the target service is distributedly deployed on multiple servers, multiple servers can cooperate to run a virtual machine, and the target service can be deployed in the virtual machine, and the virtual machine is the service device 11.

[0048] In some embodiments, the method for running the service provided in this specification can be executed on the service device 11. At this time, the service device 11 may store data or instructions for executing the method for running the service described in this specification, and may execute or be used to execute the data or instructions. In some embodiments, the service device 11 may include a hardware device with data information processing functions and necessary programs for driving the hardware device to work.

[0049] It should be understood that Figure 1 the number of service devices 11 in it is only illustrative. According to the implementation needs, there can be any number of service devices 11.

[0050] Figure 2 shows a hardware structure diagram of a computing device provided according to an embodiment of this specification. The computing device 200 can be used as Figure 1The service device 11 therein executes the operation method of the service described in this specification.

[0051] As Figure 2 shown, the computing device 200 may include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 200 may further include a communication port 250 and an internal communication bus 210. The computing device 200 may also include I / O components 260.

[0052] The internal communication bus 210 can connect different system components. For example, the internal communication bus 210 can connect the storage medium 230, the processor 220, the communication port 250, and the I / O components 260, etc.

[0053] The I / O components 260 support input / output between the computing device 200 and other components.

[0054] The communication port 250 is used for data communication between the computing device 200 and the outside world. For example, the communication port 250 can be used for data communication between the computing device 200 and the network 140. The communication port 250 can be a wired communication port or a wireless communication port.

[0055] The storage medium 230 may include a data storage device. The data storage device may be a non-transitory storage medium or a transitory storage medium. For example, the data storage device may include one or more of a magnetic disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 235. The storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, and the computer program code may include programs, routines, objects, components, data structures, processes, modules, and so on.

[0056] At least one processor 220 may be communicatively connected to at least one storage medium 230. When the computing device 200 is running, the at least one processor 220 reads the at least one instruction set and, according to the instructions of the at least one instruction set, executes the operation method of the service provided in this specification. The processor 220 may execute the steps included in the operation method of the service. The processor 220 may be in the form of one or more processors. In some embodiments, the processor 220 may include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application specific integrated circuit (ASIC), an application specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physics processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of executing one or more functions, etc., or any combination thereof.

[0057] For illustrative purposes only, only one processor 220 is shown in the computing device 200 in the drawings. However, it should be noted that the computing device 200 in this specification may also include multiple processors. Therefore, the operations and / or method steps disclosed in this specification may be executed by one processor or jointly executed by multiple processors. For example, if it is described in this specification that the processor 220 of the computing device 200 executes step A and step B, it should be understood that step A and step B may also be jointly or separately executed by two different processors 220 (for example, the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0058] Figure 3 A flowchart showing an operation method of a service provided according to an embodiment of this specification is shown. As before, the service device 11 executes the operation method of the service provided in this specification.

[0059] In this specification, taking the target service supported by the service device 11 and developed based on the Spring framework as an example for illustration, those skilled in the art should understand that the operation method of the service provided in this specification can also be applied to target services developed using other similar frameworks.

[0060] As Figure 3 shown, the operation method of the service may include:

[0061] S310: Receive a start instruction for the target service. An integration suite is introduced in the code package of the target service, and the integration suite is used to provide the integration ability of multiple middleware to the target service.

[0062] In some embodiments, the start instruction for the target service may come from an interactive page provided by the service system for setting up the target service in the service device. For example, when the service device receives an instruction issued by the operator's operation on the start button in the interactive page, it can determine that it has received the start instruction for the target service, and send the start instruction for the target service to the service device, instructing the service device to start the target service according to the start instruction for the target service. The service device may obtain the code package of the target service based on the start instruction for the target service. For example, the start instruction for the target service may include the code package of the target service, or the download address of the code package of the target service. Alternatively, the code package of the target service may also be pre-stored in the service device.

[0063] In some embodiments, the integration kit may integrate the configuration classes corresponding to multiple middleware and the service class corresponding to the target service.

[0064] Figure 4 The figure shows a schematic diagram of deploying a service in a service device based on an integration kit according to an embodiment of the present specification.

[0065] In some embodiments, different service devices can all deploy services in the service device by introducing an integration kit into the code package of the service and relying on the ability of the integration kit to integrate middleware into the service. Refer to Figure 4 , different service devices can each rely on the capabilities provided by the integration kit and deploy Service A, Service B, and Service C in the service device respectively based on the configuration file of Service A, the configuration file of Service B, and the configuration file of Service C. Among them, the configuration file of Service A can be obtained and generated by the service device from the configuration center, and the configuration files of Service B and Service C can be pre-stored or uploaded by the operator.

[0066] In this embodiment, the service devices in the service system can use the same integration kit to integrate middleware into the services they deploy respectively, can select the same technology stack for the deployed services, ensuring the consistency of the technology stack and reducing the maintenance cost during subsequent operation. Moreover, the operator can focus on the implementation logic of the service without paying attention to the integration details of the middleware, thereby improving the development efficiency of the target service and reducing the development duration of the target service.

[0067] In some embodiments, refer to Figure 4 , the integration kit may include a starter component and a common component. The integration kit can integrate the configuration classes corresponding to multiple middleware and the service class corresponding to the target service through the starter component.

[0068] In some embodiments, the launcher component can be implemented in the form of a Software Development Kit (SDK) and usage documentation. The usage documentation of the launcher component records the configuration methods of the configuration classes corresponding to each middleware in the SDK corresponding to the launcher component or the service classes corresponding to the target services.

[0069] In some embodiments, when the service device executes the configuration class corresponding to the middleware, it can create an instance of the middleware client corresponding to the middleware.

[0070] As an example, when the middleware is a Redis cluster, the configuration class corresponding to the middleware can be implemented by the following code:

[0071] @Configuration

[0072] public class RedisAutoConfiguration{

[0073] @Bean

[0074] @Primary

[0075] @Conditional(RedisCondition.class)

[0076] public RedisClusterTemplate

[0077] redisClusterTemplate(){

[0078] }

[0079] }

[0080] In the code of the configuration class provided in the example, @Configuration is used to indicate that the subsequent code is a configuration class. Among them, public class RedisAutoConfiguration indicates that this configuration class is used to automatically configure a client for a public type of Redis cluster middleware. When the service device detects the @Bean annotation, it will call the corresponding initialization conditions of the middleware according to the @Conditional annotation and verify. When the service device meets the initialization conditions, it can create an instance "RedisClusterTemplate" of a client for a public type of middleware (i.e., initialize the client of the middleware) based on the declared "redisClusterTemplate" method. This instance of the client of the middleware can be managed as a Bean through the Spring container. Among them, multiple Beans of clients of the middleware can be managed in the Spring container. When each client of the middleware corresponds to only one instance, the Spring container can be regarded as a singleton pool.

[0081] In some embodiments, when the service device executes the service class corresponding to the target service, it can inject the dependencies of the clients of the middleware involved in the service class into the target service.

[0082] As an example, when the client of the middleware is a client of the Redis cluster (RedisClusterTemplate), the service class corresponding to the target service can be implemented through the following code:

[0083] @Service

[0084] public class MyService{

[0085] @Autowired

[0086] private RedisClusterTemplate redisClusterTemplate;

[0087] }

[0088] In the code of the service class provided in the example, @Service is used to indicate that the subsequent code is a service class. Among them, public class MyService indicates that this configuration class is used to configure a public type of target service (MyService). @Autowired is the annotation corresponding to dependency injection. When the service device detects the @Autowired annotation, it determines that it needs to automatically inject the dependencies declared in the subsequent fields into the target service.

[0089] "private RedisClusterTemplate redisClusterTemplate" is a field declaration that defines a private variable of the target service. The object of the corresponding type of this private variable is the dependency to be injected into the target service. In this example, the name of the private variable is "redisClusterTemplate", and its corresponding type is "RedisClusterTemplate".

[0090] When the service device executes the service class in this example, after detecting the @Autowired annotation, it can inject an instance of the type "RedisClusterTemplate" (i.e., the instance of the Redis cluster middleware client in the above example) from the Spring container into the field of the private variable "redisClusterTemplate" of the target service according to the type "RedisClusterTemplate" corresponding to the private variable "redisClusterTemplate".

[0091] In some embodiments, the general component may include call interfaces corresponding to multiple middleware and initialization verification interfaces corresponding to multiple middleware. The general component can provide call interfaces corresponding to multiple middleware and initialization verification interfaces through the SDK.

[0092] In some embodiments, the call interface corresponding to the middleware may be an application programming interface (API) for calling the client of the middleware. Among them, the call interface of the middleware is obtained by encapsulating the original interface provided by the middleware.

[0093] In some embodiments, the initialization verification interface can be used to verify whether the client of the middleware is initialized successfully. The initialization verification interface can be an API for obtaining the running parameters of the client of the middleware. When the service device can obtain the corresponding client running parameters through the initialization verification interface and the client running parameters meet the conditions, it can be determined that the client of the middleware is initialized successfully. As an example, the client running parameters of the middleware may include the connection status between the client of the middleware and the server of the middleware, the response duration, etc.

[0094] In this embodiment, the integration kit modularly encapsulates the middleware, integrates and uniformly manages the common middleware. The operator can integrate the middleware into the target service or replace the middleware in the target service based on the SDK and usage documentation corresponding to the integration kit. When deploying the target service, the service device only needs to introduce dependencies and perform basic configuration on the middleware, and then the middleware can be integrated into the target service. This integration method of middleware has a low learning cost, greatly simplifies the integration process of middleware, can effectively reduce repetitive work, and thus improve the development efficiency of the project. At the same time, this integration method of middleware also endows the middleware with the pluggable feature, that is, the service device can integrate the middleware into the target service or replace the middleware in the target service at any time, enabling the target service to adjust the corresponding middleware in a timely manner according to the changes in service requirements, and enhancing the scalability and maintainability of the target service.

[0095] S320: In response to the start instruction, execute the start process of the target service. The start process at least includes: obtaining the configuration file of the target service, where the configuration file includes the configuration information of at least one middleware required by the target service; initializing the clients of at least one middleware based on the integration kit and the configuration file, and injecting the clients of at least one middleware into the target service.

[0096] In some embodiments, the configuration file corresponding to the target service may include a configuration file uploaded by the operator obtained from the interaction page, or a pre-stored configuration file obtained from a preset storage path.

[0097] In some embodiments, the target service is one of the services in a service system adopting a microservice architecture. The service system includes a configuration center, and the configuration center stores the configuration information of the multiple middleware. In this case, the service device can, based on the start instruction, determine at least one middleware required by the target service, obtain the configuration information of at least one middleware from the configuration center, and generate a configuration file based on the configuration information of at least one middleware.

[0098] In this embodiment, the configuration information of the middleware stored in the configuration center is pre-uploaded by developers with certain professional knowledge and a full understanding of the integration requirements of each middleware. The operator only needs to simply modify the basic parameters therein, and then can integrate the middleware into the target service based on the configuration information of the middleware and the integration kit. In this way, the risk of service system failure caused by insufficient professional knowledge of the operator and providing incorrect configuration information can be effectively reduced. At the same time, the service device can uniformly manage and dynamically update the configuration information of the middleware through the configuration center, making the configuration method of the target service more flexible and easier to maintain.

[0099] Figure 5The figure shows a schematic diagram of a startup process of a target service provided according to an embodiment of this specification. Among them, Figure 5 The startup process shown in the figure is demonstrated by taking a service in a service system adopting a microservice architecture as the target service as an example. In some embodiments, refer to Figure 5 , the service device can obtain the identifier or version of the middleware required by the target service by parsing the code package of the target service. Then, the service device can obtain the configuration information of the corresponding middleware from the configuration center based on the identifier or version of the middleware. Finally, the service device can generate a configuration file for the target service based on the obtained configuration information of the middleware.

[0100] In some embodiments, the code package of the target service may include configuration codes in multiple dimensions regarding the target service. For example, it may include configuration codes for defining and registering the target service, configuration codes for the applications required by the target service, codes for encapsulating interfaces for functions in the target service, configuration codes for monitoring components, etc. As an example, the service device can obtain the applications required by the target service according to the configuration codes for the applications required by the target service. Among them, the capabilities of some applications are implemented through middleware, and these middleware are the middleware required by the target service. For example, the middleware required by the target service can be "Middleware 1", "Middleware 2", and "Middleware 3". The service device can obtain the respective configuration information of "Middleware 1", "Middleware 2", and "Middleware 3" from the configuration center and generate a configuration file for the target service. For example, refer to Figure 5 , the configuration file of the target service may include "Configuration information of Middleware 1", "Configuration information of Middleware 2", and "Configuration information of Middleware 3".

[0101] In some embodiments, the configuration information of the middleware can be recorded through a properties file or a yml file. Among them, in the properties file, the value (value) corresponding to each key (key) that needs to be configured for the middleware can be recorded through key-value pairs. The yml file can record the parameters that need to be configured for the middleware in various forms such as key-value pairs, dictionaries (i.e., sets of key-value pairs), lists, and strings. As an example, the configuration information of the Redis cluster may include: the login password of redis, the environment type of the redis instance (development environment, test environment, or production environment), and the connection configuration parameters of redis (such as Redis cluster node information, maximum number of connections in the connection pool, maximum blocking waiting time in the connection pool, maximum number of idle connections in the connection pool, minimum number of idle connections in the connection pool, and connection timeout).

[0102] In some embodiments, the service device may initialize the client of at least one middleware based on a configuration file and the respective configuration classes corresponding to multiple middleware.

[0103] In some embodiments, when initializing the client of the middleware, the service device may first traverse multiple middleware, and for each current middleware during the traversal: determine whether the current middleware is the middleware required by the target service based on the configuration file. If so, the service device initializes the client of the current middleware based on the configuration class corresponding to the current middleware.

[0104] In some embodiments, the service device may create and manage the client (Bean) of the initialized middleware based on the Spring container. As an example, the service device may start the Spring container, traverse multiple middleware, and initialize the clients of the middleware required by the target service.

[0105] In some embodiments, the startup process of the Spring container includes:

[0106] The service device first traverses the configuration classes of the middleware and the service classes of the target service through the Spring container, scans whether there are Beans to be initialized (i.e., the clients of the middleware required by the target service) therein, and resolves the dependency relationships between each Bean to be initialized. Then, the service device initializes the Beans in the Spring container in order of priority from high to low according to the priorities in the dependency relationships. For example, the Bean in the @Service class may depend on the Bean in the @Configuration class. Therefore, according to the dependency relationship, the priority of the Bean in the @Configuration class is higher than that of the Bean in the @Service class. When the service device initializes the Bean in the Spring container, the Bean in the @Configuration class will be initialized prior to the Bean in the @Service class.

[0107] In some embodiments, the configuration class corresponding to the middleware includes the initialization conditions corresponding to the middleware. When there is configuration information corresponding to the current middleware in the configuration file and the configuration information meets the initialization conditions, the service device may determine that the current middleware is the middleware required by the target service.

[0108] Alternatively, when there is no configuration information corresponding to the current middleware in the configuration file, or there is configuration information corresponding to the current middleware but the configuration information does not meet the initialization conditions, the service device may determine that the current middleware is not the middleware required by the target service.

[0109] For example, referring to the example of the configuration class corresponding to the Redis cluster in S310, it can be verified that the initialization conditions corresponding to the Redis cluster can be implemented through the @Conditional annotation.

[0110] As an example, the initialization conditions for the Redis cluster can be: the configuration information of the Redis cluster exists, and the login password of Redis and the Redis cluster node information are configured (that is, the value of the key corresponding to the login password of Redis is not empty, and the value of the key corresponding to the Redis cluster node information is not empty). The verification process for this initialization condition can be implemented through the following code:

[0111] public class RedisCondition implements Condition{

[0112] @Override

[0113] public boolean matches(ConditionContext context,AnnotatedTypeMetadatametadata){

[0114] Environment env=context.getEnvironment();

[0115] return!StringUtils.isEmpty(env.getProperty("spring.redis.cluster.nodes"))&&!StringUtils.isEmpty(env.getProperty("spring.redis.password"));

[0116] }

[0117] }

[0118] In the code provided in the example, "public class RedisCondition implements Condition" declares a public class: "RedisCondition". "RedisCondition" implements the "Condition" interface, that is, "RedisCondition" needs to define a matching (matches) method. Only when the result returned by the matching method is true, the Bean corresponding to the @Conditional annotation will be created. That is to say, the matching method defined by "RedisCondition" is the initialization condition corresponding to the Redis cluster.

[0119] Among them, the @Override annotation is used to indicate that the subsequent code is rewritten to implement the matching method in the "Condition" interface. "public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata)" is used to represent the matching method in the interface. That is, the matching method is determined based on the given condition context (ConditionContext) and annotation type metadata (AnnotatedTypeMetadata). Among them, the annotation type metadata (AnnotatedTypeMetadata) can be used to check whether there is an annotation of the target type in the class or method associated with "RedisCondition", and determine whether the result returned by the matching method is true according to the attributes corresponding to the annotation.

[0120] In this code example, although the annotation type metadata is defined, it is not used, but the result of whether the matching method returns true is determined only based on the given condition context.

[0121] Among them, "Environment env = context.getEnvironment()" is used to represent obtaining the environment variable object (Environment) from the context. The environment variable object can include all data in the configuration information of the Redis cluster middleware. When the service device can obtain the environment variable object, it can be determined that there is configuration information corresponding to the Redis cluster. If the service device cannot obtain the environment variable object, it means that there is no configuration information corresponding to the Redis cluster, and the result returned by the matching method is "false".

[0122] The service device returns the result of checking whether the configuration items "spring.redis.cluster.nodes" and "spring.redis.password" in the environment variable object are null or empty strings through the "return" request using the "StringUtils.isEmpty()" instruction. "&&" represents logical AND, that is, the result returned by the matching method is "true" only when the check results of both configuration items are non-empty.

[0123] When the service device detects that the result returned by the matching method is "true", it can be determined that the configuration information corresponding to the Redis cluster exists in the configuration file and the configuration information meets the initialization conditions. In this case, the service device can start initializing the client of the Redis cluster (i.e., creating the Bean of the Redis cluster in the Spring container). For example, refer to Figure 5 , the configuration file of the target service includes "configuration information of middleware 1", "configuration information of middleware 2", and "configuration information of middleware 3". If these configuration information all meet the corresponding initialization conditions, the service device can initialize respectively based on the "configuration information of middleware 1", "configuration information of middleware 2", and "configuration information of middleware 3" through the Spring container, and create the "client of middleware 1", "client of middleware 1", and "client of middleware 3" in the Spring container.

[0124] When the service device detects that the result returned by the matching method is "false", it can be determined that the configuration information corresponding to the Redis cluster middleware does not exist in the configuration file, or although the configuration information corresponding to the Redis cluster middleware exists in the configuration file, the configuration information does not meet the initialization conditions. In this case, the service device will not initialize the client of the Redis cluster middleware.

[0125] In some embodiments, when the integration suite is introduced by the code packages of multiple services, the startup processes of each service initialize the clients of the middleware they need to use respectively.

[0126] In this embodiment, by introducing the initialization conditions into the configuration information of the middleware, the service device can determine whether the current middleware is the middleware that the target service needs to use, realize loading only the middleware required by the target service, avoid initializing unnecessary middleware, save the resources of the service system, optimize the startup process of the target service, and improve the development efficiency of the project.

[0127] In some embodiments, the service device can initialize the target service based on the service class corresponding to the target service in the configuration file, and inject the clients of at least one middleware into the target service during the initialization process of the target service.

[0128] As an example, the service device can create the target service (MyService) based on the service class code shown in S310, and inject the clients of at least one middleware in the Spring container into the target service through the @Autowired annotation. For example, refer to Figure 5, when the service device creates a target service, the dependencies declared subsequently with the @Autowired annotation can include "Middleware 1", "Middleware 2", and "Middleware 3". Then the service device can determine that it is necessary to inject the "clients of Middleware 1", "clients of Middleware 2", and "clients of Middleware 3" in the Spring container into the target service.

[0129] In some embodiments, the service device can inject the client of the middleware into the target service immediately after the client of the middleware is created in Spring. Alternatively, the service device can also inject the client of the middleware into the target service when the target service first invokes the client of the middleware or when the client of the middleware is first used as a dependency declared subsequently with the @Autowired annotation.

[0130] In some embodiments, referring to the example in S310, the integration suite also includes initialization verification interfaces corresponding to each middleware. After injecting the clients of at least one middleware into the target service, the service device can verify whether the client of the current middleware is initialized successfully based on the initialization verification interface corresponding to the current middleware.

[0131] As an example, when the current middleware is a Redis cluster, the following code can be used to verify whether the client of the current middleware is initialized successfully:

[0132] @PostConstruct

[0133] public void init(){

[0134] RedisConnectionFactory factory = redisTemplate.getConnectionFactory();

[0135] RedisConnection conn = RedisConnectionUtils.getConnection(factory);

[0136] LoggerUtil.info(log, "RedisCluster information: {}",

[0137] Objects.requireNonNull(conn.info()).toString());

[0138] }

[0139] In the code provided in the example, the declaration "public void init()" defines an init method of public type with no return value. The @PostConstruct annotation is applied to the init method, indicating that the init method will be called by the service device after the current Bean (Redis cluster client) is initialized in the Spring container and dependency-injected into the target service.

[0140] Among them, "RedisConnectionFactory factory = redisTemplate.getConnectionFactory()" means that the service device can first obtain the "RedisConnectionFactory" object from "redisTemplate" (i.e., the name corresponding to the Bean of the Redis cluster client) through the init method. Here, the "getConnectionFactory" method returns a connection factory (Factory) used to create a Redis connection (RedisConnection). Next, the service device can call the method "RedisConnectionUtils.getConnection(factory)" to obtain a Redis connection from the specified connection factory. A Redis connection represents an active connection between the Redis cluster client and the Redis database, and the service device can instruct the Redis database to execute Redis commands through the Redis connection. Then, the service device can obtain the specified information of the Redis server through the "conn.info()" method. The "conn.info()" method returns a Properties file that contains the status information of the Redis server (recorded in the form of key-value pairs).

[0141] The "Objects.requireNonNull" method is used to ensure that the information returned by the "conn.info()" method is not null. If the information returned by the "conn.info()" method is null, the "Objects.requireNonNull" method will throw an exception warning "NullPointerException".

[0142] Finally, the service device can record the status information of the Redis server in the Properties file into the log through the "conn.info" method. In the code provided in the example, "{}" in "RedisCluster information: {}" represents a placeholder, which will be replaced by the return value of the "conn.info().toString()" method. This method converts the key-value pairs representing the status information of the Redis server in the Properties file into a string form. The service device can determine whether the client of the Redis cluster is successfully initialized based on the obtained status information of the Redis server. For example, when the status information of the Redis server obtained by the service device indicates that the client of the Redis cluster is successfully connected to the Redis server and the connection latency meets the expectations, it can be determined that the client of the Redis cluster is successfully initialized. When the status information of the Redis server obtained by the service device indicates that the client of the Redis cluster cannot be connected to the Redis server, it can be determined that the client of the Redis cluster fails to complete the initialization.

[0143] In this embodiment, the service device verifies whether the client of the middleware is successfully initialized through the initialization verification interface, which can timely maintain the clients of the middleware that cannot normally provide service capabilities, ensure that the target service to be started can normally provide service capabilities, and thus ensure the normal operation of the service system.

[0144] In some embodiments, the startup process of the target service further includes: the service device generates a monitoring instance based on the integration suite. During the operation of the target service, the service device collects the operation parameters of at least one middleware based on the monitoring instance and generates the operation log of the target service based on the operation parameters. As an example, if the service device is a system based on the Spring framework, the monitoring instance can be a monitoring instance generated by a monitoring component integrated based on the Spring framework (such as Spring Boot Actuator, Micrometer, Prometheus, etc.). The monitoring instance can set at least one operation parameter collection plugin in the client of the middleware, obtain the operation parameters of the middleware through the data port provided by the operation parameter collection plugin, and generate the operation log of the target service based on the operation parameters. By collecting the operation parameters of the middleware and generating the operation log of the target service, the service device can monitor the operation status of the target service in real time, provide reference information when risks or failures occur in the target service, assist the operator in quickly locating problems, and ensure the stable operation of the target service and the service system.

[0145] S330: During the operation of the target service, interact with the target middleware through the client of the target middleware, where the target middleware is any one of the at least one middleware.

[0146] In some embodiments, during the operation of the target service, an interaction request may be received, which is used to indicate that the service device needs to interact with the target middleware based on the client of the target middleware. Among them, the target middleware may be the server of the target middleware. For example, referring to Figure 5 ,"the client of middleware 1" can interact with "the server of middleware 1", "the client of middleware 2" can interact with "the server of middleware 2", and "the client of middleware 3" can interact with "the server of middleware 3".

[0147] In some embodiments, the service device can implement the interaction between the client of the target middleware and the target middleware by calling the corresponding call interface of the target middleware. As an example, the corresponding call interface of the target middleware can be obtained by encapsulating the original interface provided by the middleware based on a preset standard.

[0148] In some embodiments, the interaction between the client of the target middleware and the target middleware may include: the service device configures the target middleware through the client of the target middleware. Or, the service device obtains the running parameters of the target middleware through the client of the target middleware.

[0149] As an example, when the target middleware is a Redis cluster, the service device configuring the Redis cluster through the client of the Redis cluster may include: setting the cache expiration time of the Redis cluster. The service device can implement the configuration process of the cache expiration time through the following code:

[0150]

[0151] In the code provided in the example, the @Override annotation is similar in function to that in the previous example and will not be elaborated here. "public boolean expire()" indicates the declaration of an "expire" method with a public type and a return value of boolean. "expire(String key, long time)" indicates that the "expire" method is used to receive two parameters, one is a key of type String, and the other is a time of type long. "try {}" indicates that the service device starts an exception handling block, which is used to attempt to execute the code in "{}". When no exception occurs in the exception handling block, true (return true) will be returned to indicate that the cache expiration time is set successfully. When an exception occurs in the exception handling block, the service device can catch the exception through the "catch(Exception e)" method and record the exception through the "LoggerUtil.error" method. The "LoggerUtil.error" method can receive a log object "log", an exception object "e", and an error message. At the same time, when an exception occurs in the exception handling block, false (return false) will also be returned to indicate that the cache expiration time setting fails.

[0152] "key = addEnvPreFixKey(key)" indicates that the service device calls the "addEnvPreFixKey" method to process the incoming key. The "addEnvPreFixKey" method can add a specific prefix (such as an environment identifier) to the incoming key to distinguish different operating environments.

[0153] "if(time > 0) {}" indicates that the service device will execute the code in "{}" only when the incoming time (time) is greater than 0. "redisTemplate.expire(key, time, TimeUnit.SECONDS)" is used to call the client of the Redis cluster (redisTemplate) to set the parameters for the cache expiration time of the Redis cluster. The parameters include the processed key, the expiration time time, and the time unit (TimeUnit.SECONDS, indicating that the time unit is seconds).

[0154] In some embodiments, when the target middleware is a Redis cluster, the service device can obtain the running parameters of the Redis cluster through the client of the Redis cluster, including: obtaining the cache expiration time of the Redis cluster. The service device can implement the process of obtaining the cache expiration time through the following code:

[0155] @Override

[0156] public long getExpire(String key){

[0157] key = addEnvPreFixKey(key);

[0158] return redisTemplate.getExpire(key, TimeUnit.SECONDS);

[0159] }

[0160] In the code provided in the example, the @Override annotation has a similar function to that in the previous example, which will not be elaborated here.

[0161] "public long getExpire()" indicates that a "getExpire" method with a public type and a return value type of long integer value is declared. "String key" indicates that the "getExpire" method is used to receive a "key" of type "String" as a parameter. The function of "key = addEnvPreFixKey(key)" in the code provided in this instance is similar to that in the previous code for configuring the cache expiration time, which will not be elaborated here.

[0162] "return redisTemplate.getExpire(key, TimeUnit.SECONDS)" means that the service device uses the "getExpire" method through the client of the Redis cluster (redisTemplate) to obtain the processed "key" passed in and the time unit (TimeUnit.SECONDS, indicating that the time unit is seconds), and returns the remaining expiration time of the "key" in seconds.

[0163] It should be noted that when the integration suite is introduced by the code packages of multiple services, each service realizes the interaction between the client of the target middleware and the target middleware by calling the corresponding call interface of the target middleware. That is, different services can all interact with the target middleware through the client call interface of the target middleware.

[0164] In this embodiment, when the service device configures the target middleware through the client of the target middleware, or when the service device obtains the running parameters of the target middleware through the client of the target middleware, the interaction between the client of the target middleware and the target middleware can be realized through the corresponding call interface of the target middleware (for example, for a Redis cluster, the call interfaces are all "redisTemplate"). The operator can use the call interface to realize the interaction between the client of the target middleware and the target middleware without learning to use the original interface provided by the middleware, effectively reducing the learning cost of the operator and improving the development efficiency of the project.

[0165] In some embodiments, after the target service is started successfully, the running method of the service further includes: the service device responds to the update instruction corresponding to the target middleware and executes the update process of the target middleware. The update process at least includes: the service device destroys the client of the target middleware based on the integration suite. The service device obtains the current configuration information of the target middleware from the configuration file, and based on the integration suite and the current configuration information, executes the initialization process of the target middleware to obtain the updated client of the target middleware. And the service device injects the updated client into the target service.

[0166] In some embodiments, the update instruction corresponding to the target middleware can be sent by the user to the service device based on the interaction page of the service system, or can be generated by the service device after detecting that the configuration file of the target middleware stored in the configuration center has changed. When the service device updates the target middleware, it can destroy the client of the target middleware based on the integration suite through the @PreDestroy annotation. Then, the service device can obtain the current configuration information of the target middleware based on the update instruction, and based on the integration suite and the current configuration information, execute the initialization process of the target middleware through the @Configuration annotation to obtain the updated client of the target middleware. Finally, the service device injects the updated client into the target service through the @Autowired annotation. Among them, the method for the service device to obtain the current configuration information of the target middleware, the method for executing the initialization process of the target middleware through the @Configuration annotation, and the method for injecting the updated client into the target service through the @Autowired annotation are similar to the methods provided above and will not be elaborated here.

[0167] In this embodiment, updating the target middleware through the update instruction corresponding to the target middleware can provide a more flexible middleware integration method, enabling the target system to maintain the running target middleware at any time, reducing the probability of the target middleware malfunctioning, and ensuring the stable operation of the service system and the target service.

[0168] In summary, in the method for operating a service and the service device provided in this specification, an integration suite is introduced into the code package of the target service, and the integration suite is used to provide the integration ability of multiple middleware to the target service. The service device receives and responds to the start instruction of the target service, and determines the configuration information of at least one middleware required by the target service through the configuration file of the target service. The service device initializes the clients of at least one middleware based on the integration suite and the configuration file, and injects the clients of at least one middleware into the target service. During the operation of the target service, the service device can interact with the target middleware through the client of the target middleware. Since the integration suite provides the integration ability of multiple middleware, only the configuration data of the middleware needs to be provided, and the middleware client can be injected into the target service through the integration suite. Users do not need to configure, debug, and integrate each middleware separately, reducing repetitive work and improving the development efficiency of the project.

[0169] On the other hand, this specification provides a computer-readable non-transitory storage medium storing at least one instruction set for providing data services. When the at least one instruction set is executed by a processor, the at least one instruction set directs the processor to implement the steps of the method for operating the services described in this specification. In some possible implementation manners, various aspects of this specification can also be implemented in the form of a program product, which includes program code. When the program product runs on a computing device 200, the program code is used to cause the computing device 200 to execute the steps of the method for operating the services described in this specification. The program product for implementing the above method can adopt a portable compact disc read-only memory (CD-ROM) including program code and can run on the computing device 200. However, the program product of this specification is not limited thereto. In this specification, the readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or combined with an instruction execution system. The program product can adopt any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium. The readable storage medium can, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer-readable storage medium can include a data signal propagated in a baseband or as part of a carrier wave, where the readable program code is carried. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The readable storage medium can also be any readable medium other than the readable storage medium, and this readable medium can send, propagate, or transmit a program for use by or combined with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination of the above. The program code for performing the operations of this specification can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and also including conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on the computing device 200, partially on the computing device 200, executed as an independent software package, partially on the computing device 200 and partially on a remote computing device, or entirely on a remote computing device.

[0170] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the acts or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require a particular or sequential order to achieve the desired result. In certain implementations, multitasking and parallel processing are also possible or may be advantageous.

[0171] In summary, after reading this detailed disclosure, those skilled in the art will appreciate that the foregoing detailed disclosure may be presented by way of example only and is not necessarily limiting. Although not explicitly stated herein, those skilled in the art can understand that this specification is intended to encompass various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be proposed by this specification and are within the spirit and scope of the exemplary embodiments of this specification.

[0172] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "one embodiment", "an embodiment", and / or "some embodiments" mean that the particular features, structures, or characteristics described in connection with that embodiment may be included in at least one embodiment of this specification. Thus, it should be emphasized and understood that two or more references to "an embodiment" or "one embodiment" or "alternative embodiments" in various parts of this specification do not necessarily all refer to the same embodiment. Additionally, the particular features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.

[0173] It should be understood that in the foregoing description of the embodiments of this specification, for the purpose of helping to understand a feature and for the purpose of simplifying this specification, this specification combines various features in a single embodiment, figure, or its description. However, this does not mean that the combination of these features is necessary, and those skilled in the art may well mark out some of the devices as separate embodiments for understanding when reading this specification. That is to say, the embodiments in this specification may also be understood as the integration of multiple sub - embodiments. And the content of each sub - embodiment is also valid when it has fewer features than all the features of a single foregoing disclosed embodiment.

[0174] Each patent, patent application, published patent application, and other materials cited herein, such as articles, books, specifications, publications, documents, items, etc., except for those that are inconsistent with or conflict with this document, or those that have a limiting effect on the broadest scope of the claims, may be incorporated herein by reference and used for all purposes now or hereafter associated with this document. Further, in the event of any inconsistency or conflict between the description, definition, and / or use of relevant terms in any material and the description, definition, and / or use of relevant terms in this document, the terms in this document shall prevail.

[0175] Finally, it should be understood that the embodiments of the application disclosed herein are illustrative of the principles of the embodiments of this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can adopt alternative configurations based on the embodiments in this specification to implement the application in this specification. Therefore, the embodiments of this specification are not limited to the embodiments precisely described in the application.

Claims

1. A method for operating a service, comprising: Receiving a start instruction of a target service, wherein a code package of the target service introduces an integration kit, and the integration kit is used to provide the target service with an integration capability of multiple middlewares; In response to the start instruction, a start process of the target service is executed, the start process at least comprising: Obtaining a configuration file of the target service, wherein the configuration file includes configuration information of at least one middleware required to be used by the target service; Initialize a client of the at least one middleware based on the integration kit and the configuration file, and injecting a client of the at least one middleware into the target service; and During the operation of the target service, the target middleware is interacted with by a client of the target middleware, and the target middleware is any one of the at least one middleware.

2. The method according to claim 1, wherein: The integrated kit includes: configuration classes corresponding to the plurality of middlewares respectively, and a service class corresponding to the target service; initializing a client of at least one middleware based on the integrated kit and the configuration file, and injecting the client of at least one middleware into the target service, including: Initialize a client of the at least one middleware based on the configuration file and the configuration classes corresponding to the plurality of middlewares; and The target service is initialized based on the service class corresponding to the target service, and during the initialization of the target service, the client of the at least one middleware is injected into the target service.

3. The method according to claim 2, wherein: Initializing a client of the at least one middleware based on the configuration file and the configuration classes corresponding to the plurality of middlewares respectively includes: Traverse the multiple middlewares, and for each current middleware in the traversal: determine based on the configuration file whether the current middleware is the middleware required to be used by the target service; if so, initialize the client of the current middleware based on the configuration class corresponding to the current middleware.

4. The method according to claim 3, wherein: The configuration class corresponding to the current middleware includes initialization conditions; The determining, based on the configuration file, whether the current middleware is the middleware required to be used by the target service includes: If configuration information corresponding to the current middleware exists in the configuration file and the configuration information satisfies the initialization condition, determining that the current middleware is the middleware required to be used by the target service; or When the configuration information corresponding to the current middleware does not exist in the configuration file, or when the configuration information corresponding to the current middleware exists but the configuration information does not meet the initialization condition, it is determined that the current middleware is not the middleware required to be used by the target service.

5. The method according to claim 3, wherein: The integrated kit further includes: an initialization verification interface corresponding to each of the plurality of middlewares, for verifying whether the client of the middleware is successfully initialized; after injecting the client of at least one middleware into the target service, further including: Based on the initialization verification interface corresponding to the current middleware, verify whether the client of the current middleware is successfully initialized.

6. The method according to claim 2, wherein: The integrated suite further includes: a calling interface corresponding to each of the plurality of middlewares, wherein the calling interface is obtained by encapsulating an original interface provided by the middleware; Interacting with the target middleware through the client of the target middleware includes: realizing the interaction between the client of the target middleware and the target middleware by calling the calling interface corresponding to the target middleware; When the integrated suite is introduced by the code packages of multiple services, the multiple services all implement the interaction between the client of the target middleware and the target middleware by calling the calling interface corresponding to the target middleware.

7. The method according to claim 1, wherein: The obtaining of the configuration file corresponding to the target service includes: Obtain the configuration file uploaded by the operator from the interactive page, or The configuration file is obtained from a preset storage path.

8. The method according to claim 1, wherein: The target service is a service in a service system adopting a microservice architecture, the service system includes a configuration center, and the configuration center stores configuration information of the plurality of middlewares; The obtaining of the configuration file corresponding to the target service includes: Based on the startup instruction, determining at least one middleware required to be used by the target service, The configuration information of the at least one middleware is acquired from the configuration center, and the configuration file is generated based on the configuration information of the at least one middleware.

9. The method according to claim 1, wherein: After the target service is started, the method further includes: In response to receiving the update instruction corresponding to the target middleware, executing the update process of the target middleware, the update process at least includes: Destroying the client of the target middleware based on the integration kit; Obtaining current configuration information of the target middleware from the configuration file, and executing an initialization process of the target middleware based on the integrated suite and the current configuration information to obtain an updated client of the target middleware; and Inject the updated client into the target service.

10. The method according to claim 1, wherein: The startup process also includes: generating a monitoring instance based on the integration suite; The method further includes: during the operation of the target service, collecting the operation parameters of the at least one middleware based on the monitoring instance, and generating the operation log of the target service based on the operation parameters.

11. A service device comprising: at least one storage medium storing at least one instruction set for running the service; as well as At least one processor is communicatively connected to the at least one storage medium, wherein when the service device is running, the at least one processor reads the at least one instruction set and implements the method as described in any one of claims 1-10 according to the instructions of the at least one instruction set.

12. A computer-readable non-volatile storage medium, wherein: The computer-readable non-volatile storage medium stores at least one instruction set, and when the at least one instruction set is executed by at least one processor, the method according to any one of claims 1 to 10 is implemented.

Images