CN111737032B

CN111737032B - Subprogram running method and device based on microkernel system and electronic equipment

Info

Publication number: CN111737032B
Application number: CN202010730270.3A
Authority: CN
Inventors: 詹海亮
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2020-07-27
Filing date: 2020-07-27
Publication date: 2020-11-20
Anticipated expiration: 2040-07-27
Also published as: CN111737032A

Abstract

The application discloses a subprogram running method and device based on a microkernel system and electronic equipment; the method relates to routing forwarding in the field of computer networks, and can acquire a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system; loading a target subprogram based on the front-end access path information in the subprogram calling request; calling a target subprogram, determining access information of a target post-subprogram corresponding to the target subprogram in a server, and sending a service processing request aiming at the target post-subprogram to the server; receiving service processing result information sent by a server; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram. According to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

Description

Subprogram running method and device based on microkernel system and electronic equipment

Technical Field

The application relates to the technical field of computers, in particular to a method and a device for running a subprogram based on a microkernel system and electronic equipment.

Background

Traditional network (Web) applications generally adopt a single application architecture, and developers develop functional characteristics of a view layer and a business logic layer. The single application refers to an application program in which one archive package contains all functions of the application.

However, with the increasing application demand, the code of the application program also increases rapidly, the maintainability and flexibility of the single application are gradually reduced, the maintenance cost is higher and higher, and for the single application, the application code cannot be reused among different systems.

Disclosure of Invention

The embodiment of the application provides a sub-program running method and device based on a microkernel system and electronic equipment, so that code isolation among application programs can be realized, the coupling degree among the application programs is reduced, and the development efficiency of the application system is improved.

The embodiment of the application provides a subprogram running method based on a microkernel system, which comprises the following steps:

acquiring a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system, wherein the subprogram calling request comprises front-end access path information of the target subprogram;

loading the target subprogram based on the front-end access path information in the subprogram calling request through the front-end system management module;

calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server;

sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, wherein the service processing request comprises access information of the target back-end sub-program;

receiving service processing result information which is sent by the server and responds to the service processing request;

and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page.

The embodiment of the application provides another subprogram running method based on a microkernel system, which comprises the following steps:

receiving a service processing request sent by a terminal, wherein the service processing request comprises access information of a target post-terminal program, and the service processing request is derived from a corresponding target subprogram of the target post-terminal program in the terminal;

determining, by a back-end system management module of a microkernel system, back-end access path information of the target back-end subprogram based on the access information in the service processing request;

sending, by the backend system management module, the service processing request to the target backend terminal program based on the backend access path information;

processing the service processing request through the target rear terminal program to obtain service processing result information;

and sending the service processing result information to the target subprogram in the terminal.

Correspondingly, an embodiment of the present application provides a subroutine running apparatus based on a microkernel system, including:

the system comprises an acquisition unit, a processing unit and a processing unit, wherein the acquisition unit is used for acquiring a subprogram calling request of a target subprogram aiming at a front-end host through a front-end system management module of a microkernel system, and the subprogram calling request comprises front-end access path information of the target subprogram;

the loading unit is used for loading the target subprogram based on the front-end access path information in the subprogram calling request through the front-end system management module;

the first determining unit is used for calling the target subprogram and determining the access information of the target post-subprogram corresponding to the target subprogram in the server;

a first sending unit, configured to send, to the server through the target sub-program, a service processing request for the target back-end sub-program, where the service processing request includes access information of the target back-end sub-program;

a first receiving unit, configured to receive service processing result information sent by the server and responding to the service processing request;

and the first processing unit is used for processing the service processing result information based on the target subprogram, obtaining an application page of the target subprogram and displaying the application page.

Correspondingly, an embodiment of the present application provides another apparatus for running a subroutine based on a microkernel system, including:

a second receiving unit, configured to receive a service processing request sent by a terminal, where the service processing request includes access information of a target back-end terminal program, and the service processing request is derived from a target subprogram corresponding to the target back-end terminal program in the terminal;

a second determining unit, configured to determine, by a back-end system management module of the microkernel system, back-end access path information of the target back-end subprogram based on the access information in the service processing request;

a second sending unit, configured to send, by the backend system management module, the service processing request to the target backend terminal program based on the backend access path information;

the second processing unit is used for processing the service processing request through the target rear terminal program to obtain service processing result information;

and a third sending unit, configured to send the service processing result information to the target subprogram in the terminal.

Optionally, in some embodiments of the present application, the microkernel system-based subroutine running apparatus further includes a first registration unit, where the first registration unit is used for registering a target subroutine in the microkernel system; the first registration unit comprises a first obtaining subunit, a first declaration subunit and a first configuration subunit, and the following steps are performed:

the first acquiring subunit is configured to acquire a front-end configuration file of a target subprogram to be registered, where the front-end configuration file includes a front-end subprogram identifier of the target subprogram;

the first declaration subunit is configured to perform declaration processing on the front-end configuration file through the front-end application management module to obtain a front-end declaration back file, where the front-end declaration back file includes dependency information of the target subprogram and the front-end system management module, and an access information mapping relationship between the target subprogram and a corresponding target back-end subprogram in a server, where the access information mapping relationship includes a communication interface mapping relationship between the target subprogram and the target back-end subprogram;

and the first configuration subunit is configured, by the front-end application management module, to configure a routing component of the target subprogram based on the dependency information, the access information mapping relationship, and the front-end subprogram identifier in the front-end declared file, so as to complete registration of the target subprogram in the microkernel system.

Optionally, in some embodiments of the present application, the sub-program running apparatus based on a microkernel system further includes a second registration unit, where the second registration unit is used for registering a target backend program in the microkernel system; the second registration unit may include a second acquisition subunit, a second declaration subunit, a setup subunit, and a second configuration subunit, as follows:

the second acquiring subunit is configured to acquire a back-end configuration file corresponding to a target back-end sub-program to be registered, where the back-end configuration file includes a back-end sub-program identifier and access information of the target back-end sub-program;

the second declaration subunit is configured to perform declaration processing on the backend configuration file through the backend application management module to obtain a backend declaration backend file, where the backend declaration backend file includes dependency information of the target backend terminal program and a backend system management module, and the dependency information includes call interface information that the target backend terminal program opens to the backend system management module;

the establishing subunit is used for establishing a routing node mapping relationship among the calling interface information of the target back terminal program, the back terminal program identifier and the access information through the back terminal application management module;

and a second configuration subunit, configured to configure, by the backend application management module, a routing component of the target backend application based on the routing node mapping relationship, so as to complete registration of the target backend application in the microkernel system, where the routing component is used for information interaction between the target backend application and a terminal.

The electronic device provided by the embodiment of the application comprises a processor and a memory, wherein the memory stores a plurality of instructions, and the processor loads the instructions to execute the steps in the method for running the subprogram based on the microkernel system provided by the embodiment of the application.

In addition, a storage medium is further provided, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps in the execution of the sub-program based on the microkernel system provided in the embodiments of the present application.

The embodiment of the application provides a subprogram running method, a subprogram running device and electronic equipment based on a microkernel system, wherein a subprogram calling request aiming at a target subprogram of a front-end host can be obtained through a front-end system management module of the microkernel system, and the subprogram calling request comprises front-end access path information of the target subprogram; loading the target subprogram based on the front-end access path information in the subprogram calling request through the front-end system management module; calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server; sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, wherein the service processing request comprises access information of the target back-end sub-program; receiving service processing result information which is sent by the server and responds to the service processing request; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page. According to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1a is a schematic view of a scenario of a method for running a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 1b is a flowchart of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

fig. 1c is a directory structure diagram of a method for operating a sub program based on a microkernel system according to an embodiment of the present application;

FIG. 2a is another flowchart of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 2b is another directory structure diagram of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 2c is a schematic diagram illustrating an architecture of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 2d is a schematic page diagram illustrating a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 2e is another schematic diagram of an architecture of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 2f is another flowchart of a method for operating a sub-program based on a microkernel system according to an embodiment of the present application;

FIG. 3a is a schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3b is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3c is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3d is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3e is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3f is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3g is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3h is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

FIG. 3i is another schematic structural diagram of a sub-program running apparatus based on a microkernel system according to an embodiment of the present application;

fig. 4 is a schematic structural diagram of an electronic device provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The embodiment of the application provides a subprogram running method and device based on a microkernel system and electronic equipment.

Specifically, the present embodiment provides a sub-program running apparatus (for differentiation, may be referred to as a first sub-program running apparatus) based on a microkernel system, which is suitable for a first electronic device, where the first electronic device may be a terminal or other device. The embodiment of the present application further provides a sub-program running device (for distinction, may be referred to as a second sub-program running device) based on a microkernel system, which is suitable for a second electronic device, where the second electronic device may be a network side device such as a server.

