CN117573239A

CN117573239A - Interface calling method and device and electronic equipment

Info

Publication number: CN117573239A
Application number: CN202311515775.8A
Authority: CN
Inventors: 赵提; 章强; 杨悦; 杜啸争
Original assignee: Zhongdian Jinxin Digital Technology Group Co ltd
Current assignee: Zhongdian Jinxin Digital Technology Group Co ltd
Priority date: 2023-11-14
Filing date: 2023-11-14
Publication date: 2024-02-20

Abstract

The invention provides an interface calling method, an interface calling device and electronic equipment, wherein the method comprises the following steps: in this embodiment, when the target micro service is started, the interface configuration file is read to obtain configuration information of an interface published by at least one first service system in the distributed system. And loading configuration information of each interface into a memory, so that when a second service system in the distributed system calls any interface, corresponding call return data is generated based on the loaded configuration information, and the call return data is provided for the second service system. And simultaneously monitoring the running state of each interface and call return data of each interface so as to perform exception handling when any interface is abnormal. The interfaces issued by each service system are operated and maintained through the target micro-service, so that when other service systems need to call the interfaces, the target micro-service provides corresponding call return data according to the configuration information of the interfaces, the interfaces are decoupled from the service systems, and the coupling degree is reduced.

Description

Interface calling method and device and electronic equipment

Technical Field

The present invention relates to the field of information processing technologies, and in particular, to an interface calling method, an interface calling device, and an electronic device.

Background

In a distributed system, a plurality of service systems are usually included independently of each other. The data interaction between the business systems is realized through interfaces.

In the related art, a developer realizes an interface function in a code of an accessed service system, but the development mode leads to higher coupling degree between an interface and the service system and more difficult maintenance. In some scenarios, for example, financial management related service systems, the service complexity is high, and directly writing interface related codes in the codes of the service systems further increases the service complexity.

Disclosure of Invention

The present invention aims to solve at least one of the technical problems in the related art to some extent.

Therefore, a first object of the present invention is to provide an interface calling method, an interface calling device and an electronic device, so as to reduce the coupling degree between an interface and a service system in a distributed system.

A second object of the present invention is to provide an interface calling device.

A third object of the present invention is to propose an electronic device.

A fourth object of the present invention is to propose a non-transitory computer readable storage medium.

A fifth object of the invention is to propose a computer programme product.

To achieve the above object, an embodiment of a first aspect of the present invention provides an interface calling method, which is executed by a device running a target micro service, including:

responding to the target micro-service start, reading an interface configuration file to obtain configuration information of an interface issued by at least one first service system in the distributed system;

loading configuration information of each interface into a memory, generating corresponding call return data based on the loaded configuration information when a second service system in the distributed system calls any interface, and providing the call return data for the second service system;

and monitoring the running state of each interface and call return data of each interface so as to perform exception handling when any interface is abnormal.

To achieve the above object, an embodiment of a second aspect of the present invention provides an interface calling device, including:

the starting module is used for responding to the starting of the target micro-service and reading the interface configuration file to obtain the configuration information of the interface issued by at least one first service system in the distributed system;

the calling module is used for loading configuration information of each interface into a memory, generating corresponding calling return data based on the loaded configuration information when a second service system in the distributed system calls any interface, and providing the calling return data for the second service system;

The monitoring module is used for monitoring the running state of each interface and call return data of each interface so as to carry out exception handling when any interface is abnormal.

In order to achieve the above object, an embodiment of a third aspect of the present invention provides an electronic device, including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores computer instructions that are executed by the at least one processor to cause the at least one processor to perform the method of the first aspect described above.

To achieve the above object, an embodiment of a fourth aspect of the present invention proposes a non-transitory computer-readable storage medium, computer instructions for a computer to execute the method of the foregoing first aspect.

In order to achieve the above object, an embodiment of a fifth aspect of the present invention proposes a computer program product, which when executed by an instruction processor in the computer program product, performs the method of the first aspect.

According to the interface calling method, the interface calling device and the electronic equipment, when the target micro-service is started, the interface configuration file is read, so that configuration information of the interface issued by at least one first service system in the distributed system is obtained. And loading configuration information of each interface into a memory, so that when a second service system in the distributed system calls any interface, corresponding call return data is generated based on the loaded configuration information, and the call return data is provided for the second service system. And simultaneously monitoring the running state of each interface and call return data of each interface so as to perform exception handling when any interface is abnormal. The interfaces issued by each service system are operated and maintained through the target micro-service, so that when other service systems need to call the interfaces, the target micro-service provides corresponding call return data according to the configuration information of the interfaces, the interfaces are decoupled from the service systems, and the coupling degree is reduced. Meanwhile, the target micro-service is used as a unified interface engine, so that the configuration information of the interface can be managed in a centralized way, and unified management and maintenance are convenient; configuration of the interface can be conveniently modified and adjusted, and maintainability and expandability of the system are improved; the risk of modifying the codes of the service system is reduced, and the stability and the safety of the service system are improved; meanwhile, the interfaces are flexibly configured according to the requirements, so that different service requirements can be met, and the adaptability and expansibility of the system are improved.

Additional aspects and advantages of the invention 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 invention.

Drawings

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

FIG. 1 is a flowchart of an interface calling method according to an embodiment of the present invention;

FIG. 2 is a flowchart of another method for calling an interface according to an embodiment of the present disclosure;

fig. 3 is a schematic structural diagram of an interface calling device 400 according to an embodiment of the present invention.

Detailed Description

Embodiments of the present invention 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 illustrative and intended to explain the present invention and should not be construed as limiting the invention.

The following describes an interface calling method, an interface calling device and electronic equipment according to the embodiment of the invention with reference to the accompanying drawings.

Fig. 1 is a flowchart of an interface calling method according to an embodiment of the present invention.

In a distributed system, in order to reduce the coupling degree between systems, the system may be divided into a plurality of subsystems in a business, function, or the like manner. The financial management system in the distributed system is complex and changeable in service, and a plurality of service systems serving as service objects are connected through interfaces to interact with the service systems. At present, the traditional interface development technology is mainly adopted, that is, developers realize interface functions in the codes of the accessed service system.

In order to solve the problem, the embodiment of the invention provides an interface calling method, which adopts a target micro-service to operate and maintain interfaces issued by each service system, so that when other service systems need to call the interfaces, the target micro-service provides corresponding call return data according to configuration information of the interfaces, so that the interfaces are decoupled from the service systems, and the coupling degree is reduced.

The interface calling method is executed by the equipment running the target micro-service, and the target micro-service is used as an interface engine for uniformly maintaining multiple interfaces and can be communicated with multiple business systems in the distributed system. Each business system can issue own interfaces on the target micro-service, so that other business systems needing to call the interfaces can call the interfaces through the target micro-service, and decoupling between the interfaces and the business systems is realized.

As shown in fig. 1, the method comprises the following steps:

and step 101, responding to the starting of the target micro-service, and reading an interface configuration file to obtain configuration information of an interface issued by at least one first service system in the distributed system.

In this embodiment, in order to facilitate distinction from a service system requesting to call an interface, a service system issuing an interface is referred to as a first service system, and a service system requesting to call an interface is referred to as a second service system.

The interface configuration file is used for recording configuration information of interfaces issued by each first service system in the distributed system. In order to avoid recoding the target micro-service caused by interface adjustment, the content needing dynamic configuration in the interface is written into the interface configuration file as configuration information, so that frequent code modification on the target micro-service is avoided.

As one possible implementation, the dynamically configured content may be written into the interface configuration file based on the following steps:

first, the format and storage location of the interface configuration file are determined. In particular, it is necessary to determine the format of the interface configuration file, such as text file, XML, JSON, etc., and where the interface configuration file should be stored. Typically, the interface profile will be saved under the root directory of the item or a specific configuration directory.

Second, an interface configuration file is created. Specifically, an empty interface profile is created using an appropriate editor or development environment. Depending on the format selected, a corresponding template or example may be used as a starting point.

And thirdly, adding configuration items and writing codes. Each configuration item typically consists of a key for identifying the name of the configuration item and a value representing specific setting information or parameters. Multiple configuration items may be added to the interface configuration file, with appropriate separation and annotation between each configuration item. The new configuration items or values are written into the file using a programming language or script writing.

Optionally, the device running the target micro-service includes a memory for temporary storage, and other storage spaces for non-temporary storage, such as an internal or external hard disk. Interface configuration files are stored in the non-temporarily stored storage space.

Step 102, loading configuration information of each interface into a memory, so that when a second service system in the distributed system calls any interface, corresponding call return data is generated based on the loaded configuration information, and the call return data is provided for the second service system.

Optionally, after the target micro-service is started, the configuration information read in the interface configuration file is loaded into the memory, so that when the CPU runs the code of the target micro-service, the configuration information in the memory is read according to the code requirement, and the interface function is realized.

The configuration file may include information configured in advance such as an access address of the interface, a request method, a request parameter (including an input parameter, an output parameter, and data source information of the interface). It should be noted that the request method may be a related method for implementing the interface function based on the request parameter.

As one possible implementation, the configuration may be performed using JSON language, YAML language, or the like, or may be performed using another language, which is not limited in this embodiment.

In addition, configuration information including access addresses, authentication information, output rules, and the like of the interfaces can be configured in a parameterized manner for different types of interfaces.

The access address of the interface can be a uniform resource location system (uniform resource locator, URL), and can be used for accessing the URL when the service system requests to call the interface, or carrying the URL in the request.

And outputting rules which can be used for indicating the rules which are required to be met by calling the return data when the service system calling the interface returns the call return data.

Alternatively, the data returned by the target microservice will typically contain some metadata, and the output rules may be used to indicate the rules that the metadata needs to satisfy. The following are some common rules:

http status code: the response returned by the target microservice will typically contain an HTTP status code that can be used to determine if the request was successful and what error occurred. Typically, a status code of 200 indicates that the request was successful, while other status codes indicate different types of errors, e.g., 404 indicates that the resource was not found, etc. Different processing can be done according to the different status codes, for example, when the status code is 200, the returned data can be processed continuously; when the status code is an error code, the user can be prompted for corresponding error information according to the status code.

2. Request identifier: in the data returned by the target microservice, there will typically be a request identifier (request ID) to identify the uniqueness of the request. The request identifier may be associated between the data returned by the target microservice and the interface, and the request and the returned data are associated according to the identifier.

3. Timestamp: the data returned by the target microservice may include a timestamp field to indicate the time at which the response was generated. The processing time of the request may be recorded from this timestamp or time-dependent analysis and statistics may be performed when needed.

4. The data content is as follows: of the data returned by the micro server, the most important part is the actual data content, so that corresponding processing and operation can be performed according to the data content, such as data analysis, data storage, interface updating and the like.

In general, the association between the data returned by the target micro-service and the interface may be achieved through the metadata described above. The interface may process the returned data accordingly based on the metadata and ensure the association between the requested and returned data.

And 103, monitoring the running state of each interface and call return data of each interface so as to perform exception handling when any interface is abnormal.

Optionally, in this embodiment, multiple interfaces running on the target micro service are monitored, so that the access amount of each interface can be obtained, and whether an abnormality exists in the access process, so as to perform statistical processing.

In addition, in some scenarios, because the business system may have a data sensitivity problem, the target micro-service may monitor call return data of each interface, so as to intercept the call return data in the case that the call return data has sensitive data, and avoid exposure of the sensitive data. For example: the financial system can define an interface on the target micro-service, and can release the data of the financial system to other external business systems such as human resources and the like for use in an interface mode. The financial system can more flexibly define the data released outside, and prevent the external business system from directly accessing the data of the financial system, thereby causing sensitive data leakage. The interface for monitoring and publishing the target micro-service alarms, monitors and even intercepts some sensitive data in real time so as to improve the data security.

In this embodiment, when the target micro service is started, the interface configuration file is read to obtain configuration information of an interface published by at least one first service system in the distributed system. And loading configuration information of each interface into a memory, so that when a second service system in the distributed system calls any interface, corresponding call return data is generated based on the loaded configuration information, and the call return data is provided for the second service system. And simultaneously monitoring the running state of each interface and call return data of each interface so as to perform exception handling when any interface is abnormal. The interfaces issued by each service system are operated and maintained through the target micro-service, so that when other service systems need to call the interfaces, the target micro-service provides corresponding call return data according to the configuration information of the interfaces, the interfaces are decoupled from the service systems, and the coupling degree is reduced.

In order to avoid the need of revising the code of the target micro-service during interface adjustment, the interface provided by the target micro-service is configured by interface configuration modes such as an interface configuration table, a configuration file and the like. The main parameters contained in the interface configuration table may vary according to the specific application and configuration, and the following are some common parameters:

table 1 parameters and description thereof

When performing interface configuration and call, first, a developer is required to define the interface configuration, and write the defined interface configuration into an interface configuration file. And when the target micro service is started, the configuration information is obtained by reading the interface configuration file, so that the target micro service performs interface call based on the loaded configuration information, and after the original data is obtained, the adjustment steps such as data mapping and the like are performed based on the output rule in the configuration information. And finally, recording the calling process in a log so as to carry out interface supervision.

For example: in the case where the finance system applies the method of the embodiment, the interface function may be integrated by a micro-service mode. Defining financial system interface data on a target micro-service for realizing an interface function, and obtaining an input parameter and an output parameter of each interface and data source information for acquiring data through the predefined interface function, wherein the interface receives the input parameter, performs data query in a data source by taking the input parameter as a query condition, and takes a query result as the output parameter. If the interface of the current team salary is provided, a salary data table can be configured, the input parameters are team information and inquiry time, and the output parameters are salary details of all members of the current team. After the configuration information of the interface is configured, the configuration information of the interface is loaded to the memory every time the target micro-service is started, and if external business systems such as the HR system and the like need to use financial data of the financial system, such as salaries of current team members are acquired, the HR system can call the interface based on the interface information issued by the financial system.

The target micro-service and interface parameters are typically used together in the context of a micro-service architecture. The micro-service architecture is an architecture style that splits a large application into multiple small services, each running in a separate process, and communicating using a lightweight communication mechanism.

In a micro-service architecture, each micro-service typically exposes some interfaces (also called APIs) for other services, systems, or clients to call. These interfaces typically communicate using a protocol such as RESTful or gRPC, and interface parameters are used to pass specific data or instruct the server to perform specific operations.

The target microservice is typically run as part of a microservice architecture, responsible for providing interface services. In this case, the target micro-service will process the request according to the interface parameters and return a corresponding response.

For example: the HR system transmits the personnel identification of the payroll to be inquired to the target micro-service, and transmits the identification (for example, the access address of the interface) corresponding to the interface to be called to the target micro-service, so that the target micro-service determines the interface to be called based on the access address of the interface, and transmits the personnel identification to the interface to realize the call to the interface.

For another example, in an e-commerce web site, there may be multiple micro-services to handle different functions, such as merchandise management, order processing, user management, etc. Each micro-service exposes some interfaces for other micro-services and clients to call. When the interface is invoked, certain parameters, such as a commodity ID, order number, user ID, etc., need to be passed to indicate that the corresponding operation is to be performed.

In order to clearly illustrate a specific interface calling procedure after the target micro service is started, the present embodiment provides an interface calling method, and fig. 2 is a schematic flow chart of another interface calling method provided by the embodiment of the present disclosure.

As shown in fig. 2, the method may include the steps of:

step 301, a request for invoking a first service system interface by a second service system is received.

The request of the second service system for calling the first service system interface can carry the access address of the interface, so that the target micro-service can identify the interface to be called based on the access address after receiving the request.

In the case that the called interface needs to enter the input parameter, the request of the second service system for calling the first service system interface also needs to carry the input parameter. There are two possible implementations of the incoming input parameters. As a first possible implementation, parameter delivery is based on HTTP requests: the micro services typically communicate using the HTTP protocol, with HTTP request parameters passing through splice parameters in URLs or passing parameters in the request body of POST requests. For example, suppose there are two micro services a and B, and micro service a needs to pass certain data to micro service B. The micro service A can splice parameters in the URL through a parameter transmission mode of the HTTP request and send data to the micro service B. After receiving the request, the micro service B analyzes the data from the URL parameter to complete parameter transfer. As a second possible implementation, message queue delivery is based on: message queuing is a common way to pass parameters between microservices. Through the message queues, communication between asynchronous, decoupled services can be achieved. The sender packages the parameters into a message, sends the message into a message queue, and the receiver acquires and processes the message from the message queue. The advantage of message queues is that decoupling can be achieved, and the sender and receiver do not need to communicate directly, but rather parameter delivery is accomplished through message queue middleware.

In this embodiment, the interface of the first service system is published in the target micro service, and may be referred to as a called interface, and the type of the called interface is not limited in this embodiment.

Step 302, the request is parsed to obtain information carried by the request.

Optionally, when the first service system defines the interface, request rule information may also be written in the configuration file. The request rule information is used for analyzing the request, so that various information carried in the request, such as access addresses, input parameters and the like, are obtained.

Step 303, determining the interface identification of the called interface according to the access address in the request carrying information.

Optionally, based on the access address carried by the request, determining the called interface, and further obtaining the interface identifier of the interface. The interface identification is used for inquiring configuration information corresponding to the called interface in the follow-up step of the target micro-service.

Step 304, according to the interface identifier of the called interface, inquiring the target configuration information corresponding to the interface identifier, and authenticating the authentication parameter carried by the request based on the authentication information in the target configuration information.

As a possible implementation manner, in the distributed system, when the second service system invokes any interface, through the foregoing step 303, the front end of the target micro service parses the request, and after obtaining the interface identifier of the invoked interface, in this step, the interface identifier is transferred from the front end to the back end of the target micro service. And inquiring the target configuration information corresponding to the interface identifier through the rear end of the target micro-service. For example: and loading the interface identifier into a memory, and inquiring the configuration information loaded into the memory through the rear end of the target micro-service to obtain target configuration information corresponding to the interface identifier.

Optionally, in order to further enhance the security of access, the called interface may define an access right and an access authentication manner, so that when the second service system needs to call the called interface, it may be checked whether the second service system may call the interface, and an authentication method including right verification and identity verification may be performed. The specific manner of authentication in this embodiment is not limited.

Step 305, allowing the second service system to call the called interface if the authentication is passed; and if the authentication is not passed, refusing the call of the second service system to the called interface, and ending the flow.

And step 306, accessing a third service system according to the data source information in the target configuration information to obtain the original data.

The data source information is an address, database, etc. for indicating a data source that is allowed to be accessed in the third service system. So that the target micro-service accesses the original data from which the third service system acquired the call based on the data source information. It should be noted that, the third service system where the data source is located and the first service system of the publishing interface may be the same or different, which is not limited in this embodiment.

Optionally, the back end accesses and publishes the third service system to obtain the original data according to the data source information in the target configuration information, so as to generate the call return data provided for the second service system according to the original data.

Step 307, generating call return data provided to the second service system according to the original data and providing the call return data to the second service system.

As a possible implementation manner, according to the output rule in the target configuration information, the original data is subjected to data processing to obtain the call return data provided to the second service system. In order to avoid direct exposure of the original data to the second service system. The original data may be subjected to data processing such as desensitization processing, mapping processing, etc., in the target microservice. The method of data processing may be pre-specified in the output rule, that is, when the first service system configures the interface, the relevant configuration may be performed in the target configuration information of the invoked interface.

As another possible implementation manner, the original data is filtered according to the parameter transferred when the second service system performs interface call, so as to obtain the call return data provided for the second service system.

For example: the original data is a payroll data table, screening is carried out in the original data based on team information and query time in the input parameters, and output parameter related data conforming to the team information and the query time is queried, namely payroll details of all members of the team are returned to the second service system as call return data.

Step 309, monitoring the running state of the called interface and the call return data, and generating a log record with the monitoring result.

In order to perform exception monitoring on the invoked interface, the following several possible implementations are provided in this embodiment:

as a first possible implementation, the monitoring of the interface-based return data: by analyzing the data returned by the interface, whether the interface works normally or not can be found. If the data returned by the interface is abnormal, the interface is indicated to have a problem. The purpose of interface monitoring can be achieved by comparing whether the structure of the returned data meets the requirements, checking the validity of the returned data, and the like.

As a second possible implementation, log-based monitoring: in the interface service system, log records are carried out on all interface requests, and the log is analyzed, so that abnormal conditions of the interfaces can be found. For example, the response time of an interface request may be monitored, if the response time is too long, indicating that the interface is problematic. Meanwhile, the success rate of the interface request can be monitored, and if the success rate is too low, the problem of the interface is also indicated.

As a third possible implementation, the monitoring based on the third party tool: monitoring of the interface may be accomplished using a third party tool. For example, tools such as Zabbix, nagios may be used to monitor the status of the interface and to discover and handle interface anomalies in time.

As a fourth possible implementation, the monitoring is customized: a self-defined monitoring script can be written, and the interface is monitored in real time. For example, script may be written in a scripting language such as Python, shell, etc. to monitor the status of the interface, including verification of the interface's return data, monitoring of response time, etc.

As a fifth possible implementation, the monitoring based on the service governance framework: the API interface service system is managed and monitored by a service governance framework (e.g., dubbo, spring Cloud, etc.). These frameworks provide many management functions such as service registration and discovery, load balancing, fusing, etc., which can help us better manage and monitor the interface service system.

In order to implement the above embodiment, the present invention further provides an interface calling device 400

As shown in fig. 3, the interface calling device 400 includes: a start module 401, a call module 402 and a monitor module 403.

The starting module 401 is configured to respond to the target micro-service start, and read the interface configuration file to obtain configuration information of an interface published by at least one first service system in the distributed system.

And the calling module 402 is configured to load configuration information of each interface into a memory, so that when any interface is called by a second service system in the distributed system, corresponding call return data is generated based on the loaded configuration information, and the call return data is provided to the second service system.

The monitoring module 403 is configured to monitor an operation state of each of the interfaces and call return data of each of the interfaces, so as to perform exception handling when any of the interfaces has an exception.

Further, in a possible implementation manner of the embodiment of the present invention, the configuration information in the interface configuration file defines an access address, authentication information and request rule information of the interface.

Based on this, the calling module 402 of the interface calling device 400 is further configured to:

receiving a request of the second service system call interface;

determining an interface identifier of the called interface according to the access address in the request carrying information;

adopting the authentication information corresponding to the interface identifier to authenticate the authentication parameters carried by the request;

and allowing the second service system to call the called interface under the condition that the authentication is passed.

Optionally, when the second service system in the distributed system invokes any interface, the invoking module 402 generates corresponding invoking return data based on the loaded configuration information, and provides the invoking return data to the second service system, including: when a second service system calls any interface in the distributed system, inquiring target configuration information corresponding to the interface identifier according to the interface identifier of the called interface; accessing and releasing a first service system of the called interface according to the data source information in the target configuration information to obtain original data; and generating the call return data provided for the second service system according to the original data.

Optionally, the calling module 402 generates the call return data provided to the second service system according to the original data, including: according to the output rule in the target configuration information, carrying out data processing on the original data to obtain the call return data provided for the second service system; or screening the original data according to the input parameters transferred when the second service system performs interface call so as to obtain call return data provided for the second service system.

Optionally, when the second service system in the distributed system invokes any interface, the invoking module 402 queries, according to an interface identifier of the invoked interface, target configuration information corresponding to the interface identifier, including: when a second business system calls any interface in the distributed system, acquiring an interface identifier of the called interface through the front end of the target micro-service, and transmitting the interface identifier from the front end to the rear end of the target micro-service; inquiring target configuration information corresponding to the interface identifier through the rear end of the target micro service, so that the rear end accesses a third service system to obtain original data according to data source information in the target configuration information, and generates calling return data provided for the second service system according to the original data. For example, in some possible implementations: the interface identifier is loaded into a memory, configuration information loaded into the memory is queried through the rear end of the target micro service to obtain target configuration information corresponding to the interface identifier, the rear end accesses the third service system to obtain original data according to data source information in the target configuration information, and calling return data provided for the second service system is generated according to the original data.

Further, the interface profile is generated based on the steps of:

determining the format and the storage position of an interface configuration file;

according to the format, an editor or a development environment corresponding to the format is adopted to create an empty interface configuration file;

and adding a configuration item in the empty interface configuration file, wherein the configuration item comprises a key and a value, the key is used for identifying the name of the configuration item, and the value represents setting information or parameters.

Further, the call return data is used to determine an interface in the second business system for receiving the call return data in the following manner:

the response of the load call return data contains a request identifier, wherein a corresponding relation exists between the request identifier and the interface.

Further, the entry is carried in a request body of the request of the second service system call interface; or splicing the entry into an interface identifier of the called interface, wherein the interface identifier is in a URL form; or the participation package is a message, and the message is written into a message queue, wherein the message queue is used for carrying out data transfer between the target micro-service and the second service system.

It should be noted that the explanation of the foregoing embodiment of the interface calling method is also applicable to the interface calling device of this embodiment, and will not be repeated here.

In order to achieve the above embodiment, the present invention further provides an electronic device, including: a processor, and a memory for storing instructions executable by the processor.

Wherein the processor is configured to perform the method of any of the preceding embodiments.

To achieve the above embodiments, the present invention also proposes a non-transitory computer-readable storage medium, which when executed by a processor is capable of performing the method of any of the previous embodiments.

To achieve the above embodiments, the present invention also proposes a computer program product which, when executed by an instruction processor in the computer program product, performs the method according to any of the previous embodiments.

In the description of the present specification, a description referring to terms "one embodiment," "some 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 invention. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

Furthermore, the terms "first," "second," and the like, are used for descriptive purposes only and are not to be construed as indicating or implying a relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In the description of the present invention, the meaning of "plurality" means at least two, for example, two, three, etc., unless specifically defined otherwise.

Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and additional implementations are included within the scope of the preferred embodiment of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order from that shown or discussed, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the embodiments of the present invention.

Logic and/or steps represented in the flowcharts or otherwise described herein, e.g., a ordered listing of executable instructions for implementing logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). In addition, the computer readable medium may even be paper or other suitable medium on which the program is printed, as the program may be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

It is to be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, the various steps or methods may be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As with the other embodiments, if implemented in hardware, may be implemented using any one or combination of the following techniques, as is well known in the art: discrete logic circuits having logic gates for implementing logic functions on data signals, application specific integrated circuits having suitable combinational logic gates, programmable Gate Arrays (PGAs), field Programmable Gate Arrays (FPGAs), and the like.

Those of ordinary skill in the art will appreciate that all or a portion of the steps carried out in the method of the above-described embodiments may be implemented by a program to instruct related hardware, where the program may be stored in a computer readable storage medium, and where the program, when executed, includes one or a combination of the steps of the method embodiments.

In addition, each functional unit in the embodiments of the present invention may be integrated in one processing module, or each unit may exist alone physically, or two or more units may be integrated in one module. The integrated modules may be implemented in hardware or in software functional modules. The integrated modules may also be stored in a computer readable storage medium if implemented in the form of software functional modules and sold or used as a stand-alone product.

The above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, or the like. While embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and not to be construed as limiting the invention, and that variations, modifications, alternatives and variations may be made to the above embodiments by one of ordinary skill in the art within the scope of the invention.

Claims

1. An interface calling method, characterized in that the method comprises the following steps:

2. The method of claim 1, wherein the configuration information in the interface configuration file defines an access address, authentication information, and request rule information of the interface; the method further comprises the steps of:

Receiving a request of the second service system call interface;

determining an interface identifier of the called interface according to the access address carried by the request;

3. The method according to claim 1 or 2, wherein when the second service system in the distributed system invokes either interface, generating corresponding call return data based on the loaded configuration information, and providing the call return data to the second service system, includes:

when a second service system calls any interface in the distributed system, inquiring target configuration information corresponding to the interface identifier according to the interface identifier of the called interface;

accessing a third service system to which the data source belongs according to the data source information in the target configuration information to obtain original data;

and generating the call return data provided for the second service system according to the original data.

4. A method according to claim 3, wherein said generating said call return data provided to said second business system from said raw data comprises:

According to the output rule in the target configuration information, carrying out data processing on the original data to obtain the call return data provided for the second service system; or,

and screening the original data according to the input parameters transferred when the second service system performs interface call so as to obtain call return data provided for the second service system.

5. The method according to claim 3, wherein when the second service system calls any interface in the distributed system, according to the interface identifier of the called interface, querying the target configuration information corresponding to the interface identifier includes:

when a second business system calls any interface in the distributed system, acquiring an interface identifier of the called interface through the front end of the target micro-service, and transmitting the interface identifier from the front end to the rear end of the target micro-service;

inquiring target configuration information corresponding to the interface identifier through the rear end of the target micro service, so that the rear end accesses the third service system to obtain original data according to data source information in the target configuration information, and generates calling return data provided for the second service system according to the original data.

6. The method according to claim 5, wherein the querying, by the backend of the target micro service, the target configuration information corresponding to the interface identifier, to access, by the backend, the third service system to obtain original data according to data source information in the target configuration information, and generating, according to the original data, the call return data provided to the second service system includes:

the interface identifier is loaded into a memory, configuration information loaded into the memory is queried through the rear end of the target micro service to obtain target configuration information corresponding to the interface identifier, the rear end accesses the third service system to obtain original data according to data source information in the target configuration information, and calling return data provided for the second service system is generated according to the original data.

7. The method according to claim 1 or 2, wherein the interface profile is generated based on the steps of:

8. A method according to claim 1 or 2, wherein the call return data is used to determine an interface in the second business system for receiving the call return data by:

the response carrying the call return data comprises a request identifier, wherein a corresponding relation exists between the request identifier and an interface.

9. The method of claim 4, wherein the step of determining the position of the first electrode is performed,

the entry is carried in a request body of a request for calling the second service system interface; or,

the entry is spliced in an interface identifier of the called interface, and the interface identifier is in a URL form; or,

and the parameter entering package is used for packaging information and writing the information into an information queue, wherein the information queue is used for carrying out data transmission between the target micro-service and the second service system.

10. An interface calling device, comprising: