An implementation method and device for application atomization fusion orchestration based on OPENAPI

Abstract

The application provides an implementation method and device for application atomization fusion arrangement based on OPENAPI, relates to the technical field of computer application, and covers service disintegration and interface definition, service registration and discovery, arrangement and adaptive execution, data processing and mapping, security control, integrated deployment and operation and maintenance steps; the application splits complex business into atomized services, defines interfaces according to the OpenAPI specification, facilitates service management, reduces integration cost, and improves system flexibility and expansibility; load balancing is realized by constructing a service registration center and combining a weighted round robin algorithm to guarantee efficient and stable service calling; API gateways, containerization technology and automatic operation and maintenance systems are used to realize rapid service deployment, elastic scaling and intelligent operation and maintenance; meanwhile, data is processed through semantic analysis and format conversion, and security is guaranteed through multi-level identity authentication and encryption.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, and in particular to a method and apparatus for implementing application atomization fusion orchestration based on OpenAPI. Background Technology

[0002] With the rapid development of information technology, enterprise business systems are becoming increasingly complex, and the demand for integration and collaborative work between different systems is growing. Traditional application integration methods often suffer from problems such as inconsistent interfaces, high development costs, and maintenance difficulties, making it difficult to meet rapidly changing business needs.

[0003] Currently, although there are some API-based application integration methods, there are still shortcomings in areas such as atomic decomposition of services, flexible orchestration, data processing, and security control. For example, existing service orchestration technologies lack dynamic adaptive capabilities and cannot intelligently adjust according to the real-time status of services. In terms of data processing, the understanding and mapping of data semantics are not accurate enough, which can easily lead to data transmission errors. In terms of security control, it is also difficult to achieve multi-level, fine-grained access control.

[0004] Therefore, a new technical solution is needed to address the above problems, realize atomic fusion orchestration of applications based on OPENAPI, improve the efficiency and flexibility of application integration, and ensure the security and reliability of the system. Summary of the Invention

[0005] The purpose of this invention is to provide a method and apparatus for implementing application atomic fusion orchestration based on OPENAPI, so as to solve the problems of inconsistent interfaces, inflexible orchestration, inaccurate data processing and insufficient security control in the application integration of the prior art, and to achieve efficient fusion and intelligent orchestration of application services.

[0006] To address the aforementioned technical problems, this invention provides a method and apparatus for implementing application atomized fusion orchestration based on OpenAPI, comprising the following steps:

[0007] S1: Service Decomposition and Interface Definition: Decompose complex business applications into atomic services and define the interfaces of each service according to the OpenAPI specification;

[0008] S2: Service Registration and Discovery: Build a service registry center to store OpenAPI documentation and metadata, register services when they start up, and dynamically discover services based on their health status when they are invoked;

[0009] S3: Orchestration and Adaptive Execution: Orchestrate service processes according to business needs, generate call templates based on OpenAPI, and monitor and adaptively adjust in real time during execution;

[0010] S4: Data processing and mapping: semantic analysis when delivering data, complete format conversion, cleaning verification and semantic mapping;

[0011] S5: Security management: multi-level authentication and authorization, encrypted data transmission;

[0012] S6: Integration deployment and operation: integrate services through API gateway, deploy with container technology, build automatic operation and maintenance system for monitoring and processing.

[0013] As preferred, based on step S1, the complex business application is split into atomized services, and each service interface is defined according to OpenAPI specification, as follows:

[0014] S11: Function analysis is performed on the complex business application, which is disassembled into a plurality of atomized services with single and clear functions; the atomized services include user authentication service, data query service, and order processing service;

[0015] S12: For each atomized service, a standardized interface is defined according to the OpenAPI specification, the input parameters, output results, request method and response status code of the interface are described, and the OpenAPI document of the atomized service is formed.

[0016] As preferred, based on step S2, the service registry center is constructed to store service OpenAPI documents and metadata, and services are registered when started and dynamically discovered when called in combination with health status, as follows:

[0017] S21: A distributed architecture is used to construct a service registry center, which is used to store OpenAPI documents and related metadata of each atomized service, the metadata including service name, version number, endpoint address, and service health status information; the service registry center monitors the health status of the service in real time through a heartbeat mechanism;

[0018] S22: When the atomized service is started, its OpenAPI document and metadata are registered in the service registry center, wherein the registration process can be completed through the RESTful API provided by the service registry center; at the same time, the service registry center updates the health status information of the service in real time, and if no heartbeat information of the service is received within a set time, the service is marked as unhealthy;

[0019] S23: When an application or service needs to call an atomized service, the service registry center is used to dynamically discover and select the appropriate atomized service according to the service name, function description or metadata information, and in combination with the real-time health status of the service;

[0020] In the selection of services, a weighted round robin algorithm is used, specifically as follows:

[0021] The number of all current service instances SE is identified as n, the weight of the i-th service instance is set as wi, and the index of the current request round is index. The calculation formula of the selected service instance SE is:

[0022] ;

[0023] All server instances are traversed, and the weights are accumulated. When the accumulated value is greater than or equal to index, the server instance is selected.

[0024] As preferred, based on step S4, semantic analysis is performed when data is transmitted, and format conversion, cleaning verification and semantic mapping are completed, specifically as follows:

[0025] S41: Using natural language processing technology and domain ontology library, the data transmitted between atomized services is subjected to semantic analysis; key entities and relationships in the data are identified, and the meaning and purpose of the data are understood;

[0026] S42: According to the data format requirements of the source service and the target service, data format conversion is performed; data format conversion is achieved by using data conversion tools or writing custom scripts;

[0027] S43: Clean and verify the data, remove invalid, duplicate and error data; define data verification rules, including data type checking, length checking, range checking;

[0028] S44: Establish a semantic mapping table to map the data between different services semantically.

[0029] As preferred, based on step S5, multi-level identity authentication and authorization are adopted, and data transmission is encrypted, specifically including:

[0030] S51: A multi-level identity authentication mechanism is adopted, including token verification based on OAuth2.0 and identity verification based on digital certificate; the user or application needs to provide valid identity credentials when calling the atomized service;

[0031] S52: According to the roles and permissions of the user or application, fine-grained authorization control is performed on the access to the atomized service; a role-based access control model is adopted to define the permission set of different roles;

[0032] S53: In the data transmission process, SSL / TLS encryption protocol is adopted to encrypt the data.

[0033] As preferred, based on step S6, the service is integrated through API gateway, deployed with containerization technology, and an automatic operation and maintenance system is built to monitor and process, specifically as follows:

[0034] S61, integrating the orchestrated atomized services into a unified interface layer using an API gateway; wherein the API gateway is responsible for receiving external requests, forwarding the requests to the corresponding atomized services according to the request path and parameters, and performing unified processing on the requests and responses, including log recording, flow limiting, and caching;

[0035] S62, packaging the atomized services into independent containers using Docker containerization technology, and using Kubernetes for container orchestration and management; the containerization deployment is used to realize the rapid deployment, elastic scaling, and resource isolation of the services;

[0036] S63, establishing an automated operation and maintenance system, using Prometheus for service performance monitoring, and using Grafana for data visualization; when an exception occurs or the performance index exceeds the threshold, an automatic alarm and processing mechanism is triggered, including automatic service restart and resource expansion.

[0037] As a preferred, based on step S3, the service process is arranged according to business requirements, the calling template is generated according to OpenAPI, and the specific steps are as follows:

[0038] S31: business process arrangement design:

[0039] Visual arrangement: provide a visual arrangement tool, users can drag and drop atomized service icons to the arrangement interface, and use lines to represent the calling order between services; during the arrangement process, the calling order of services, data transmission relationship, and conditional judgment logic can be defined;

[0040] Code programming arrangement: provide API interfaces based on specific programming languages; the API interfaces use code to write service arrangement logic;

[0041] S32: calling module generation:

[0042] According to the OpenAPI document of the atomized service, a service calling template is automatically generated; for each interface defined in the OpenAPI document, the request method, request URL, request parameter, and response format information are extracted;

[0043] S33: arrangement process execution:

[0044] Sequential execution: according to the service calling order of the arrangement design, each atomized service is called in turn; when each service is called, the generated calling template is used, and the necessary parameters are passed to the service;

[0045] Concurrent execution: for relatively independent service calls, a concurrent execution mode is adopted;

[0046] S34: In the service calling process, the performance indicators of each atomized service are monitored and analyzed in real time; the service state information is obtained through the health check mechanism of the service registry center or the state interface provided by the service itself, including whether the service is normally running or whether it has exited abnormally; the execution result is generated by comparing the service state information with the preset condition;

[0047] The performance indicators of each atomized service are monitored and analyzed in real time, and if the response time is greater than its response time threshold, it is marked as service response time being too long; if the throughput is less than its throughput threshold, it is marked as insufficient throughput, and if the error rate is greater than its error rate threshold, it is marked as high service error rate;

[0048] The change trend of the performance indicators and the execution result is analyzed at the same time, specifically:

[0049] The performance indicators in a set time region before the current time are obtained, the set time region is divided into several time partitions, and the trend value of the performance indicators in each time partition is calculated using the standard deviation formula;

[0050] A partition trend threshold is set, and if the trend value is greater than the partition trend threshold, it is marked as an abnormal trend of the performance indicators; the number of abnormal trends in the set time region is counted and recorded as the abnormal trend number;

[0051] The trend values in each time partition in the set time region are calculated to obtain a total trend value using the standard deviation formula; the total trend value and the abnormal trend number are normalized and weighted to obtain a trend influence value; if the trend influence value is greater than the preset total trend threshold, the corresponding performance indicator is marked as an abnormal performance indicator; the abnormal performance indicators include service response time abnormality, throughput abnormality and error rate abnormality;

[0052] S35: If the performance indicators of each atomized service appear abnormal or the execution result appears abnormal, the corresponding adjustment strategy is executed;

[0053] S36: Adjustment effect evaluation and feedback:

[0054] After the adjustment, the performance indicators of the service are collected and compared with those before the adjustment, and the difference between the performance indicators after the adjustment and those before the adjustment is quantified;

[0055] The adjusted performance indicators and their corresponding threshold values are calculated to obtain the threshold difference value corresponding to the performance indicators;

[0056] The threshold difference is normalized and weighted with the difference degree to obtain an adjustment influence value; if the adjustment influence value is greater than an adjustment effect evaluation threshold, it indicates that the performance index is improved; otherwise, it indicates that the performance index is not significantly improved or deteriorated, and S35 is re-executed until a preset execution number is reached; at the same time, according to the business target and the logic, whether the execution result of the arranged process meets the expectation is evaluated.

[0057] As preferred, based on step S35, if the performance index of each atomized service appears an abnormal condition, or the execution result appears an exception, a corresponding adjustment strategy is executed, specifically:

[0058] S351, if the service response time is too long or the service response time is abnormal, it indicates that the response time is too long due to network fluctuation or temporary load being too high, an exponential backoff algorithm is used for retry, and the request parameter is adjusted to optimize performance;

[0059] The exponential backoff algorithm is used to determine the retry interval time, the initial retry interval is set to , the retry number is m, and the time interval of the mth retry is The calculation formula is: ;

[0060] When any service still fails after a set number of retries, it is identified whether there is a backup service, if there is, the backup service is switched to; when selecting the backup service, a weighted round robin algorithm can be used according to the performance index and health status of the service;

[0061] S352, if the service throughput is insufficient or the throughput is abnormal, it indicates that the service processing capacity is insufficient or fluctuates greatly, the number of service instances is increased through a container orchestration tool;

[0062] S353, if the service error rate is too high or the error rate is abnormal, it indicates that the service frequently appears errors when processing requests, the error log of the service is viewed and error troubleshooting is performed; according to the error troubleshooting result, the service is repaired;

[0063] S354, if the execution result appears an exception, it indicates that the returned result of the service does not meet the expectation, then:

[0064] S3541, detailed information of the execution result exception is recorded, including request parameters, response content, and error time;

[0065] S3542, the business logic of the service is reviewed, if there is a logic error, the logic error is corrected;

[0066] S3543, the consistency of the service related data is checked, if there is a data inconsistency problem, data repair and synchronization are performed;

[0067] S3544, attempts to re-execute the operation for a set number of times, and observes whether the result returns to normal within the set number of times; if not, indicating that the execution result is an abnormality, a rollback operation is performed; when the execution result is an abnormality, a warning mechanism is triggered, and the detailed information of the execution result abnormality is sent to the service-related operation and maintenance personnel.

[0068] As preferred, the application further provides an implementation device for atomic service fusion orchestration based on OPENAPI, comprising:

[0069] a service disassembly and interface definition module, configured to analyze the functions of a complex business application, disassemble the complex business application into atomic services, define service interfaces according to an OpenAPI specification, and generate an OpenAPI document;

[0070] a service registration and discovery module, configured to build a service registration center, implement the registration, health state monitoring and service discovery functions of the atomic services, and select appropriate service instances using a load balancing algorithm;

[0071] an orchestration and adaptive execution module, configured to provide orchestration tools and interfaces, orchestrate service processes according to business requirements, generate service calling templates, monitor service execution states in real time and perform adaptive adjustment;

[0072] a data processing and mapping module, configured to perform semantic analysis, format conversion, cleaning verification and semantic mapping on data transmitted between the atomic services;

[0073] a security control module, configured to implement multi-level identity verification, authorization management and data encryption;

[0074] an integrated deployment and operation and maintenance module, configured to integrate services through an API gateway, use containerization technology for deployment, and establish an automatic operation and maintenance system for monitoring and processing.

[0075] Compared with the related art, the implementation method and device for atomic service fusion orchestration based on OPENAPI provided by the application have the following beneficial effects:

[0076] 1. The application disassembles complex businesses into atomic services, defines interfaces according to the OpenAPI specification, facilitates the addition, deletion and modification of services, reduces integration costs, can quickly respond to business changes, and improves system flexibility and expandability.

[0077] 2. The application builds a service registration center, dynamically discovers services in combination with health states, uses a weighted round robin algorithm to select instances to achieve load balancing, monitors and adjusts in real time during orchestration and execution, guarantees efficient and stable operation of services, and enhances service calling and management capabilities.

[0078] 3、The application integrates atomized services by using API gateway, deploys and arranges through Docker containerization technology and Kubernetes, realizes rapid deployment and elastic scaling of services, and constructs an automatic operation and maintenance system by means of Prometheus and Grafana, realizes real-time monitoring of performance indexes, and automatically alarms and handles when an exception occurs.

[0079] To sum up, at the architecture level, the atomized services are designed according to the OpenAPI specification interface, the system flexibility and expansibility are improved, and the integration cost is reduced; in terms of service management, the service registry center realizes load balancing in combination with the weighted round robin algorithm, and real-time monitoring and adjustment in the execution process guarantee the high efficiency and stability of the services; in terms of deployment and operation, the combination of API gateway, containerization technology and the automatic operation and maintenance system realizes rapid deployment, elastic scaling and intelligent operation and maintenance of services; through these advantages, the problems proposed in the background technology are effectively solved, and an efficient and reliable solution is provided for the development, integration and management of complex business applications. BRIEF DESCRIPTION OF DRAWINGS

[0080] Fig. 1 A flowchart of an implementation method of application atomization fusion arrangement based on OPENAPI provided by the application;

[0081] Fig. 2 A principle block diagram of an implementation device of application atomization fusion arrangement based on OPENAPI provided by the application. DETAILED DESCRIPTION

[0082] The technical solutions in the embodiments of the application will be clearly and completely described below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, rather than all the embodiments of the application. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor fall within the protection scope of the application.

[0083] The terms used in the present disclosure are merely for the purpose of describing specific embodiments, and are not intended to limit the present disclosure. The singular forms "a", "an" and "the" used in the present disclosure and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein means and includes any or all possible combinations of one or more associated listed items.

[0084] It should be understood that, although the terms first, second, third, etc. can be employed in this disclosure to describe various information, the information should not be limited to these terms. These terms are only used to distinguish one type of information from another type of information. For example, without departing from the scope of the present disclosure, first information can also be referred to as second information, and similarly, second information can also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "upon" or "in response to determining".

[0085] Reference should be made to Figs. 1-2 An implementation method of application atomization fusion orchestration based on OPENAPI, comprising the following steps:

[0086] S1: service disintegration and interface definition: complex business applications are disintegrated into atomized services, and the interfaces of each service are defined according to the OpenAPI specification;

[0087] S2: service registration and discovery: a service registration center is built to store service OpenAPI documents and metadata, and services are registered when starting and dynamically discovered when calling in combination with health status;

[0088] S3: orchestration and adaptive execution: service processes are orchestrated according to business requirements, calling templates are generated according to OpenAPI, and real-time monitoring and adaptive adjustment are performed during execution;

[0089] S4: data processing and mapping: semantic analysis is performed when data is transmitted, and format conversion, cleaning verification and semantic mapping are completed;

[0090] S5: security control: multi-level authentication and authorization are adopted, and data is transmitted by encryption;

[0091] S6: integration, deployment and operation: services are integrated through an API gateway, deployed by containerization technology, and an automatic operation and maintenance system is built for monitoring and processing.

[0092] In the present application, based on step S1, complex business applications are disintegrated into atomized services, and the interfaces of each service are defined according to the OpenAPI specification, as follows:

[0093] S11: complex business applications are analyzed for functions, and are disintegrated into a plurality of atomized services with single and clear functions; the atomized services include but are not limited to user authentication services, data query services, order processing services, etc.;

[0094] S12: for each atomized service, a standardized interface is defined according to the OpenAPI specification, the input parameters, output results, request methods and response status codes of the interface are described, and the OpenAPI document of the atomized service is formed.

[0095] It should be noted that through the above steps, the functional specificity of the atomized service enables the developer to focus on the implementation and optimization of a single function, reducing the development complexity. The standardized OpenAPI document provides a clear specification for inter-service interaction, and services developed by different teams can be connected according to the document, reducing communication costs and errors during integration, greatly improving the maintainability and scalability of the system. When business requirements change, atomized services can be easily added, modified or deleted, quickly responding to market changes and improving enterprise competitiveness.

[0096] In the present application, based on step S2, the service registration center is constructed, and the service OpenAPI document and metadata are stored. The service is registered when it is started, and the service is dynamically discovered in combination with the health status when it is called. The specific steps are as follows:

[0097] S21: A service registration center is constructed using a distributed architecture. The service registration center is used to store the OpenAPI document and related metadata of each atomized service. The metadata includes service name, version number, endpoint address, and service health status information. The service registration center monitors the health status of the service in real time through a heartbeat mechanism;

[0098] S22: When the atomized service is started, its OpenAPI document and metadata are registered in the service registration center. The registration process can be completed through the RESTful API provided by the service registration center. At the same time, the service registration center updates the health status information of the service in real time. If the heartbeat information of the service is not received within a set time, the service is marked as unhealthy;

[0099] S23: When an application or service needs to call an atomized service, the service registration center is used to dynamically discover and select the appropriate atomized service according to the service name, function description or metadata information, and in combination with the real-time health status of the service;

[0100] Wherein, in the selection of services, a weighted round-robin algorithm is used, specifically:

[0101] The number of all current service instances SE is denoted as n, the weight of the ith service instance is denoted as wi, and the index of the current request round is denoted as index. The calculation formula of the selected service instance SE is:

[0102] ;

[0103] All server instances are traversed, and the weights are accumulated. When the accumulated value is greater than or equal to the index, the server instance is selected.

[0104] It should be noted that in the weighted round robin algorithm, the setting of the weight wi can allocate the weight according to the hardware resources of the server where the service instance is located and the historical performance data of the service instance, the hardware resources include CPU, memory, disk I / O, etc., the weight setting method is a conventional technology, therefore, it is not described in detail; in the heartbeat mechanism, the selection of the set time is usually set by considering factors such as network delay, average length of service processing request, etc., which is a conventional technology, therefore, it is not described in detail;

[0105] By constructing a service registration center and using a weighted round robin algorithm to select a service instance, appropriate service instances can be accurately provided for the calling party according to the real-time health status of the service and the preset weight, and the calling of unhealthy or poor performance service instances is avoided, thereby improving the efficiency and accuracy of service discovery and ensuring the stable operation of the system;

[0106] The service registration center based on the distributed architecture can easily cope with the registration and management of a large number of atomized services, the atomized services are automatically registered when starting, and are dynamically discovered when being called, so that the system does not need to be modified on a large scale when adding or deleting services, and the scalability and flexibility of the system are enhanced;

[0107] Through the heartbeat mechanism, the health status of the service is monitored in real time, and unhealthy services are marked in time to prevent the calling party from using unavailable services, thereby ensuring the high availability of the entire system; at the same time, the weighted round robin algorithm can allocate requests according to different weights, and reasonably utilize service resources, thereby further improving the availability and performance of the system.

[0108] In the present application, based on step S4, semantic analysis is performed when data is transmitted, format conversion, cleaning verification and semantic mapping are completed, specifically:

[0109] S41: using natural language processing (NLP) technology and domain ontology library, the data transmitted between atomized services is subjected to semantic analysis; key entities and relationships in the data are identified, and the meaning and purpose of the data are understood;

[0110] S42: according to the data format requirements of the source service and the target service, data format conversion is performed; data format conversion is realized by using data conversion tools or writing custom scripts; for example, XML format data is converted into JSON format;

[0111] S43: cleaning and verifying the data, removing invalid data, duplicate data and error data, for ensuring the accuracy and integrity of the data; defining data verification rules, including data type checking, length checking, range checking;

[0112] S44: Establish a semantic mapping table to map the data between different services semantically; for example, map the user ID field between the user authentication service and the order processing service to ensure data consistency.

[0113] In the present application, based on step S5, multi-level identity authentication and authorization are adopted to encrypt the transmission data, specifically including:

[0114] S51: A multi-level identity authentication mechanism is adopted, including OAuth2.0-based token verification and digital certificate-based identity authentication; the user or application needs to provide valid identity credentials when calling the atomized service.

[0115] S52: According to the role and permission of the user or application, fine-grained authorization control is performed on the access to the atomized service; a role-based access control (RBAC) model is adopted to define the permission set of different roles;

[0116] S53: In the data transmission process, the SSL / TLS encryption protocol is adopted to encrypt the data, preventing data leakage and tampering.

[0117] In the present application, based on step S6, the API gateway integration service is used, the containerization technology is deployed, and the automatic operation and maintenance system is monitored and processed, and the specific steps are as follows:

[0118] S61, use API gateway (for example, Kong or Nginx) to integrate the arranged atomized services into a unified interface layer; the API gateway is responsible for receiving external requests, forwarding the requests to the corresponding atomized services according to the request path and parameters, and uniformly processing the requests and responses, including log recording, flow limiting, and caching;

[0119] S62, use Docker containerization technology to package the atomized services into independent containers, and use Kubernetes for container orchestration and management; containerized deployment is used to realize fast deployment, elastic scaling, and resource isolation of services;