For example, the first sub-program execution means may be integrated in the terminal. The terminal may be a mobile phone, a tablet Computer, a notebook Computer, a desktop Computer, a Personal Computer (PC), or the like, but is not limited thereto. The second sub-program execution means may be integrated in the server. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as cloud service, a cloud database, cloud computing, a cloud function, cloud storage, Network service, cloud communication, middleware service, domain name service, security service, Content Delivery Network (CDN), big data and an artificial intelligence platform. The terminal and the server may be directly or indirectly connected through wired or wireless communication, and the application is not limited herein.

In the embodiment of the application, a method for operating a subroutine based on a microkernel system is described by taking a first electronic device as a terminal and a second electronic device as a server as an example.

As shown in fig. 1a, the embodiment of the present application provides a sub-program running system based on a microkernel system, where the system includes a terminal 10 and a server 11, and the terminal 10 and the server 11 are connected through a network, for example, a wireless network connection. Among them, the terminal 10 may have a client integrated therein.

The terminal 10 may be configured to obtain, by a front-end system management module of the microkernel system, a subprogram call request for a target subprogram of a front-end host, where the subprogram call request includes front-end access path information of the target subprogram; loading the target subprogram based on front-end access path information in the subprogram calling request through the front-end system management module; calling a target subprogram, and determining access information of a target post-subprogram corresponding to the target subprogram in the server 11; sending a service processing request aiming at the target back-end sub-program to the server 11 through the target sub-program, wherein the service processing request comprises access information of the target back-end sub-program; receiving service processing result information sent by the server 11 in response to the service processing request; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page.

The server 11 may be configured to receive a service processing request sent by the terminal 10, where the service processing request includes access information of a target back-end terminal program, and the service processing request is derived from a target subprogram corresponding to the target back-end terminal program in the terminal 10; determining, by a back-end system management module of a microkernel system, back-end access path information of the target back-end subprogram based on the access information in the service processing request; sending, by the backend system management module, the service processing request to the target backend terminal program based on the backend access path information; processing the service processing request through the target rear terminal program to obtain service processing result information; and sending the service processing result information to the target subprogram in the terminal 10.

In this embodiment, information transmission between the terminal and the server may be implemented through some communication networks, and the types and the systems of the communication networks are not limited.

The subprogram running method based on the microkernel system provided by the embodiment of the application relates to the field of Cloud technology.

The Cloud technology (Cloud technology) is a hosting technology for unifying series resources such as hardware, software, network and the like in a wide area network or a local area network to realize calculation, storage, processing and sharing of data. The cloud technology is a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied based on a cloud computing business model, can form a resource pool, is used as required, and is flexible and convenient. Cloud computing technology will become an important support. Background services of the technical network system require a large amount of computing and storage resources, such as video websites, picture-like websites and more web portals. With the high development and application of the internet industry, each article may have its own identification mark and needs to be transmitted to a background system for logic processing, data in different levels are processed separately, and various industrial data need strong system background support and can only be realized through cloud computing.

The following are detailed below. It should be noted that the following description of the embodiments is not intended to limit the preferred order of the embodiments.

The present embodiment will be described from the perspective of a first sub-program execution device, which may be specifically integrated in a terminal. The subprogram running method based on the microkernel system can be applied to various scenes in which the application program needs to be plugged, such as scenes in which product application is modularized.

The embodiment of the present application provides a method for running a subroutine based on a microkernel system, and as shown in fig. 1b, the specific process of the method for running a subroutine based on a microkernel system may be as follows:

101. acquiring a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system, wherein the subprogram calling request comprises front-end access path information of the target subprogram.

A micro kernel is an operating system kernel that can provide necessary services, such as tasks, threads, inter-process communication, and memory management. The microkernel architecture mode, also known as plug-in architecture mode, is a natural mode for implementing product-based applications. Product-based applications are packaged and have different versions, downloadable as third-party plug-ins. Microkernel systems allow users to add additional applications, such as plug-ins, to the core application, which in turn provides extensibility and use of functionality separation. By means of plug-in of the application program, functions of continuous expansion can be dispersed in the plug-in, logic is maintained in a centralized mode inside the plug-in, the data are similar to database transverse expansion, the structure is unchanged, and data are split.

The microkernel system of this embodiment is improved on the basis of the existing microkernel system, and the microkernel system of this embodiment includes a front-end (i.e. terminal or Client) system and a back-end (server) system, and optionally, at the front end, the microkernel system includes: a front-end System management module (which may also be understood as a Client System Layer (CSL) in the following examples) and a front-end Application management module (which may also be understood as a Client Application Layer (CAL) in the following examples).

Wherein, the front-end system management module is responsible for: maintaining the application capability of the Client system; specifically, the method can support the user equipment including an integrated React application capability plug-umi-plug-React, a sub-application loading routing capability plug-umi-plug-adaptor and the like. The front-end system management module may include a sub-application routing load management sub-module, and the sub-application routing load management sub-module may support a sub-application loading routing capability plug-in-plug loader, and may be specifically configured to load a routing component of a target sub-program.

Wherein, the front terminal application management module is responsible for: and developing and maintaining the business function characteristics of the Client sub-application layer.

Optionally, in some embodiments, the subprogram call request may be specifically generated based on a trigger operation of a user on a function page of the front-end host, and the front-end host program may send the subprogram call request to a front-end system management module of the microkernel system; and loading the target subprogram through the front-end system management module based on the front-end access path information in the subprogram calling request. Further, in a computer environment, a software environment in which software lives is referred to as a host program. In some embodiments, the front-end system management module of the microkernel system may also be understood to be part of the front-end host.

Specifically, the function page of the front-end host includes an entry corresponding to the target subprogram, and the entry may exist in the form of an icon, a control, and the like, which is not limited in this embodiment. Optionally, the triggering of the subprogram call request may be implemented by an operation on an entry corresponding to the target subprogram, and when the front-end host program detects a triggering operation on the entry in the function page, the subprogram call request for the target subprogram may be generated based on information of the target subprogram known per se.

In an example, optionally, when the front-end host is a browser, if the front-end host program detects a trigger operation for the entry in the function page, the front-end access path information may be displayed in an address bar of the browser as a URL. Optionally, the front-end access path information may be added to the displayed address in the address bar for display, a subprogram call request is generated based on the front-end access path information, and the subprogram call request is sent to the front-end system management module of the microkernel system.

In another example, when the front-end host is a browser, the user may obtain the application page of the target sub-program by inputting front-end access path information in an address bar of the browser. Optionally, when the front-end host program detects an input operation of a user in an address bar of the browser, if the format of the address information input by the user is the format of the front-end access path information, the front-end host program obtains the front-end access path information according to the address information input by the user, and generates a subprogram call request based on the front-end access path information.

The target sub program, i.e. the Client sub application, may be regarded as a plug-in program of the host program (front-end host). Both the front-end host and the target subprogram are deployed in the terminal. The embodiment can realize code isolation among application programs through a plug-in architecture mode, and reduce the coupling degree of the application programs.

Optionally, in some embodiments, the microkernel system further includes a front-end application management module, and before the step "obtaining, by the front-end system management module of the microkernel system, a subroutine call request for a target subroutine of a front-end host", the method may further include:

acquiring a front-end configuration file of a target subprogram to be registered, wherein the front-end configuration file comprises a front subprogram identifier of the target subprogram;

performing declaration processing on the front-end configuration file through the front-end application management module to obtain a front-end declared file, wherein the front-end declared file comprises dependency information of the target subprogram and a front-end system management module and an access information mapping relation between the target subprogram and a corresponding target back-end subprogram in a server, and the access information mapping relation comprises a communication interface mapping relation between the target subprogram and the target back-end subprogram;

and configuring a routing component of the target subprogram through the front terminal application management module based on the dependency information, the access information mapping relation and the front terminal program identifier in the file after the front end declaration so as to complete the registration of the target subprogram in the microkernel system.

The dependency information of the target subprogram and the front-end system management module may include calling interface information that the target subprogram opens to the front-end system management module, and specifically may be information of an interface used by the front-end system management module (front-end host program) or other front-end subprograms in the terminal to call the subprogram. After the front-end system management module analyzes the access address of the user (i.e. the front-end access path information), a front-end subprogram identifier can be obtained, and the target subprogram can be called or loaded based on the calling interface information of the target subprogram corresponding to the front-end subprogram identifier.

The declaration processing on the front-end configuration file may specifically include declarations of common components, service interfaces, data models, and the like of the target subprogram.

After the routing component of the target subprogram is configured, the access information of the target back-end subprogram corresponding to the target subprogram may be obtained based on the access information mapping relationship in the routing component, where the access information may be a Command Prompt (cmd, Command Prompt), and specifically may be a routing interface of the target back-end subprogram, and based on the access information, the target subprogram may route the service processing request to the routing interface { cmd } of the target back-end subprogram.

