Microservice-based service simulation calling method and system

Abstract

This invention provides a microservice-based service simulation invocation method, characterized by the following steps: Step S1: Displaying corresponding service information according to different service types; Step S2: Automatically generating service documentation and inputting service parameters based on the service information; Step S3: Performing service debugging and sending microservice invocation requests; Step S4: Querying and obtaining return results based on service type; Step S5: Viewing service invocation chain information based on the return results and troubleshooting problems encountered in the service invocation. This invention, through a customized microservice-based service simulation invocation method, addresses the shortcomings of traditional service simulation invocation in handling multi-platform industrial big data in terms of high availability, customization, security, service documentation, and result display. It effectively improves the user's experience in trying and simulating services and leverages big data technology to mine the potential value of user trial data.

Description

Technical Field

[0001] This invention relates to the field of microservices technology, and more specifically, to a service simulation invocation method and system based on microservices. Background Technology

[0002] The essence of a data middle platform is to leverage the storage and computing capabilities of a big data platform; to achieve business and management goals of serving, understanding, driving, and creating value in line with the enterprise's development strategy; to organize, integrate, and model data; to continuously accumulate standardized data service capabilities and data asset operation capabilities; and to empower front-end businesses and provide flexible and efficient data services.

[0003] However, when users need to try or debug data sharing services and standard sharing services, these data services do not provide simulation call functionality. In this case, a new service call mode is needed to enable users to simulate calls to the data services.

[0004] Compared with the current simulation call products in China, the following limitations were found: (1) Service calls are limited to basic interface calls and microservices are not customized; (2) The simulation call schemes used are not stored, so the service parameters need to be backed up by the user; (3) There is a lack of flexible parameter display function, and parameters can only be input in one view.

[0005] A search revealed that patent document CN108959076A discloses an online API debugging method. Developers use standard JavaDoc format specifications to write interface comments and add custom annotations to the API implementation code. An API format description generation tool scans the project, parses the JavaDoc format comment information and custom annotation content, forming a unified API format description, which is then registered with the API center. The API center is responsible for the unified management of all API documents, parsing the API format descriptions, generating standardized API documents and web pages, and persisting them. Users can access the corresponding web page through a client or browser to read the API documents and perform real-time debugging and testing of the API. While this existing technology improves interface development efficiency and interface integration quality by enabling online debugging of different types of APIs, it bypasses the requirements for high service availability, customized simulation, and data security. It only provides a solution for automatic generation and management based on API documentation. Although it standardizes API management to some extent, it fails to address issues such as customized service configuration and anonymization of simulation data. Users can only input parameters from one view, and there is no effective solution for managing historical simulation call parameters. Therefore, it does not meet the core problem of solving simulation calls for multiple services.

[0006] Patent document CN110457017A discloses an enterprise middleware system employing a domain-layered design, comprising: Layered design: Based on a business and data layered management strategy, the enterprise middleware architecture is designed as a domain layer and a general center layer, which are connected via API communication and provide unified external service management through an application service gateway; Domain division: Each layer is divided into sub-centers according to domain design principles; Capability orchestration: Customized aggregation and orchestration of platform capabilities is implemented; Process orchestration: Customized scenarios for business processes are addressed; Domain configuration: Resource item configuration management is implemented. While this prior art can solve the problem of coupling between business processes and business data, it cannot solve the problem of simulating and calling multiple services.

[0007] Therefore, there is an urgent need to develop and design a method and system that enables users to simulate and invoke data services. Summary of the Invention

[0008] To address the shortcomings of existing technologies, the purpose of this invention is to provide a service simulation invocation method and system based on microservices. It solves the problem of how to implement data service simulation invocation technology based on a microservice architecture, enabling it to possess high availability, customization, and data anonymization characteristics, meeting users' trial and debugging needs, and overcoming the deficiencies of traditional service simulation.

[0009] A service simulation invocation method based on microservices according to the present invention includes the following steps:

[0010] Step S1: Display the corresponding service information according to different service types;

[0011] Step S2: Automatically generate service documents based on service information and enter service parameters;

[0012] Step S3: Debug the service using the built-in parameter example template and send a microservice call request;

[0013] Step S4: Query and obtain the returned results based on the service type;

[0014] Step S5: Based on the returned results, view the service call chain information, perform service rate limiting and service degradation settings, and troubleshoot problems encountered in service calls.