[0120] Further, for Kubernetes, its advanced features in service discovery, load balancing, and rolling upgrade can be further explained; in terms of service discovery, Kubernetes provides name resolution for containers through DNS services, enabling different containerized services to easily access each other; in terms of load balancing, Kubernetes provides various load balancing strategies, such as round robin, weight-based load balancing, etc., which can be selected according to the performance and resource status of the service. In rolling upgrade, Kubernetes supports gradually replacing old version containers to ensure service continuity, while monitoring the health status of the service during the upgrade process, and if problems occur, it can be rolled back in time;

[0121] S63, an automated operation and maintenance system is established, Prometheus is used for service performance indicator monitoring, and Grafana is used for data visualization display; when an exception occurs or the performance indicator exceeds the threshold, an automatic alarm and processing mechanism is triggered, including automatic restart of the service and expansion of resources;

[0122] Further, Prometheus supports custom monitoring indicators, and users can collect specific performance data according to the characteristics of the atomic service, such as database connection number, thread pool usage, etc. For alarm rules, it should be clear how to set different alarm levels and notification methods, such as sending alarm information through email, SMS or instant messaging tools; in addition, other tools such as Elasticsearch and Kibana can be combined to realize centralized management and analysis of log data, so as to better troubleshoot system failures.

[0123] Integrate atomic services into the unified interface layer through the API gateway to provide a unified access entry for external systems, simplify the interaction between external systems and atomic services, and reduce system complexity; the unified processing function of the API gateway, such as log recording, flow limiting and caching, helps to manage and optimize the system, improve the performance and security of the system;

[0124] Efficient deployment and flexible expansion: containerization technology (Docker and Kubernetes) realizes the rapid deployment, elastic scaling and resource isolation of atomic services; rapid deployment reduces the time of service online, improves the development and operation efficiency; elastic scaling can automatically adjust the number of service instances according to the change of business load, improve resource utilization and reduce cost; resource isolation ensures the independence of different services, avoids mutual interference, and enhances the stability of the system.

[0125] In the present application, based on step S3, the service process is arranged according to the business requirements, the calling template is generated according to the OpenAPI, and the real-time monitoring and adaptive adjustment are performed during execution, and the specific steps are as follows:

[0126] S31: Business process orchestration design:

[0127] Visual orchestration: Provide a visual orchestration tool, users can drag and drop atomized service icons to the orchestration interface, and use lines to represent the calling order between services; During the orchestration process, the calling order of services, data transmission relationship and conditional judgment logic can be defined;

[0128] Code programming orchestration: Provide API interfaces based on specific programming languages (such as Python, Java, etc. Common programming languages); API interfaces are used to write service orchestration logic using code;

[0129] S32: Call module generation:

[0130] According to the OpenAPI document of the atomized service, a service call template is automatically generated; For each interface defined in the OpenAPI document, extract its request method, request URL, request parameter and response format, etc. Information, request method, such as GET, POST;

[0131] S33: Orchestration process execution:

[0132] Sequential execution: According to the service calling order of the orchestration design, each atomized service is called in turn; When calling each service, use the generated call template and pass the necessary parameters to the service;

[0133] Concurrent execution: For relatively independent service calls, use concurrent execution; It should be noted that when executing concurrently, concurrent control methods based on semaphore, thread pool size and other parameters can be used; This is a mature technical means, which allows users to reasonably configure the number of services executed concurrently according to the resource consumption of the service and the performance requirements of the system; In this way, it can effectively avoid the depletion of system resources due to too high concurrency, and ensure the stable operation of the system; Since this is an existing mature technology, it will not be explained in detail here;

[0134] S34: During service calling, the performance indicators of each atomized service are monitored and analyzed in real time; Through the health check mechanism of the service registry center or the state interface provided by the service itself, service state information is obtained, including whether the service is running normally or whether it has exited abnormally; According to the comparison between the service state information and the preset situation to generate the execution result;

[0135] Real-time monitoring of the performance indicators of each atomized service, and the specific process of obtaining service state information:

[0136] The monitoring points are set at the service calling end and the service end, the request sending and response receiving time are recorded at the service calling end to calculate the response time T; the number of processed requests and the number of error requests in a unit time are counted at the service end to calculate the throughput Q and the error rate E, wherein the response time T represents the time interval from sending the request to receiving the response, the throughput Q represents the number of processed requests in a unit time, and the error rate E represents the proportion of errors in processing the request, and the calculation formula is: wherein represents the number of error requests, represents the total number of requests; and whether the execution result is as expected is determined according to the service return value and the business logic;

[0137] Threshold values of performance indicators of each atomized service are set, including a response time threshold value, a throughput threshold value and an error rate threshold value; the response time threshold value is a maximum acceptable response time set for each atomized service, the throughput threshold value is a minimum request processing quantity that the service must reach in a unit time, and the error rate threshold value is a maximum error proportion allowed by the service; a reasonable threshold value range is set for the execution result of the service according to the business logic of the atomized service;

[0138] If the response time is greater than the response time threshold value, the service is marked as having a long response time; if the throughput is less than the throughput threshold value, the service is marked as having insufficient throughput; if the error rate is greater than the error rate threshold value, the service is marked as having a high error rate; and if the execution result is not in the set reasonable threshold value range, the execution result is determined to be abnormal;

[0139] Meanwhile, the change trend of the performance indicators and the execution result is analyzed, specifically as follows:

[0140] The performance indicators in a set time range before the current time are obtained, the set time range is divided into a plurality of time partitions, and the trend value of the performance indicators in each time partition is calculated by using a standard deviation formula;

[0141] A partition trend threshold value is set, and if the trend value is greater than the partition trend threshold value, the corresponding abnormal trend of the performance indicators is marked; the number of times of the abnormal trend in the set time range is counted and recorded as the abnormal trend number;

