Method, device and equipment for accessing non-cloud native application to cloud native platform and medium

Abstract

The invention relates to the technical field of cloud, the technical scheme can be applied to the field of financial science and technology / medical health, and discloses a method, device, equipment and medium for accessing a non-cloud native application to a cloud native platform, and the method comprises the steps: generating state detection logic decoupled from a target application through analyzing the operation characteristics of the target application; injecting the state detection logic into a cloud native platform in a dynamically updatable configuration resource form, and mounting the state detection logic to an example container of the target application when the target application is instantiated; a health probe which is periodically triggered is configured in the cloud native platform, so that the health probe directionally calls the state detection logic; and automatically triggering the cloud native platform to perform operation and maintenance operation according to an execution result of the state detection logic. According to the technical scheme, non-intrusive, real-time and accurate check access to the cloud native platform of the non-cloud native application can be realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the cloud technology field, the financial technology field and the medical health field, and in particular to a method and device for accessing a cloud native platform by a non-cloud native application, equipment and medium. BACKGROUND

[0002] With cloud native technology becoming a de facto standard of modern infrastructure, container orchestration platforms represented by Kubernetes have been deployed on a large scale in production environments. In particular in key fields such as financial technology and medical health, cloud native architecture significantly improves the reliability and business continuity of the system due to its elastic scaling capacity, gray release mechanism and automated operation and maintenance features.

[0003] Under the premise of wide application of cloud native infrastructure (especially Kubernetes, K8S), although K8S and other cloud native platforms based on K8S have made a lot of efforts in adaptation, migration and modification of non-cloud native applications to facilitate low-cost migration to cloud native environment, the design concept of cloud native determines that the modification of the application program to adapt to the design concept of cloud native is necessary to fully exert the full capacity of the cloud native platform. For example, the liveness mechanism of K8S is an important prerequisite for accessing the cloud native platform for operation and maintenance capabilities such as restart repair, automatic scaling, and traffic management.

[0004] Currently, the K8S platform provides platform interfaces to the applications deployed on the platform in the probe mode to access the liveness mechanism, which is divided into livenessprobe and readnessprobe (corresponding to instance alive detection and instance serviceable detection), and each mechanism can provide exec, httpget, and tcpsocket three types of interface access methods; a qualified cloud native application should consider adapting the liveness mechanism of the cloud native platform in the design. However, for the stock of non-cloud native applications, there are the following problems in accessing: special design and implementation of interfaces require certain manpower and maintenance consumption; in the case of rapid business changes, the high coupling between the liveness interface and the application will cause the problem of not being able to respond to changes in time; for services and software that have entered the maintenance life cycle, the cost of modification is high. SUMMARY

[0005] The present application provides a method, device, equipment and storage medium for accessing a cloud native platform by a non-cloud native application, aiming to solve the problem of non-intrusive and real-time accurate liveness access to a cloud native platform by a non-cloud native application.

[0006] In a first aspect, a method for accessing a cloud native platform by a non-cloud native application is provided, comprising the steps of:

[0007] S10. Generate state detection logic decoupled from the target application by analyzing the operating characteristics of the target application;

[0008] S20: Inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources, and mount it to the instance container of the target application when it is instantiated;

[0009] S30. Configuring a periodically triggered health probe in the cloud native platform to direct the calling of the status detection logic;

[0010] S40. Automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0011] In a second aspect, a device for accessing a non-cloud native application to a cloud native platform is provided, including:

[0012] A detection logic generation module, configured to generate a state detection logic decoupled from the target application by analyzing the operation characteristics of the target application;

[0013] A dynamic injection module is used to inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources and mount it to the instance container of the target application when it is instantiated;

[0014] A probe configuration module is used to configure a periodically triggered health probe in the cloud native platform so that it can call the status detection logic in a targeted manner;

[0015] The operation and maintenance trigger module is used to automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0016] In a third aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the method for connecting a non-cloud native application to a cloud native platform are implemented.

[0017] In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program. When the computer program is executed by a processor, the steps of the method for connecting a non-cloud native application to a cloud native platform are implemented.

