Method and apparatus for starting a tenant plug-in and enabling in-process communication

Abstract

Embodiments of the present specification provide a method and device for starting a tenant plug-in and implementing in-process communication. In the method for starting a tenant plug-in, a tenant plug-in starting request from a client device is received, the tenant plug-in starting request including a programming language virtual machine type used by the tenant plug-in and storage path information of a dynamic link library corresponding to the tenant plug-in; a dynamic link library of the tenant plug-in is obtained according to the storage path information of the dynamic link library in the tenant plug-in starting request, the dynamic link library including a tenant plug-in program instance and a programming language virtual machine; a resource control group is created for the tenant plug-in; the obtained dynamic link library is loaded to a current system process in an isolated resource environment limited by the resource control group, so as to start the corresponding programming language virtual machine and implement instantiation and initialization of the tenant plug-in; and a response message indicating that the tenant plug-in is started successfully is sent to the client device in response to completion of the tenant plug-in initialization.

Description

Technical Field

[0001] The embodiments in this specification generally relate to the field of computer technology, and more particularly to methods and apparatus for launching tenant plugins and implementing intra-process communication. Background Technology

[0002] With the rapid development of internet technology, in the context of the cloud-native era, application instances developed based on virtual machines using a single programming language are increasingly unable to meet the needs of multi-tenant models. Cloud-native is a method for building and running applications; it is a set of technologies and methodologies. Cloud-native technologies enable organizations to build and run scalable applications in new dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs (Application Programming Interfaces) are examples of this approach.

[0003] One existing technology employs a single-instance model, residing the data of different tenants within the same programming language virtual machine. Since users can directly access other tenants' data through code symbols, it's difficult to guarantee data isolation and security. Furthermore, due to limitations of programming language version control systems, an external dependency can only have one version. When different tenants depend on different versions of this dependency, the latest version is forced to be used, potentially causing compilation failures for tenants using older versions. Another existing technology uses a multi-process model, where each tenant's programming language virtual machine runs within a different system process. However, since communication between tenants can only be achieved through cross-process communication, this incurs greater performance overhead. Summary of the Invention

[0004] In view of the above, embodiments of this specification provide a method and apparatus for launching tenant plugins and implementing intra-process communication. Using this method and apparatus, secure startup of multiple tenants within the same system process can be achieved; and multiple tenant plugins can achieve high performance in intra-process communication while maintaining resource isolation.

[0005] According to one aspect of an embodiment of this specification, a method for launching a tenant plugin is provided, comprising: receiving a tenant plugin launch request from a client device, the tenant plugin launch request including the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin; obtaining the dynamic link library of the tenant plugin to be launched based on the storage path information of the dynamic link library in the tenant plugin launch request, the dynamic link library including a tenant plugin program instance and a programming language virtual machine; creating a resource control group for the tenant plugin; loading the obtained dynamic link library into the current system process within the isolated resource environment restricted by the resource control group to launch the corresponding programming language virtual machine and realize the instantiation and initialization of the tenant plugin; and in response to the completion of the tenant plugin initialization, sending a response message indicating successful startup of the tenant plugin to the client device.

[0006] According to another aspect of the embodiments of this specification, a method for implementing intra-process communication between tenant plugins is provided, comprising: receiving a first intra-process communication request from a first tenant plugin, the first intra-process communication request including a tenant plugin identifier of a second tenant plugin as the communication peer and communication parameter information for intra-process communication, the communication parameter information including a function call method and function call parameters; locating the second tenant plugin in a set of tenant plugins started in the same system process according to the tenant plugin identifier of the second tenant plugin; sending a second intra-process communication request to the located second tenant plugin, the second intra-process communication request including the communication parameter information for intra-process communication, the second tenant plugin calling a target function according to the function call method and the function call parameters to generate a response message for intra-process communication; receiving a response message returned by the second tenant plugin; and sending the response message to the first tenant plugin, wherein, when each tenant plugin in the set of tenant plugins started in the same system process starts, each loads its own dynamic link library into the same system process within an isolated resource environment restricted by its own resource control group, so as to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin, and each started tenant plugin has a tenant plugin identifier.

[0007] According to another aspect of the embodiments of this specification, an apparatus for launching a tenant plugin is provided, comprising: a request receiving unit for receiving a tenant plugin launch request from a client device, the tenant plugin launch request including the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin; a library acquisition unit for acquiring the dynamic link library of the tenant plugin to be launched according to the storage path information of the dynamic link library in the tenant plugin launch request, the dynamic link library including a tenant plugin program instance and a programming language virtual machine; a resource control group creation unit for creating a resource control group for the tenant plugin; a library loading unit for loading the acquired dynamic link library into the current system process within the isolated resource environment restricted by the resource control group, so as to launch the corresponding programming language virtual machine and realize the instantiation and initialization of the tenant plugin; and a response sending unit for sending a response message indicating successful launch of the tenant plugin to the client device in response to the completion of the tenant plugin initialization.

[0008] According to another aspect of the embodiments of this specification, an apparatus for implementing intra-process communication between tenant plugins is provided. The apparatus includes: a communication request receiving unit, which receives a first intra-process communication request from a first tenant plugin, the first intra-process communication request including a tenant plugin identifier of a second tenant plugin (as the communication peer) and communication parameter information for intra-process communication, the communication parameter information including a function call method and function call parameters; a tenant plugin locating unit, which locates the second tenant plugin from a group of tenant plugins started in the same system process based on the tenant plugin identifier of the second tenant plugin; and a communication request sending unit, which sends a second intra-process communication request to the located second tenant plugin, the second intra-process communication request including... The communication parameter information of the intra-process communication; the second tenant plugin calls the target function according to the function call method and the function call parameters to generate the response message of the intra-process communication; the response message receiving unit receives the response message returned by the second tenant plugin; and the response message sending unit sends the response message to the first tenant plugin. In this case, each tenant plugin in the tenant plugin set started in the same system process loads its own dynamic link library into the same system process within the isolated resource environment restricted by its respective resource control group when it starts, so as to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin. Each started tenant plugin has a tenant plugin identifier.

[0009] According to another aspect of the embodiments of this specification, a tenant plug-in management device is provided, comprising: means for activating a tenant plug-in as described above; and means for enabling intra-process communication between tenant plug-ins as described above.

[0010] According to another aspect of the embodiments of this specification, an apparatus for launching a tenant plugin is provided, comprising: at least one processor, and a memory coupled to the at least one processor, and a computer program stored on the memory, wherein the at least one processor executes the computer program to implement the method for launching a tenant plugin as described above.

[0011] According to another aspect of the embodiments of this specification, an apparatus for implementing intra-process communication between tenant plugins is provided, comprising: at least one processor, and a memory coupled to the at least one processor, and a computer program stored on the memory, wherein the at least one processor executes the computer program to implement the method for implementing intra-process communication between tenant plugins as described above.

[0012] According to another aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program, which, when executed by a processor, implements the methods described above for launching tenant plugins and / or for enabling intra-process communication between tenant plugins.