[0142] The trend values in each time partition in the set time range are calculated to obtain a total trend value by using the standard deviation formula; the total trend value and the abnormal trend number are normalized and weighted to obtain a trend influence value; if the trend influence value is greater than a preset total trend threshold value, the corresponding performance indicator is marked as an abnormal performance indicator; the abnormal performance indicators include service response time abnormality, throughput abnormality and error rate abnormality;

[0143] S35: If the performance indicators of each atomized service appear abnormal or the execution result appears abnormal, the corresponding adjustment strategy is executed;

[0144] S36: Adjustment effect evaluation and feedback: after the adjustment is executed, the performance indicators of the service are collected and compared with those before the adjustment, the difference degree of the performance indicators after the adjustment and those before the adjustment is quantified; then the difference value of the performance indicators after the adjustment and the corresponding threshold value is calculated to obtain the threshold value difference corresponding to the performance indicators; the threshold value difference and the difference degree are normalized and weighted to obtain the adjustment influence value; if the adjustment influence value is greater than the adjustment effect evaluation threshold value, it indicates that the performance indicators are improved; otherwise, it indicates that the performance indicators are not obviously improved or deteriorated, and S35 is re-executed until the preset execution number is reached; at the same time, according to the business target and the logic, whether the execution result of the orchestration process meets the expectation is evaluated.

[0145] It should be noted that the above steps execute the corresponding adjustment strategy according to the monitoring result of the performance indicators, such as increasing the number of service instances, optimizing the algorithm logic, etc., which can effectively improve the performance of the system; at the same time, the configuration of the concurrency control strategy and the selection of the standby service reasonably utilize the system resources, avoid resource waste, improve resource utilization, and reduce system cost;

[0146] And through the adjustment effect evaluation and feedback mechanism, the orchestration process and the adjustment strategy are continuously optimized to ensure that the execution result of the orchestration process meets the business target and the logic.

[0147] In the present application, based on step S35, if the performance indicators of each atomized service appear abnormal or the execution result appears abnormal, the corresponding adjustment strategy is executed, specifically:

[0148] S351: If the service response time is too long or the service response time is abnormal, it indicates that the response time is too long due to network fluctuation or temporary high load, the exponential backoff algorithm is used for retry, and the request parameter is adjusted to optimize the performance;

[0149] The exponential backoff algorithm is used to determine the retry interval time, the initial retry interval is set to , the retry number is m, and the time interval of the mth retry is calculated as follows: ; for example, the initial retry interval = 1 second, the first retry interval is 1 second, the second retry interval is 2 seconds, the third retry interval is 4 seconds, and so on; wherein the initial retry interval and the maximum retry number should be dynamically adjusted according to the characteristics of different services and business requirements, for example, for services with high real-time requirements, the initial retry interval And reduce the maximum number of retries; for services with lower real-time requirements but higher accuracy requirements, the maximum number of retries can be increased And increase the maximum number of retries; at the same time, introduce a maximum retry time limit to avoid indefinite retries;

[0150] When any service fails after a certain number of retries, identify whether there is a backup service, if there is, switch to the backup service; when selecting a backup service, a weighted round robin algorithm can be used according to the performance indicators and health status of the service;

[0151] S352, if the throughput of the service is insufficient or abnormal, indicating that the service processing capacity is insufficient or fluctuates greatly, increase the number of service instances through a container orchestration tool such as Kubernetes, and increase the processing capacity by increasing the number of service instances; it should be noted that when increasing the number of service instances, according to the change trend and historical data of the throughput, a throughput threshold is set, when the throughput is lower than the threshold, the number of service instances is increased by a certain step, and in order to avoid overcapacity, an upper limit of the number of service instances can be set;

[0152] S353, if the service error rate is too high or abnormal, indicating that the service frequently encounters errors when processing requests, then check the error logs of the service and perform error troubleshooting; repair according to the results of error troubleshooting;

[0153] S354, if the execution result is abnormal, indicating that the returned result of the service does not meet the expected result, i.e. the data format is incorrect, the data content is incorrect or the business logic execution result does not meet the regulations, then:

[0154] S3541, record the detailed information of the execution result exception, including request parameters, response content, error time and service call chain information, the call chain information includes the service name, the call order, and the execution time of each service;

[0155] S3542, review the business logic of the service to ensure that it meets the business requirements and rules; if there is a logic error, correct the logic error;

[0156] S3543, check the consistency of the service related data to ensure that the data has not been modified or lost during the service execution process; if there is a data inconsistency problem, perform data repair and synchronization;

[0157] S3544, try to re-execute the operation for a set number of times, observe whether the result returns to normal within the set number of times, if not, it means that the execution result is abnormal, then a rollback operation is performed, for services involving database operations, the rollback can be performed through the transaction mechanism of the database, for services involving file operations, the files can be backed up and restored to the previous state during rollback, after the rollback operation is completed, verification needs to be performed to ensure that the system returns to a normal state, when the execution result is abnormal, a warning mechanism is triggered, and the detailed information of the execution result exception is sent to the operation and maintenance personnel of the service.

[0158] It should be noted that the above steps can timely handle problems such as long service response time, insufficient throughput, high error rate, and execution result exception by executing corresponding adjustment strategies for different abnormal situations, avoid the abnormality of individual services from affecting the normal operation of the entire system, and improve the reliability and stability of the system; the performance of the system can be effectively optimized by using the exponential backoff algorithm retry, adjusting the request parameters, and increasing the number of service instances, and the response speed and processing capacity of the service are improved, meeting the requirements of users on the performance of the system.

[0159] In the present application, an implementation device for atomic application fusion orchestration based on OPENAPI is also provided, comprising:

[0160] A service disassembly and interface definition module is configured to analyze the functions of a complex business application, disassemble it into atomic services, define the service interfaces according to the OpenAPI specification, and generate OpenAPI documents.