[0018] In the solution implemented by the above-mentioned method, apparatus, computer equipment and storage medium for accessing a non-cloud native application to a cloud native platform, by analyzing the operating characteristics of the target application, a state detection logic decoupled from the target application is generated; the state detection logic is injected into the cloud native platform in the form of a dynamically updateable configuration resource, and mounted to its instance container when the target application is instantiated; a periodically triggered health probe is configured in the cloud native platform to direct the call of the state detection logic; and the cloud native platform is automatically triggered to perform operation and maintenance operations based on the execution result of the state detection logic. In the solution provided by the present invention, by dynamically injecting the detection logic decoupled from the business, seamless adaptation of non-cloud native applications to the detection mechanism of the cloud native platform is achieved under the premise of zero code modification, and the hot loading mechanism of configuration resources is used to eliminate the protocol barriers in highly compliant fields such as finance / medical care, thereby reducing adaptation costs while ensuring business continuity. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 This is a schematic diagram of an application environment for a method of connecting a non-cloud native application to a cloud native platform in one embodiment of the present invention;

[0021] Figure 2 This is a flowchart of a method for connecting a non-cloud native application to a cloud native platform in one embodiment of the present invention;

[0022] Figure 3 This is a schematic diagram of a flow chart of state detection logic generation in one embodiment of the present invention;

[0023] Figure 4 This is a flow chart of the execution logic of the interface simulation mode in one embodiment of the present invention;

[0024] Figure 5 This is a flow chart of the execution logic of the log analysis mode in one embodiment of the present invention;

[0025] Figure 6 This is a flow chart of logic injection in one embodiment of the present invention;

[0026] Figure 7 This is a schematic diagram of a process for configuring a platform-level probe in one embodiment of the present invention;

[0027] Figure 8 Schematic diagram of a device for connecting a non-cloud native application to a cloud native platform in one embodiment of the present invention;

[0028] Figure 9 is a structural diagram of a computer device in one embodiment of the present invention;

[0029] Figure 10 FIG. 2 is another structural diagram of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0031] The method for accessing a non-cloud native application to a cloud native platform provided by the embodiment of the present invention is applied in the following Figure 1 In an application environment, the client communicates with the server through a network. A non-cloud native application is deployed on the client, and a cloud native platform is deployed on the server. The server analyzes the operating characteristics of the target application and generates a state detection logic that is decoupled from the target application; the state detection logic is injected into the cloud native platform in the form of a dynamically updateable configuration resource, and is mounted to its instance container when the target application is instantiated; a periodically triggered health probe is configured in the cloud native platform to direct the call of the state detection logic; and the cloud native platform is automatically triggered to perform operation and maintenance operations based on the execution result of the state detection logic. In the solution provided by the present invention, the detection logic that is decoupled from the business is dynamically injected, and the seamless adaptation of the non-cloud native application to the cloud native platform detection mechanism is achieved under the premise of zero code transformation. The configuration resource hot loading mechanism is used to eliminate the protocol barriers in highly compliant fields such as finance / medical care, thereby reducing the adaptation cost while ensuring business continuity. Among them, the client can be, but is not limited to, various personal computers, laptops, smart phones, tablets and portable wearable devices. The server can be implemented with an independent server or a server cluster consisting of multiple servers. The present invention is described in detail below through specific embodiments.

[0032] See also Figure 2 As shown, Figure 2 A flowchart of a method for connecting a non-cloud native application to a cloud native platform provided by an embodiment of the present invention includes the following steps:

[0033] S10. Generate state detection logic decoupled from the target application by analyzing the operation characteristics of the target application.

[0034] In this embodiment, the target application is a non-cloud-native financial application or medical application. A ConfigMap resource containing a liveness check script is created in the Kubernetes cluster, and the entire script content is placed in the data field.

[0035] The target application's operational characteristics refer to the observable behavior exhibited by the application during runtime, including interface characteristics, log characteristics, and resource consumption characteristics. Interface characteristics include the core business interface call method (HTTP / TCP), response format, and throughput threshold. Log characteristics include the log output frequency during peak / off-peak service periods, critical error log patterns, and business success markers. Resource consumption characteristics include CPU / memory baseline levels and thread blocking patterns.

[0036] The status detection logic is a health judgment program that is decoupled from the business and is divided into two implementation forms: interface simulation script: simulates business requests through curl or nc tools to verify return codes and response content; log analysis script: uses grep / awk to scan log files.