[0013] According to another aspect of the embodiments of this specification, a computer program product is provided, including a computer program that is executed by a processor to implement the methods for launching tenant plugins and / or for enabling intra-process communication between tenant plugins as described above. Attached Figure Description

[0014] A further understanding of the nature and advantages of this specification can be achieved by referring to the following figures. In the figures, similar components or features may have the same reference numerals.

[0015] Figure 1 An exemplary architecture is shown for methods and apparatus for launching tenant plugins, and methods and apparatus for enabling intra-process communication between tenant plugins, according to embodiments of this specification.

[0016] Figure 2 A flowchart illustrating an example of a method for launching a tenant plugin according to an embodiment of this specification is shown.

[0017] Figure 3a , Figure 3b Schematic diagrams are shown for an example of a tenant plugin startup request according to an embodiment of this specification.

[0018] Figure 4 A flowchart illustrating an example of the loading process of a dynamic link library according to an embodiment of this specification is shown.

[0019] Figure 5A flowchart illustrating yet another example of a method for launching a tenant plugin according to an embodiment of this specification is shown.

[0020] Figure 6 A flowchart illustrating an example of a method for implementing intra-process communication between tenant plugins according to an embodiment of this specification is shown.

[0021] Figure 7a , Figure 7b Schematic diagrams are shown for an example of a first in-process communication request according to embodiments of this specification.

[0022] Figure 8a , Figure 8b Schematic diagrams of an example of a response message according to an embodiment of this specification are shown.

[0023] Figure 9 An interactive timing diagram is shown as an example of a method for implementing intra-process communication between tenant plugins according to an embodiment of this specification.

[0024] Figure 10 A block diagram illustrating an example of an apparatus for launching a tenant plugin according to an embodiment of this specification is shown.

[0025] Figure 11 A block diagram of an example library loading unit in an apparatus for launching a tenant plugin according to an embodiment of this specification is shown.

[0026] Figure 12 A block diagram of yet another example of an apparatus for launching a tenant plugin according to an embodiment of this specification is shown.

[0027] Figure 13 A block diagram illustrating an example of an apparatus for enabling intra-process communication between tenant plugins according to an embodiment of this specification is shown.

[0028] Figure 14 A block diagram of an example tenant plug-in management device according to an embodiment of this specification is shown;

[0029] Figure 15 A block diagram illustrating an example of an apparatus for launching a tenant plugin according to an embodiment of this specification is shown.

[0030] Figure 16 A block diagram illustrating an example of an apparatus for enabling intra-process communication between tenant plugins according to an embodiment of this specification is shown. Detailed Implementation

[0031] The subject matter described herein will be discussed below with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of the embodiments described herein. Various processes or components may be omitted, substituted, or added as needed in the various examples. Furthermore, features described in some examples may be combined in other examples.

[0032] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0033] In this specification, the term "tenant" can be used to refer to a user or group of users in a cloud serving context. "Multi-tenancy" refers to a software architecture that can simultaneously provide services to multiple different user groups within a single software instance, while providing a certain degree of data isolation.