[0161] A service registration and discovery module is configured to build a service registration center, implement the registration, health state monitoring, and service discovery functions of atomic services, and select appropriate service instances using a load balancing algorithm.

[0162] An orchestration and adaptive execution module is configured to provide orchestration tools and interfaces, orchestrate service processes according to business requirements, generate service call templates, monitor service execution states in real time, and perform adaptive adjustments.

[0163] A data processing and mapping module is configured to perform semantic analysis, format conversion, cleaning verification, and semantic mapping on the data transmitted between atomic services.

[0164] A security control module is configured to implement multi-level identity verification, authorization management, and data encryption to ensure the security of the system.

[0165] An integrated deployment and operation module is configured to integrate services through an API gateway, use containerization technology for deployment, and establish an automated operation and maintenance system for monitoring and processing.

[0166] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. It is intended that the application be construed as including any patent, any patent applications, and any patent publications to the extent that such patent, patent applications, and patent publications are consistent with the present disclosure. It is intended that the specification and examples be considered exemplary only, with the true scope and spirit of the application being indicated by the following claims.

[0167] It is to be understood that the application is not limited to the precise construction herein disclosed and shown in the drawings, and that various modifications and changes can be effected therein by those skilled in the art without departing from the scope of the application. The scope of the application is to be limited only by the appended claims.

Claims

1. An implementation method of application atomization fusion orchestration based on OPENAPI, characterized in that, Comprise the following steps: S1: service disassembly and interface definition: split the complex business application into atomized services, define each service interface according to OpenAPI specification; S2: service registration and discovery: build a service registration center, store service OpenAPI documents and metadata, register when the service starts, and dynamically discover the service in combination with the health status when calling, the specific steps are as follows: S21: a distributed architecture is used to build a service registration center, which is used to store the OpenAPI documents and related metadata of each atomized service, the metadata includes service name, version number, endpoint address, service health status information; The service registration center monitors the health status of the service in real time through the heartbeat mechanism; S22: when the atomized service starts, register its OpenAPI document and metadata in the service registration center, wherein the registration process can be completed through the RESTful API provided by the service registration center; At the same time, the service registration center updates the health status information of the service in real time, and if the heartbeat information of the service is not received within a set time, the service is marked as unhealthy; S23: when an application or service needs to call an atomized service, through the service registration center, according to the service name, function description or metadata information, and in combination with the real-time health status of the service, the appropriate atomized service is dynamically discovered and selected; Wherein, in the selection of services, a weighted round robin algorithm is used, specifically: Identify the number of all service instances SE as n, set the weight of the i-th service instance as wi, and the index of the current request round as index, then the calculation formula of the selected service instance SE is: ； Traverse all server instances, accumulate weights, and select the server instance when the accumulated value is greater than or equal to index; S3: orchestration and adaptive execution: orchestrate service processes according to business needs, generate call templates according to OpenAPI, and monitor and adaptively adjust in real time during execution; S4: data processing and mapping: perform semantic analysis when passing data, complete format conversion, cleaning verification and semantic mapping; S5: security control: multi-level authentication and authorization are used, and data transmission is encrypted; S6: integration deployment and operation: integrate services through API gateway, deploy with containerization technology, and build automatic operation and maintenance system for monitoring and processing. 2.The method of claim 1, wherein, Based on step S1, the complex business application is split into atomized services, and each service interface is defined according to OpenAPI specification, specifically as follows: S11: perform functional analysis on the complex business application, and split it into multiple atomized services with single and clear functions; The atomized services include user authentication service, data query service, order processing service; S12: for each atomized service, define a standardized interface according to OpenAPI specification, describe the input parameters, output results, request method and response status code of the interface, and form the OpenAPI document of the atomized service. 3.The method of claim 1, wherein, Based on step S4, semantic analysis is performed when passing data, format conversion, cleaning verification and semantic mapping are completed, specifically as follows: S41: Use natural language processing technology and domain ontology library to perform semantic analysis on the data transmitted between atomized services; identify key entities and relationships in the data, understand the meaning and purpose of the data; S42: Perform data format conversion according to the data format requirements of the source service and the target service; Data format conversion is achieved by using data conversion tools or writing custom scripts; S43: Clean and verify the data, remove invalid, duplicate and error data; define data verification rules, including data type checking, length checking, range checking; S44: Establish a semantic mapping table to map the data between different services semantically.

4. The method of claim 1, wherein the method is characterized in that, Based on step S5, multi-level authentication and authorization are adopted, and data transmission is encrypted, including: S51: Adopt a multi-level authentication mechanism, including OAuth2.0-based token verification and digital certificate-based authentication; users or applications need to provide valid identity credentials when calling atomized services; S52: According to the role and permission of the user or application, the access to the atomized service is controlled in a fine-grained manner; a role-based access control model is adopted to define the permission set of different roles; S53: In the data transmission process, SSL / TLS encryption protocol is used to encrypt the data.

5. The method of claim 1, wherein the method is based on OPENAPI, and characterized in that, Based on step S6, integrate services through API gateway, deploy with containerization technology, and build an automated operation and maintenance system for monitoring and processing, with the following specific steps: S61, use API gateway to integrate the arranged atomized services into a unified interface layer; The API gateway is responsible for receiving external requests, forwarding the requests to the corresponding atomized services according to the request path and parameters, and performing unified processing on the requests and responses, including log recording, flow limiting, and caching; S62, use Docker containerization technology to package the atomized services into independent containers, and use Kubernetes for container orchestration and management; the containerized deployment is used to realize the rapid deployment, elastic scaling and resource isolation of services; S63, build an automated operation and maintenance system, use Prometheus for service performance monitoring, and use Grafana for data visualization; when an exception occurs or the performance indicator exceeds the threshold, automatically trigger the alarm and processing mechanism, including automatically restarting the service and expanding resources.