[0037] In a specific embodiment, the state detection logic is dynamically updated through a configuration management channel that is independent of the application deployment process.

[0038] In this embodiment, the script content is updated through a configuration management channel independent of the application deployment process; the rolling update mechanism of Kubernetes is used to implement hot loading of the detection and activation strategy.

[0039] like Figure 3 As shown, in a specific embodiment, step S10 specifically includes:

[0040] S11. Build interface simulation mode: Select the read operation interface in the core business process of the target application as the detection endpoint, and build a detection script that includes timeout control and return value verification;

[0041] S12. Build a log analysis model: Identify the regular log output characteristics of the target application and build a log analysis script based on time window weighted calculation.

[0042] In this embodiment, when building the interface simulation mode, timeout monitoring is added to the monitoring logic; a log check script ops_log_healthtest.sh is built, and the log is scanned in the script to determine whether the service is alive by checking whether the log is output normally. If it is normal, the script returns True, otherwise it returns False.

[0043] like Figure 4 As shown, in a specific embodiment, the execution logic of the interface simulation mode specifically includes:

[0044] S111. Screen interfaces that meet the following conditions: read operation interfaces located in core business links; have predictable response data formats; and have call frequencies below the business traffic threshold.

[0045] S112: Embed a local call identifier in the detection script, and configure the application monitoring system to filter log entries containing the identifier.

[0046] In this embodiment, a specific interface representing the service is selected. In principle, interfaces within the core business flow are selected, with read interfaces prioritized and write interfaces avoided as much as possible. A value of 0 is returned when a request is successfully executed, and a non-zero value is returned when a request fails. Timeout monitoring must be added to the monitoring logic. Requests are filtered based on whether they originate locally on the supporting log and monitoring platforms to avoid contamination.

[0047] like Figure 5 As shown, in a specific embodiment, the execution logic of the log analysis mode specifically includes:

[0048] S121. Divide the service / non-service time period according to the service time characteristics of the target application;

[0049] S122. During the service period, calculate the log volumes N1, N2, and N3 within the time windows T, 2T, and 3T before and after the current time respectively; calculate the weighted log volume N = αN1 + βN2 + γN3 according to the preset weight coefficients; where α, β, and γ are weight coefficients respectively;

[0050] S123: When the weighted log volume is lower than the threshold, a multi-time window verification mechanism is started to confirm the status.

[0051] In this embodiment, during the non-service time period, success is directly returned; during the service time period, according to the frequency of log generation, the log volume within the T time window before and after (based on the frequency of log generation of its own application) is extracted to determine whether it reaches the average volume.

[0052] S20. Inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources, and mount it to its instance container when the target application is instantiated.

[0053] like Figure 6 As shown, in a specific embodiment, step S20 specifically includes:

[0054] S21. Create a cloud-native configuration resource object containing state detection logic, where the cloud-native configuration resource object stores the state detection logic in the form of key-value pairs;

[0055] S22. Declare a volume mount relationship in the target application deployment description, and dynamically mount the cloud native configuration resource object to the file system of the application container instance as a read-only volume;

[0056] S23. Implement instantiation loading of the detection logic based on the container runtime mechanism, so that the detection script is generated in a predetermined path when the container is started.

[0057] In this embodiment, the dynamically updateable configuration resource refers to the Kubernetes ConfigMap object, which includes key-value storage: scripts are stored as keys; and a hot reload mechanism: after updating the ConfigMap via kubectl apply , the kubelet automatically synchronizes the new scripts to the mounted volume. This physically isolates scripts from applications, eliminating the need to modify application images. Subsequent script updates require only modifying the ConfigMap, triggering a rolling pod update to take effect, reducing maintenance costs.

[0058] Dynamically mount the ConfigMap resource as a volume to the target application's Pod instance. When the Pod instance starts, a file with the same name and content as in the data field is generated in the mounted directory. This is equivalent to adding the monitoring script to the instance without changing the application image.

[0059] S30. Configure a periodically triggered health probe in the cloud native platform to direct the calling of the status detection logic.

[0060] like Figure 7 As shown, in a specific embodiment, step S30 specifically includes:

[0061] S31. Configure livenessProbe and / or readinessProbe probe objects;

[0062] S32. Set the probe execution mode to command call mode, pointing to the detection script path mounted in the container;

[0063] S33. Implement periodic activation of the probe based on the platform scheduler, and dynamically configure the execution period according to the business characteristics of the target application.

[0064] In this embodiment, the livenessProbe or readinessProbe probe of the Pod instance deployment resource is configured. After running, Kubernetes will periodically execute the script of the status detection logic through the livenessProbe or readinessProbe.

[0065] S40. Automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0066] In this embodiment, the cloud native platform performs operation and maintenance operations including container restart, traffic switching, scaling, and other operations.

[0067] In a specific embodiment, the method for accessing a non-cloud native application to a cloud native platform further includes setting a pollution filtering mechanism, specifically including:

[0068] Set up a request source IP whitelist in the application monitoring system;

[0069] Automatically filter log entries containing local execution tags;

[0070] Establish a traffic isolation channel for detection requests and business requests.

[0071] In this embodiment, setting up a pollution filtering mechanism can prevent detection requests from polluting business monitoring data, thereby ensuring the accuracy of log analysis.

[0072] The present invention also provides a method for accessing a non-cloud native application to a cloud native platform for application in the field of financial technology, and a securities settlement fund penetrating supervision system, comprising:

[0073] Read interface precise screening:

[0074] Select the "Available Stock Balance Query" interface (read operation / return XML format);

[0075] Configure the upper limit of call frequency: 50 times / minute (<< business traffic 2000 times / minute);

[0076] Implant probe identification:

[0077] <requestheader> <probeflag> Y< / probeflag> < / requestheader>

[0078] Dynamic log analysis:

[0079] Service time cut-off:

[0080] Core delivery period (15:00-15:05), T = 10 seconds;

[0081] End of trading period (15:05-16:30), T = 30 seconds;

[0082] Key log features: SUCCESS'FundsTransfer'Account=* / / Funds transfer success flag.

[0083] Circuit breaker linkage: When two consecutive detection failures occur: immediately release the database connection (execute DB2 UNLOAD POOL); trigger the standby machine switch.

[0084] Breaking through regulatory compliance restrictions: Probe identification enables audit logs to comply with the "Guidelines for Data Classification and Grading in the Securities and Futures Industry";

[0085] Dynamic weighting to cope with liquidation peaks: The misjudgment rate of core settlement periods is significantly reduced;

[0086] Automatic release of the connection pool: Avoid single point failures that could cause market-wide settlement delays;

[0087] Improved fault location efficiency: Quickly filter irrelevant logs through probe identification.

[0088] The present invention also provides a method for accessing a non-cloud native application to a cloud native platform for application in the medical and health field, and an intelligent navigation system for interventional surgery, comprising:

[0089] Dynamic time division:

[0090] Service time = surgical schedule + intraoperative extended buffer period (automatically extended by 2 hours);

[0091] Enable basic process detection during non-service hours;

[0092] Multi-dimensional log analysis:

[0093] Core feature: Identify "DSA-Mask generation successful" (should appear once per second);

[0094] Time window: T = 15 seconds (matching the contrast agent injection period);

[0095] Weight configuration: α = 0.7 (current window) β = 0.2 (historical baseline) γ = 0.1 (device readiness signal);

[0096] Secondary verification: When the weighted value N < 0.5, check the DICOM port response delay;

[0097] Clinical value: Accurately capture image processing freezes after contrast agent injection (false alarm rate <0.01%); automatically restart the container within 300ms to avoid navigation screen freezes during surgery; eliminate misjudgments during the equipment warm-up window through dynamic weighting; and meet the stringent service continuity requirements of the operating room RTLS (Real-Time Location System).

[0098] This invention dynamically injects decoupled liveness detection logic, enabling non-cloud native applications to seamlessly access the cloud native platform with zero code modification, thus overcoming the protocol adaptation barriers in high-compliance fields (finance / healthcare). The ConfigMap hot loading mechanism is used to update liveness detection policies in seconds, and local interface simulation and log time series weighted algorithms are combined to accurately identify the suspended state of processes with a low misjudgment rate. At the same time, request identifier filtering and dedicated channel isolation completely eliminate the interference of detection traffic on business monitoring, resulting in a low pollution rate. While ensuring millisecond-level response for financial transactions and 200ms fault switching for real-time medical systems, the transformation cost is reduced.