[0015] Preferably, the different service types in step S1 include standard shared services and data shared services. The service information displayed by the standard shared services includes the shared service identifier, the shared service name, and the shared service input parameters; the service information displayed by the data shared services includes the API name, the model name, and the parameter input.

[0016] Preferably, the service document in step S2 includes service details, request parameter descriptions, status code descriptions, request code examples, and return result examples.

[0017] Preferably, the service parameters entered in step S2 include tabular parameter entry or JSON format parameter entry. Tabular parameter entry displays the parameter name, parameter description, and whether the field is required, and automatically fills in example parameter values. Users can modify the parameter values ​​for invocation. JSON format parameter entry displays the parameter name and corresponding parameter value. JSON format parameters are a fixed-format data structure called EiInfo.

[0018] Preferably, the results returned in step S4 are displayed in a table format by default. When the data returned by the service is a simple key-value pair and is not suitable for table display, it is displayed in JSON format.

[0019] Preferably, the simulation call process for the standard shared service is as follows: first, check if the standard shared service exists; if it exists, call the shared service; and finally, display the execution result of the shared service on the simulation call page.

[0020] Preferably, the simulation call process for the data sharing service is as follows: first, anonymous filtering is performed according to the model identifier; then, a query is performed to see if a data sharing service model and API exist. If a data sharing service model and API exist, the query is performed according to the database type to obtain the returned results. Finally, the execution results of the data sharing service are displayed on the simulation call page.

[0021] According to the present invention, a microservice-based service simulation invocation system includes:

[0022] Data sharing service module: Model 1 is a combination of business domain data tables. A set of APIs can be defined on the model to access the data tables. After the model is associated with the API and the API is associated with the microservice, the service is called to obtain the data in the data table.

[0023] Standard shared service module: Service sharing is achieved directly through microservice calls.

[0024] Preferably, it also includes a microservice module, which obtains the microservice call address based on the microservice information, calls the remote service via REST, and uniformly uses EiInfo to parse the microservice return results.

[0025] Preferably, it further includes:

[0026] Data Platform - Data Service Module: The Data Platform - Data Service Module provides three data service interfaces, including custom SQL single-table queries, custom API multi-table SQL queries, and model actions;

[0027] Basic Platform - Shared Service Module: The Basic Platform - Shared Service Module packages some microservices into shared services for cross-platform use.

[0028] Compared with the prior art, the present invention has the following beneficial effects:

[0029] 1. This invention addresses the shortcomings of traditional service simulation invocation in dealing with multi-platform industrial big data in terms of high availability, customization, security, service documentation, and result display through a customized microservice-based service simulation invocation method. It effectively improves the user's trial and simulation experience of services and utilizes big data technology to mine the potential value of user trial data.

[0030] 2. This invention achieves high-availability service simulation by simplifying the shared service simulation call process. Each step of the service simulation call process is visualized, including selecting the simulation service, setting service parameters, viewing service documentation, and displaying the return results. The call process is simple; through built-in parameter example templates and saving service simulation records, service simulation calls can be performed with just a few clicks, without any input. Based on the service link information in the simulation service results, service rate limiting and service degradation settings can be implemented, thereby achieving high service availability.

[0031] 3. This invention allows for customized configuration of data sharing services and standard sharing services, stores existing simulation schemes for users to read, and ensures data security.

[0032] 4. This invention automatically generates detailed service documents for user reference and displays input parameters and output results in multiple views. Attached Figure Description

[0033] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0034] Figure 1 This is a flowchart of the steps of the microservice-based service simulation invocation method in this invention;

[0035] Figure 2 This is a framework diagram of the shared service module in this invention;

[0036] Figure 3 This is the first framework diagram of the microservice module in this invention;

[0037] Figure 4 This is the second framework diagram of the microservice module in this invention;

[0038] Figure 5 This is a schematic diagram illustrating the basic information structure of microservices in this invention. Detailed Implementation

[0039] The present invention will be described in detail below with reference to specific embodiments. The following examples will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those skilled in the art, several changes and improvements can be made without departing from the scope of the present invention. These all fall within the scope of protection of the present invention.

[0040] like Figure 1 As shown, this invention provides a service simulation invocation method based on microservices, including the following steps:

[0041] Step S1: Display the corresponding service information based on different service types. Specifically:

[0042] In step S1, the different service types include standard shared services and data shared services. The service information displayed for standard shared services includes the shared service identifier, shared service name, and shared service input parameters; the service information displayed for data shared services includes the API name, model name, and parameter input.