6. The method of claim 1, wherein the method is based on OPENAPI. Based on step S3, arrange service processes according to business requirements, generate call templates based on OpenAPI, and monitor and adaptively adjust in real time during execution, with the following specific steps: S31: Business process orchestration design: Visual orchestration: Provide a visual orchestration tool, users can drag and drop atomized service icons to the orchestration interface, and use lines to represent the calling order between services; During the orchestration process, the calling order of services, data transmission relationship and conditional judgment logic can be defined; Code programming orchestration: Provide API interfaces based on specific programming languages; The API interface uses code to write service orchestration logic; S32: Call module generation: According to the OpenAPI document of the atomized service, a service call template is automatically generated; for each interface defined in the OpenAPI document, the request method, request URL, request parameter and response format information are extracted; S33: orchestration process execution: Sequential execution: according to the service call sequence designed in orchestration, each atomized service is called in turn; when each service is called, the generated call template is used, and the necessary parameters are passed to the service; Concurrent execution: for relatively independent service calls, concurrent execution is adopted; S34: In the process of service call, the performance indicators of each atomized service are monitored and analyzed in real time; the service state information is obtained through the health check mechanism of the service registry center or the state interface provided by the service, including whether the service is normally running or whether it exits abnormally; According to the comparison between the service state information and the preset condition, the execution result is generated; Real-time monitoring of the performance indicators of each atomized service and analysis, if the response time is greater than its response time threshold, it is marked as service response time is too long; If the throughput is less than its throughput threshold, it is marked as insufficient throughput, and if the error rate is greater than its error rate threshold, it is marked as high service error rate; At the same time, the change trend of performance indicators and execution results is analyzed, specifically: Get the performance indicators in a set time range before the current time, divide the set time range into several time partitions, and calculate the trend value of the performance indicators in each time partition using the standard deviation formula; Set the partition trend threshold, if the trend value is greater than the partition trend threshold, mark the abnormal trend of the performance indicators; The number of abnormal trends in the set time range is recorded as the number of abnormal trends; Then calculate the total trend value of the trend values in each time partition in the set time range using the standard deviation formula; The total trend value and the number of abnormal trends are normalized and weighted to obtain the trend influence value; If the trend influence value is greater than its preset total trend threshold, the corresponding performance indicator is marked as an abnormal performance indicator; the abnormal performance indicators include service response time anomaly, throughput anomaly and error rate anomaly; S35: If the performance indicators of each atomized service appear abnormal or the execution result appears abnormal, execute the corresponding adjustment strategy; S36: adjustment effect evaluation and feedback: After adjusting the corresponding adjustment strategy, the performance indicators of the service are collected and compared with those before the adjustment, and the difference between the performance indicators after the adjustment and those before the adjustment is quantified; Then calculate the threshold difference value of the adjusted performance indicators and their corresponding threshold values; The threshold difference value and the difference degree are normalized and weighted to obtain the adjustment influence value; if the adjustment influence value is greater than its adjustment effect evaluation threshold, the performance indicators are improved; Conversely, it means that the performance indicators have not been significantly improved or deteriorated, and S35 is executed again until the preset execution number is reached; at the same time, according to the business target and logic, whether the execution result of the orchestration process meets the expectation is evaluated.

7. The method of claim 6, wherein the method is characterized in that, Based on step S35, if the performance indicators of each atomized service appear abnormal or the execution result appears abnormal, execute the corresponding adjustment strategy, specifically: S351, if the service response time is too long or the service response time is abnormal, it indicates that the response time is too long due to network fluctuations or temporary high load, and the exponential backoff algorithm is used for retry and adjustment of request parameters to optimize performance; The exponential backoff algorithm is used to determine the retry interval time, and the initial retry interval is set to , the retry number is m, and the time interval of the mth retry is The calculation formula is: ; When any service fails after a certain number of retries, identify whether there is a backup service, if there is, switch to the backup service; When selecting a backup service, you can use a weighted round-robin algorithm to select a service based on its performance indicators and health status; S352, if the service throughput is insufficient or the throughput is abnormal, it indicates that the service processing capacity is insufficient or fluctuates greatly, and the number of service instances is increased through container orchestration tools; S353, if the service error rate is too high or the error rate is abnormal, it indicates that the service frequently makes errors when processing requests, then check the error log of the service and perform error troubleshooting; Repair according to the results of error troubleshooting; S354, if the execution result is abnormal, it indicates that the result returned by the service does not meet the expected result, then: S3541, record the detailed information of the execution result exception, including request parameters, response content, error time; S3542, review the service business logic, if there is a logic error, correct the logic error; S3543, check the consistency of the service related data, if there is a data inconsistency problem, perform data repair and synchronization; S3544, try to re-execute the operation for a certain number of times, and observe whether the result returns to normal within the set number of times; If it does not return to normal, it indicates that the execution result is very abnormal, then perform rollback operation; When the execution result is very abnormal, trigger the early warning mechanism and send the detailed information of the execution result exception to the service related operation and maintenance personnel.

8. An implementation device for atomic application fusion orchestration based on OPENAPI according to any one of claims 1-7, characterized in that, Including: Service disassembly and interface definition module, used for functional analysis of complex business applications, splitting them into atomic services, and defining each service interface according to OpenAPI specification to generate OpenAPI document; Service registration and discovery module, used to build a service registration center to realize the registration, health status monitoring and service discovery functions of atomic services, and select appropriate service instances using load balancing algorithm; Orchestration and adaptive execution module, used to provide orchestration tools and interfaces to orchestrate service processes according to business needs, generate service call templates, monitor service execution status in real time and make adaptive adjustments; Data processing and mapping module, used for semantic analysis, format conversion, cleaning and verification and semantic mapping of data transmitted between atomic services; Security control module, used to realize multi-level identity verification, authorization management and data encryption; Integrated deployment and operation and maintenance module, used to integrate services through API gateway, use containerization technology for deployment, and establish an automated operation and maintenance system for monitoring and processing.

Images