In this embodiment, the front-end application management module may be configured to declare the front-end configuration file. Specifically, the front-end application management module may include a front-end declaration sub-module, a front-end routing configuration sub-module, a front-end data model management sub-module, an interface mapping management sub-module, and a component configuration sub-module.

The front-end declaration sub-module may be configured to implement connection between the target sub-program and the front-end system management module, where the connection specifically includes declaration of a sub-application identifier (i.e., front-end sub-program identifier), a dependency declaration for the front-end system management module, a dependency declaration for global, a dependency declaration for other sub-applications, and a method of exposing itself to other applications. Wherein, the dependency declaration on the global state may include: a dependency declaration for the front-end host.

The front-end routing configuration submodule is responsible for: and developing and maintaining the service function of the routing component of the target subprogram.

Wherein, the front-end data model management submodule is responsible for: the maintenance of the data model of the target subprogram can specifically support the data model calling modes such as dva and read Hook.

The interface mapping management submodule can be used for declaring the service interface dependence of the target subprogram, encapsulating a Client request interface method and mapping the target subprogram and the target post-terminal program routing interface one by one.

The component configuration submodule can be used for declaring dependent components of the target subprogram and encapsulating common components in the application.

Alternatively, the structure of the file after the front-end declaration of the target sub-program may be a default directory organization structure. Agreed Client sub-application directory organization structure as shown in fig. 1c, an application namespace (AppNamespace) may be identified for the front-end sub-program of the target sub-program. The meaning of the file directory declaration after the front declaration in fig. 1c is as follows:

under the common component (components) directory of the sub-application, the dependent component of the target sub-program is declared, the common component in the application is encapsulated, and the exposed object is a read.

Under the directory of service interfaces (services) of the sub-applications, the service interface dependence of a target sub-program (namely, Client sub-application) is declared, a Client request interface method is encapsulated, and a one-to-one mapping relation is maintained with a routing interface of a target back-end sub-program (namely, Server sub-application), namely, an access information mapping relation between the target sub-program and the corresponding target back-end sub-program in a Server is declared (the part can be executed through an interface mapping management sub-module);

under the directory of data models (models) of the sub-applications, a data stream scheme of a target sub-program is declared, and two data stream object schemes of dva models and read hooks are supported. The dva model data stream model manages models of a field through a model concept, and comprises reducers of synchronous update states (states), effects of processing asynchronous logic, and subscriptions of data sources (the parts can be executed through a front-end data model management submodule);

under the directory of a routing component (router component. js) of the sub-application, the configuration entry component as router.

Under the directory of a declaration file (index. js) of the sub-application, calling interface information of the target sub-program is declared, connection between the target sub-program and a Client system layer is achieved, wherein front-end sub-program identification, dependency declarations of the global system, dependency declarations of other sub-applications and methods of the sub-program exposed to other applications are declared (the part can be executed through a front-end declaration sub-module).

Wherein, React is a JavaScript library for constructing a user interface.

The dva is a data flow scheme based on reduce and reduce-saga, and in order to simplify the development experience, the dva additionally embeds read-Router and fetch, so that the dva can also be understood as a lightweight application framework.

The React Hooks mainly solve the problem of state logic multiplexing of React components, are a state sharing scheme and cannot generate the problem of JSX nested jails. JSX is a JavaScript syntax extension applied to the React framework. An element is the smallest unit that constitutes the React application, JSX is the element used to declare the React, which uses JSX to describe the user interface.

102. And loading the target subprogram based on the front-end access path information in the subprogram calling request through the front-end system management module.

The subroutine call request may be specifically generated based on a user trigger operation on a function page of the front-end host program, and may include a request address (i.e., front-end access path information). The front-end access path information may be a network address or may be referred to as a Uniform Resource Locator (URL). In the network, each information resource has a uniform and unique address on the network.

Optionally, in this embodiment, the target subprogram, that is, the loading manner of the Client sub application, may be implemented based on multiple front-end application frameworks, for example, implemented by front-end frameworks such as Umi, fact, Vue, and Angular.

Umi is an extensible enterprise-level front-end application framework. Umi, it is based on route, and supports configuration type route and constraint type route, and ensures the complete function of route, and expands the function; and a plug-in system with perfect life cycle is matched to cover each life cycle from a source code to a constructed product, and various function expansion and service requirements are supported.

Wherein, React is a JavaScript library for constructing a user interface. The fact may transfer various types of parameters, such as declaration code, rendering Interface (UI), a HyperText Markup Language (HTML) Document Object Model (DOM) element that may be static, a dynamic variable, and even an interactive application component. The JavaScript is an transliterated script language, is a dynamic type, weak type, prototype-based language, and is internally provided with a support type. Its interpreter, called JavaScript engine, is a part of the browser, widely used in the scripting language of the client, and was originally used on the HTML web page to add dynamic functionality to the HTML web page.

Vue is a set of progressive frameworks for building user interfaces. Unlike other large frames, Vue is designed to be applied layer by layer from the bottom up. Vue, which focuses only on the viewing layer, is easy to handle, and also facilitates integration with third party libraries or existing projects. On the other hand, Vue is also fully capable of providing drivers for complex single page applications when used in conjunction with modern tool chains and various supporting class libraries.

Among them, Angular is a development platform. The Angular declarative templates, dependent injection, end-to-end tools and some best practices are integrated, and the Web (network) application can be built more easily.

Optionally, in some embodiments, the front-end system management module includes a sub-application route loading management sub-module; the step of loading, by the front-end system management module, the target subprogram based on the front-end access path information in the subprogram call request may include:

and loading the routing component of the target subprogram based on the front-end access path information in the subprogram calling request through the subprogram routing loading management submodule.

Specifically, the sub-application route loading management sub-module can analyze the front-end access path information through a real-Router route analysis function built in the umi, and determine a Router Component in the target sub-program.

Optionally, in some embodiments, the front-end access path information includes a front-end subprogram identifier and a routing component identifier of the target subprogram; the step of loading, by the sub-application routing load management sub-module, the routing component of the target sub-program based on the front-end access path information in the sub-program call request may include:

analyzing the front-end access path information in the subprogram calling request through the subprogram routing loading management submodule to obtain a front-end subprogram identifier and a routing component identifier of the target subprogram;

determining a routing component of the target subprogram based on the front subprogram identification and the routing component identification;

and loading the routing component of the target subprogram.

In other embodiments, the front-end access path information may further include a front-end host identification of the front-end host program. Analyzing the front-end access path information to obtain a front-end host identifier, a front-end subprogram identifier and a routing component identifier; the front-end host program may be determined based on the front-end host identifier, and then the target subprogram may be determined based on the front-end subprogram identifier, thereby determining the routing component of the target subprogram.

For example, in a specific embodiment, the front-end access path information may be/app/{ AppNamespace }/routercompent, where app is the front-end host identifier, AppNamespace is the front-end subprogram identifier, and routercompent is the routing component identifier. When the user accesses url address path/app/{ AppNamespace }/RouteR computer, the route can be analyzed to the route component RouteR computer in the target sub-program corresponding to the front sub-program identification through the route analysis function of the Client system layer.

103. And calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server.

Optionally, in some embodiments, the step of "calling the target subprogram, and determining access information of a target post-subprogram corresponding to the target subprogram in the server" may include:

and calling the routing component, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server.

Specifically, the access information of the target post-subprogram corresponding to the target subprogram in the server may be determined through the access information mapping relationship in the routing component.

and determining the access information of the target post-terminal program corresponding to the target subprogram in the server according to the access information mapping relation in the target subprogram.

In the registration stage of the target subprogram, the interface mapping management submodule declares an access information mapping relationship between the target subprogram and the target post-terminal program, wherein the access information mapping relationship comprises a communication interface mapping relationship between the target subprogram and the target post-terminal program. Specifically, the access information mapping relationship includes access information of the target back-end sub-program, and the access information is specifically a routing interface of the target back-end sub-program. The target subprogram can determine the target post-subprogram corresponding to the target subprogram in the server through the access information.

104. And sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, wherein the service processing request comprises the access information of the target back-end sub-program.

In some embodiments, after the service processing request is sent to the Server, the route interface { cmd } of the target back-end sub-terminal program may be called by an appRequest method, and the Server system layer may route the interface request to the route interface { cmd } of the corresponding target back-end sub-terminal program, so as to execute a back-end service logic call by the target back-end sub-terminal program.

Specifically, the data request method in the application can automatically route and call the target back-end terminal program through a request method appRequest exposed by umi-plugin-adaptor (child application load routing capability plug-in), and automatically route to the routing interface of the target back-end terminal program. That is, when a { cmd } route is requested in an application, a back-end system management module (Server system layer) of the microkernel system can automatically assemble a request path as/api/{ AppNamespace }/{ cmd }, so that the request is routed to a Server sub-application routing interface { cmd }.

The implementation principle of the appRequest is to implement interception of a request object based on umi-request.

The umi-request is a network request library based on fetch encapsulation, has the characteristics of fetch and axios (axes), aims to provide a uniform api calling mode for developers, simplifies the use, and provides common functions such as caching, overtime, character coding processing, error processing and the like. Catch is a form of HTTP data request. axios is a premium-based HTTP library that can be used in browsers and nodes. A promise is an object that represents the eventual completion or failure of an asynchronous operation.

Optionally, in some embodiments, the step "sending, by the target sub-program, a service processing request for the target back-end sub-program to the server" may include:

and sending a service processing request aiming at the target post-terminal program to the server through the routing component.

Wherein the routing component can be used for forwarding of data information.

Optionally, in some embodiments, the service processing request may be directly sent to the target backend terminal program through the target subprogram, and does not need to be indirectly sent to the target backend terminal program through a backend system management module of the microkernel system.

105. And receiving service processing result information which is sent by the server and responds to the service processing request.

In some embodiments, the service processing result information may include identification information of the target sub-program. When a front-end system management module of the microkernel system receives service processing result information sent by the server, the service processing result information can be analyzed to obtain identification information of a target subprogram; and sending the service processing result information to the target subprogram based on the identification information.

106. And processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page.

Optionally, in some embodiments, after the step "processing the service processing result information based on the target subprogram, to obtain an application page of the target subprogram, and displaying the application page", the method may further include:

when detecting a data acquisition operation aiming at the application page, sending a data request corresponding to the data acquisition operation to a server through the routing component, wherein the data request comprises access information of the target post-terminal program;

receiving response data information sent by the server in response to the data request;

and updating the application page based on the response data information.

The data obtaining operation may be an operation of clicking an application page or submitting a form, and the like, which is not limited in this embodiment. And the server routes the data request to a corresponding target post-terminal program routing interface based on the access information of the target post-terminal program in the data request, and returns response data information generated by the target post-terminal program to the target sub-application so as to enable the terminal to re-render the application page based on the response data information.

when the switching operation aiming at the target subprogram is detected, unloading the target subprogram through the front-end system management module;

acquiring a new subprogram calling request, wherein the new subprogram calling request comprises front-end access path information of a new target subprogram, and loading the new target subprogram based on the front-end access path information in the new subprogram calling request through the front-end system management module;

and taking the new target subprogram as a new target subprogram, executing the step of calling the target subprogram, and determining the access information of the target subprogram in the server corresponding to the target subprogram so as to display the application page of the new target subprogram.

The switching operation may be set according to actual conditions, which is not limited in this embodiment. Specifically, the user switches the target sub-program, the Client system layer unloads the currently running target sub-application, then switches to the new target sub-application, and repeats the steps of loading the new target sub-application and rendering the corresponding application page.

Optionally, in this embodiment, in order to avoid that the rendering duration of the application page is too long, two-layer rendering may be performed on the application page, that is, after the target subprogram is loaded, the page is primarily rendered, and after the service processing result information is received, the application page is rendered again, where the specific method is described below.

Optionally, in some embodiments, after the step "loading, by the front-end system management module, the target subroutine based on the front-end access path information in the subroutine call request", the method may further include:

determining basic page elements needing to be rendered through a preset application page model of the target subprogram;

rendering an initial application page according to the basic page elements;

the processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page, including:

and rendering the initial application page based on the service processing result information through the target subprogram to obtain an application page of the target subprogram, and displaying the application page.

The initial application page can be rendered by the routing Component, calling the hook function, and executing the Component rendering method React Component render (rendering function). And after the target subprogram receives the service processing result information, triggering the React Component state change hook method, and calling the React Component render method again to finish the rendering task of the application page.

The hook function (i.e., hook function) refers to a code segment inserted after the program is started, so that the program runs a newly added code to obtain information when the target function runs.

Optionally, in some embodiments, after the initial application page is rendered according to the base page elements, the initial application page may also be displayed.

As can be seen from the above, in this embodiment, a front-end system management module of a microkernel system may be used to obtain a subprogram call request for a target subprogram of a front-end host, where the subprogram call request includes front-end access path information of the target subprogram; loading the target subprogram based on the front-end access path information in the subprogram calling request through the front-end system management module; calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server; sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, wherein the service processing request comprises access information of the target back-end sub-program; receiving service processing result information which is sent by the server and responds to the service processing request; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page. According to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

The present embodiment will be described from the perspective of a second sub-program execution device, which may be specifically integrated in a server, and the server may be specifically a cloud server or the like.

An embodiment of the present application provides a method for running a subroutine based on a microkernel system, and as shown in fig. 2a, a specific process of the method for running a subroutine based on a microkernel system may be as follows:

201. receiving a service processing request sent by a terminal, wherein the service processing request comprises access information of a target post-terminal program, and the service processing request is derived from a target subprogram corresponding to the target post-terminal program in the terminal.

The microkernel system of this embodiment includes a front-end (i.e. terminal or Client) system and a back-end (Server) system, and optionally, at the back-end, the microkernel system includes: a backend System management module (which may also be understood as a Server System Layer (SSL) in the following example) and a backend Application management module (which may also be understood as a Server Application Layer (SAL) in the following example).

Wherein, the back-end system management module is responsible for: maintaining the capability of the application of the Server system; specifically, the support may include sub-application configuration model koa-config, data model koa-model, routing model capability koa-router, and sub-application loading capability koa-adaptor, among others. The back-end system management module may include a sub-application load management submodule, and the sub-application load management submodule may specifically support a sub-application load capability koa-applicator for loading the target back-end terminal program.

Wherein, the rear terminal application management module is responsible for: and developing and maintaining the service function characteristics of the Server sub-application.

In some embodiments, the backend system management module of the microkernel system may also be understood as part of the backend host program.

The back-end host is specifically an application program that provides existing services for the front-end host.

The target back-end sub-program, namely the Server sub-application, can be regarded as a plug-in program of the host program, and the back-end host and the target back-end sub-program are deployed in the Server.

Optionally, in some embodiments, the microkernel system further includes a backend application management module; before the step "receiving a service processing request sent by a terminal", the method may further include:

acquiring a back-end configuration file corresponding to a target back-end terminal program to be registered, wherein the back-end configuration file comprises a back-end terminal program identifier and access information of the target back-end terminal program;

declaring the backend configuration file through the backend application management module to obtain a backend declared file, wherein the backend declared file comprises dependency information of the target backend terminal program and a backend system management module, and the dependency information comprises calling interface information opened by the target backend terminal program to the backend system management module;

establishing a routing node mapping relation among the calling interface information of the target rear terminal program, the rear terminal program identification and the access information through the rear terminal application management module;

and configuring a routing component of the target back-end terminal program based on the routing node mapping relation through the back-end terminal application management module so as to complete the registration of the target back-end terminal program in the microkernel system, wherein the routing component is used for information interaction between the target back-end terminal program and a terminal.

The dependency information of the target backend terminal program and the backend system management module may include call interface information that the target backend terminal program opens to the backend system management module, and specifically may be information of an interface used by the backend system management module (backend host program) or other backend terminal programs in the server to call the subprogram.

The declaration processing on the backend configuration file may specifically include declarations of common dependencies, configuration items, data models, and the like of the target backend terminal (i.e., the Server sub-application).

In this embodiment, the backend application management module may be configured to declare the backend configuration file. Specifically, the backend application management module may include a backend declaration sub-module, a backend routing configuration sub-module, a backend data model management sub-module, a configuration item management sub-module, and a common dependency management sub-module.

The backend declaration sub-module may be configured to implement connection between the target backend sub-program and the backend system management module, where the connection specifically includes declaring a sub-application identifier (i.e., a backend sub-program identifier), a dependency declaration for the backend system management module, a dependency declaration for the global system, a dependency declaration for other sub-applications, and a method of exposing itself to other applications. Wherein, the dependency declaration on the global state may include: a dependency declaration for a back-end host.

Wherein, the back-end route configuration sub-module is responsible for: and developing and maintaining the routing interface function of the target post terminal program.

Wherein, the back-end data model management submodule is responsible for: development and maintenance of a server data model of the target back terminal program, and declaration of a data model scheme of the target back terminal program can be specifically realized by supporting MySQL data source reading through koa-model by default.

The configuration item management submodule can be used for declaring the configuration items of the target post-terminal program.

Wherein, the common dependency management submodule can be used for declaring the common dependency of the target post-terminal program.

Optionally, the backend declaration file of the target backend terminal program may be an agreed directory organization. As shown in FIG. 2b, an application namespace (AppNamespace) may be the backend program identifier of the target backend program. The meaning of the back-end declaration in FIG. 2b is as follows:

under the catalogue of common dependency (libs, library file) of the sub-application, the common dependency of the target post-terminal program is declared (the part can be executed by the common dependency management submodule);

under the public configuration (configs) directory of the sub-application, the configuration item of the target post-sub-program is declared, and the exposed object is JS (JavaScript) object literal volume (the part can be executed by the configuration item management sub-module);

under the directory of data models (models) of the sub-applications, a data model scheme of a target back-end sub-terminal program is declared, calling of MySQL data sources and other database sources can be realized based on knex, an exposed object is a JS object literal quantity, and a data calling method is returned (the part can be executed through a back-end data model management submodule);

under the interface route (routes) directory of the sub-application, a configuration route component serving as a target post-terminal program is declared, the interface logic of the target post-terminal program is realized, and an exposed object is @ koa/router instance (the part can be executed through a back-end route configuration submodule);

under the directory of a declaration file (index. js) of the sub-application, calling interface information of the target post-terminal program is declared, connection between the target post-terminal program and a Server system layer is realized, wherein a sub-application identifier, a dependency declaration of the global, dependency declarations of other sub-applications and methods of exposing the sub-application to other applications are declared (the part can be executed by a post-terminal application management module).

The @ koa/router is a commonly used routing library koa, and is responsible for defining and loading application routing.

Js is a Structured Query Language (SQL) Query generator, which is intended to be flexible, portable, and easy to use. Js callback function separation mode in the traditional node, async (asynchronous communication) flow control calling mode in the modern time, query and mode generator with complete functions, transaction support (with save points savepoints), connection pool and standardized response capability between different query clients and dialects.

MySQL is a Relational Database Management System, and is one of the best Relational Database Management System (RDBMS) application software in terms of Web application.

Optionally, in this embodiment, the target backend terminal program, that is, the loading manner of the Server sub-application, may be implemented based on multiple Server application frameworks, for example, implemented by Server frameworks such as Koa, egg.

Koa is a new Web server Application framework, and is aimed at becoming a smaller, more expressive, and more robust foundation in the field of Web Application and Application Programming Interface (API) development. By utilizing the async (asynchronous communication) function, Koa discards the callback function and strongly enhances error handling. Koa do not bind any middleware and can write server applications quickly.

The egg.js is an enterprise-level framework and an application, is a node.js framework for solving the problem of enterprise-level development, can customize more upper-layer frameworks through the egg.js, and is used for helping development teams and developers to reduce development and maintenance cost. Js is an open source code and cross-platform JavaScript running environment capable of running JavaScript at a server side. Js can improve the performance based on technologies such as event-driven, non-blocking and asynchronous input and output models, and can optimize the transmission quantity and scale of an application program.

Js Web application development framework, which can provide a set of powerful functions for Web and mobile applications.

Hapi is an open-source node.js-based application framework, which is suitable for building applications and services, and the design goal is to let developers concentrate on developing reusable application business logic and provide the developers with the infrastructure needed to build application business logic.

Specifically, after declaring the Server sub-application directory organization structure, the sub-application load management sub-module of the back-end system management module may read the Server sub-application configuration list, automatically traverse to obtain the Server sub-application directory, load the Server sub-application declaration file, initialize the Server sub-application configuration, execute the Server sub-application hook function, and load the Server sub-application data model. And completing the registration process of loading the Server sub application routes interface through the appRouter (application route).

The appOuter may uniformly register the intra-application routing path { cmd } to the Server sub-application routing namespace/api/{ appNamespace }, or may establish a mapping relationship between the routing path { cmd } and/api/{ appNamespace }, thereby implementing isolation of the sub-application request namespaces.

In the registration process of the target back-end terminal program, loading a Server sub-application declaration file, initializing Server sub-application configuration, executing a Server sub-application hook function, and loading a Server sub-application data model, namely loading the target back-end terminal program. Specifically, the target post-terminal program can be loaded based on the koa-adaptor sub-application loading capability of the sub-application loading management sub-module.

The application can standardize the application declaration in an agreed mode, and according to the set of specifications, the independent application (sub-application) is realized, and the management of the life cycle of a single application is realized.

202. And determining the back-end access path information of the target back-end terminal program based on the access information in the service processing request through a back-end system management module of the microkernel system.

Optionally, in some embodiments, the step "determining, by a backend system management module of a microkernel system, backend access path information of the target backend subprogram based on the access information in the service processing request" may include:

acquiring the access information from the service processing request through a back-end system management module of a microkernel system;

acquiring a routing node mapping relation corresponding to the access information from the established routing node mapping relation;

and sequentially splicing the calling interface information, the back-end terminal program identifier and the access information in the routing node mapping relation corresponding to the access information to obtain back-end access path information of the target back-end terminal program.

In the registration stage of the target back-end terminal program, a back-end application management module establishes a routing node mapping relationship among the calling interface information of the target back-end terminal program, the back-end terminal program identifier and the access information, and the calling interface information corresponding to the access information and the back-end terminal program identifier can be obtained from the routing node mapping relationship through the back-end system management module and then sequentially spliced to obtain the back-end access path information of the target back-end terminal program.

In a specific embodiment, the calling interface information of the target backend terminal program is api, the backend terminal program is identified as AppNamespace, the access information is cmd, and the specific process of establishing the mapping relationship of the routing node through the backend terminal application management module may be: by the @ koa/router object using method of the backend application management module, the route path { cmd } in the application is uniformly registered to the Server sub-application (namely, the target backend application) route namespace/api/{ AppNamespace }. When the Server system layer receives the service processing request, the request path can be automatically assembled to be/api/{ AppNamespace }/{ cmd },/api/{ AppNamespace }/{ cmd } which is the back-end access path information of the target back-end terminal program based on the routing node mapping relation corresponding to the access information cmd in the service processing request, so that the service processing request is routed to the Server sub-application routing interface { cmd }.

203. And sending the service processing request to the target back-end terminal program through the back-end system management module based on the back-end access path information.

Optionally, in some embodiments, the service processing request may be preprocessed, and then the preprocessed service processing request is sent to the target backend terminal program by the backend system management module based on the backend access path information, where the preprocessing may be data format conversion or the like.

204. And processing the service processing request through the target rear terminal program to obtain service processing result information.

Optionally, in some embodiments, the step of processing the service processing request through the target backend terminal program to obtain service processing result information may include:

determining the identification information of the target subprogram corresponding to the target post-terminal program in the terminal through the target post-terminal program;

processing the service processing request through the target rear terminal program to obtain service information;

and fusing the service information and the identification information of the target subprogram to obtain service processing result information.

The fusion of the service information and the identification information of the target subprogram may be specifically realized by simply packaging the service information and the identification information of the target subprogram to obtain service processing result information. The fusion operation can be set according to actual conditions, and the embodiment does not limit the operation. The identification information of the target subprogram is similar to the access information of the target post-subprogram. The identification information of the target subprogram may specifically be a routing interface of the target subprogram. Based on the identification information, the target back-end sub-program may route the business process result information to a routing interface of the target sub-program.

205. And sending the service processing result information to the target subprogram in the terminal.

In some embodiments, the business process result information may include identification information of the target sub-program. After the terminal receives the service processing result information, the front-end system management module can analyze the service processing result information to obtain the identification information of the target subprogram; and sending the service processing result information to the target subprogram based on the identification information.

The development and maintenance of application systems of different hierarchies can be managed through the pluggable microkernel application system. For example, the present application may be applied to a product application modularization solution in a security operation center, and fig. 2c is an overall system application hierarchical architecture diagram, where each module may correspond to a plug-in, i.e., a sub-application, and hierarchical management may be implemented by modularizing product applications in security operation.

Specifically, when the user accesses the dashboard (sub-application) address (i.e., the front-end access path information) through the browser address bar, the dashboard Client sub-application routing component can be automatically routed and searched through the micro-kernel application system, and the dashboard Server sub-application routing interface is called to obtain the service processing result information, so as to complete component rendering of the dashboard sub-application, as shown in fig. 2 d.

The method and the device can expand the plug-in capability of the single application architecture based on the microkernel application system, realize the pluggable application plug-in system, and further realize the capability of independent development, test and deployment of the application service of the sub-application system based on the design mode of the micro front-end architecture.

The micro front end is an architecture similar to micro service, and the micro front end architecture design mode applies the concept of micro service to the browser end, namely, Web application is changed from single application to application of integrating multiple small front end applications. Each front-end application can also run independently, be developed independently and be deployed independently.

According to the method described in the previous embodiment, the following describes a sub-program running device based on a microkernel system, with Umi as a front-end application framework and Koa as a server-end application framework.

The microkernel application system may be composed of 4 layered modules, which are a Client system layer, a Client application layer, a Server system layer, and a Server application layer, as shown in fig. 2e, where "dashboard", "report", and "security intelligence" are the respective modules of the host program, and each module may correspond to a plug-in, i.e., a sub-application, and the specific description is as follows:

a Client System Layer (CSL) responsible for capability maintenance of Client System applications, and supports including an integrated read application capability plugin (umi-plug-return) and a sub-application loading routing capability plugin (umi-plug-adapter), see fig. 2e, where a plugin set may be umi-plug-return.

