CN117294770A - Service component scheduling method, device, equipment and storage medium - Google Patents

Service component scheduling method, device, equipment and storage medium Download PDF

Info

Publication number
CN117294770A
CN117294770A CN202311149395.7A CN202311149395A CN117294770A CN 117294770 A CN117294770 A CN 117294770A CN 202311149395 A CN202311149395 A CN 202311149395A CN 117294770 A CN117294770 A CN 117294770A
Authority
CN
China
Prior art keywords
component
service
business
service component
calling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311149395.7A
Other languages
Chinese (zh)
Inventor
叶志欣
孙奇
严骏驰
王月
柏路平
古英杰
初瑞
舒敏根
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Information Technology Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Information Technology Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202311149395.7A priority Critical patent/CN117294770A/en
Publication of CN117294770A publication Critical patent/CN117294770A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63Routing a service request depending on the request content or context
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

The application discloses a service component scheduling method, a device, equipment and a storage medium, wherein the method comprises the following steps: determining a service component to be called according to the received component call request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local call server; and determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy so as to execute the service application corresponding to the service component, wherein the preset scheduling policy is associated with the scheduling frequency of the service component, and the local communication channel is used for locally calling the service component. The method and the device improve the calling efficiency of the business party to the related components.

Description

Service component scheduling method, device, equipment and storage medium
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a service component scheduling method, device, apparatus, and storage medium.
Background
As the business environments become more complex and variable, and the enterprise numbers become more intelligent, to address these challenges with great speed and efficiency, more and more system construction tends to refine the granularity of micro services further, form many highly cohesive and reusable atomic functional components, and business and technology teams can order components and arrange several components obtained into an application system that meets the business needs.
In the related art, a plurality of components of the component management platform are remotely called, and then a plurality of called components are organized into an application system meeting service requirements, when the service functions of the system are numerous, the split atomic service data are greatly increased, meanwhile, message middleware connection generated during data interaction also greatly occupies system resources to influence the system performance, and the calling efficiency of the related components is low.
Disclosure of Invention
The main purpose of the present application is to provide a method, an apparatus, a device, and a storage medium for scheduling service components, which are aimed at solving the technical problem that in the related art, a plurality of components of a component management platform are remotely invoked, and system resources are greatly occupied by message middleware connection generated during data interaction to affect system performance, resulting in low invoking efficiency of related components.
In order to achieve the above object, an embodiment of the present application provides a service component scheduling method, where the method includes:
determining a service component to be called according to the received component call request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local call server;
and determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy so as to execute the service application corresponding to the service component, wherein the preset scheduling policy is associated with the scheduling frequency of the service component, and the local communication channel is used for locally calling the service component.
In a possible implementation manner of the present application, the step of determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy includes:
acquiring the real-time calling frequency of the service component;
comparing the real-time calling frequency with a preset threshold value to obtain a comparison result;
if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, calling the service component through the local communication channel;
And if the comparison result shows that the real-time calling frequency is smaller than a preset threshold value, remotely calling the service component.
In one possible implementation manner of the present application, the step of calling the service component through the local communication channel if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value includes:
if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, verifying the request parameters corresponding to the component calling request to obtain a verification result;
and if the verification result is that the verification is passed, calling a corresponding service component through the local communication channel and the analysis executor.
In one possible implementation manner of the application, the combined service component constructs the service application through the low-code platform, so that the number of codes corresponding to the transmitted service components is reduced when at least one service component is called.
In one possible implementation manner of the present application, after the step of determining the service component to be invoked according to the component invocation request, the method further includes:
and deploying the service type component to a cloud platform according to the component calling request, and loading the functional type component to an analysis executor, wherein the functional type component is stored in the analysis executor in a static code mode, and is converted into an operation state when being called, and the service type component is used for caching or preloading data corresponding to the business service application.
In one possible implementation manner of the application, the parsing executor integrates multiple program language packages, and when the parsing executor loads business components containing multiple program languages, the loaded business components are flexibly arranged.
In a possible implementation manner of the present application, the business service application is decoupled from the business component, and when the working state of the business component is changed, the business service application corresponding to the business component is kept unchanged.
The application also provides a service component scheduling device, which comprises:
the first determining module is used for determining a service component to be called according to the received component calling request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local calling server;
and the second determining module is used for determining remote call or call of the business component through the local communication channel based on a preset scheduling strategy so as to execute business service application corresponding to the business component, wherein the preset scheduling strategy is associated with the scheduling frequency of the business component, and the local communication channel is used for carrying out local call on the business component.
The application also provides a service component scheduling device, where the service component scheduling device is an entity node device, and the service component scheduling device includes: the system comprises a memory, a processor and a program of the business component scheduling method stored in the memory and capable of running on the processor, wherein the program of the business component scheduling method can realize the steps of the business component scheduling method when being executed by the processor.
In order to achieve the above object, there is also provided a storage medium having stored thereon a service component scheduler, which when executed by a processor, implements the steps of any of the service component scheduling methods described above.
The application provides a service component scheduling method, device, equipment and storage medium. Compared with the related art that the remote calling is carried out on a plurality of components of the component management platform, and system performance is greatly influenced by system resources due to the fact that message middleware connection generated during data interaction is also occupied, the calling efficiency of the related components is low, in the application, a service component to be called is determined according to the received component calling request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local calling server; and determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy so as to execute the service application corresponding to the service component, wherein the preset scheduling policy is associated with the scheduling frequency of the service component, and the local communication channel is used for locally calling the service component. In the application, the service components to be called are determined through the component call request of the cloud platform, and according to a preset scheduling strategy, remote call is determined or the acquired service components are flexibly scheduled through the local communication channel, and the service components are called through the local communication channel instead of the remote call, so that the occupation proportion of system resources is reduced, and the calling efficiency of a service party to related components is improved.
Drawings
Fig. 1 is a schematic flow chart of a first embodiment of a service component scheduling method of the present application;
FIG. 2 is a flow chart of scheduling service components in the service component scheduling method of the present application;
FIG. 3 is a schematic diagram of a device architecture of a hardware operating environment according to an embodiment of the present application;
FIG. 4 is a flow chart of data interaction between a functional interface module and an analysis executor according to the service component scheduling method of the present application;
FIG. 5 is a flow chart of data execution of a functional interface module according to the service component scheduling method of the present application;
FIG. 6 is a flow chart of processing logic of an analysis executor involved in the business component scheduling method of the present application;
FIG. 7 is a schematic diagram of service component function mapping related to a service component scheduling method of the present application;
FIG. 8 is a schematic diagram of an execution layer processing flow related to a service component scheduling method of the present application;
FIG. 9 is a schematic flow chart of establishing a local communication channel between an analysis executor and a local call server according to the service component scheduling method of the present application;
FIG. 10 is a schematic diagram of a service component localization call flow related to a service component scheduling method of the present application;
fig. 11 is a schematic diagram of a service component call flow related to a service component scheduling method of the present application.
Detailed Description
It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.
An embodiment of the present application provides a service component scheduling method, applied to a cloud platform, and in a first embodiment of the service component scheduling method of the present application, referring to fig. 1, the method includes:
step S10, determining a service component to be called according to the received component call request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local call server;
step S20, determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy, so as to execute a service application corresponding to the service component, where the preset scheduling policy is associated with a scheduling frequency of the service component, and the local communication channel is used to locally call the service component.
The present embodiment aims at: the method has the advantages that through two calling modes of local calling and remote calling, and a local inter-process communication channel is established between the analysis executor and the local calling server, the effects of arranging and calling components taking local calling as a main part and taking remote calling as an auxiliary part are achieved, the occupation proportion of system resources is reduced, and the calling efficiency of a business party to related components is improved.
In this embodiment, the research and development background is aimed at:
as the enterprise numbers intelligently upgrade and business environments become more complex and variable, and these challenges are addressed by agile and high effects, more and more system construction tends to further refine the granularity of micro services, forming numerous atomic functional components with high cohesive and reusability functions. The business and technology team can quickly respond by building blocks to arrange a plurality of components into an application system meeting business requirements.
The business service components are disassembled into a plurality of atomic services, interaction is monitored among the atomic services through a rest API or message events, the plurality of atomic services can be assembled into business components with different functions, and the business components are dragged to be arranged through a visual arrangement interface to realize specific business demand service; when the system service functions are complex, the split atomic service data is greatly increased, and accordingly, a complex and lengthy call chain and numerous resurf ul/http calls or message middleware connection also occupy system resources to influence the system performance. Currently, the cloud platform walks on its way, and in the cloud environment, if all the atomic services or component services exist as mirror image containers in an running state, the resource consumption of the host will also increase linearly.
In this embodiment, the application scenario aimed at is:
when the business side subscribes and invokes the components in the related component management platform, the component management platform loads the functional components to the cloud platform analysis executor, and builds the required business service application through the low-code platform integrated component interface module according to the subscribed components.
The method comprises the following specific steps:
step S10, determining a service component to be called according to the received component call request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local call server;
as an example, the service component scheduling method may be applied to a service component scheduling apparatus, which belongs to a service component scheduling system, which belongs to a service component scheduling device.
As an example, the component call request may be a call request sent by the middle platform to the cloud platform according to the received service request, where the middle platform is an electronic device, may be a mobile device, a local device, or a server, and the middle platform may support multiple services, and when a certain service needs to be executed, a service demand end (a terminal for executing the service may be the electronic device of the middle platform itself or another electronic device) sends the service request.
As an example, the service component is a component subscribed by the service system corresponding to the service party from the component management platform, the service component is divided into two types of functional components and service components according to the scene and the functional characteristics, each component can select different development languages (java/c/c++/python/go, etc.), the compiled components are packaged and uploaded to be uniformly and intensively managed by the management platform, and after the subscription of the application system, the component management platform automatically loads the subscribed components to the analysis executor deploys the subscribed components to the cloud environment/cloud platform according to the types of the components.
As an example, the functional component may be a component that is formed by a functional body that can directly compile and execute a complete atomic function of the static code without preprocessing, pre-buffering, and pre-loading, such as a digital signature rsa core algorithm, a two-dimensional code generation algorithm, and the like.
As an example, a service component may be a component deployed in a service in a running state, such as public parameter caching, file content preloading, etc., all providing a unified standard restful/http API interface and interface parameter call, shaped as: http: the/(Module-NAME/METHOD-NAME { parameter 1, parameter 2, parameter N.
As one example, business components include multiple components that are deployed or loaded after the cloud platform is completed.
As an example, a data interaction flow chart of the functional interface module and the analysis executor is shown in fig. 4, the functional interface module is integrated with the business service of arranging a plurality of functional components, the functional interface module and the analysis executor establish local process communication to form a local communication channel, and the interface module requests the executor to call the components and processes the call results.
After the step of determining the service component to be invoked according to the component invoking request, the method further comprises the following steps:
step S110, deploying the service component to a cloud platform according to the component call request, and loading the functional component to an analysis executor, where the functional component is stored in the analysis executor in a form of a static code, and is converted into an operation state when being called, and the service component is used to cache or preload data corresponding to the service application.
As an example, after a service component is ordered, the service component is deployed and operated in a container service state on a cloud platform, and when the service component is operated, more system resources are generally required to be occupied, and generally, a plurality of business services share service component instances, and when a business service calls a certain service component frequently, service component instances are created and privately owned locally in the business service.
As one example, the functional component provides unified standard function interfaces and interface parameter calls, shaped as: the method name parameter 1, parameter 2, parameter N. The type component is not deployed in service form, but is loaded to the resolution executor after subscription, waiting for call execution.
As an example, after the loading of the functional component is completed or after the deployment of the service component is completed, the call execution is waited, and the functional component and the service component are independent and do not interfere with each other.
As an example, the parsing executor belongs to the whole cluster, is an infrastructure of the whole platform, isolates the component resources subscribed by each application system through the naming space, and after the service component is subscribed, the parsing executor is used as a loading end/deployment end of the service component and is used as a basis for subsequently calling the component.
As an example, a service component orchestration call flow chart is shown in fig. 2, a scheme divides components into functional components and service components according to scenes and attributes, the functional components are maintained by a component management platform, when a service system side initiates subscription, the component management platform loads the functional components into a cloud platform analysis executor and exists in a static code form, the functional components become an operation state when being called, the subscribed service components are deployed to the cloud platform and exist in a mirror image container service form, a service developer integrates the components interface module according to the subscribed components through a low code platform to construct required service application, the scheme completes interaction of the structures such as the component interface module, the analysis executor, a local call adapter and the like, component call is completed, and call calculation self-adaption transfer is completed through resource statistics and access statistics.
As an example, as shown in fig. 5, the data execution flow chart of the functional interface module is shown in fig. 5, the service integrates the functional interface module, through transferring the corresponding component ID and the method name, the service parameter invokes the interface module, the interface module performs format verification on the parameter transferred by the service, if the parameter format is input correctly, establishes a local communication connection with the parsing executor, initiates the invoking request and the response receiving through the local communication connection, and the service generally needs to invoke a plurality of components, can organize the invoking parameters of the plurality of components as required, and initiates the invoking request respectively.
The analysis executor integrates multiple program language packages, and when the analysis executor loads service components containing multiple program languages, the loaded service components are flexibly arranged.
As an example, after receiving the call request, the parsing executor processes the call request through the interface access layer, the interface parsing layer and the execution layer, and selects an appropriate execution node (local priority node), and parses the component id in the request parameter: module_id, method name: api_name, and service parameters: vars, mapping to find the function interface of the corresponding component, calling different language executors to execute according to the language type, and returning an execution result.
Step S20, determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy, so as to execute a service application corresponding to the service component, where the preset scheduling policy is associated with a scheduling frequency of the service component, and the local communication channel is used to locally call the service component.
As an example, the preset scheduling policy is specifically: the local/remote calling mode with highest calling component efficiency is selected by counting variables such as local resources, response time, calling frequency and the like, so that the purpose of dynamically and adaptively selecting local execution calling or remote execution calling is achieved.
As an example, when the preset scheduling policy is adopted, whether the local resource can still meet the condition of the calling component needs to be considered, and if the local resource is insufficient at this time, the calling is not performed.
As an example, when the response time exceeds a set time threshold, then switch to the local call server, which in terms of call components, saves more system resources than the remote call server.
In terms of calling frequency, when the service component is called, the corresponding calling frequency can be counted, when the calling frequency is too high, the calling speed of the service component is reduced by using a remote calling mode, at the moment, the service component is more suitable to be called by using a local calling mode, when the calling frequency is normal or too low, the calling speed is not influenced by other systems, and at the moment, the service component is more suitable to be called remotely.
As an example, after determining the calling mode, the parsing executor completes the component calling work, specifically as shown in fig. 6, after receiving the component calling request information, the parsing executor starts to enter the interface access layer processing logic: the interface access layer preferentially calls the local component, and meanwhile, according to the statistical result of the system resource load, such as the use conditions of a CPU, a memory, IO and the like, when the use of the local resource reaches a threshold value, the analysis executor processing of the local component is transferred and calculated to other nodes, and the processing logic is as follows:
after the analysis executors on a plurality of nodes of the cluster are started, counting the resource use condition of the current node once by the analysis executors on each node every certain time, and counting the CPU use rate: ucpu, memory usage: umem, percentage of CPU time the IO latency occupies (io_wait): uio.
Each node analysis executor calculates an execution coefficient E corresponding to each component respectively:
E=a*Ucpu+b*Umem+c*Uio(a,b,c∈[0,1],a+b+c=100)
each component sets different values of a, b and c according to the respective characteristics, the proportion of a to be increased by the compute-intensive component, the value of b to be increased by the memory-occupying component, and the value of c to be increased by the IO-intensive component. The lower the value of E, the more suitable the current node is to execute as the current component. E is stored after the calculation is completed, and the local result is synchronized to other nodes through a shift algorithm. The set of E stored by each node after synchronization is as follows:
[{module1:{node1:E1,node2:E2,`···}}
{module2:{node1:E1,node2:E2,`···}}
···]
And taking the latest request after the E value is calculated, sending a test running request to two nodes with the minimum corresponding component E value while executing locally, and comparing the calculated final response time of the three nodes. If the response time of the local node is smaller, the subsequent requests are locally executed before the next E value calculation, if the response time of other nodes is smaller, the subsequent requests are forwarded to the nodex for execution before the next E value calculation, the E value is not needed to be judged in an analysis executor of the nodex, and after the next E value calculation, the previous three sequences are not changed, and the execution node still takes the execution node for calculating the E value last time.
As an example, in the executing node, the service component function mapping diagram is shown in fig. 7, after being processed by the interface access layer, the service component function mapping diagram enters the interface analysis layer to analyze the request parameters, and the request parameters are analyzed by the component ID: the module_id maps the corresponding component, then maps the corresponding interface function after resolving the method name, the method parameter and the return value, and copies the component compiling file to the execution layer appointed directory.
As an example, after mapping out the function method, the method enters an execution layer, where the processing flow diagram of the execution layer is shown in fig. 8, the execution layer encapsulates multiple language execution commands, and selects a corresponding execution command according to the language type of the component mapped by the parsing layer, and executes the function in the corresponding component function directory. And after the execution is completed, returning an execution result according to the return value type.
The application provides a service component scheduling method, device, equipment and storage medium. Compared with the related art that the remote calling is carried out on a plurality of components of the component management platform, and system performance is greatly influenced by system resources due to the fact that message middleware connection generated during data interaction is also occupied, the calling efficiency of the related components is low, in the application, a service component to be called is determined according to the received component calling request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local calling server; and determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy so as to execute the service application corresponding to the service component, wherein the preset scheduling policy is associated with the scheduling frequency of the service component, and the local communication channel is used for locally calling the service component. In the application, the service components to be called are determined through the component call request of the cloud platform, and according to a preset scheduling strategy, remote call is determined or the acquired service components are flexibly scheduled through the local communication channel, and the service components are called through the local communication channel instead of the remote call, so that the occupation proportion of system resources is reduced, and the calling efficiency of a service party to related components is improved.
Further, based on the first embodiment of the present application, another embodiment of the present application is provided, in which the step of determining to remotely invoke or invoke the service component through the local communication channel based on a preset scheduling policy includes:
step A1, acquiring the real-time calling frequency of the service component;
as an example, as business components are invoked, the real-time frequency of invocation of the corresponding components may be counted.
Step A2, comparing the real-time calling frequency with a preset threshold value to obtain a comparison result;
as an example, by comparing the real-time call frequency with a preset threshold, it is determined whether to establish a communication channel with the local call server according to the obtained comparison result.
As an example, the preset threshold is a preset frequency value of the user, and may be modified according to the requirement of the user, which is not limited in particular.
As an example, the comparison result may be that the real-time call frequency is greater than or equal to a preset threshold or the real-time call frequency is less than a preset threshold.
Step A3, if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, calling the service component through the local communication channel;
As an example, when the real-time calling frequency is greater than or equal to the preset threshold, it indicates that the calling frequency is too high at this time, and a load is generated on the system, and at this time, the local server needs to be switched to improve the calling efficiency.
And step A4, if the comparison result shows that the real-time calling frequency is smaller than a preset threshold value, remotely calling the service component.
As an example, when the real-time calling frequency is smaller than the preset threshold, it indicates that the calling frequency of the related component is not high at this time, the remote calling can meet the requirement of the user, and at this time, the remote server is selected to be used as the calling server currently used.
As an example, when selecting a server that specifically needs to be invoked, the resources of the local server and the response time of invoking the service component need to be considered, so that the invocation of the service component is performed by the local/remote invocation server through multiple aspects of consideration.
As an example, the functional interface module and the parsing executor establish a LOCAL inter-process IPC communication channel through Unix domain socket (af_local), and specifically as shown in fig. 9, the service container adopts a virtualization technology, and generally does not directly expose a real LOCAL process number, and needs to map a service container logical process number and a service container actual process number. According to Unix domain socket principle, information interaction is completed by different local processes through socket files, IPC channels are respectively established between different service processes and an analysis executor process, different socket files are used, for example, module1 is used/tmp/module 1.Local, and module2 is used/tmp/module 2.Local.
As an example, after the local communication channel is established, the interaction logic of the functional interface module and the parsing executor is as follows:
1. the business service encapsulates parameters according to the standard interface and executes the entry of the functional interface module, and the parameter content comprises a component ID: module_id, function name: api_name, several service parameters: vars, and by performing the serial number: the service distinguishes the current request; the expression of the parameters may be: { Module_id: module_id, api_name $ api_name, VARs { VAR1 $ VAR1, VAR2 $ VA r2· · }, SERIAL $ serial_no };
2. the functional interface module transmits the component ID and the function name to an analysis executor to identify the corresponding component and function interface, and the business service performs the arrangement of the component by organizing a plurality of component IDs and function names by a small amount of codes; in particular, when the business service needs to asynchronously call multiple components at the same time, like the same time as the string encryption and checksum, the parameters can be organized as follows:
[ { Module_id $Module_ID, api_name $API_NAME, VARs { VAR1 $ VAR1, VAR2 $ VAR2 · · }, SERIAL $ SERIAL_NO }, corresponding to the parameter content portion of step 1.
3. And the functional interface module completes parameter verification of service assembly, and if the data format is correct, the functional interface module establishes a LOCAL inter-process IPC communication channel with an analysis executor through Unix domain socket (AF_local) and sends a call execution request.
4. After receiving the call request, the parsing executor processes the call request through the interface access layer, the interface parsing layer and the execution layer respectively, selects a proper execution node (local priority node), and parses the component id in the request parameter: module_id, method name: api_name, and service parameters: vars, mapping to find the function interface of the corresponding component, calling different language executors to execute according to the language type, and returning an execution result. The return result format is as follows:
{module_id:$MODULE_ID,api_name:$API_NAME,result:{code:$CODE,va lues:$VALUES}},serial:$SERIAL_NO];
result is the returned execution result, wherein code is the state code, and values are the result value of specific execution.
5. And the business service receives the processing result and completes corresponding business logic processing according to the return code. If the code value is true, the execution is successful, and the normal business processing flow can be performed; if the code value is false, the execution exception is indicated, and the exception processing flow is entered.
And if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold, calling the service component through the local communication channel, wherein the step comprises the following steps:
step B1, if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, verifying request parameters corresponding to the component calling request to obtain a verification result;
And step B2, if the verification result is that the verification is passed, calling a corresponding service component through the local communication channel and the analysis executor.
As an example, as shown in fig. 10, after service components subscribe and release, service components are typically deployed in a cluster in the form of a shared service, and multiple service components may share an instance of the service components after release. The service component completes the interaction with the service component through the service interface module, and the logic is as follows: when the service component calls the service component through the service interface module, remotely calling a standard API interface of the service component through a restful/http, and counting calling frequency TPS in real time;
the request URI is as follows: http: when the real-time calling frequency TPS exceeds a set threshold, the METHOD enters a component service localization flow.
As an example, the server component call flow diagram is shown in fig. 11, and when the system sets TPS > = max_req_mes_per_second (the average number of remote service calls PER SECOND) and min_duration (the minimum DURATION) is sustained, the service interface module applies for creating a local service component instance to the cluster.
As an example, the service component itself integrates a LOCAL call adapter, and the service component integrated service interface module establishes a LOCAL inter-process IPC communication channel with the LOCAL service component call adapter through Unix domain socket (af_local), and the principle is referred to in fig. 9. When a business component interacts with multiple local component services, there will likewise be multiple socket files corresponding to the business component.
As an example, the business service encapsulates parameters according to a standard interface and performs a service-like interface module entry, with the request parameters being the same as the functional components:
{module_id:$MODULE_ID,api_name:$API_NAME,vars:{var1:$VAR1,var2:$VAR2···},serial:$SERIAL_NO};
the service interface module entry function completes the parameter format check and initiates a call request to the local service component corresponding to the module_id.
As an example, the local service component receives and analyzes the request parameters through the local call adapter, and after the api_name is analyzed, the interface corresponding to the api_name is directly called in the adapter, and then the execution result is returned to the service component interface module. The response parameters are as follows:
{module_id:$MODULE_ID,api_name:$API_NAME,result:{code:$CODE,va lues:$VALUES}},serial:$SERIAL_NO];
as one example, the service interface module performs the corresponding business logic processing by return code.
As an example, after the service interface module establishes the local call, the remote call interface information is saved, and a keep-alive request is sent at regular time to detect whether the remote service survives, or whether the version number is updated, etc.
As an example, when TPS < max_req_mes_per_second (maximum number of requests calls PER SECOND on average for remote service) and min_duration (minimum DURATION) is sustained, the "return to tilling" mechanism is triggered, remote calls are resumed, and the local instance is destroyed.
As an example, the updated components in the component management platform are re-ordered and service component instances are re-smoothly deployed according to the release mechanism of the cloud platform itself. The service interface module detects whether the remote service version number is changed or not through a keep-alive mechanism, and when the version number is changed and a local service component instance exists, the service interface module reinitiates application to create the local service component instance, and after the local IPC channel is reestablished, the local service component instance of the old version is deleted.
In this embodiment, by counting variables such as local resources, response time, and call frequency, a local execution call or a remote execution call is dynamically and adaptively selected, so that call efficiency of related components is improved.
Further, based on the first embodiment and the second embodiment in the present application, another embodiment in the present application is provided, in this embodiment, the combined service component builds a service application through a low code platform, so that when at least one service component is called, the number of codes corresponding to the transmitted service component is reduced.
As an example, when the application system side builds the business service application on the low-code platform, only the interface module is integrated with the business service, and when the business service application calls one or more components through the interface module, only a small amount of codes are written to transfer the corresponding component ID, method name and business parameters.
As an example, business services are built through a low code platform, so that the transmitted codes are reduced, and the transmission speed is improved.
In this embodiment, the business service is constructed by the low code platform, so as to reduce the transmitted codes and improve the transmission speed.
Further, based on the first, second and third embodiments in the present application, another embodiment of the present application is provided, in which the business service application is decoupled from the business component, and when the working state of the business component is changed, the business service application corresponding to the business component remains unchanged.
As an example, both functional and service components are completely decoupled from orchestration logic and business services in terms of development and deployment usage, with maximally reduced impact on the business system during the update and upgrade process.
As an example, the updated components in the component management platform are reordered and loaded to the parsing executor, when the updated components are detected to exist in the execution directory of the execution layer, the components are required to be copied to the execution directory again, the old version is covered after the copying is completed, and the components of the old version still run in the process before the covering.
In this embodiment, by decoupling the service application from the service component, the impact of the service component on the service application when the update or state change occurs is reduced.
Referring to fig. 3, fig. 3 is a schematic device structure diagram of a hardware running environment according to an embodiment of the present application.
As shown in fig. 3, the service component scheduling apparatus may include: a processor 1001, a memory 1005, and a communication bus 1002. The communication bus 1002 is used to enable connected communication between the processor 1001 and the memory 1005.
Optionally, the service component scheduling device may further include a user interface, a network interface, a camera, an RF (Radio Frequency) circuit, a sensor, a WiFi module, and so on. The user interface may include a Display, an input sub-module such as a Keyboard (Keyboard), and the optional user interface may also include a standard wired interface, a wireless interface. The network interface may include a standard wired interface, a wireless interface (e.g., WI-FI interface).
Those skilled in the art will appreciate that the business component scheduling apparatus structure shown in fig. 3 does not constitute a limitation of the business component scheduling apparatus, and may include more or fewer components than shown, or may combine certain components, or may be a different arrangement of components.
As shown in fig. 3, an operating system, a network communication module, and a service component scheduler may be included in the memory 1005, which is one type of storage medium. An operating system is a program that manages and controls the hardware and software resources of a business component scheduler, supporting the operation of the business component scheduler as well as other software and/or programs. The network communication module is used to enable communication between components within the memory 1005 and with other hardware and software in the business component scheduling system.
In the service component scheduling apparatus shown in fig. 3, a processor 1001 is configured to execute a service component scheduling program stored in a memory 1005, and implement the steps of the service component scheduling method described in any one of the above.
The specific implementation manner of the service component scheduling device is basically the same as that of each embodiment of the service component scheduling method, and is not repeated here.
The application also provides a service component scheduling device, which further comprises:
The first determining module is used for determining a service component to be called according to the received component calling request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local calling server;
and the second determining module is used for determining remote call or call of the business component through the local communication channel based on a preset scheduling strategy so as to execute business service application corresponding to the business component, wherein the preset scheduling strategy is associated with the scheduling frequency of the business component, and the local communication channel is used for carrying out local call on the business component.
In one possible embodiment of the present application, the second determining module includes:
the acquisition unit is used for acquiring the real-time calling frequency of the service component;
the comparison unit is used for comparing the real-time calling frequency with a preset threshold value to obtain a comparison result;
the first calling unit is used for calling the service component through the local communication channel if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value;
And the second calling unit is used for remotely calling the service component if the comparison result shows that the real-time calling frequency is smaller than a preset threshold value.
In one possible implementation manner of the present application, the first calling unit includes:
the verification subunit is used for verifying the request parameters corresponding to the component call request if the comparison result shows that the real-time call frequency is greater than or equal to a preset threshold value, so as to obtain a verification result;
and the calling subunit is used for calling the corresponding service component through the local communication channel and the analysis executor if the verification result is that the verification is passed.
In a possible embodiment of the present application, the apparatus further comprises:
the deployment module is used for deploying the service type component to the cloud platform according to the component calling request and loading the function type component to the analysis executor, wherein the function type component is stored in the analysis executor in a static code mode, and is converted into an operation state when being called, and the service type component is used for caching or preloading data corresponding to the business service application.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.
The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) as described above, including several instructions for causing a terminal device (which may be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to perform the method described in the embodiments of the present application.
The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the claims, and all equivalent structures or equivalent processes using the descriptions and drawings of the present application, or direct or indirect application in other related technical fields are included in the scope of the claims of the present application.

Claims (10)

1. A business component scheduling method, characterized by being applied to a cloud platform, comprising the following steps:
determining a service component to be called according to the received component call request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local call server;
and determining to remotely call or call the service component through the local communication channel based on a preset scheduling policy so as to execute the service application corresponding to the service component, wherein the preset scheduling policy is associated with the scheduling frequency of the service component, and the local communication channel is used for locally calling the service component.
2. The business component scheduling method of claim 1, wherein the step of determining to call the business component remotely or through the local communication channel based on a preset scheduling policy comprises:
Acquiring the real-time calling frequency of the service component;
comparing the real-time calling frequency with a preset threshold value to obtain a comparison result;
if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, calling the service component through the local communication channel;
and if the comparison result shows that the real-time calling frequency is smaller than a preset threshold value, remotely calling the service component.
3. The service component scheduling method according to claim 2, wherein the step of calling the service component through the local communication channel if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value includes:
if the comparison result shows that the real-time calling frequency is greater than or equal to a preset threshold value, verifying the request parameters corresponding to the component calling request to obtain a verification result;
and if the verification result is that the verification is passed, calling a corresponding service component through the local communication channel and the analysis executor.
4. The business component scheduling method of claim 1, wherein the business components construct business service applications through a low code platform so that the number of codes corresponding to the transmitted business components is reduced when at least one business component is scheduled.
5. The service component scheduling method of claim 1, further comprising, after the step of determining the service component to be invoked according to the component invocation request:
and deploying the service type component to a cloud platform according to the component calling request, and loading the functional type component to an analysis executor, wherein the functional type component is stored in the analysis executor in a static code mode, and is converted into an operation state when being called, and the service type component is used for caching or preloading data corresponding to the business service application.
6. The business component scheduling method of claim 5, wherein the parsing executor integrates multiple program language packages, and flexibly programs the loaded business components when the parsing executor loads the business components containing multiple program languages.
7. The business component scheduling method of claim 1, wherein the business service application is decoupled from the business component, and wherein the business service application corresponding to the business component remains unchanged when the operational state of the business component changes.
8. A service component scheduling apparatus, characterized in that the service component scheduling apparatus comprises:
The first determining module is used for determining a service component to be called according to the received component calling request, wherein the service component comprises a functional component and a service component, and a local communication channel is arranged among the functional component, the service component, an analysis executor of a cloud platform and a local calling server;
and the second determining module is used for determining remote call or call of the business component through the local communication channel based on a preset scheduling strategy so as to execute business service application corresponding to the business component, wherein the preset scheduling strategy is associated with the scheduling frequency of the business component, and the local communication channel is used for carrying out local call on the business component.
9. A business component scheduling apparatus, the apparatus comprising: memory, a processor and a business component scheduler stored on the memory and executable on the processor, the business component scheduler being configured to implement the steps of the business component scheduling method of any of claims 1 to 7.
10. A computer storage medium having stored thereon a service component scheduler, which when executed by a processor, implements the steps of the service component scheduling method of any one of claims 1 to 7.
CN202311149395.7A 2023-09-06 2023-09-06 Service component scheduling method, device, equipment and storage medium Pending CN117294770A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311149395.7A CN117294770A (en) 2023-09-06 2023-09-06 Service component scheduling method, device, equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311149395.7A CN117294770A (en) 2023-09-06 2023-09-06 Service component scheduling method, device, equipment and storage medium

Publications (1)

Publication Number Publication Date
CN117294770A true CN117294770A (en) 2023-12-26

Family

ID=89256360

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311149395.7A Pending CN117294770A (en) 2023-09-06 2023-09-06 Service component scheduling method, device, equipment and storage medium

Country Status (1)

Country Link
CN (1) CN117294770A (en)

Similar Documents

Publication Publication Date Title
US20200137151A1 (en) Load balancing engine, client, distributed computing system, and load balancing method
JP5030592B2 (en) Scalable synchronous and asynchronous processing of monitoring rules
CN109302483A (en) A kind of management method and system of application program
US20060053415A1 (en) Method and system for efficiently interpreting a computer program
US11716264B2 (en) In situ triggered function as a service within a service mesh
US20060271911A1 (en) Generating executable objects implementing methods for an information model
US8640150B2 (en) Information processing terminal, information processing method, and program product
CN115061717B (en) Application management method, application subscription method and related equipment
JP2011118587A (en) System for executing cooperative service by plurality of servers
WO2024002299A1 (en) Application management method, application subscription method, and related device
CN111736809A (en) Distributed robot cluster network management framework and implementation method thereof
US8205199B2 (en) Method and system for associating new queues with deployed programs in distributed processing systems
CN110730197B (en) Service discovery method and system
US20100023950A1 (en) Workflow processing apparatus
JP2005531061A (en) Execution environment for mobile applications
CN111683005A (en) Internet of things intelligent gateway equipment and construction method thereof
CN117294770A (en) Service component scheduling method, device, equipment and storage medium
CN111831402A (en) Method, apparatus and computer program product for managing software functions
CN109218259B (en) License management method and device, APPLM functional entity and computer readable storage medium
JP2000259417A (en) Device and method for data processing and program providing medium
CN115987872A (en) Cloud system based on resource routing
CN105827567B (en) Service management and control method and capability opening platform
CN110198225A (en) A kind of management method and management server of more clusters
CN114625479A (en) Cloud edge collaborative application management method in edge computing and corresponding device
CN114610509A (en) Calling parameter processing method, system, device, storage medium and product

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination