CN116560756A

CN116560756A - Service orchestration method, electronic device, computer-readable storage medium

Info

Publication number: CN116560756A
Application number: CN202310850867.5A
Authority: CN
Inventors: 池虹雨; 王耀威; 李潘; 山其本; 袁锦宇
Original assignee: Peng Cheng Laboratory
Current assignee: Peng Cheng Laboratory
Priority date: 2023-07-12
Filing date: 2023-07-12
Publication date: 2023-08-08
Anticipated expiration: 2043-07-12
Also published as: CN116560756B

Abstract

The present invention relates to the field of data processing technologies, and in particular, to a service orchestration method, an electronic device, and a computer-readable storage medium. The service arrangement method of the application needs to acquire service configuration information and service coding programs first, and then performs standardized encapsulation processing based on each service configuration information and corresponding service coding programs to generate a service coding packet. After the service code packet is generated, service access information is acquired. Determining a target service program corresponding to the service configuration information and the service access information from the service coding packet based on the service access information; based on the target service program, a target service is created. And acquiring a service arrangement instruction, and arranging and processing the target service based on the service arrangement instruction to obtain an application service program. The service coding packet is generated by carrying out standardized encapsulation processing on each service configuration information and the corresponding service coding program, so that the reusable service capacity can be more efficiently docked.

Description

Service orchestration method, electronic device, computer-readable storage medium

Technical Field

The present invention relates to the field of data processing technologies, and in particular, to a service orchestration method, an electronic device, and a computer-readable storage medium.

Background

With the rapid development of information technology, the arrangement mode of algorithm service is in a rapid development stage, and various algorithms or various applications are landed in a high-efficiency low-code or non-coding management mode, so that the method is a mode which is willing to be widely adopted by large-scale information technology projects. In a broad informationized integration project, there are two general collections: integration represents various capabilities, such as a vehicle driving database, a vehicle snapshot camera, a license plate recognition algorithm, a picture license plate recognition interface and the like; the second set represents various application services such as park gate management, vehicle overspeed management, blacklist vehicle tracking management. It should be noted that the relationship between the first set and the second set is actually a many-to-many relationship, for example, the campus gateway management project needs to use the four types of capabilities listed in the first set, and when building the vehicle overspeed management application and the blacklist vehicle tracking management application, various types of capabilities in the first set need to be multiplexed.

In the related art, multiplexing of service capability is required to be achieved by interfacing at a code level, and interfacing at the code level often requires a programmer to complete, so that the efficiency of such a service arrangement manner is not high. Therefore, how to more efficiently dock reusable service capabilities has become a problem to be solved in the industry.

Disclosure of Invention

The present application aims to solve at least one of the technical problems existing in the prior art. To this end, the present application proposes a service orchestration method, an electronic device, a computer-readable storage medium, capable of more efficient interfacing of reusable service capabilities.

According to an embodiment of the first aspect of the present application, a service orchestration method comprises:

acquiring a first number of service configuration information and a first number of service coding programs;

performing normalized encapsulation processing based on each service configuration information and the corresponding service coding program to generate a service coding packet;

after the service coding packet is generated, acquiring a second number of service access information;

determining a second number of target service programs corresponding to the service configuration information and the service access information from the service coding packet based on the second number of service access information;

creating a second number of target services based on the second number of target service programs;

and acquiring a service arrangement instruction, arranging a second number of target services based on the service arrangement instruction, and establishing an association relationship of the second number of target services to obtain an application service program.

According to some embodiments of the present application, the generating a service coding packet based on normalized packaging processing performed by each service configuration information and the corresponding service coding program includes:

creating a service call port based on each service configuration information and the corresponding service coding program to obtain a service call specification;

and generating the service coding package based on the service coding program and the service call specification.

According to some embodiments of the present application, the service coding program corresponding to the service configuration information is used for providing an interface calling service;

the creating a service call port based on each service configuration information and the corresponding service coding program to obtain a service call specification includes:

determining an interface gateway address and an interface request parameter according to the service configuration information;

and creating the service call port in a standardized format based on the interface gateway address and the interface request parameter to obtain the service call specification.

According to some embodiments of the present application, the creating the service call port in a normalized format based on the interface gateway address and the interface request parameter, to obtain the service call specification includes:

Generating an interface calling request and an interface verification request based on the interface request parameters;

the interface calling request and the interface verification request are sent to an interface server through the interface gateway address;

acquiring calling feedback parameters and verification feedback parameters from the interface server;

and when the verification feedback parameters meet a preset first verification condition, the call feedback parameters are included in the service call specification.

According to some embodiments of the present application, the service encoding program corresponding to the service configuration information is used for providing a data source calling service;

determining a data source standardized call statement, target type information and login verification information according to the service configuration information;

acquiring multiple types of alternative data sources through the data source standardized calling statement;

determining a target data source from a plurality of types of the alternative data sources based on the target type information;

and creating the service call port based on the login verification information and the target data source to obtain the service call specification.

According to some embodiments of the present application, the service encoding program corresponding to the service configuration information is used for providing an algorithm service;

acquiring an algorithm code packet based on the service configuration information;

and creating the service call port based on the algorithm code package and the service coding program to obtain the service call specification.

According to some embodiments of the present application, the service configuration information includes environment configuration information and program configuration information;

the step of generating a service code packet based on normalized encapsulation processing of each service configuration information and the corresponding service code program includes:

creating an environment deployment file based on the environment configuration information;

determining the service coding program corresponding to the program configuration information from a first number of the service coding programs;

and integrating the environment deployment file with the service coding program to generate the service coding packet.