[0043] Step S2: Automatically generate service documents based on service information and enter service parameters. Specifically:

[0044] The service documentation in step S2 includes service details, request parameter descriptions, status code descriptions, request code examples, and return result examples.

[0045] Step S2 involves entering service parameters, which can be either tabular or JSON format. Tabular parameters display the parameter name, description, and whether the field is required, and automatically include example parameter values. Users can modify these values ​​for later use. JSON parameters display the parameter name and its corresponding value. JSON parameters are a fixed-format data structure called EiInfo, primarily consisting of an attribute area (extAttr) and a data area (blocks). Compared to tabular parameters, JSON parameters offer greater flexibility. For example: {extAttr:{userId:178237},blocks:{q:{metas:{'companyCode','appCode'},rows:[['1001','BSMS']]}}}.

[0046] Step S3: Debug the service using the built-in parameter example template and send a microservice call request.

[0047] Step S4: Query and retrieve the results based on the service type. Specifically:

[0048] In step S4, the returned results are displayed in a table format by default. When the service returns simple key-value pairs and the data is not suitable for table display, it is displayed in JSON format. For example, the service returns user login status data {status:0,msg:'User login successful',extAttr:{loginStatus:0}}.

[0049] Step S5: Based on the returned results, view the service call chain information, perform service rate limiting and service degradation settings, and troubleshoot problems encountered in service calls.

[0050] like Figure 2-5 As shown, the present invention also provides a service simulation invocation system based on microservices, comprising:

[0051] Data sharing service module: Model one is a combination of business domain data tables. A set of APIs can be defined on the model to access the data tables. After the model is associated with the API and the API is associated with the microservice, the service is called to obtain the data in the data table.

[0052] Standard shared service module: Service sharing is achieved directly through microservice calls.

[0053] Microservice module: Obtain the microservice call address based on the microservice information, call the remote service via REST (using HTTP protocol POST request: service call address + / service / serviceId), and uniformly use EiInfo (JSON format in 4, which can represent request parameters and return results) to parse the microservice return results.

[0054] Data Platform - Data Service Module: The Data Platform - Data Service Module provides three data service interfaces, including custom SQL single-table queries, custom API multi-table SQL queries, and model actions;

[0055] Basic Platform - Shared Service Module: The Basic Platform - Shared Service Module packages some microservices into shared services for cross-platform use.

[0056] The simulation call process for standard shared services is as follows: first, it checks whether the standard shared service exists; if it does, it calls the shared service; and finally, it displays the execution result of the shared service on the simulation call page.

[0057] The simulation call process for the data sharing service is as follows: first, anonymous filtering is performed according to the model identifier; then, the existence of the data sharing service model and API is queried. If the data sharing service model and API exist, the query is performed according to the database type to obtain the returned results. Finally, the execution results of the data sharing service are displayed on the simulation call page.

[0058] This invention effectively enhances the user's trial and simulation experience of the service, and utilizes big data technology to mine the potential value of user trial data, and has the following characteristics:

[0059] (1) The service simulation calling method provided by this invention is customized for data sharing services and standard sharing services. For data services with relatively fixed input parameters and return results, tabular parameter entry and multiple result display methods are provided; while for standard sharing services with relatively variable return results, tabular data block switching and JSON format result display are provided.

[0060] (2) The security of data transmission is guaranteed by the data encryption of the data middle platform and the basic middle platform. Simulation calls only allow users to query desensitized data after prefix retention and masking. The security of scheme storage is guaranteed by the data storage copy mechanism. The entire simulation call process, from data transmission and simulation to final scheme storage, is safe and reliable.

[0061] (3) The service simulation calling method provided by this patent can read the input parameters of data services or shared services and perform multi-dimensional queries to meet users' needs for comprehensive simulation trial of services.

[0062] (4) Each user can add, delete, modify and query their own simulation schemes to avoid duplicate parameter input and improve the user's simulation scheme experience. Specific embodiment:

[0064] This invention utilizes a service marketplace for end users, which provides service trial functionality for service users. The following example, "user trial service," illustrates how users can implement customized simulation calls.

[0065] (1) Users find the data service [ROI Model] in the service marketplace and click the "Try" button to jump to the trial page.