[0099] like Figure 8 As shown, an embodiment of the present invention further provides a device for accessing a non-cloud native application to a cloud native platform, including:

[0100] A detection logic generation module 10 is configured to generate a state detection logic decoupled from the target application by analyzing the operation characteristics of the target application;

[0101] A dynamic injection module 20 is used to inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources and mount it to the instance container of the target application when it is instantiated;

[0102] A probe configuration module 30 is used to configure a periodically triggered health probe in the cloud native platform so that it can call the status detection logic in a targeted manner;

[0103] The operation and maintenance trigger module 40 is used to automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0104] In a specific embodiment, the state detection logic is dynamically updated through a configuration management channel that is independent of the application deployment process.

[0105] In a specific embodiment, the generating of the state detection logic decoupled from the target application by analyzing the running characteristics of the target application specifically includes:

[0106] Build an interface simulation mode: Select the read operation interface in the core business process of the target application as the detection endpoint, and build a detection script that includes timeout control and return value verification;

[0107] Build a log analysis model: Identify the regular log output characteristics of the target application and build a log analysis script based on time window weighted calculation.

[0108] In a specific embodiment, the execution logic of the interface simulation mode specifically includes:

[0109] Screen interfaces that meet the following conditions: read operation interfaces located in core business links; interfaces with predictable response data formats; interfaces with call frequencies below the business traffic threshold;

[0110] Embed a local call identifier in the detection script and configure the application monitoring system to filter log entries containing this identifier.

[0111] In a specific embodiment, the execution logic of the log analysis mode specifically includes:

[0112] Divide the service / non-service periods according to the service time characteristics of the target application;

[0113] During the service period, calculate the log volume N1, N2, and N3 in the time windows T, 2T, and 3T before and after the current time respectively; calculate the weighted log volume N = αN1 + βN2 + γN3 according to the preset weight coefficients; where α, β, and γ are weight coefficients respectively;

[0114] When the weighted log volume is lower than the threshold, the multi-time window verification mechanism is activated to confirm the status.

[0115] In a specific embodiment, injecting the state detection logic into the cloud native platform in the form of a dynamically updateable configuration resource and mounting it to the instance container of the target application when the target application is instantiated specifically includes:

[0116] Creating a cloud-native configuration resource object containing state detection logic, wherein the cloud-native configuration resource object stores the state detection logic in the form of key-value pairs;

[0117] Declare a volume mount relationship in the target application deployment description, and dynamically mount the cloud native configuration resource object to the file system of the application container instance as a read-only volume;

[0118] The instantiation loading of the detection logic is realized based on the container runtime mechanism, so that the detection script is generated in the predetermined path when the container is started.

[0119] In a specific embodiment, configuring a periodically triggered health probe in the cloud native platform so that it calls the status detection logic in a targeted manner specifically includes:

[0120] Configure livenessProbe and / or readinessProbe probe objects;

[0121] Set the probe execution mode to command call mode, pointing to the detection script path mounted in the container;

[0122] The probe is periodically activated based on the platform scheduler, and the execution period is dynamically configured according to the business characteristics of the target application.

[0123] For the specific limitations on the device for accessing a non-cloud native application to a cloud native platform, please refer to the limitations on the method for accessing a non-cloud native application to a cloud native platform above, which will not be repeated here. The various modules in the above-mentioned device for accessing a non-cloud native application to a cloud native platform can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0124] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 9As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a method for a non-cloud native application to access a cloud native platform on the service side.

[0125] In one embodiment, a computer device is provided. The computer device may be a client, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor, memory, network interface, display screen and input device connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the client-side functions or steps of a method for connecting a non-cloud native application to a cloud native platform.

[0126] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0127] S10. Generate state detection logic decoupled from the target application by analyzing the operating characteristics of the target application;

[0128] S20: Inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources, and mount it to the instance container of the target application when it is instantiated;

[0129] S30. Configuring a periodically triggered health probe in the cloud native platform to direct the calling of the status detection logic;

[0130] S40. Automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0131] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the following steps are implemented:

[0132] S10. Generate state detection logic decoupled from the target application by analyzing the operating characteristics of the target application;

[0133] S20: Inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources, and mount it to the instance container of the target application when it is instantiated;

[0134] S30. Configuring a periodically triggered health probe in the cloud native platform to direct the calling of the status detection logic;

[0135] S40. Automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

[0136] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can be found in the relevant descriptions of the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0137] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0138] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0139] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention, and should all be included in the scope of protection of the present invention.

Claims

1. A method for accessing a non-cloud native application to a cloud native platform, characterized in that: Including steps: By analyzing the operating characteristics of the target application, generating a state detection logic decoupled from the target application; Inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources and mount it to the instance container when the target application is instantiated; Configure a periodically triggered health probe in the cloud native platform to invoke the status detection logic in a targeted manner; Automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

2. The method for accessing a non-cloud native application to a cloud native platform according to claim 1, wherein: The state detection logic is dynamically updated through a configuration management channel that is independent of the application deployment process.

3. The method for accessing a non-cloud native application to a cloud native platform according to claim 1 or 2, characterized in that: The step of generating a state detection logic decoupled from the target application by analyzing the operation characteristics of the target application specifically includes: Build an interface simulation mode: Select the read operation interface in the core business process of the target application as the detection endpoint, and build a detection script that includes timeout control and return value verification; Build a log analysis model: Identify the regular log output characteristics of the target application and build a log analysis script based on time window weighted calculation.

4. The method for accessing a non-cloud native application to a cloud native platform according to claim 3, wherein: The execution logic of the interface simulation mode specifically includes: Screen interfaces that meet the following conditions: read operation interfaces located in core business links; have predictable response data formats; and have call frequencies below the business traffic threshold. Embed a local call identifier in the detection script and configure the application monitoring system to filter log entries containing this identifier.

5. The method for accessing a non-cloud native application to a cloud native platform according to claim 3, characterized in that: The execution logic of the log analysis mode specifically includes: Divide the service / non-service periods according to the service time characteristics of the target application; During the service period, calculate the log volume N1, N2, and N3 in the time windows T, 2T, and 3T before and after the current time respectively; calculate the weighted log volume N = αN1 + βN2 + γN3 according to the preset weight coefficients; where α, β, and γ are weight coefficients respectively; When the weighted log volume is lower than the threshold, the multi-time window verification mechanism is activated to confirm the status.

6. The method for accessing a non-cloud native application to a cloud native platform according to claim 1, wherein: Injecting the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources and mounting it to the instance container of the target application when it is instantiated specifically includes: Creating a cloud-native configuration resource object containing state detection logic, wherein the cloud-native configuration resource object stores the state detection logic in the form of key-value pairs; Declare a volume mount relationship in the target application deployment description, and dynamically mount the cloud native configuration resource object to the file system of the application container instance as a read-only volume; The instantiation loading of the detection logic is realized based on the container runtime mechanism, so that the detection script is generated in the predetermined path when the container is started.

7. The method for accessing a non-cloud native application to a cloud native platform according to claim 1, wherein: Configuring a periodically triggered health probe in the cloud native platform to direct the calling of the status detection logic specifically includes: Configure livenessProbe and / or readinessProbe probe objects; Set the probe execution mode to command call mode, pointing to the detection script path mounted in the container; The probe is periodically activated based on the platform scheduler, and the execution period is dynamically configured according to the business characteristics of the target application.

8. A device for accessing a non-cloud native application to a cloud native platform, characterized in that: include: A detection logic generation module, configured to generate a state detection logic decoupled from the target application by analyzing the operation characteristics of the target application; A dynamic injection module is used to inject the state detection logic into the cloud native platform in the form of dynamically updateable configuration resources and mount it to the instance container of the target application when it is instantiated; A probe configuration module is used to configure a periodically triggered health probe in the cloud native platform so that it can call the status detection logic in a targeted manner; The operation and maintenance trigger module is used to automatically trigger the cloud native platform to perform operation and maintenance operations based on the execution results of the status detection logic.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the method for accessing a non-cloud native application to a cloud native platform as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method for accessing a non-cloud native application to a cloud native platform as described in any one of claims 1 to 7 are implemented.

Images