According to some embodiments of the present application, the service orchestration instructions include function orchestration instructions, data filtering configuration instructions, and current limiting program configuration instructions;

The step of arranging the second number of the target services based on the service arrangement instruction, establishing the association relation of the second number of the target services, and obtaining the application service program, includes:

determining a third number of flow sub-services from the second number of target services based on the function programming instruction, and arranging the third number of flow sub-services to generate a function service program;

determining an interactive operation code section from a third number of the flow sub-services based on the current limiting program configuration instruction, and configuring a preset current limiting sub-program in the interactive operation code section of the function service program;

determining a data acquisition code segment from a third number of the flow sub-services based on the data filtering configuration instruction, and configuring a preset data filtering sub-program after the data acquisition code segment of the function service program;

and determining the function service program configured with the current limiting subprogram and the data filtering subprogram as the application service program.

In a second aspect, an embodiment of the present application provides an electronic device, including: a memory, a processor, the memory storing a computer program, the processor implementing a service orchestration method according to any one of the embodiments of the first aspect of the present application when the computer program is executed.

In a third aspect, embodiments of the present application provide a computer readable storage medium storing a program that is executed by a processor to implement a service orchestration method according to any one of the embodiments of the first aspect of the present application.

The service arrangement method according to the embodiment of the application has at least the following beneficial effects:

according to the service arrangement method, the first number of service configuration information and the first number of service coding programs are acquired first, and then normalized packaging processing is carried out on the basis of each service configuration information and the corresponding service coding programs to generate the service coding packet. After the service encoding packet is generated, a second number of service access information is obtained. Further, determining a second number of target service programs corresponding to the service configuration information and the service access information from the service coding packet based on the second number of service access information; still further, a second number of target services is created based on the second number of target services. And further, acquiring a service arrangement instruction, arranging the second number of target services based on the service arrangement instruction, and establishing an association relationship of the second number of target services to obtain the application service program. The service coding packet is generated by carrying out standardized encapsulation processing on each service configuration information and the corresponding service coding program, so that the reusable service capacity can be more efficiently docked.

Additional aspects and advantages of the application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application.

Drawings

The foregoing and/or additional aspects and advantages of the present application will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a schematic flow chart of an alternative service orchestration method according to embodiments of the present application;

FIG. 2 is a schematic diagram of an alternative flow of step S102 in FIG. 1;

FIG. 3 is a schematic diagram of an alternative flow chart of step S102 in FIG. 1;

FIG. 4 is a schematic diagram of an alternative flow chart of step S301 in FIG. 3;

FIG. 5 is a schematic diagram of an alternative flow chart of step S402 in FIG. 4;

FIG. 6 is a schematic diagram of an alternative flow chart of step S301 in FIG. 3;

FIG. 7 is a schematic diagram of an alternative flow chart of step S301 in FIG. 3;

FIG. 8 is a schematic diagram of an alternative flow chart of step S106 in FIG. 1;

fig. 9 is a schematic hardware structure of an electronic device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to like or similar elements or elements having like or similar functions throughout. The embodiments described below by referring to the drawings are exemplary only for the purpose of explaining the present application and are not to be construed as limiting the present application.

In the description of the present application, the meaning of a number is one or more, the meaning of a number is two or more, greater than, less than, exceeding, etc. are understood to not include the present number, and the meaning of a number above, below, within, etc. are understood to include the present number. The description of the first and second is for the purpose of distinguishing between technical features only and should not be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated or implicitly indicating the precedence of the technical features indicated.

In the description of the present application, it should be understood that the direction or positional relationship indicated with respect to the description of the orientation, such as up, down, left, right, front, rear, etc., is based on the direction or positional relationship shown in the drawings, is merely for convenience of describing the present application and simplifying the description, and does not indicate or imply that the apparatus or element to be referred to must have a specific orientation, be configured and operated in a specific orientation, and thus should not be construed as limiting the present application.

In the description of the present specification, reference to the terms "one embodiment," "some embodiments," "illustrative embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations of the above terms do not necessarily refer to the same embodiments or examples. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

In the description of the present application, unless explicitly defined otherwise, terms such as arrangement, installation, connection, etc. should be construed broadly and the specific meaning of the terms in the present application can be reasonably determined by a person skilled in the art in combination with the specific content of the technical solution. In addition, the following description of specific steps does not represent limitations on the order of steps or logic performed, and the order of steps and logic performed between steps should be understood and appreciated with reference to what is described in the embodiments.

Referring to fig. 1, the service orchestration method provided according to the embodiments of the present application may include, but is not limited to, steps S101 to S106 described below.

Step S101, obtaining a first number of service configuration information and a first number of service coding programs;

step S102, carrying out standardized encapsulation processing on the basis of each service configuration information and a corresponding service coding program to generate a service coding packet;

step S103, after generating the service coding packet, acquiring a second number of service access information;

step S104, determining a second number of target service programs corresponding to the service configuration information and the service access information from the service coding packet based on the second number of service access information;

Step S105, creating a second number of target services based on the second number of target service programs;

and S106, acquiring a service arrangement instruction, arranging a second number of target services based on the service arrangement instruction, and establishing an association relationship of the second number of target services to obtain the application service program.

The following describes steps S101 to S106.

In step S101 of some embodiments, a first number of service configuration information and a first number of service codes are acquired. The service encoding program refers to an encoding program for providing local service capability. It should be noted that, in order to configure an application service to be used, a service encoding program is applied to a specific scenario, and in addition to a service encoding program for providing application service execution logic, service configuration information for providing a parameter basis is required to be acquired, so that the application service is adaptively configured according to the service encoding program based on the service configuration information.