[0066] (2) The trial page displays service information for the "Investment Return Model" as a data service type (service description: query investment return information), and automatically generates service documentation for reference. The service documentation includes five parts: "Service Details", "Request Parameter Description", "Status Code Description", "Request Code Example", and "Return Result Example".

[0067] (3) Parameters are entered in a table format by default. Users can refer to the service documentation to enter parameter values, or directly call the service based on the provided default parameter values. This service has a parameter

ACCT_PERIOD_NO

[0068] (4) Click the “Test” button to execute the simulation call.

[0069] (5) View the returned results in table format. Ten rows of data were returned, which are the data-anonymized investment return information of Baosteel Packaging and Baosteel Co., Ltd. The returned results can be switched to JSON format for display.

[0070] (6) When a user clicks the “View Call Chain” button, they will be redirected to the “Call Chain Details” page to view the call chain information of the service.

[0071] Those skilled in the art will appreciate that, in addition to implementing the system and its various devices, modules, and units provided by the present invention in purely computer-readable program code, it is entirely possible to implement the same functions of the system and its various devices, modules, and units provided by the present invention in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; the devices, modules, and units for implementing various functions can also be considered as both software modules implementing the method and structures within the hardware component.

[0072] In the description of this application, it should be understood that the terms "up", "down", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside", etc., indicating the orientation or position relationship, are based on the orientation or position relationship shown in the accompanying drawings, and are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on this application.

[0073] The above describes specific embodiments of the present invention. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art may make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. The embodiments of this application and the features in the embodiments may be combined with each other in any manner unless there is a conflict.

Claims

1. A service simulation invocation method based on microservices, characterized in that, Includes the following steps: Step S1: Display the corresponding service information according to different service types; The different service types in step S1 include standard shared services and data shared services. The service information displayed by the standard shared services includes the shared service identifier, the shared service name, and the shared service input parameters. The service information displayed by the data shared services includes the API name, the model name, and the parameter input. Step S2: Automatically generate service documents based on service information and enter service parameters; The service document in step S2 includes service details, request parameter descriptions, status code descriptions, request code examples, and return result examples; Step S3: Debug the service using the built-in parameter example template and send a microservice call request; Step S4: Query and obtain the returned results based on the service type; Step S5: Based on the returned results, view the service call chain information, perform service rate limiting and service degradation settings, and troubleshoot problems encountered in service calls; The simulation call process for standard shared services is as follows: first, it checks whether a standard shared service exists; if a standard shared service exists, it calls the shared service; and finally, it displays the execution result of the shared service on the simulation call page. The simulation call process for the data sharing service is as follows: first, anonymous filtering is performed according to the model identifier; then, the existence of the data sharing service model and API is queried. If the data sharing service model and API exist, the query is performed according to the database type to obtain the returned results. Finally, the execution results of the data sharing service are displayed on the simulation call page.

2. The service simulation invocation method based on microservices according to claim 1, characterized in that, The service parameters entered in step S2 include tabular parameter entry or JSON parameter entry. Tabular parameter entry displays the parameter name, parameter description, and whether the field is required, and automatically fills in example parameter values. Users can modify the parameter values ​​to make calls. JSON parameter entry displays the parameter name and corresponding parameter value. The JSON format parameter is a fixed-format data structure called EiInfo.

3. The service simulation invocation method based on microservices according to claim 1, characterized in that, In step S4, the returned results are displayed in a table format by default. When the service returns simple key-value pairs and the data is not suitable for table display, it is displayed in JSON format.

4. A service simulation and invocation system based on microservices, characterized in that, The service simulation invocation method based on microservices, as described in any one of claims 1 to 3, includes: Data sharing service module: After associating models with APIs and APIs with microservices, service calls are made to retrieve data from data tables. Among them, one type of model is a combination of business domain data tables, and a set of APIs can be defined on the model to access the data tables. Standard shared service module: Service sharing is achieved directly through microservice calls.

5. The microservice-based service simulation invocation system according to claim 4, characterized in that, It also includes a microservices module, which obtains the microservice call address based on the microservice information, calls remote services via REST, and uniformly uses EiInfo to parse the microservice return results.

6. The service simulation and invocation system based on microservices according to claim 4, characterized in that, Also includes: Data Platform - Data Service Module: The Data Platform - Data Service Module provides three data service interfaces, including custom SQL single-table queries, custom API multi-table SQL queries, and model actions; Basic Platform - Shared Service Module: The Basic Platform - Shared Service Module packages some microservices into shared services for cross-platform use.

Images