[0034] In this specification, the term "plugin" refers to a program written according to a certain application programming interface (API) specification, designed to develop and implement functions not available on the application software platform. Plugins communicate with the host program through an interface, much like hardware cards; they can be deleted, inserted, and modified at any time, resulting in a flexible structure, ease of modification, and convenient software upgrades and maintenance. The term "tenant plugin" can be viewed as an independent program instance, also called a "tenant plugin instance," indicating that the cloud service system can provide tenants with services that can be dynamically loaded or unloaded, possessing pluggable functionality like plugins. A "tenant plugin" can run code logic specified by the tenant (e.g., the tenant's program), and the resources it uses are subject to the limitations of the cloud service system.

[0035] In this specification, the term "Dynamic-Link Library" can refer to a binary program file that allows programs to share code and other resources necessary to perform a specific task, and allows the library file to be dynamically linked and loaded by the host program only when needed, such as dynamically linking to an executable file at runtime. In one example, the file extension for a dynamic-link library on a Windows platform is ".dll". In another example, the file extension on a Linux platform is ".so". In yet another example, the file extension on a Mac platform is ".dylib".

[0036] In this specification, the term "programming language virtual machine" can refer to a virtual machine specifically designed to run code in a particular language. A "virtual machine" is a computer software system simulated by software, having a completely isolated environment. In one example, a programming language virtual machine may include the JVM for running the Java language. In one example, a programming language virtual machine may include the Go Runtime for running the Go language. In one example, a programming language virtual machine may include WebAssembly running in a modern web browser.

[0037] The following describes in detail, with reference to the accompanying drawings, a method and apparatus for launching a tenant plugin, and a method and apparatus for implementing intra-process communication between tenant plugins according to embodiments of this specification.

[0038] Figure 1 An exemplary architecture 100 is shown for a method and apparatus for launching a tenant plugin, and a method and apparatus for implementing intra-process communication between tenant plugins, according to embodiments of this specification.

[0039] exist Figure 1 In this context, network 110 is used to interconnect terminal device 120 and console 130.

[0040] Network 110 can be any type of network capable of interconnecting network entities. Network 110 can be a single network or a combination of various networks. In terms of coverage, network 110 can be a local area network (LAN), a wide area network (WAN), etc. In terms of the carrying medium, network 110 can be a wired network, a wireless network, etc. In terms of data switching technology, network 110 can be a circuit-switched network, a packet-switched network, etc.

[0041] Terminal device 120 can be any type of electronic computing device capable of connecting to network 110, accessing servers or websites on network 110, processing data or signals, etc. For example, terminal device 120 can be a desktop computer, laptop computer, tablet computer, smartphone, etc. Although in Figure 1Only one terminal device is shown in the diagram, but it should be understood that a different number of terminal devices may be connected to network 110.

[0042] In one implementation, terminal device 120 can be used by a user. Terminal device 120 may include an application client (e.g., application client 121) that can provide various services to the user. In one example, the application client may be a program development application, etc. In some cases, application client 121 can interact with console 130. For example, application client 121 can transmit user-input messages (e.g., instructions to start a tenant plugin) to console 130 and receive responses associated with those messages from console 130.

[0043] Console 130 can connect to cloud server 140. Cloud server 140 can provide various cloud services to application client 121. Cloud server 140 may include system process 141 and plugin management base 142 as a user process. Plugin management base 142 can be a resident process, working with system process 141 to provide pluggable services (e.g., running tenant programs 143, 144, and 145 respectively) for tenant plugins (e.g., tenant plugin 1, tenant plugin 2, and tenant plugin 3). Typically, plugin management base 142 itself does not run any tenant-specific logic; it is configured to support tenant plugin startup, resource management, and intra-process communication.

[0044] It should be understood that Figure 1 All network entities shown are exemplary, and any other network entities may be involved in Architecture 100 depending on the specific application requirements.

[0045] Figure 2 A flowchart of a method 200 for launching a tenant plugin according to an embodiment of this specification is shown.

[0046] like Figure 2 As shown in 210, a tenant plugin startup request is received from the client device.

[0047] In this embodiment, a tenant plugin startup request can be received from a client device. This request may include the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin. In one example, the client device may be a client used by the tenant. The tenant plugin startup request may originate directly from the client used by the tenant.

[0048] Optionally, the aforementioned tenant plugin launch request may include a single integrated tenant plugin launch request obtained by aggregating at least two tenant plugin launch requests through the console responsible for managing the tenant (e.g., packaging multiple requests). These at least two tenant plugin launch requests may originate from clients used by different tenants, thereby saving communication overhead.

[0049] In one example, a tenant plugin startup request could be like this: Figure 3a As shown in the diagram. Here, `type` can be used to represent the type of programming language virtual machine used by the tenant plugin. For example, Java or Go. `progPath` can be used to represent the storage path of the dynamic link library corresponding to the tenant plugin.

[0050] Optionally, in one example, the tenant plugin startup request may also include resource limitation information for the tenant plugin. This resource limitation information may include, for example, maximum CPU usage and maximum memory usage.

[0051] Optionally, in one example, the tenant plugin startup request may also include the tenant plugin identifier of the tenant plugin. The tenant plugin identifier can be used to identify different tenant plugins. Furthermore, the created tenant plugin can be associated with the tenant plugin identifier of the tenant plugin to distinguish multiple tenant plugins running within the same system process.

[0052] In one example, a tenant plugin startup request could be like this: Figure 3b As shown in the diagram. Here, `cpu` represents the maximum CPU usage of the tenant plugin. `mem` represents the maximum memory usage of the tenant plugin. `tenantID` represents the unique identifier of the tenant plugin. The specific meanings of `type` and `progPath` can be found above.

[0053] Optionally, in one example, the tenant plugin startup request described above can also include custom configuration items (e.g., represented by `config`), which can be configured to any string according to the actual operational needs of the user plugin. For example, some network programs can use these configuration items to specify the port to listen on, while some database programs can use them to specify operating parameters, and so on. This enhances the flexibility of the tenant plugin.

[0054] Back Figure 2 In step 220, based on the storage path information of the dynamic link library in the tenant plugin startup request, the dynamic link library of the tenant plugin to be started is obtained.

[0055] In this embodiment, the storage path information of the dynamic link library can be used to indicate the execution entity of the method that can be used to start the tenant plugin (e.g., Figure 1 The path obtained by the plugin management platform 142 shown. Dynamic link libraries can include tenant plugin instances and programming language virtual machines. In one example, a tenant plugin instance can be a pre-prepared, runnable program instance by the tenant. The dynamic link library corresponding to the tenant plugin can typically be generated by packaging and compiling based on the pre-prepared, runnable program instance and the programming language virtual machine required to run the program instance. Here, the aforementioned program instance can refer to a program written by the user as needed.

[0056] In 230, create a resource control group for the tenant plugin.

[0057] In this embodiment, resource control groups can be created for tenant plugins. These resource control groups are used to limit and isolate resources based on system processes. For example, resource control groups can be created for each tenant plugin according to default resource limits. In one example, a resource control group can be a Cgroups (control groups) in the Linux operating system, used to limit, control, and isolate the resources (such as CPU, memory, disk I / O, etc.) of a process group. In another example, similarly, a resource control group can be a Job Object in the Windows operating system, which allows process groups to be managed as a unit. Job objects are named, secure, and shareable objects used to control the attributes of the processes associated with them.

[0058] Optionally, a resource control group can be created for the corresponding tenant plugin based on the resource limitation information of the tenant plugin included in the tenant plugin startup request. The resources that can be restricted in the resource control group corresponding to the created tenant plugin can correspond to the resource limitation information of the aforementioned tenant plugin.

[0059] Based on this, this solution can restrict and isolate the resources required by each tenant based on the resource control group of a single system process, thereby meeting the resource isolation requirements of different tenants within the same process.

[0060] In 240, within the isolated resource environment restricted by the resource control group, the acquired dynamic link library is loaded into the current system process to start the corresponding programming language virtual machine and instantiate and initialize the tenant plugin.

[0061] In one example, within the isolated resource environment restricted by the created resource control group, the acquired dynamic link library can be loaded into the current system process using the dlopen() standard library function provided by the Linux system. During the loading process, the corresponding programming language virtual machine can be started, and the tenant plugin can be instantiated and initialized. This ensures that all child threads subsequently started by the tenant plugin are within their respective tenant plugin's resource control group and subject to the resource restrictions of that group.

[0062] The following is for reference. Figure 4 , Figure 4 A flowchart illustrating an example of a dynamic link library loading process 400 according to an embodiment of this specification is shown.

[0063] like Figure 4 As shown in step 410, the tenant plugin is instantiated using the tenant plugin program instance in the obtained dynamic link library to create the corresponding tenant plugin.

[0064] In one example, the process of instantiating a tenant plugin described above can be viewed as creating a tenant plugin instance. This created tenant plugin instance provides the foundation for the operation of the tenant plugin program instance through subsequent initialization.

[0065] At 420, start the virtual machine for the programming language corresponding to the tenant plugin.

[0066] In this embodiment, the programming language virtual machine corresponding to the tenant plugin can be started in various ways. In one example, the corresponding programming language virtual machine can be started in a manner that matches the type of programming language virtual machine used by the tenant plugin. For example, the Go programming language virtual machine can be started using the dlopen() standard library function provided by the Linux system. As another example, the Java programming language virtual machine can be started using the dlopen() standard library function provided by the Linux system and the JNI interface provided by Java. These programming language virtual machines can correspond to a created resource control group; that is, each programming language virtual machine is subject to the resource limits of the corresponding resource control group.

[0067] In step 430, based on the acquired dynamic link library, the corresponding initialization code is executed in the programming language virtual machine to initialize the tenant plugin.

[0068] In this embodiment, since dynamic link libraries typically integrate the code to be run and other resources required for code execution, the initialization code of the corresponding tenant's program (e.g., a tenant plugin program instance) can be executed in the corresponding programming language virtual machine based on the obtained dynamic link library to achieve the initialization of the tenant plugin.

[0069] It is understandable that steps 410-430 above are usually performed within an isolated resource environment restricted by the corresponding resource control group.

[0070] Based on this, this solution combines programming language virtual machines with the corresponding dynamic link libraries of tenant plugins. Each tenant plugin can be viewed as an independent program instance, provided by the user as a dynamic link library. Thus, the compilation process of the program instance is entirely controlled by the user, and program instances from different tenants are compiled and packaged separately. The inherent isolation characteristics of programming language virtual machines ensure that programs running within a single virtual machine can only access the code instructions and data resources loaded by that virtual machine, thereby satisfying the isolation requirements of multi-tenancy. Furthermore, by providing separate programming language virtual machines for each tenant's program instance, this solution allows program instances from different tenants to run within different programming language virtual machines, eliminating any dependencies between them and thus overcoming the problem of dependency version conflicts.

[0071] Back Figure 2 In step 250, in response to the completion of tenant plugin initialization, a response message indicating that the tenant plugin has started successfully is sent to the client device.

[0072] In this embodiment, as an example, the system process can detect the completion of tenant plugin initialization. Then, a response message indicating successful tenant plugin startup can be sent to the client device. In one example, a tenant plugin can correspond to multiple tenant plugin program instances. Once all multiple tenant plugin program instances have completed initialization, a response message indicating successful tenant plugin startup can be sent to the client device.

[0073] Continue to refer to Figure 5 , Figure 5 A flowchart is shown as yet another example of a method 500 for launching a tenant plugin according to an embodiment of this specification.

[0074] In step 510, a tenant plugin launch request is received from the client device.

[0075] In step 520, the dynamic link library of the tenant plugin to be started is obtained based on the storage path information of the dynamic link library in the tenant plugin startup request.

[0076] In this embodiment, the dynamic link library may include declared communication interface definitions. These communication interface definitions indicate the requirements that the in-process communication interface to be created must meet. The in-process communication interface can be the execution body of the method used to start the tenant plugin (e.g., ...). Figure 1It provides an intra-process communication channel between the plugin management base 142 and the plugin management base.

[0077] In 530, create a resource control group for the tenant plugin.

[0078] In 540, within the isolated resource environment restricted by the resource control group, the acquired dynamic link library is loaded into the current system process to start the corresponding programming language virtual machine and instantiate and initialize the tenant plugin.

[0079] At 550, in response to the completion of tenant plugin initialization, a response message indicating that the tenant plugin has started successfully is sent to the client device.

[0080] It should be noted that the above steps 510-550 can refer to the relevant descriptions of steps 210-250 in the foregoing embodiments, and will not be repeated here.

[0081] In 560, based on the communication interface definition declared in the dynamic link library, an intra-process communication interface is created for the tenant plugin to communicate with other tenant plugins running in the same system process through the created intra-process communication interface.

[0082] In this embodiment, referring to the description of step 520 above, an intra-process communication interface conforming to the above communication interface definition can be created for the tenant plugin to conduct intra-process communication with other tenant plugins running in the same system process through the created intra-process communication interface. In one example, the intra-process communication interface can be created according to the relevant parameters of the above communication interface definition.

[0083] Based on this, this solution can use the created intra-process communication interface as an intra-process communication channel to communicate with each tenant plugin, thereby enabling the execution body of the method used to start the tenant plugin (e.g. Figure 1 The plugin management platform 142 provides the technical foundation for communication between various tenant plugins. Optionally, by using a single system process combined with multiple programming language virtual machines, the communication channels provided above are used to proxy intra-process communication requests between tenant plugins. This allows all communication requests between tenant plugins to be completed within the same system process, thus achieving performance far superior to cross-process communication.

[0084] In some optional implementations of this embodiment, step 560 can also be specifically referred to below. Figure 6 The specific operations described in the examples.

[0085] use Figures 1-5The disclosed method for launching tenant plugins creates a separate tenant plugin instance for each tenant. This, combined with system process-based resource control groups and programming language virtual machines, isolates the code instructions and data resources of each tenant, ensuring the isolation and security of multi-tenant plugin data. Furthermore, by loading the dynamic link libraries provided by each tenant into the system process within their respective tenant plugin's resource control group, it avoids compilation failures that might occur when different tenants rely on different versions of third-party dependencies. This achieves secure startup of multiple tenants within the same system process.

[0086] The following is for reference. Figure 6 , Figure 6 A flowchart illustrating an example of a method 600 for implementing intra-process communication between tenant plugins according to an embodiment of this specification is shown. In this embodiment, each tenant plugin in a set of tenant plugins launched within the same system process loads its own dynamic link library into the same system process within the isolated resource environment restricted by its respective resource control group, thereby launching its own programming language virtual machine and instantiating and initializing its own tenant plugin. Each launched tenant plugin may have a tenant plugin identifier. Specific details can be found in the corresponding descriptions in the foregoing embodiments, and will not be repeated here.

[0087] At 610, the first intra-process communication request from the first tenant plugin is received.

[0088] In this embodiment, the first intra-process communication request may include the tenant plugin identifier of the second tenant plugin, which serves as the communication peer, and communication parameter information for intra-process communication. The communication parameter information includes the function call method and function call parameters.

[0089] In one example, the aforementioned first intra-process communication request can be as follows: Figure 7a As shown in the diagram. Here, `targetTenantID` can be used to represent the unique identifier of the tenant plugin (e.g., tenant plugin 2) acting as the communication peer. `method` can be used to represent the function call method. `inputs` can be used to represent the function call parameters (e.g., custom parameters).

[0090] Optionally, the aforementioned first intra-process communication request may further include a tenant plugin identifier of the first tenant plugin acting as the caller. Optionally, the aforementioned communication parameter information may further include a call identifier.

[0091] In one example, the aforementioned first intra-process communication request can be as follows: Figure 7bAs shown in the diagram. `sourceTenantID` can be used to represent the unique identifier of the tenant plugin (e.g., tenant plugin 1) acting as the caller. `callID` can be used to represent the call identifier, which should generally be unique to the caller, used to associate the call context of this in-process communication request when the corresponding response message is returned. The call context can include call-related attributes, such as the call address, the caller's application name, timeout, and custom data passed by the user in addition to the parameters defined in the interface. The specific meanings of `targetTenantID`, `method`, and `inputs` can be found above.

[0092] Back Figure 6 In 620, based on the tenant plugin identifier of the second tenant plugin, the second tenant plugin is located in the group of tenant plugins started in the same system process.

[0093] In this embodiment, the aforementioned "location" can be understood as identifying and locating the tenant plugin corresponding to the tenant plugin identifier. This is typically applied in scenarios where multiple tenant plugins are launched within the same system process.

[0094] At 630, the second in-process communication request is sent to the located second tenant plugin.

[0095] In this embodiment, the second intra-process communication request may include communication parameter information for intra-process communication. This communication parameter information is typically consistent with the communication parameter information of the first intra-process communication request. Therefore, the second tenant plugin can generate the response message for the intra-process communication by calling the target function according to the function call method (e.g., the method mentioned above) and function call parameters (e.g., the inputs mentioned above) of the communication parameter information. Optionally, the second intra-process communication request may also be the same as the first intra-process communication request.

[0096] At 640, receive the response message returned by the second tenant plugin.

[0097] In this embodiment, the response message may include the call result corresponding to the second intra-process communication request. The call result may, for example, be the return value of the method corresponding to the function call. Optionally, the response message may further include at least one of the following: the tenant plugin identifier of the first tenant plugin as the caller, and the tenant plugin identifier of the second tenant plugin as the callee.

[0098] In one example, the above response message could be as follows: Figure 8a As shown. `outputs` can be used to represent the return value of this call. The specific meanings of `sourceTenantID` and `targetTenantID` can be found above.

[0099] Optionally, in one example, the response message may also include a call identifier, so that the first tenant plugin can associate the received response message with the call of the current intra-process communication request based on the call identifier.

[0100] In one example, the above response message could be as follows: Figure 8b As shown. The specific meanings of sourceTenantID, targetTenantID, callID, and outputs can be found above.

[0101] It should be noted that the tenant plugin identifier of the first tenant plugin, the tenant plugin identifier of the second tenant plugin, and the call identifier in the above response message are usually consistent with the corresponding fields contained in the corresponding intra-process communication request.

[0102] Back Figure 6 At 650, the response message will be sent to the first tenant plugin.

[0103] In this embodiment, the corresponding tenant plugin, i.e., the first tenant plugin, can be determined based on the identifier of the first tenant plugin included in the response message. Then, the response message can be sent to the first tenant plugin in a similar manner as described above.

[0104] Optionally, the first tenant plugin can associate it with the corresponding sent in-process communication request based on the call identifier in the response message, thereby completing the cross-tenant plugin communication call.

[0105] Optionally, the first tenant plugin can send first intra-process communication requests and receive response messages through the first intra-process communication interface. The second tenant plugin can receive second intra-process communication requests and send response messages through the second intra-process communication interface. The first and second intra-process communication interfaces can be created respectively during the startup process of the first and second tenant plugins based on the communication interface definitions declared in their respective dynamic link libraries. The descriptions of the first and second intra-process communication interfaces can be found in the preceding embodiments under the term "intra-process communication interface," and will not be repeated here.

[0106] In one example, dependency injection can be used to inject an intra-process communication interface (e.g., the first intra-process communication interface) as an external dependency function symbol into the dynamic link library of a tenant plugin (e.g., the first tenant plugin) when loading the dynamic link library of that tenant plugin (e.g., the first tenant plugin). This enables function calls within the same process, i.e., the execution body of the method used to implement intra-process communication between tenant plugins (e.g., the first tenant plugin's interface). Figure 1 Communication between the plugin management base 142 and tenant plugins (e.g., the first tenant plugin).

[0107] Optionally, in one example, the first tenant plugin and the second tenant plugin described above can be configured as described in the foregoing. Figure 1-5 The method for starting the tenant plugin described in the embodiment is initiated.

[0108] Continue to refer to Figure 9 , Figure 9 An interactive timing diagram is shown as an example of a method 900 for implementing intra-process communication between tenant plugins according to an embodiment of this specification.

[0109] In 910, the plugin management dock receives tenant plugin launch requests sent from the console.

[0110] In this embodiment, the tenant plugin startup request sent by the console may include at least one tenant plugin startup request from a client device.

[0111] In version 920, the plugin management platform obtains the dynamic link library of the tenant plugin to be launched based on the storage path information of the dynamic link library in the tenant plugin startup request.

[0112] In 930, the plugin management dashboard creates resource control groups for each tenant plugin.

[0113] In 940, the plugin management platform loads the dynamic link libraries of each tenant plugin into the current system process within the isolated resource environment restricted by the various resource control groups it creates.

[0114] It should be noted that since the plugin management base and the first tenant plugin and the second tenant plugin are all user processes that depend on the same system process, the above step 940 involves interaction based on the system process.

[0115] At 950, in response to the completion of tenant plugin initialization, the plugin management dock will send a response message to the console to indicate that the tenant plugin has started successfully.

[0116] In one example of this embodiment, the console can also return a message indicating that the tenant plugin has started successfully to the client used by the corresponding tenant, based on the above response message.

[0117] In 960, the plugin management dock receives the first intra-process communication request from the first tenant plugin.

[0118] In this embodiment, the aforementioned first intra-process communication request includes the tenant plugin identifier of the second tenant plugin, which serves as the communication peer, and communication parameter information for intra-process communication. The communication parameter information includes the function call method and function call parameters.

[0119] In 970, based on the tenant plugin identifier of the second tenant plugin, the plugin management base centrally locates the second tenant plugin among the tenant plugins started in the same system process.

[0120] In 980, the plugin management dock sends the second in-process communication request to the located second tenant plugin.

[0121] In this embodiment, the aforementioned second intra-process communication request includes communication parameter information for intra-process communication. The aforementioned second tenant plugin generates an intra-process communication response message by calling the target function according to the function call method and function call parameters.

[0122] At 990, the plugin management dock receives the response message returned by the second tenant plugin.

[0123] In this embodiment, the response message may include the call result corresponding to the first intra-process communication request.

[0124] In 9100, the plugin management dock will send a response message to the first tenant plugin.

[0125] It should be noted that steps 910-950 above can be referred to the aforementioned... Figures 1-5 The method for starting the tenant plugin described in the embodiments. Steps 960-9100 above can be referred to the foregoing. Figure 6 The method for enabling intra-process communication between tenant plugins, as described in the embodiment of Figure 8, will not be repeated here.

[0126] use Figures 6-9 The disclosed method for enabling intra-process communication between tenant plugins establishes intra-process communication channels with each tenant plugin by leveraging the method used during startup to load dynamic link libraries into the same system process within the isolated resource environment restricted by their respective resource control groups. These channels act as intermediaries for proxying intra-process communication requests between tenant plugins. Since communication requests between tenant plugins can be completed within the same system process, it offers significantly higher performance than cross-process communication. This allows multiple tenant plugins to achieve high-performance intra-process communication while maintaining resource isolation.

[0127] Figure 10 A block diagram illustrating an example of a tenant plug-in device 1000 according to an embodiment of this specification is shown. This device embodiment can be used with... Figures 1-5Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0128] like Figure 10 As shown, the tenant plug-in device 1000 may include a request receiving unit 1010, a library acquisition unit 1020, a resource control group creation unit 1030, a library loading unit 1040, and a response sending unit 1050.

[0129] The request receiving unit 1010 is configured to receive a tenant plugin startup request from a client device. The tenant plugin startup request includes the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin. The operation of the request receiving unit 1010 can be referred to above. Figure 2 The operation described in section 210.

[0130] In one example, the tenant plugin launch request includes at least two tenant plugin launch requests, and the at least two tenant plugin launch requests are combined into a single combined tenant plugin launch request for sending.

[0131] The library acquisition unit 1020 is configured to acquire the dynamic link library of the tenant plugin to be launched based on the storage path information of the dynamic link library in the tenant plugin startup request. The dynamic link library includes a tenant plugin program instance and a programming language virtual machine. The operation of the library acquisition unit 1020 can be referred to above. Figure 2 The operation described in section 220.

[0132] Resource control group creation unit 1030 is configured to create resource control groups for the tenant plugin. The operation of resource control group creation unit 1030 can be referred to above. Figure 2 The operation described in section 230.

[0133] In one example, the aforementioned tenant plugin startup request may further include resource restriction information for the tenant plugin. The aforementioned resource control group creation unit 1030 may be further configured to create a resource control group for the tenant plugin based on the resource restriction information.

[0134] The library loading unit 1040 is configured to load the acquired dynamic link library into the current system process within the isolated resource environment restricted by the resource control group, so as to start the corresponding programming language virtual machine and realize the instantiation and initialization of the tenant plugin. The operation of the library loading unit 1040 can be referred to above. Figure 2 The operation described in section 240.

[0135] Further reference Figure 11 , Figure 11A block diagram of an example of a library loading unit 1100 in an apparatus for launching a tenant plugin according to an embodiment of this specification is shown.

[0136] The aforementioned library loading unit 1100 may include a tenant plugin creation module 1110, a virtual machine startup module 1120, and an initialization module 1130.

[0137] The tenant plugin creation module 1110 is configured to instantiate tenant plugins using the tenant plugin program instance from the acquired dynamic link library, thereby creating the corresponding tenant plugin. The operation of the tenant plugin creation module 1110 can be referenced above. Figure 4 The operation described in section 410.

[0138] The virtual machine startup module 1120 is configured to start the programming language virtual machine corresponding to the tenant plugin. The operation of the virtual machine startup module 1120 can be referred to above. Figure 4 The operation described in section 420.

[0139] Initialization module 1120 is configured to execute corresponding initialization code in the programming language virtual machine based on the acquired dynamic link library to initialize the tenant plugin. The operation of initialization module 1130 can be referenced above. Figure 4 The operation described in section 430.

[0140] Back Figure 10 The response sending unit 1050 is configured to send a response message indicating successful startup of the tenant plugin to the client device in response to the completion of the tenant plugin initialization. The operation of the response sending unit 1050 can be referred to above. Figure 2 The operation described is 250.

[0141] In one example, the tenant plugin launch request also includes a tenant plugin identifier of the tenant plugin. The means for launching a tenant plugin may further include an identifier association unit (not shown in the figure), configured to associate the created tenant plugin with the tenant plugin identifier of the tenant plugin.

[0142] Continue to refer to Figure 12 , Figure 12 A block diagram of yet another example of a device 1200 for launching a tenant plugin according to an embodiment of this specification is shown.

[0143] like Figure 12 As shown, the apparatus 1200 for launching a tenant plugin may include a request receiving unit 1210, a library acquisition unit 1220, a resource control group creation unit 1230, a library loading unit 1240, a response sending unit 1250, and a communication interface creation unit 1260.

[0144] The communication interface creation unit 1260 is configured to create an intra-process communication interface for the tenant plugin based on the communication interface definition declared in the dynamic link library, so as to conduct intra-process communication with other tenant plugins running in the same system process through the created intra-process communication interface. The operation of the communication interface creation unit 1260 can be referred to above. Figure 5 The description of the 560's operation.

[0145] The aforementioned request receiving unit 1210, library acquisition unit 1220, resource control group creation unit 1230, library loading unit 1240, and response sending unit 1250 can be referenced. Figure 10 The corresponding descriptions of the request receiving unit 1010, library acquisition unit 1020, resource control group creation unit 1030, library loading unit 1040, and response sending unit 1050 in the embodiment will not be repeated here.

[0146] Continue to refer to Figure 13 , Figure 13 A block diagram of an example of an apparatus 1300 for implementing intra-process communication between tenant plugins according to an embodiment of this specification is shown. This apparatus embodiment can be used with... Figures 6-9 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0147] In this embodiment, when each tenant plugin in the tenant plugin set launched in the same system process is launched, it loads its own dynamic link library into the same system process within the isolated resource environment restricted by its respective resource control group, so as to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin. Each launched tenant plugin has a tenant plugin identifier.

[0148] like Figure 13 As shown, the apparatus 1300 for enabling intra-process communication between tenant plugins may include a communication request receiving unit 1310, a tenant plugin locating unit 1320, a communication request sending unit 1330, a response message receiving unit 1340, and a response message sending unit 1350.

[0149] The communication request receiving unit 1310 is configured to receive a first intra-process communication request from a first tenant plugin. The first intra-process communication request includes a tenant plugin identifier of a second tenant plugin (which serves as the communication peer) and intra-process communication parameter information, including a function call method and function call parameters. The operation of the communication request receiving unit 1310 can be referred to the above. Figure 6 The operation of 610 is described.

[0150] In one example, the communication parameter information also includes a call identifier, and the response message is associated with the call context of the in-process communication request in the first tenant plugin.

[0151] Tenant plugin location unit 1320 is configured to locate the second tenant plugin from among tenant plugins started in the same system process based on the tenant plugin identifier of the second tenant plugin. The operation of tenant plugin location unit 1320 can be referred to above. Figure 6 The operation described in section 620.

[0152] The communication request sending unit 1330 is configured to send a second intra-process communication request to a located second tenant plugin. The second intra-process communication request includes communication parameter information for the intra-process communication. The second tenant plugin generates a response message for the intra-process communication by calling a target function according to the function call method and the function call parameters. The operation of the communication request sending unit 1330 can be referred to above. Figure 6 The operation described in section 630.

[0153] The response message receiving unit 1340 is configured to receive the response message returned by the second tenant plugin. The operation of the response message receiving unit 1340 can be referred to above. Figure 6 The operation described in section 640.

[0154] The response message sending unit 1350 is configured to send the response message to the first tenant plugin. The operation of the response message sending unit 1350 can be referred to above. Figure 6 The operation described is 650.

[0155] In one example, the first tenant plugin sends the first intra-process communication request and receives the response message through the first intra-process communication interface, and the second tenant plugin receives the second intra-process communication request and sends the response message through the second intra-process communication interface. The first intra-process communication interface and the second intra-process communication interface are created during the startup process of the first tenant plugin and the second tenant plugin, respectively, according to the communication interface definitions declared in their respective dynamic link libraries.

[0156] In one example, the first tenant plugin and the second tenant plugin described above are accessed via, for example... Figures 1-5 The described method for starting the tenant plugin is then initiated.

[0157] Reference above Figures 1 to 13 Embodiments of methods and apparatus for launching tenant plugins and methods and apparatus for implementing intra-process communication between tenant plugins according to embodiments of this specification have been described.

[0158] The apparatus for launching tenant plugins and the apparatus for enabling intra-process communication between tenant plugins in the embodiments of this specification can be implemented in hardware, software, or a combination of hardware and software. Taking software implementation as an example, as a logically defined apparatus, it is formed by the processor of its host device reading the corresponding computer program instructions from memory into memory and executing them. In the embodiments of this specification, the apparatus for launching tenant plugins and the apparatus for enabling intra-process communication between tenant plugins can, for example, be implemented using electronic devices.

[0159] Figure 14 A block diagram 1400 of an example tenant plug-in management device according to an embodiment of this specification is shown. Figure 14 As shown, according to one embodiment, a tenant plugin management device is provided, including: a means 1410 for launching tenant plugins and a means 1420 for enabling intra-process communication between tenant plugins. The means 1410 for launching tenant plugins can be referred to... Figures 10-12 The corresponding description in the embodiments. The apparatus 1420 for enabling intra-process communication between tenant plugins can be referred to. Figure 13 The corresponding descriptions in the embodiments.

[0160] Figure 15 A schematic diagram of an apparatus 1500 for launching a tenant plugin, according to an embodiment of this specification, is shown.

[0161] like Figure 15 As shown, the apparatus 1500 for launching a tenant plug-in may include at least one processor 1510, a memory (e.g., non-volatile memory) 1520, a memory 1530, and a communication interface 1540, and the at least one processor 1510, memory 1520, memory 1530, and communication interface 1540 are connected together via a bus 1550. At least one processor 1510 executes at least one computer-readable instruction (i.e., the elements implemented in software above) stored or encoded in the memory.

[0162] In one embodiment, computer-executable instructions are stored in memory, which, when executed, cause at least one processor 1510 to: receive a tenant plugin launch request from a client device, the tenant plugin launch request including the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin; obtain the dynamic link library of the tenant plugin to be launched based on the storage path information of the dynamic link library in the tenant plugin launch request, the dynamic link library including a tenant plugin program instance and a programming language virtual machine; create a resource control group for the tenant plugin; load the obtained dynamic link library into the current system process within the isolated resource environment restricted by the resource control group to launch the corresponding programming language virtual machine and realize the instantiation and initialization of the tenant plugin; and, in response to the completion of the tenant plugin initialization, send a response message indicating that the tenant plugin has started successfully to the client device.

[0163] It should be understood that the computer-executable instructions stored in memory, when executed, cause at least one processor 1510 to perform the above-described combinations in the various embodiments of this specification. Figure 1-5 The description includes various operations and functions.

[0164] Figure 16 A schematic diagram of an apparatus 1600 for enabling intra-process communication between tenant plugins, according to an embodiment of this specification, is shown.

[0165] like Figure 16 As shown, the apparatus 1600 for enabling intra-process communication between tenant plug-ins may include at least one processor 1610, memory (e.g., non-volatile memory) 1620, RAM 1630, and communication interface 1640, and the at least one processor 1610, memory 1620, RAM 1630, and communication interface 1640 are connected together via bus 1650. At least one processor 1610 executes at least one computer-readable instruction (i.e., the elements implemented in software described above) stored or encoded in memory.

[0166] In one embodiment, computer-executable instructions are stored in memory, which, when executed, cause at least one processor 1610 to: receive a first intra-process communication request from a first tenant plugin, the first intra-process communication request including a tenant plugin identifier of a second tenant plugin as the communication peer and communication parameter information for intra-process communication, the communication parameter information including a function call method and function call parameters; locate the second tenant plugin in a set of tenant plugins launched in the same system process according to the tenant plugin identifier of the second tenant plugin; send a second intra-process communication request to the located second tenant plugin, the second intra-process communication request including the communication parameter information for intra-process communication, the second tenant plugin calling a target function according to the function call method and the function call parameters to generate a response message for intra-process communication; receive a response message returned by the second tenant plugin; and send the response message to the first tenant plugin, wherein, upon startup, each tenant plugin in the set of tenant plugins launched in the same system process loads its own dynamic link library into the same system process within an isolated resource environment restricted by its respective resource control group, to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin, and each launched tenant plugin has a tenant plugin identifier.

[0167] It should be understood that the computer-executable instructions stored in memory, when executed, cause at least one processor 1610 to perform the above-described combinations in the various embodiments of this specification. Figures 6 to 9 The description includes various operations and functions.

[0168] According to one embodiment, a program product, such as a computer-readable medium, is provided. The computer-readable medium may have instructions (i.e., the elements implemented in software as described above), which, when executed by a computer, cause the computer to perform the above-described combinations of the various embodiments of this specification. Figure 1-9 The description includes various operations and functions.

[0169] Specifically, a system or apparatus equipped with a readable storage medium may be provided, on which software program code implementing the functions of any of the embodiments described above is stored, and the computer or processor of the system or apparatus can read and execute the instructions stored in the readable storage medium.

[0170] In this case, the program code itself, which can be read from a readable medium, can perform the functions of any of the above embodiments. Therefore, the machine-readable code and the readable storage medium storing the machine-readable code constitute a part of the present invention.

[0171] The computer program code required for the operation of each part of this manual can be written in any one or more programming languages, including object-oriented programming languages ​​such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB, .NET, and Python; conventional procedural programming languages ​​such as C, Visual Basic 2003, Perl, COBOL 2002, PHP, and ABAP; dynamic programming languages ​​such as Python, Ruby, and Groovy; or other programming languages. This program code can run on the user's computer, or as a standalone software package on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any network, such as a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., via the Internet), or in a cloud computing environment, or used as a service, such as Software as a Service (SaaS).

[0172] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer or the cloud via a communication network.

[0173] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0174] Not all steps and units in the above process and system structure diagrams are mandatory; some steps or units can be omitted as needed. The execution order of each step is not fixed and can be determined as required. The device structure described in the above embodiments can be a physical structure or a logical structure. That is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

[0175] The term "exemplary" as used throughout this specification means "serving as an example, instance, or illustration" and does not imply that it is "preferred" or "advantageous" over other embodiments. Detailed descriptions are included for the purpose of providing an understanding of the described techniques. However, these techniques may be practiced without these detailed descriptions. In some instances, well-known structures and apparatuses are shown in block diagram form to avoid obscuring the concepts of the described embodiments.

[0176] The optional embodiments of the present specification have been described in detail above with reference to the accompanying drawings. However, the embodiments of the present specification are not limited to the specific details in the above embodiments. Within the scope of the technical concept of the embodiments of the present specification, various simple modifications can be made to the technical solutions of the embodiments of the present specification, and these simple modifications all fall within the protection scope of the embodiments of the present specification.

[0177] The foregoing description of this specification is provided to enable any person skilled in the art to implement or use the content of this specification. Various modifications to the content of this specification will be apparent to those skilled in the art, and the general principles defined herein can be applied to other variations without departing from the scope of protection of this specification. Therefore, this specification is not limited to the examples and designs described herein, but is consistent with the widest scope of the principles and novel features disclosed herein.

Claims

1. A method for starting a tenant plugin, comprising: Receive a tenant plugin startup request from a client device. The tenant plugin startup request includes the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin. Based on the storage path information of the dynamic link library in the tenant plugin startup request, obtain the dynamic link library of the tenant plugin to be started. The dynamic link library includes a tenant plugin program instance and a programming language virtual machine. Create a resource control group for the tenant plugin; Within the isolated resource environment restricted by the resource control group, the acquired dynamic link library is loaded into the current system process to start the corresponding programming language virtual machine and instantiate and initialize the tenant plugin; and In response to the completion of the tenant plugin initialization, a response message indicating that the tenant plugin has started successfully is sent to the client device.

2. The method as described in claim 1, wherein, The tenant plugin startup request also includes resource limitation information for the tenant plugin. Creating a resource control group for the tenant plugin includes: Based on the resource restriction information, create a resource control group for the tenant plugin.

3. The method as described in claim 1, wherein, The tenant plugin startup request also includes the tenant plugin identifier, and the method further includes: Associate the created tenant plugin with the tenant plugin identifier of the tenant plugin.

4. The method of claim 1, wherein, Within the isolated resource environment restricted by the resource control group, loading the acquired dynamic link library into the current system process to start the corresponding programming language virtual machine and instantiate and initialize the tenant plugin includes: The tenant plugin is instantiated using the tenant plugin program instance in the obtained dynamic link library to create the corresponding tenant plugin; Start the virtual machine of the programming language corresponding to the tenant plugin; and Based on the obtained dynamic link library, execute the corresponding initialization code in the programming language virtual machine to initialize the tenant plugin.

5. The method as described in claim 1, wherein, The tenant plugin launch request includes at least two tenant plugin launch requests, and the at least two tenant plugin launch requests are combined into a single combined tenant plugin launch request for sending.

6. The method as described in any one of claims 1 to 5, further comprising: Based on the communication interface definition declared in the dynamic link library, an intra-process communication interface is created for the tenant plugin to communicate with other tenant plugins running in the same system process through the created intra-process communication interface.

7. A method for enabling intra-process communication between tenant plugins, comprising: Receive a first intra-process communication request from a first tenant plugin. The first intra-process communication request includes the tenant plugin identifier of a second tenant plugin that serves as the communication peer, as well as communication parameter information for intra-process communication. The communication parameter information includes a function call method and function call parameters. Based on the tenant plugin identifier of the second tenant plugin, the second tenant plugin is located in a centralized manner among the tenant plugins started in the same system process; The second intra-process communication request is sent to the located second tenant plugin. The second intra-process communication request includes the communication parameter information of the intra-process communication. The second tenant plugin calls the target function according to the function call method and the function call parameters to generate the response message of the intra-process communication. Receive the response message returned by the second tenant plugin; as well as The response message is sent to the first tenant plugin. Among them, when each tenant plugin in the tenant plugin set launched in the same system process is launched, it loads its own dynamic link library into the same system process within the isolated resource environment restricted by its respective resource control group, so as to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin, and each launched tenant plugin has a tenant plugin identifier.

8. The method of claim 7, wherein, The communication parameter information also includes a call identifier, and the response message is associated with the call context of the first in-process communication request in the first tenant plugin.

9. The method of claim 7, wherein, The first tenant plugin sends the first intra-process communication request and receives the response message through the first intra-process communication interface, and the second tenant plugin receives the second intra-process communication request and sends the response message through the second intra-process communication interface. The first intra-process communication interface and the second intra-process communication interface are created according to the communication interface definitions declared in their respective dynamic link libraries during the startup process of the first tenant plugin and the second tenant plugin, respectively.

10. The method as described in any one of claims 7 to 9, wherein, Each tenant plugin in the tenant plugin set launched in the same system process is launched in accordance with the method for launching a tenant plugin as described in any one of claims 1 to 5.

11. An apparatus for launching a tenant plugin, comprising: The request receiving unit receives a tenant plugin startup request from a client device. The tenant plugin startup request includes the programming language virtual machine type used by the tenant plugin and the storage path information of the dynamic link library corresponding to the tenant plugin. The library acquisition unit acquires the dynamic link library of the tenant plugin to be started based on the storage path information of the dynamic link library in the tenant plugin startup request. The dynamic link library includes a tenant plugin program instance and a programming language virtual machine. The resource control group creation unit creates a resource control group for the tenant plugin; The library loading unit loads the acquired dynamic link library into the current system process within the isolated resource environment restricted by the resource control group, so as to start the corresponding programming language virtual machine and realize the instantiation and initialization of the tenant plugin. as well as The response sending unit, in response to the completion of the tenant plugin initialization, sends a response message indicating that the tenant plugin has started successfully to the client device.

12. The apparatus of claim 11, wherein, The tenant plugin startup request also includes resource limitation information for the tenant plugin. The resource control group creation unit creates a resource control group for the tenant plugin based on the resource restriction information.

13. The apparatus of claim 11, wherein, The tenant plugin startup request also includes the tenant plugin identifier of the tenant plugin, and the device further includes: The identification association unit associates the created tenant plugin with the tenant plugin identifier of the tenant plugin.

14. The apparatus of claim 11, wherein, The library loading unit includes: The tenant plugin creation module instantiates the tenant plugin using the tenant plugin program instance in the obtained dynamic link library to create the corresponding tenant plugin. The virtual machine startup module starts the virtual machine for the programming language corresponding to the tenant plugin; and The initialization module executes corresponding initialization code in the programming language virtual machine based on the obtained dynamic link library to initialize the tenant plugin.

15. The apparatus of any one of claims 11 to 14, wherein the apparatus further comprises: The communication interface creation unit creates an intra-process communication interface for the tenant plugin based on the communication interface definition declared in the dynamic link library, so as to communicate with other tenant plugins running in the same system process through the created intra-process communication interface.

16. An apparatus for enabling intra-process communication between tenant plugins, comprising: The communication request receiving unit receives a first intra-process communication request from a first tenant plugin. The first intra-process communication request includes a tenant plugin identifier of a second tenant plugin that serves as the communication peer, as well as communication parameter information for intra-process communication. The communication parameter information includes a function call method and function call parameters. The tenant plugin location unit locates the second tenant plugin in a centralized manner among tenant plugins started in the same system process, based on the tenant plugin identifier of the second tenant plugin. The communication request sending unit sends a second intra-process communication request to the located second tenant plugin. The second intra-process communication request includes communication parameter information of the intra-process communication. The second tenant plugin calls the target function according to the function call method and the function call parameters to generate the response message of the intra-process communication. The response message receiving unit receives the response message returned by the second tenant plugin; as well as The response message sending unit sends the response message to the first tenant plugin. Among them, when each tenant plugin in the tenant plugin set launched in the same system process is launched, it loads its own dynamic link library into the same system process within the isolated resource environment restricted by its respective resource control group, so as to start its own programming language virtual machine and realize the instantiation and initialization of its own tenant plugin, and each launched tenant plugin has a tenant plugin identifier.

17. A tenant plug-in management device, comprising: The apparatus for launching a tenant plug-in as described in any one of claims 11 to 15; as well as The apparatus for enabling intra-process communication between tenant plugins as described in claim 16.

18. An apparatus for launching a tenant plugin, comprising: At least one processor, a memory coupled to the at least one processor, and a computer program stored on the memory, wherein the at least one processor executes the computer program to implement the method for launching a tenant plugin as described in any one of claims 1 to 6.

19. An apparatus for enabling intra-process communication between tenant plugins, comprising: At least one processor, a memory coupled to the at least one processor, and a computer program stored on the memory, wherein the at least one processor executes the computer program to implement the method for enabling in-process communication between tenant plug-ins as described in any one of claims 7 to 10.

20. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for launching a tenant plugin as described in any one of claims 1 to 6, or the method for enabling intra-process communication between tenant plugins as described in any one of claims 7 to 10.

21. A computer program product comprising a computer program executed by a processor to implement the method for launching a tenant plugin as described in any one of claims 1 to 6, or the method for enabling intra-process communication between tenant plugins as described in any one of claims 7 to 10.

Images