In some embodiments, the service code may be a code for accessing an algorithm, a code for invoking an application programming interface (ApplicationProgrammingInterface, API), or a code for accessing a data source or data stream. It should be appreciated that the types of service code programs are numerous and not limited to the specific embodiments set forth above. Correspondingly, based on various types of service coding programs, various service configuration information, such as service identification information, application service type, service access mode, and the like, exists.

It should be clear that the acquisition of the service coding program and the service configuration information can be realized through the information input of the input device, can be called from some preset databases, and can also be in other types of acquisition modes.

In step S102 of some embodiments, a service coding packet is generated based on normalized encapsulation processing performed by each service configuration information and a corresponding service coding program. It should be noted that, the normalized encapsulation process refers to encapsulating various service coding programs to form a unified service port for external calling.

The following is a description of conventional service arrangement, and the problems of the conventional service arrangement:

first, the conventional service arrangement method faces to multi-service logic, and needs to split the flow service. Specifically, various service control components are required to be utilized, and each service flow is called in turn according to a preset business logic rule. It should be noted that, once the manner of splitting the flow service needs to control too much service, the coupling degree is too high, and a bulky situation is easy to occur.

Secondly, in the message-driven mode of the traditional service arrangement mode, each service operation needs to control the flow of each service through a message monitoring mechanism, and the mode is difficult to directly monitor the processing link of each service. In order to realize effective monitoring of each processing link, an additional monitoring system is required to be added, and the landing cost is correspondingly increased while the redundancy is increased.

Third, the API gateway of the conventional service orchestration approach can be seen as a simple interface aggregation or service splitting. After the application service is generated, the gateway needs to be reached first, and the gateway calls each micro service and finally aggregates/splits the result needing to be fed back. This way is simply a network adapter, and when the service logic is too high, the gateway interface coupling degree and complexity will be increased sharply, and become bloated, so that the method is only suitable for the scene with simpler service logic.

In some embodiments provided herein, a service coding packet is generated by performing normalized encapsulation processing based on each service configuration information and a corresponding service coding program, so as to solve the problems existing in the conventional service arrangement manner. Specifically, after the service configuration information and the service code program are acquired, an environment deployment file for deploying the base operating environment needs to be displayed, which is generated from the service configuration information. And pulling the environment deployment file based on a preset service file template and a service coding program to form a corresponding service coding packet. It should be noted that after the creation of the service code packet is completed, the service port corresponding to the service code packet may be exposed to external access.

Referring to fig. 2, according to some embodiments of the present application, the service configuration information includes environment configuration information and program configuration information, and step S102 may include, but is not limited to, steps S201 to S203 described below.

Step S201, creating an environment deployment file based on environment configuration information;

step S202, determining a service coding program corresponding to the program configuration information from the first number of service coding programs;

step S203, integrating the environment deployment file with the service coding program to generate a service coding package.

The following describes step S201 to step S203.

In steps S201 to S203 of some embodiments, an environment deployment file is created based on the environment configuration information, then a service encoding program corresponding to the program configuration information is determined from the first number of service encoding programs, and further, the environment deployment file and the service encoding program are integrated to generate a service encoding packet. It should be noted that, in some embodiments, different types of service code programs need to be normally loaded in different basic operating environments, and conventional service arrangement modes often only combine various service control components for providing capabilities, so that compatibility problems caused by differences of the basic operating environments are ignored. For example, JAVA applications need to deploy JDK environments, and front-end applications need to deploy Linux environments.

Some embodiments are provided in which the service configuration information includes environment configuration information and program configuration information. The environment configuration information is used for configuring a basic operation environment corresponding to the service coding program, and the program configuration information is used for configuring actual parameters to be filled in the service coding program. Based on the environment configuration information, creation of an environment deployment file may be achieved. It is emphasized that the environment deployment file is used to deploy the underlying operating environment. After the environment deployment file is created, a service coding program corresponding to the program configuration information is further determined from the first number of service coding programs, and then the environment deployment file and the service coding program are integrated, so that a service coding package can be generated. It is clear that the service code package includes both an environment deployment file for deploying the basic operating environment and a service code program for providing local service capability, so that the service code program can be deployed corresponding to the basic operating environment based on the environment deployment file, thereby improving the compatibility problem caused by the difference of the basic operating environments.

It should be noted that Kubernetes (K8S) is a technique for managing the organization of portable containers for container services. Kubernetes provides a series of functions of deployment operation, resource scheduling, service discovery, dynamic scaling and the like for containerized applications on the basis of Docker technology. Recently, more and more application programs are transplanted from a host platform to a Kubernetes platform, and resource abstraction and resource management are realized through the Kubernetes platform, however, the Kubernetes platform architecture is different from the host platform architecture, the host platform architecture is mainly based on that a processor in a host supports running of an application by using local resources, while the Kubernetes platform architecture is based on a distributed cluster server at the bottom layer to provide computing power, and further, operations such as cluster management, scheduling optimization and the like are performed on resources required by the application programs through a Kubernetes operating system. It should be clear that the Kubernetes cloud platform is a container cluster management system that provides a container-centric infrastructure for ease and efficiency of deploying containerized applications. The Kubernetes cloud platform supports automated deployment, large scale scalability, application containerization management, when an application is deployed in a production environment, multiple instances of the application are typically deployed for load balancing application requests. In the Kubernetes cloud platform, we can create multiple containers, each container runs an application instance, and then manage, discover and access the group of application instances through a built-in load balancing strategy, and the details do not need operation and maintenance personnel to carry out complex manual configuration and processing.

In some more specific embodiments, the service configuration information may include a generic configuration file (config file), and the execution subject to which the service orchestration method of the present application is applied may be a Kubernetes cloud platform. After the config file and the service coding program are acquired, a corresponding master host (the master host is a Server node of the Kubernetes cloud platform) is accessed through the acquired config file, the config file is copied to the local in the master host, and then the client object created by taking the config file as an entry is further used for accessing the API Server of the Kubernetes cloud platform.

And configuring a deployment file for deploying a basic operating environment in a dockerfile template according to a config file in a client object in an API Server of the Kubernetes cloud platform, and further pulling a corresponding environment deployment file according to a service coding program and the configured dockerfile template to form a deployable service coding package, wherein the format of the service coding package is a docker image file. Still further, a replyment file is created according to the constructed service coding packet, an application service is created according to the replyment file, and finally a service port corresponding to the application service is exposed to the outside for external access.

It should be noted that, either the service code for accessing an algorithm, the service code for calling an application programming interface, or the code for accessing a data source or data stream may be packaged as an external service port for calling in the above manner. These packaged services are stored in a modular form for the user to invoke orchestration.

Referring to fig. 3, step S102 may include, but is not limited to, steps S301 to S302 described below, according to some embodiments of the present application.

Step S301, a service call port is created based on each service configuration information and a corresponding service coding program, and a service call specification is obtained;

step S302, a service coding packet is generated based on the service coding program and the service call specification.

The following describes step S301 to step S302.

In steps S301 to S302 of some embodiments, a service call port is created based on each service configuration information and a corresponding service coding program, a service call specification is obtained, and then a service coding packet is generated based on the service coding program and the service call specification. The service call specification is a specification for describing a service call port, which is obtained in the service call port creation process. In some embodiments, when the service encoding program corresponding to the service configuration information is used for providing the interface call service, the service call specification may specifically include a return value of the interface call, or a description document generated by integrating relevant parameters of the interface call; when the service coding program corresponding to the service configuration information is used for providing the data source calling service, the service calling specification can specifically include a calling return value of the target data source, or a description document generated by integrating related calling parameters of the target data source; when the service coding program corresponding to the service configuration information is used for providing the algorithm service, the service call specification may specifically include a return value of the algorithm call. It should be appreciated that the types of service invocation specifications are numerous and may include, but are not limited to, the specific embodiments set forth above. After the service invocation specification is obtained, a service encoding package can be generated further based on the service encoding program and the service invocation specification.

Through the embodiments shown in steps S301 to S302, the service code package is generated on the basis of the service code program and the service call specification, and the service code programs providing various capabilities can be uniformly packaged in the service code package. In this way, algorithms from different platforms and devices, different types of data sources and different data service interfaces can be connected in series through the above embodiments, and the algorithms, data input sources and service interfaces are arranged into a complete algorithm workflow through a unified abstract port specification. Therefore, the workflow layout of cross-platform, cross-equipment, cross-data sources and cross-data services can be realized, so that the flexibility and adaptability of the workflow are improved, the workflow design of different scenes and requirements is met, and the problems of compatibility and dependence are improved.

Referring to fig. 4, according to some embodiments of the present application, a service encoding program corresponding to service configuration information is used to provide an interface call service, and step S301 may include, but is not limited to, steps S401 to S402 described below.

Step S401, according to the service configuration information, determining the interface gateway address and the interface request parameter;

Step S402, a service call port is created in a standardized format based on the interface gateway address and the interface request parameter, and a service call specification is obtained.

The following describes steps S401 to S402.

In step S401 of some embodiments, an interface gateway address and an interface request parameter are determined according to the service configuration information. It should be noted that the gateway interface is a section of program, which runs on the WEB server and provides an interface with the HTML page of the client. The gateway interface is used for connecting the webpage with the execution program in the WEB server, transmitting the instruction received by the HTML to the WEB server, and returning the execution result of the WEB server to the HTML page. The gateway interface can be used for processing a plurality of operations such as forms, database inquiry, email sending and the like. The gateway interface transitions the web page from static to interactive. It should be noted that the interface gateway address refers to the address of the gateway interface, and the interface request parameter is a parameter required for implementing a certain function request through the gateway interface. The interface gateway address and the interface request parameter may be obtained through an input device (such as a mouse, a touch screen, etc.), or may be obtained by calling from a preset database. It should be understood that the ways of obtaining the interface gateway address and the interface request parameter are various, and may include, but are not limited to, the above-mentioned embodiments.

In step S402 of some embodiments, a service call port is created in a normalized format based on the interface gateway address and the interface request parameter, resulting in a service call specification. It should be noted that, after the interface gateway address and the interface request parameter are acquired, the creation of the service call port may be performed. The standardized format is used for unifying various interfaces for standardization. Note that JS object numbered musical notation (JavaScript Object Notation, JSON) is a lightweight data exchange format. It stores and presents data in a text format that is completely independent of the programming language based on a subset of js specifications (European Computer Manufacturers Association, ECMAScript) established by the european computer institute. The compact and clear hierarchical structure makes JSON an ideal data exchange language. Is easy to read and write by people, is easy to analyze and generate by machines, and effectively improves the network transmission efficiency. Thus, JSON format may be used as a canonical format in embodiments of the present application.

Through the embodiments of the present application shown in steps S401 to S402, according to the service configuration information, the interface gateway address and the interface request parameter are determined, and then the service call port is created in a standardized format based on the interface gateway address and the interface request parameter, so as to obtain the service call specification. The method can effectively integrate the interface call services of various types in different service coding programs and create the service call ports in a standardized format. It should be noted that the service invocation specification thus obtained may be used for further integration with a service encoding program to generate a service encoding package. Therefore, various service coding programs for executing the interface calling service can be integrated through the unified abstract port specification, and the compatibility problem caused by the difference of the service coding programs is solved.