A Client Application Layer (CAL for short) responsible for the development and maintenance of the business function characteristics of the Client sub-Application Layer, and the support functions include:

js, application entry declaration file index: the application identification statement responsible for the Client sub-application, the dependency statement on a Client System Layer (CSL), the dependency statement on other applications and the statement which needs to be exposed per se;

routercompent routing component: the Client sub-application routing component is responsible for developing and maintaining the service function of the Client sub-application routing component;

models data model: the method is responsible for maintaining the Client sub application data model and supports two data model calling modes of dva and React Hook.

The Server System Layer (SSL) is responsible for the capability maintenance of the Server System application, and the support comprises a sub-application configuration model koa-config, a data model koa-model, a routing model capability koa-router and a sub-application loading capability koa-adaptor.

The Server Application Layer (SAL for short) is responsible for the development and maintenance of the Server sub-Application service function characteristics, and the support functions include:

js, application entry declaration file index: the application identification statement responsible for the sub-applications, the dependency statement on a Client system layer, the dependency statement on other applications and the statement required to be exposed per se;

routes routing interface: the Server sub-application routing interface function is developed and maintained;

models data model: the method is responsible for developing and maintaining a data model of the Server sub application Server, and supports MySQL data source reading through koa-model by default.

The umi-plugin-act is an official packaged plug-in set, comprises basic functional characteristics for reach front-end component development, and is integrated to comprise a act basic library, an anti front-end component library, a dux-based dva data stream solution, dynamic loading component capability, internationalization capability and webpack-based packaging construction capability. Wherein redux is a front-end architecture; antd is a component library; webpack is a modular packager.

Among them, the Backend as a Service (bass) in fig. 2e is a Service model, which is used to provide a method for linking an application to Backend cloud storage and an API exposed by the Backend application for Web application and mobile application developers, and also provide functions such as user management, push notification, and integration with social network services. These services are APIs provided through the use of custom Software Development Kits (SDKs) and application programming interfaces.

In a specific embodiment, as shown in fig. 2f, the registration phase and the execution phase of the sub-application are as follows.

1. Registration phase of Client sub-application (i.e. target sub-program):

through the front-end application management module, a directory organization structure of the agreed Client sub-application is declared, that is, a sub-application specification is declared, and the specific description refers to the above embodiment; and then configuring a routing component Router computer.js at config/router, namely automatically registering the Client sub-application in the running process of Umi. The data request method in the application can automatically route and call the Server sub-application through the request method appRequest exposed by the umi-plugin-adaptor, and automatically route the data request method to the Server sub-application routing interface. The appRequest implementation principle is that a request object is intercepted based on umi-request, namely when a { cmd } route is requested in an application, a request path is automatically assembled to be/api/{ AppNamespace }/{ cmd }, so that the request is routed to a Server sub-application routing interface { cmd }.

2. Server sub-application (i.e. target post-terminal program) registration phase:

through the backend application management module, a directory organization structure of the Server sub-application is declared, that is, a sub-application specification is declared, and the specific description refers to the above embodiment; and reading the configuration list of the Server sub-application through koa-application loader (application load) of the sub-application load management sub-module, automatically traversing to obtain a Server sub-application directory, loading a Server sub-application declaration file, initializing the configuration of the Server sub-application, executing a Server sub-application hook function for preprocessing, and loading a Server sub-application data model. And completing the registration process of loading the Server sub-application routes interface through the aprouter. The aprouter implementation principle is that an intra-application routing path { cmd } is uniformly registered to a Server sub-application routing namespace/api/{ AppNamespace } by an @ koa/router object use method, so that the isolation of sub-application request namespaces is achieved, namely the code isolation among multiple applications is achieved.

3. And a sub-application execution phase:

starting a Client system layer, loading a Client application layer according to a request url route, associating a Client data model, constructing a sub-application route request through umi-adapter, calling the request to a Server system layer, scheduling and executing the Server application layer through koa-adapter, and returning a processing result. In addition, the sub-applications can be switched, and corresponding data can be acquired according to the request corresponding to the new sub-application.

In one embodiment, the sub-application execution phase is as follows: the user accesses an address path url of/app/{ AppNamespace }/RouteR Component, the Client system layer analyzes the route to a routing Component RouteR Component in the Client sub-application through a React-Router route analysis function built in Umi, and then an execution Component rendering method React Component render can be called for the first time to render an initial application page;

after the Client sub-application routing Component first rendering method is completed, a Server sub-application routing interface { cmd } can be called through an appRequest method, a Server system layer carries out sequential splicing on calling interface information api corresponding to the { cmd }, rear terminal program identification appNamespace and the { cmd } based on a routing node mapping relation of the { cmd }, an interface request is routed to the corresponding Server sub-application routing interface/api/{ appNamespace }/{ cmd }, rear-end service logic calling is executed, service data is returned to the Client sub-application, a React Component state change hook method is triggered, a React Component render rendering method is called again, and a rendering task of a data view is completed.

The read-Router is a routing component library, and switching of components and change of states can be achieved by managing URLs.

The traditional Web application system comprises a front-end display layer Client and a back-end service layer Server, and in the current related technology, a single application architecture is usually adopted, and a Web developer is responsible for developing the functional characteristics of the Client view layer and the Server service logic layer in a unified manner. As application requirements increase, codebases are also expanding at a rapid pace. The single application is gradually overstocked, the maintainability and the flexibility are gradually reduced, the maintenance cost is higher and higher, and simultaneously, the application codes cannot be reused among different systems.

According to the method and the device, a set of plug-in micro-kernel application system can be realized on the basis of a single application architecture, the development organization paradigm of the sub-application is agreed, the management of the application life cycle is supported, the logic complexity of the development of the sub-application is simplified, the decoupling between the applications and the purpose that the sub-application codes can be reused among different service systems are realized, the development efficiency of the application system is greatly improved, and the code maintenance difficulty and the maintenance cost are reduced.

As can be seen from the above, this embodiment may receive a service processing request sent by a terminal, where the service processing request includes access information of a target back-end terminal program, and the service processing request is derived from a target subprogram corresponding to the target back-end terminal program in the terminal; determining, by a back-end system management module of a microkernel system, back-end access path information of the target back-end subprogram based on the access information in the service processing request; sending, by the backend system management module, the service processing request to the target backend terminal program based on the backend access path information; processing the service processing request through the target rear terminal program to obtain service processing result information; and sending the service processing result information to the target subprogram in the terminal. According to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

In order to better implement the method, the embodiment of the application also provides a sub-program running system based on the microkernel system. As shown in fig. 3a, the sub program running system based on the microkernel system includes a first sub program running device 31 and a second sub program running device 32, where the first sub program running device may be specifically integrated in the terminal, and the second sub program running device may be specifically integrated in the server. The first subroutine operating device 31 may include an acquisition unit 3101, a loading unit 3102, a first determination unit 3103, a first transmission unit 3104, a first reception unit 3105, and a first processing unit 3106; the second subroutine operating device 32 may include a second receiving unit 3201, a second determining unit 3202, a second transmitting unit 3203, a second processing unit 3204, and a third transmitting unit 3205, as follows:

(1) an acquisition unit 3101;

an obtaining unit 3101, configured to obtain, through a front-end system management module of the microkernel system, a subprogram call request for a target subprogram of a front-end host, where the subprogram call request includes front-end access path information of the target subprogram.

(2) A load unit 3102;

a loading unit 3102, configured to load the target sub program based on the front-end access path information in the sub program call request through the front-end system management module.

Optionally, in some embodiments of the present application, the front-end system management module includes a sub-application routing loading management sub-module; the loading unit 3102 may be specifically configured to load, through the sub-application routing load management sub-module, the routing component of the target sub-program based on the front-end access path information in the sub-program call request.

Optionally, in some embodiments of the present application, the front-end access path information includes a front-end subprogram identifier and a routing component identifier of the target subprogram; the load unit 3102 may include a parsing subunit 31021, a first determining subunit 31022 and a first load subunit 31023, see fig. 3b, as follows:

the analysis subunit 31021 is configured to analyze the front-end access path information in the subroutine call request through the sub-application route loading management sub-module, so as to obtain a front-end sub-routine identifier and a route component identifier of the target subroutine;

a first determining sub-unit 31022 for determining a routing component of the target sub-program based on the front-end sub-program identification and the routing component identification;

a first loading subunit 31023, configured to load the routing component of the target subroutine.

Optionally, in some embodiments of the present application, the loading unit 3102 may include a second determining subunit 31024 and a rendering subunit 31025, see fig. 3c, as follows:

the second determining subunit 31024 is configured to determine, through a preset application page model of the target subroutine, a basic page element to be rendered;

a rendering subunit 31025, configured to render the initial application page according to the base page elements.

(3) A first determination unit 3103;

a first determining unit 3103, configured to invoke the target sub program, and determine access information of a target back-end sub program corresponding to the target sub program in the server.

Optionally, in some embodiments of the present application, the first determining unit 3103 may be specifically configured to invoke the routing component, and determine access information of a target back-end sub-program corresponding to the target sub-program in a server.

Optionally, in some embodiments of the present application, the first determining unit 3103 may be specifically configured to determine, through the access information mapping relationship in the target sub-program, the access information of the target post-sub-program corresponding to the target sub-program in the server.

(4) A first transmission unit 3104;

a first sending unit 3104, configured to send, to the server through the target sub-program, a service processing request for the target back-end sub-program, where the service processing request includes access information of the target back-end sub-program.

Optionally, in some embodiments of the present application, the first sending unit 3104 may be specifically configured to send, to the server, a service processing request for the target backend application through the routing component.

(5) A first receiving unit 3105;

a first receiving unit 3105, configured to receive service processing result information sent by the server in response to the service processing request.

(6) A first processing unit 3106;

the first processing unit 3106 is configured to process the service processing result information based on the target subprogram, obtain an application page of the target subprogram, and display the application page.

Optionally, in some embodiments of the present application, the first processing unit 3106 may include a sending subunit 31061, a receiving subunit 31062 and an updating subunit 31063, see fig. 3d, as follows:

the sending subunit 31061, configured to, when detecting a data obtaining operation for the application page, send a data request corresponding to the data obtaining operation to a server through the routing component, where the data request includes access information of the target backend application;

a receiving sub-unit 31062, configured to receive response data information sent by the server in response to the data request;

an updating subunit 31063, configured to update the application page based on the response data information.

Optionally, in some embodiments of the present application, the first processing unit 3106 may be specifically configured to render, by the target sub-program and based on the service processing result information, the initial application page, obtain an application page of the target sub-program, and display the application page.

Optionally, in some embodiments of the present application, the first subprogram running device 31 further includes a first registration unit 3107, where the first registration unit 3107 is used for registering a target subprogram in the microkernel system; the microkernel system also comprises a front terminal application management module; the first registration unit 3107 includes a first acquisition subunit 31071, a first declaration subunit 31072 and a first configuration subunit 31073, see fig. 3e, as follows:

the first obtaining subunit 31071, configured to obtain a front-end configuration file of a target subprogram to be registered, where the front-end configuration file includes a front-end subprogram identifier of the target subprogram;

a first declaration subunit 31072, configured to perform declaration processing on the front-end configuration file through the front-end application management module to obtain a front-end declared file, where the front-end declared file includes dependency information of the target subprogram and the front-end system management module, and an access information mapping relationship between the target subprogram and a corresponding target back-end subprogram in a server, where the access information mapping relationship includes a communication interface mapping relationship between the target subprogram and the target back-end subprogram;

a first configuration subunit 31073, configured, by the front-end application management module, to configure a routing component of the target subprogram based on the dependency information, the access information mapping relationship, and the front-end subprogram identifier in the front-end declared file, so as to complete registration of the target subprogram in the microkernel system.

Optionally, in some embodiments of the present application, the first sub-program running device 31 further includes a switching unit 3108, and the switching unit 3108 is configured to switch the target sub-program; the switching unit 3108 may include an unload subunit 31081, a second load subunit 31082 and a return subunit 31083, see fig. 3f, as follows:

the uninstall subunit 31081 is configured to uninstall, by the front-end system management module, the target sub program when a switching operation for the target sub program is detected;

a second loading subunit 31082, configured to obtain a new subprogram call request, where the new subprogram call request includes front-end access path information of a new target subprogram, and load, through the front-end system management module, the new target subprogram based on the front-end access path information in the new subprogram call request;

a returning subunit 31083, configured to take the new target subprogram as a new target subprogram, execute the step of calling the target subprogram, and determine access information of a target post-subprogram corresponding to the target subprogram in the server, so as to display an application page of the new target subprogram.

(7) A second receiving unit 3201;

a second receiving unit 3201, configured to receive a service processing request sent by a terminal, where the service processing request includes access information of a target back-end sub-program, and the service processing request is derived from a target sub-program corresponding to the target back-end sub-program in the terminal.

(8) A second determination unit 3202;

a second determining unit 3202, configured to determine, by a backend system management module of the microkernel system, backend access path information of the target backend subprogram based on the access information in the service processing request.

Optionally, in some embodiments of the present application, the second determining unit 3202 may include a third acquiring subunit 32021, a fourth acquiring subunit 32022, and a splicing subunit 32023, see fig. 3g, as follows:

the third obtaining subunit 32021 is configured to obtain, through a back-end system management module of the microkernel system, the access information from the service processing request;

a fourth obtaining subunit 32022, configured to obtain, from the established routing node mapping relationship, a routing node mapping relationship corresponding to the access information;

a splicing subunit 32023, configured to splice, in sequence, the call interface information, the backend program identifier, and the access information in the routing node mapping relationship corresponding to the access information, to obtain backend access path information of the target backend program.

(9) A second transmitting unit 3203;

a second sending unit 3203, configured to send, by the backend system management module, the service processing request to the target backend terminal program based on the backend access path information.

(10) A second processing unit 3204;

the second processing unit 3204 is configured to process the service processing request through the target backend terminal program to obtain service processing result information.

Optionally, in some embodiments of the present application, the second processing unit 3204 may include a third determining subunit 32041, a processing subunit 32042, and a fusing subunit 32043, see fig. 3h, as follows:

the third determining subunit 32041 is configured to determine, by the target back-end sub-program, identification information of a target sub-program corresponding to the target back-end sub-program in the terminal;

a processing subunit 32042, configured to process the service processing request through the target backend terminal program to obtain service information;

a fusion subunit 32043, configured to fuse the service information with the identification information of the target subroutine to obtain service processing result information.

(11) A third transmitting unit 3205;

a third sending unit 3205, configured to send the service processing result information to the target subprogram in the terminal.

Optionally, in some embodiments of the present application, the second subprogram running device 32 further includes a second registration unit 3206, where the second registration unit 3206 is used for registering the target backend subprogram in the microkernel system; the microkernel system also comprises a rear terminal application management module; the second registration unit 3206 may include a second acquisition subunit 32061, a second declaration subunit 32062, a setup subunit 32063, and a second configuration subunit 32064, see fig. 3i, as follows:

the second obtaining subunit 32061 is configured to obtain a backend configuration file corresponding to a target backend terminal program to be registered, where the backend configuration file includes a backend terminal program identifier and access information of the target backend terminal program;

a second declaration subunit 32062, configured to perform declaration processing on the backend configuration file through the backend application management module to obtain a backend declaration backend file, where the backend declaration backend file includes dependency information of the target backend application and a backend system management module, and the dependency information includes call interface information that the target backend application opens to the backend system management module;

an establishing subunit 32063, configured to establish, through the backend application management module, a routing node mapping relationship among the calling interface information of the target backend program, the backend program identifier, and the access information;

a second configuring subunit 32064, configured to configure, through the backend application management module, a routing component of the target backend application based on the routing node mapping relationship, so as to complete registration of the target backend application in the microkernel system, where the routing component is used for information interaction between the target backend application and a terminal.

As can be seen from the above, in this embodiment, the obtaining unit 3101 may obtain, through the front-end system management module of the microkernel system, a subroutine call request for a target subroutine of a front-end host; loading the target subprogram based on the front-end access path information in the subprogram call request by the loading unit 3102 through the front-end system management module; the first determining unit 3103 calls the target subprogram, and determines the access information of the target post-subprogram corresponding to the target subprogram in the server; transmitting, by the first transmitting unit 3104, a service processing request for the target back-end sub-program to the server through the target sub-program, the service processing request including access information of the target back-end sub-program; receiving, by the first receiving unit 3105, service processing result information sent by the server in response to the service processing request; the first processing unit 3106 processes the service processing result information based on the target subprogram, obtains an application page of the target subprogram, and displays the application page;

or, the second receiving unit 3201 receives a service processing request sent by the terminal; determining, by the second determining unit 3202, backend access path information of the target backend subprogram based on the access information in the service processing request through a backend system management module of the microkernel system; a second sending unit 3203 sends the service processing request to the target backend terminal program through the backend system management module based on the backend access path information; the second processing unit 3204 processes the service processing request through the target backend terminal program to obtain service processing result information; transmitting the service processing result information to the target subprogram in the terminal through a third transmitting unit 3205;

according to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

An electronic device according to an embodiment of the present application is further provided, as shown in fig. 4, which shows a schematic structural diagram of the electronic device according to an embodiment of the present application, specifically:

the electronic device may include components such as a processor 401 of one or more processing cores, memory 402 of one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will appreciate that the electronic device configuration shown in fig. 4 does not constitute a limitation of the electronic device and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components. Wherein:

the processor 401 is a control center of the electronic device, connects various parts of the whole electronic device by various interfaces and lines, performs various functions of the electronic device and processes data by running or executing software programs and/or modules stored in the memory 402 and calling data stored in the memory 402, thereby performing overall monitoring of the electronic device. Optionally, processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor, which mainly handles operating systems, user interfaces, application programs, etc., and a modem processor, which mainly handles wireless communications. It will be appreciated that the modem processor described above may not be integrated into the processor 401.

The memory 402 may be used to store software programs and modules, and the processor 401 executes various functional applications and data processing by operating the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, etc.), and the like; the storage data area may store data created according to use of the electronic device, and the like. Further, the memory 402 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other volatile solid state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 access to the memory 402.

The electronic device further comprises a power supply 403 for supplying power to the various components, and preferably, the power supply 403 is logically connected to the processor 401 through a power management system, so that functions of managing charging, discharging, and power consumption are realized through the power management system. The power supply 403 may also include any component of one or more dc or ac power sources, recharging systems, power failure detection circuitry, power converters or inverters, power status indicators, and the like.

The electronic device may further include an input unit 404, and the input unit 404 may be used to receive input numeric or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

Although not shown, the electronic device may further include a display unit and the like, which are not described in detail herein. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable file corresponding to the process of one or more application programs into the memory 402 according to the following instructions, and the processor 401 runs the application program stored in the memory 402.

If the electronic device is a terminal, the electronic device can implement the following functions:

acquiring a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system; loading a target subprogram based on front-end access path information in the subprogram calling request; calling a target subprogram, and determining access information of a target post-subprogram corresponding to the target subprogram in a server; sending a service processing request aiming at the target post-terminal program to a server through a target subprogram; receiving service processing result information which is sent by the server and responds to the service processing request; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page.

If the electronic device is a server, the electronic device may implement the following functions:

receiving a service processing request sent by a terminal; determining, by a back-end system management module of a microkernel system, back-end access path information of the target back-end subprogram based on the access information in the service processing request; sending the service processing request to the target back-end terminal program through the back-end access path information; processing the service processing request through the target rear terminal program to obtain service processing result information; and sending the service processing result information to the target subprogram in the terminal.

The above operations can be implemented in the foregoing embodiments, and are not described in detail herein.

As can be seen from the above, in this embodiment, the sub-program call request for the target sub-program of the front-end host may be obtained through the front-end system management module of the microkernel system; loading the target subprogram based on the front-end access path information in the subprogram calling request; calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server; sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, wherein the service processing request comprises access information of the target back-end sub-program; receiving service processing result information which is sent by a server and responds to the service processing request; and processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page. According to the method and the device, code isolation among the application programs is achieved in an application program plug-in mode, the coupling degree among the application programs is reduced, and the development efficiency of an application system is improved.

It will be understood by those skilled in the art that all or part of the steps of the methods of the above embodiments may be performed by instructions or by associated hardware controlled by the instructions, which may be stored in a computer readable storage medium and loaded and executed by a processor.

To this end, the present application provides a storage medium, in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any one of the methods for operating a sub-program based on a microkernel system provided in the present application. For example, the instructions may perform the steps of:

acquiring a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system; loading the target subprogram based on the front-end access path information in the subprogram calling request; calling the target subprogram, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server; sending a service processing request aiming at the target post-terminal program to the server through the target sub-program; receiving service processing result information which is sent by the server and responds to the service processing request; processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram, and displaying the application page; alternatively, the first and second electrodes may be,

Wherein the storage medium may include: read Only Memory (ROM), Random Access Memory (RAM), magnetic or optical disks, and the like.

Since the instructions stored in the storage medium may execute the steps in any one of the methods for running a subroutine based on a microkernel system provided in the embodiments of the present application, beneficial effects that can be achieved by any one of the methods for running a subroutine based on a microkernel system provided in the embodiments of the present application may be achieved, for details, see the foregoing embodiments, and are not described herein again.

According to an aspect of the application, a computer program product or computer program is provided, comprising computer instructions, the computer instructions being stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the methods provided in the various alternative implementations of the microkernel system-based subroutine execution aspect described above.

The method, the device and the electronic device for operating the sub-program based on the microkernel system provided by the embodiment of the application are introduced in detail, a specific example is applied in the description to explain the principle and the implementation of the application, and the description of the embodiment is only used for helping to understand the method and the core idea of the application; meanwhile, for those skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A subprogram running method based on a microkernel system is characterized by comprising the following steps:

acquiring a subprogram calling request aiming at a target subprogram of a front-end host through a front-end system management module of a microkernel system, wherein the subprogram calling request comprises front-end access path information of the target subprogram, the target subprogram is an internal function module in the front-end host, and the front-end host provides corresponding service by a back-end host;

sending a service processing request aiming at the target back-end sub-program to the server through the target sub-program, so that the server determines back-end access path information of the target back-end sub-program based on access information in the service processing request, and sending the service processing request to a target back-end sub-program corresponding to the target sub-program in a plurality of back-end sub-programs of the server based on the back-end access path information, wherein the service processing request comprises the access information of the target back-end sub-program;

2. The method of claim 1, wherein the microkernel system further comprises a front-end application management module; before the obtaining, by the front-end system management module of the microkernel system, a subprogram call request for a target subprogram of a front-end host, the method further includes:

3. The method of claim 2, wherein the front-end system management module comprises a sub-application routing load management sub-module; the loading, by the front-end system management module, the target subprogram based on the front-end access path information in the subprogram call request includes:

loading a routing component of the target subprogram based on the front-end access path information in the subprogram calling request through the subprogram routing loading management submodule;

the calling the target subprogram and determining the access information of the target subprogram corresponding to the target subprogram in the server comprises the following steps:

calling the routing component, and determining the access information of the target post-subprogram corresponding to the target subprogram in the server;

the sending, by the target subprogram, a service processing request for the target backend subprogram to the server includes:

4. The method of claim 3, wherein the front-end access path information comprises a front-end subprogram identification and a routing component identification of the target subprogram; the loading, by the sub-application route loading management sub-module, a route component of the target sub-program based on the front-end access path information in the sub-program call request includes:

and loading the routing component of the target subprogram.

5. The method of claim 2, wherein the invoking the target subprogram, and determining the access information of the target subprogram corresponding to the target subprogram in the server, comprises:

6. The method according to claim 3, wherein after the processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram and displaying the application page, the method further comprises:

and updating the application page based on the response data information.

7. The method according to claim 1, wherein after the processing the service processing result information based on the target subprogram to obtain an application page of the target subprogram and displaying the application page, the method further comprises:

8. The method of claim 1, wherein after loading, by the front-end system management module, the target subroutine based on the front-end access path information in the subroutine call request, further comprising:

rendering an initial application page according to the basic page elements;

9. A subprogram running method based on a microkernel system is characterized by comprising the following steps:

receiving a service processing request sent by a terminal, wherein the service processing request comprises access information of a target back-end terminal program, the service processing request is derived from a target subprogram corresponding to the target back-end terminal program in the terminal, the target subprogram is an internal function module in a front-end host, and the front-end host provides corresponding service by a back-end host;

10. The method of claim 9, wherein the microkernel system further comprises a backend application management module; before the receiving the service processing request sent by the terminal, the method further includes:

11. The method of claim 10, wherein determining, by a backend system management module of a microkernel system, backend access path information for the target backend subprogram based on the access information in the business process request comprises:

12. The method according to claim 9, wherein the processing the service processing request by the target backend terminal program to obtain service processing result information includes:

13. A child program execution apparatus based on a microkernel system, comprising:

an obtaining unit, configured to obtain, through a front-end system management module of a microkernel system, a subprogram call request for a target subprogram of a front-end host, where the subprogram call request includes front-end access path information of the target subprogram, the target subprogram is an internal function module in the front-end host, and the front-end host provides corresponding service by a back-end host;

a first sending unit, configured to send, by the target sub-program, a service processing request for the target back-end sub-program to the server, so that the server determines back-end access path information of the target back-end sub-program based on access information in the service processing request, and send, based on the back-end access path information, the service processing request to a target back-end sub-program corresponding to the target sub-program in multiple back-end sub-programs of the server, where the service processing request includes the access information of the target back-end sub-program;

14. A child program execution apparatus based on a microkernel system, comprising:

a second receiving unit, configured to receive a service processing request sent by a terminal, where the service processing request includes access information of a target back-end sub-program, and the service processing request is derived from a target sub-program corresponding to the target back-end sub-program in the terminal, where the target sub-program is an internal function module in a front-end host, and the front-end host provides a corresponding service by a back-end host;

15. An electronic device comprising a memory and a processor; the memory stores an application program, and the processor is configured to execute the application program in the memory to perform the operations of the microkernel system-based subroutine execution method according to any one of claims 1 to 12.