Referring to fig. 5, step S402 may include, but is not limited to, steps S501 to S504 described below, according to some embodiments of the present application.

Step S501, generating an interface call request and an interface verification request based on the interface request parameters;

step S502, an interface calling request and an interface verification request are sent to an interface server through an interface gateway address;

step S503, obtaining calling feedback parameters and verification feedback parameters from an interface server;

in step S504, when the verification feedback parameter meets the preset first verification condition, the call feedback parameter is included in the service call specification.

The following describes step S501 to step S504.

In steps S501 to S504 of some embodiments, an interface call request and an interface verification request are generated based on the interface request parameter, and then the interface call request and the interface verification request are sent to an interface server through an interface gateway address, further, a call feedback parameter and a verification feedback parameter are obtained from the interface server, and when the verification feedback parameter meets a preset first verification condition, the call feedback parameter is included in a service call specification. It should be noted that, the interface call request and the interface verification request may be generated based on the interface request parameter. The interface call request is used for requesting specific interface call, and the interface verification request is used for verifying whether the called interface is abnormal or not. And verifying feedback parameters, namely verifying the called interface and obtaining the feedback parameters. When the verification feedback parameters meet the preset first verification conditions, the verification means that the called interface passes the verification, and the call feedback parameters can be brought into the service call specification.

In some more specific embodiments, the user may configure the interface gateway address and the interface request parameter through the service configuration information, and the system as the execution subject of the embodiments of the present application needs to use a unified JSON format to make an API request based on the interface gateway address and the interface request parameter. Specifically, the system reads the interface gateway address and the interface request parameter configured by the user, further, the system sets a JSON object, writes the interface gateway address and the interface request parameter configured by the user into the JSON object, performs an http request through httpclient, and verifies whether the return values of the APIs of different platforms comprise abnormal values or not. An API for which there is no outlier in the return value is judged to be connected. Still further, the API interface return value is read, and corresponding return parameters are generated through MAP. And finally integrating all the return parameters to form a parameter document. The service call specification may be a return parameter generated by MAP or a parameter document generated by integrating the return parameters.

In the embodiment of the application shown in steps S501 to S504, in the process of determining the service call specification, an interface call request and an interface verification request are generated based on the interface request parameter, when the verification feedback parameter meets the first preset condition, the called interface is considered to be abnormal, and further the call feedback parameter corresponding to the interface call request is determined to be the service call specification, so that the security and reliability of interface call can be improved.

Referring to fig. 6, according to some embodiments of the present application, a service encoding procedure corresponding to service configuration information is used to provide a data source invoking service, and step S301 may include, but is not limited to, steps S601 to S604 described below.

Step S601, determining a data source standardized call statement, target type information and login verification information according to service configuration information;

step S602, obtaining multiple types of alternative data sources through a data source standardized call statement;

step S603, determining a target data source from a plurality of types of alternative data sources based on the target type information;

step S604, a service call port is created based on the login verification information and the target data source, and a service call specification is obtained.

The following describes step S601 to step S604.

In step S601 of some embodiments, a data source normalized call statement, target type information, and login verification information are determined according to service configuration information. It should be noted that, the data source normalized call statement refers to a data source call code statement written in a normalized programming language. The target type information is used for indicating the type of the data source to be connected, and the login verification information is the verification information required by accessing the data source.

Note that SQL (Structured Query Language) is a database language with multiple functions such as data manipulation and data definition, and this language has an interactive characteristic, which can provide great convenience for users, and the database management system should make full use of the SQL language to improve the working quality and efficiency of the computer application system. The SQL language can be independently applied to the terminal, and can also be used as a sub-language to provide effective assistance for other programming. Thus, in some more specific embodiments, the SQL language is used as the normalized programming language, and the data source normalized call statement may refer to a data source call code statement written in the SQL language.

In step S602 of some embodiments, multiple types of alternative data sources are obtained by a data source normalized call statement. It should be noted that, multiple types of alternative data sources are obtained through the data source standardization calling sentence, so that the data source calling service provided for the service coding program accesses various alternative data sources in a unified way based on the data source standardization calling sentence, so as to make a selection from among the alternative data sources according to the target type information. In some embodiments, when the data source normalized call statement is a data source call code statement written in the SQL language, the data source types that are run-on may include, but are not limited to MySQL, mongoDB, pgSQL and ES.

In steps S603 to S604 of some embodiments, a target data source is determined from multiple types of candidate data sources based on the target type information, and then a service call port is created based on the login verification information and the target data source, so as to obtain a service call specification. It should be noted that, since the target type information is used to indicate the type of the data source that needs to be connected, the target data source can be determined from among multiple types of alternative data sources based on the target type information. And then, because the login verification information is verification information needed by accessing the data source, a service call port is created based on the login verification information and the target data source, and the service call specification can be obtained.

In some more specific embodiments, as a system of the execution body in the embodiments of the present application, the SQL statement may be used to execute the query, and different types of data sources (such as MySQL, mongoDB, pgSQL, ES) are accessed in a unified manner. Specifically, the data source normalized call statement, the target type information and the login verification information can be configured by a user through service configuration information, wherein the data source normalized call statement can refer to a data source call code statement written in SQL language. Furthermore, according to the standardized call statement of the data source configured by the user, various data sources to be connected are accessed, and the availability and stability of heterogeneous data connection are ensured. Still further, a target data source is determined from among the multiple types of alternative data sources based on the target type information, and a service call port is created based on the login verification information and the target data source to obtain a service call specification. The service call port is created based on the login verification information and the target data source to obtain service call specifications, or the system writes the login verification information and the target data source into the JSON object, and http request is carried out through httpclient to connect the API. Still further, the API interface return value is read, and corresponding return parameters are generated through MAP. And finally integrating all the return parameters to form a parameter document. It should be emphasized that the service invocation specification may be either a return parameter generated by MAP or a parameter document generated by integration of the return parameters.

Through the embodiments of the present application shown in steps S601 to S604, multiple types of candidate data sources may be effectively obtained through the data source normalized call statement, so that the target type information is compared, and the target data source is determined from the multiple types of candidate data sources. Therefore, various service coding programs for executing the data source calling service can be integrated through the unified abstract port specification, and the compatibility problem caused by the difference of the service coding programs is solved.

Referring to fig. 7, according to some embodiments of the present application, a service encoding program corresponding to service configuration information is used to provide an algorithm service, and step S301 may include, but is not limited to, steps S701 to S702 described below.

Step S701, acquiring an algorithm code packet based on service configuration information;

step S702, a service call port is created based on the algorithm code package and the service coding program, and a service call specification is obtained.

In steps S701 to S702 of some embodiments, an algorithm code packet is acquired based on the service configuration information, and then a service call port is created based on the algorithm code packet and the service coding program, so as to obtain a service call specification. It should be noted that, the service coding program corresponding to the service configuration information may be used to provide the algorithm service. In some embodiments, the algorithm code package may be obtained from the service configuration information, and the service encoding program includes a calling program for the algorithm code package, so that a service calling port for providing the algorithm service to the outside may be created based on the algorithm code package and the service encoding program. It should be noted that in creating a service call port based on an algorithm code package and a service coding program, a service call specification may be obtained, and the service call specification is used to integrate with the service coding program to generate a service code package.

In some more specific embodiments, for different algorithms, the user may package them into corresponding algorithm code packages. As the system of the execution main body of the embodiment of the application, the grammar information corresponding to the algorithm code package can be configured first, and then the algorithm code package is deployed into the operable service. In some embodiments, the algorithm code package can also be written into the JSON object by the system, and an http request is made through the httpclient, so that the API is connected. Still further, the API interface return value is read, and corresponding return parameters are generated through MAP. And finally integrating all the return parameters to form a parameter document. It should be emphasized that the service invocation specification may be either a return parameter generated by MAP or a parameter document generated by integration of the return parameters.

Through the embodiments of the present application shown in steps S701 to S702, various types of algorithm code packages can be effectively acquired from service configuration information, so as to provide various algorithm services. Therefore, various service coding programs for executing algorithm services can be integrated through the unified abstract port specification, and the compatibility problem caused by the difference of the service coding programs is solved.

In steps S103 to S104 of some embodiments, after the service encoding packet is generated, a second number of service access information is acquired, and based on the second number of service access information, a second number of target service procedures, in which the service configuration information corresponds to the service access information, is determined from the service encoding packet.

It is emphasized that in a wide range of informationized integration projects, there are two general collections: integrating one represents various capabilities; set two represents various application services. It should be noted that, through steps S101 to S102, various service encoding programs can be encapsulated into a service encoding packet based on the service configuration information, where the service encoding packet can be regarded as a set one containing various capabilities. Before the service arrangement is performed to form the application service, a plurality of capabilities needed for the service arrangement need to be determined, namely, a target service program needed to be used is determined from each service code program in the service code package. It should be noted that the service access information is used for comparing with the service configuration information in the encapsulated service coding packet, determining a corresponding service coding program according to the successfully compared service configuration information, and using the service coding program as a target service program. The service access information may include, but is not limited to, various information such as input service name, configuration service address, configuration service environment, and configuration service type.

In some more specific embodiments, the service code packet is encapsulated with, but not limited to: calling a service coding program of a vehicle parking registration database, calling a service coding program of a vehicle running database, controlling a camera to take vehicle shots, controlling the camera to take high-definition license plate pictures, executing a service coding program of a license plate recognition algorithm, executing a service coding program of vehicle speed measurement and executing a service coding program of parking state detection.

In order to arrange the application service of "vehicle overspeed management", some embodiments need to acquire service access information first, and then determine, based on the service access information, target service programs corresponding to the service access information in service configuration information from a service coding packet, where the target service programs include: calling a service coding program of a vehicle running database, a service coding program for controlling a camera to take vehicle shots, a service coding program for executing a license plate recognition algorithm and a service coding program for executing vehicle speed measurement, thereby realizing application service corresponding to vehicle overspeed management: the method comprises the steps of firstly measuring the speed of a vehicle, carrying out vehicle snapshot when an overspeed vehicle is detected, further carrying out a license plate recognition algorithm on a vehicle picture obtained by snapshot, comparing the recognized license plate number in a vehicle running database, and determining the vehicle attribution information.

In order to arrange the application service of "park entrance gateway management", some embodiments need to acquire service access information first, and then determine, based on the service access information, target service programs corresponding to the service configuration information and the service access information from the service code packet, where the target service programs include: calling a service coding program of a vehicle parking registration database, a service coding program for controlling a camera to shoot high-definition license plates, a service coding program for executing a license plate recognition algorithm and a service coding program for executing parking state detection, thereby realizing application service corresponding to park entrance and exit gateway management: firstly, parking state detection is carried out, when a vehicle is detected to be parked at an entrance barrier gate, high-definition license plate picture shooting is carried out, then a license plate recognition algorithm is carried out on the shot high-definition license plate picture, and vehicle parking information in a vehicle parking registration database is updated based on the recognized license plate number.

It should be appreciated that the capabilities used in different application scenarios may be the same or different and are provided by the target service program. Therefore, it is required to determine which target service programs in the service code packet need to be accessed according to the service access information, so that the application services can be arranged based on the accessed target service programs in the process of arranging the application later.

In step S105 of some embodiments, a second number of target services is created based on the second number of target services. It should be noted that, according to each target service program, a target service may be created. Accordingly, after determining a second number of target services for which the service configuration information corresponds to the service access information from the service coding package based on the second number of service access information, the second number of target services may be created based on the second number of target services.

In step S106 of some embodiments, a service orchestration instruction is obtained, and orchestration processing is performed on a second number of target services based on the service orchestration instruction, and an association relationship of the second number of target services is established, so as to obtain an application service program. It should be noted that, the service orchestration instruction is used to orchestrate the flow of the various services already created to form an overall application service. It is clear that after the second number of target services are arranged based on the service arrangement instruction, the association relation of the second number of target services is established. It should be noted that the association relationship of the second number of target services reflects the function implementation sequence of each target service, and each target service is sequentially executed according to the association relationship of the second number of target services, so that the corresponding application service required currently can be implemented. In this way, the second number of target services arranged according to the association relationship is the whole program of the second number of target services, which is the application service program for providing the application service.

Referring to fig. 8, according to some embodiments of the present application, the service orchestration instructions include a function orchestration instruction, a data filtering configuration instruction, and a current limiting program configuration instruction, and step S106 may include, but is not limited to, step S801 to step S804 described below.

Step S801, determining a third number of flow sub-services from the second number of target services based on the function programming instruction, and arranging the third number of flow sub-services to generate a function service program;

step S802, based on the current limiting program configuration instruction, determining an interactive operation code section from the third number of flow sub-services, and configuring a preset current limiting subprogram in the interactive operation code section of the function service program;

step S803, based on the data filtering configuration instruction, determining a data acquisition code segment from the third number of flow sub-services, and configuring a preset data filtering sub-program after the data acquisition code segment of the function service program;

in step S804, the function service program configured with the flow restriction subroutine and the data filtering subroutine is determined as the application service program.

The following describes step S801 to step S804.

In step S801 of some embodiments, a third number of flow sub-services is determined from the second number of target services based on the function programming instruction, and the third number of flow sub-services are arranged to generate a function service program. It should be noted that the function programming instruction is used to determine the third number of flow sub-services from the second number of target services, and arrange the third number of flow sub-services to form the execution sequence, so as to form the corresponding function service program.

In some more specific embodiments, in order to program the application service "vehicle overspeed management", it is necessary to acquire service access information first, then determine, based on the service access information, a target service program corresponding to the service access information in service configuration information from a service coding packet, further create each target service based on each target service program, and then determine, based on a function programming instruction, the following flow sub-service from each target service: invoking a flow sub-service of a vehicle running database, controlling a camera to perform vehicle snapshot, executing a flow sub-service of a license plate recognition algorithm, executing a flow sub-service of vehicle speed measurement, and arranging the flow sub-services to form an application service corresponding to vehicle overspeed management: the method comprises the steps of firstly measuring the speed of a vehicle, carrying out vehicle snapshot when an overspeed vehicle is detected, further carrying out a license plate recognition algorithm on a vehicle picture obtained by snapshot, comparing the recognized license plate number in a vehicle running database, and determining the vehicle attribution information.

In some embodiments, in order to program an application service of "park entrance and exit gateway management", service access information needs to be acquired first, then, based on the service access information, a target service program corresponding to the service configuration information and the service access information is determined from a service coding packet, each target service is further created based on each target service program, and then, based on a function programming instruction, the following flow sub-service is determined from each target service: invoking a flow sub-service of a vehicle parking registration database, controlling a camera to carry out high-definition license plate picture shooting, executing a license plate recognition algorithm, executing a parking state detection flow sub-service, and arranging the flow sub-services to form an application service corresponding to 'park entrance and exit gate management': firstly, parking state detection is carried out, when a vehicle is detected to be parked at an entrance barrier gate, high-definition license plate picture shooting is carried out, then a license plate recognition algorithm is carried out on the shot high-definition license plate picture, and vehicle parking information in a vehicle parking registration database is updated based on the recognized license plate number.

In step S802 of some embodiments, based on the current-limiting program configuration instruction, an interactive operation code segment is determined from the third number of flow sub-services, and a preset current-limiting subroutine is configured among the interactive operation code segments of the function service program. It should be noted that, in the present application, current limiting refers to limiting the frequency of message transmission in a certain interval during the process of receiving and transmitting data, so as to reduce the load of the system; wherein, the received and transmitted data keeps integrity on the content; the current limiter configuration instructions are for determining the interactive operation code segments from the third number of flow sub-services. The interactive operation code segment is a component of the function service program, and specifically refers to program code for executing external data interaction in the function service program. It should be understood that, the interactive operation code segment for performing data interaction externally may perform data interaction operation with higher frequency, which may bring about a small computational burden on the system as an execution body in the embodiment of the present application. In order to reduce the system load, the embodiments of the present application require configuring a preset current limiter subroutine in the interactive operation code segment of the function service program. The current limiting subroutine can perform current limiting operation on the interactive operation code section for externally executing data interaction according to a preset current limiting rule. In some more specific embodiments, the throttling operation may be implemented by paging reduced query data or reduced operation requests.

In step S803 of some embodiments, a data acquisition code segment is determined from the third number of flow sub-services based on the data filtering configuration instruction, and a preset data filtering sub-program is configured after the data acquisition code segment of the function service program. It should be noted that, in the data filtering in the present application, a part of data needed to be used is selected to be reserved in the process of data acquisition, and correction, conversion and filtering operations can be performed according to actual conditions for the data, repeated data, error data, invalid data and abnormal data which are not needed to be used, so that the data is more simplified, and the processing efficiency of the data is improved; the data filtering configuration instructions are for determining a data acquisition code segment from the third number of flow sub-services. Wherein the data acquisition code segment is an integral part of the function service program, and specifically refers to program code for acquiring data from outside in the function service program. It should be understood that, in the data acquisition code segment for acquiring data from outside, invalid data, erroneous data, useless data and abnormal data may be acquired together, which may cause redundancy and complexity of data transmission to the system as the execution subject of the embodiment of the present application. In order to clean and filter the acquired data, the embodiment of the application needs to configure a preset data filtering subroutine in a data acquisition code segment of the function service program. The data filtering subroutine may perform a cleaning operation on a data acquisition code segment for acquiring data from the outside according to a preset cleaning rule. In some specific embodiments, if the data obtained from the outside is of a single table type, the data can be cleaned and filtered through a WHERE condition, and if the data obtained from the outside is of a multi-table type, the cleaning and filtering can be realized through precompiled SQL sentences after the multi-tables are associated.

In step S804 of some embodiments, a function service program configured with a current limiter subroutine and a data filter subroutine is determined as an application service program.

After the embodiments shown in steps S801 to S804 are configured to the function service program, the configuration of the current limiting subroutine and the data filtering subroutine means that the function service program can reduce the system load when performing data interaction externally, and can ensure the simplification of the transmission data when acquiring the data from the outside. It is emphasized that the reduction of the transmission data is to screen the data used in the process to remove repeated data information, abnormal data and the like to obtain the needed high-quality data, so as to reduce the pressure of the system and improve the accuracy of arrangement.

Fig. 9 shows an electronic device 900 provided in an embodiment of the present application. The electronic device 900 includes: a processor 901, a memory 902 and a computer program stored on the memory 902 and executable on the processor 901, the computer program being operative to perform the service orchestration method described above.

The processor 901 and the memory 902 may be connected by a bus or other means.

The memory 902, as a non-transitory computer readable storage medium, may be used to store non-transitory software programs and non-transitory computer executable programs, such as the service orchestration methods described in embodiments of the present application. The processor 901 implements the service orchestration method described above by running non-transitory software programs and instructions stored in the memory 902.

The memory 902 may include a storage program area that may store an operating system, at least one application program required for functionality, and a storage data area. The storage data area may store information for performing the service orchestration method described above. In addition, the memory 902 may include high-speed random access memory 902 and may also include non-transitory memory 902, such as at least one storage device memory device, flash memory device, or other non-transitory solid state memory device. In some implementations, the memory 902 optionally includes memory 902 located remotely from the processor 901, the remote memory 902 being connectable to the electronic device 900 through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The non-transitory software programs and instructions required to implement the above-described service orchestration method are stored in the memory 902, and when executed by the one or more processors 901, the above-described service orchestration method is performed, for example, performing method steps S101 to S106 in fig. 1, method steps S201 to S203 in fig. 2, method steps S301 to S302 in fig. 3, method steps S401 to S402 in fig. 4, method steps S501 to S504 in fig. 5, method steps S601 to S604 in fig. 6, method steps S701 to S702 in fig. 7, and method steps S801 to S804 in fig. 8.

The embodiment of the application also provides a computer readable storage medium, which stores computer executable instructions for executing the service orchestration method.

In an embodiment, the computer-readable storage medium stores computer-executable instructions that are executed by one or more control processors, for example, to perform method steps S101 through S106 in fig. 1, method steps S201 through S203 in fig. 2, method steps S301 through S302 in fig. 3, method steps S401 through S402 in fig. 4, method steps S501 through S504 in fig. 5, method steps S601 through S604 in fig. 6, method steps S701 through S702 in fig. 7, and method steps S801 through S804 in fig. 8.

The above described apparatus embodiments are merely illustrative, wherein the units illustrated as separate components may or may not be physically separate, i.e. may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, storage device storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically include computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. It should also be appreciated that the various embodiments provided in the embodiments of the present application may be arbitrarily combined to achieve different technical effects.

While the preferred embodiments of the present application have been described in detail, the present application is not limited to the above embodiments, and various equivalent modifications and substitutions can be made by those skilled in the art without departing from the spirit and scope of the present application, and these equivalent modifications and substitutions are intended to be included in the scope of the present application as defined in the appended claims.

Claims

1. A method of service orchestration, comprising:

2. The method of claim 1, wherein generating a service code package based on the normalized encapsulation of each service configuration information with the corresponding service code program comprises:

3. The method of claim 2, wherein the service code program corresponding to the service configuration information is used to provide an interface call service;

4. The method of claim 3, wherein creating the service invocation port in a normalized format based on the interface gateway address and the interface request parameter results in the service invocation specification, comprising:

5. The method of claim 2, wherein the service coding program corresponding to the service configuration information is used for providing a data source calling service;

6. The method of claim 2, wherein the service coding program corresponding to the service configuration information is used for providing an algorithm service;

7. The method of claim 1, wherein the service configuration information includes environment configuration information and program configuration information;

8. The method of claim 1, wherein the service orchestration instructions comprise function orchestration instructions, data filtering configuration instructions, and current limiting program configuration instructions;

9. An electronic device, comprising: a memory, a processor storing a computer program, the processor implementing the service orchestration method according to any one of claims 1-8 when the computer program is executed.

10. A computer-readable storage medium storing a program that is executed by a processor to implement the service orchestration method according to any one of claims 1-8.