Service publishing method, apparatus, device, and storage medium

Abstract

The application relates to the technical field of data processing, and discloses a service publishing method, device and equipment and a storage medium. The method comprises the following steps: determining a target service to be changed, setting the state of the target service and the state of an associated service having a dependency relationship with the target service to a change state; acquiring associated information corresponding to a service change request, and determining a configuration condition; generating change content based on the configuration condition, and changing the target service and the associated service; testing the changed target service and the associated service, setting the changed target service and the associated service to a to-be-published state according to a test result; acquiring a program file and a configuration file of the target service, and publishing the service according to the program file and the configuration file. The system notification and response are achieved by changing the service state, the technical problem that the upstream and downstream systems cannot be synchronously changed and published during system change publishing is solved, and the service publishing efficiency of the system is improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a service publishing method, apparatus, device, and storage medium. Background Technology

[0002] Currently, system releases, especially those involving multiple interconnected systems, rely on changing system administrators to recruit staff and then informing upstream and downstream systems through discussion groups or announcements. This approach presents several problems: Data synchronization / notification methods suffer because older systems have undergone multiple handovers, and current maintenance personnel may not fully understand upstream and downstream dependencies. Service changes cannot guarantee notification to all relevant systems. Even if downstream systems are aware of changes to their upstream systems, they cannot quickly determine which parts of their system (the downstream system) depend on the changed services, especially for maintenance colleagues newly taking over the project. In cases of multi-level dependencies, the lowest-level service (the downstream system) is generally unaware of upstream system changes until problems arise, requiring a hierarchical investigation to identify the upstream system as the source of the change.

[0003] Because notifications of changes via discussion groups or announcements are easily overwritten, subsequent participants are unaware of the changes, requiring repeated communication and confirmation, resulting in high communication costs, low efficiency, and a lack of security. Furthermore, when a system publishes changes, it's uncertain whether downstream systems have made corresponding adjustments, leading to successful notifications but asynchronous publication times, causing production issues. Therefore, achieving inter-system notification and response through changes to service status has become a technical problem that those skilled in the art must address. Summary of the Invention

[0004] The present invention mainly solves the technical problem in the prior art that when the services of interconnected upstream and downstream systems change, the systems cannot track and synchronize with each other.

[0005] The first aspect of the present invention provides a service publishing method, comprising: receiving a service change request; determining a target service to be changed based on the service change request, wherein the system to which the target service belongs is a target system; determining associated services that have a dependency relationship with the target service based on a pre-defined dependency relationship between multiple services, and setting the status of the target service and the associated services to a changed state; obtaining association information corresponding to the service change request, and determining configuration conditions based on the association information; generating change content based on the configuration conditions, and changing the target service and the associated services according to the change content; constructing a test case library to test the changed target service and associated services, and setting the changed target service and associated services to a pending publishing state based on the test results; obtaining the program file and configuration file of the target service, and publishing the service according to the program file and the configuration file.

[0006] Optionally, in a first implementation of the first aspect of the present invention, before determining the associated services that have a dependency relationship with the target service based on the pre-defined dependency relationships between multiple services, and setting the state of the target service and the associated services to a changed state, the method further includes: determining the service dependency relationships of the target service test scenario based on the parameter transmission information between services during the test of the target service test scenario; recording the runtime statistics of the service test scenario during the test, wherein the runtime statistics characterize the runtime characteristics of the service test scenario during the test; clustering the runtime statistics of all service test scenarios to obtain at least one cluster; merging the service dependency relationships of each service test scenario within each cluster to obtain the service dependency relationship of the cluster; and merging the service dependency relationships of the at least one cluster to obtain the dependency relationships between the multiple services.

[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of constructing a test case library to test the modified target service and related services, and setting the modified target service and related services to a pending release state based on the test results, includes: constructing a test case library for synchronously testing the functionality and performance of the modified target service and related services; when the modified target service and related services are released to the public, executing the test cases in the test case library in parallel to test the modified target service and related services and obtaining test results; analyzing the test results to generate a functional result analysis report and a performance result analysis report for the target system; and setting the modified target service and related services to a pending release state based on the functional result analysis report and the performance result analysis report.

[0008] Optionally, in a third implementation of the first aspect of the present invention, obtaining the program file and configuration file of the target service and publishing the service based on the program file and configuration file includes: obtaining the program file and configuration file of the target service; generating an image file of the target service based on the program file and configuration file; and publishing the service based on the image file.

[0009] Optionally, in a fourth implementation of the first aspect of the present invention, after generating the change content based on the configuration conditions and changing the target service and the associated service according to the change content, the method further includes: obtaining the dependencies between multiple systems; determining the associated systems that have a dependency relationship with the target system according to the dependencies between the multiple systems; sending the change content to the associated systems and setting the status of the associated systems to known; obtaining all services contained in the associated systems and setting the status of the services to changed status.

[0010] Optionally, in a fifth implementation of the first aspect of the present invention, obtaining the dependencies between multiple systems includes: receiving user requests through the target system and assigning a tracking ID to each user request; monitoring requests sent by each system to other systems and recording the monitoring results of each system as logs; and statistically analyzing the logs of each system to obtain the dependencies between different systems.

[0011] Optionally, in a sixth implementation of the first aspect of the present invention, recording the operational statistics of the service test scenario during the test process includes: obtaining log information of the plurality of services during the test process; taking non-interface operation error log information in the log information of the plurality of services during the test process as invalid log information of the plurality of services during the test process; and taking the operational statistics of each service in the log information of the plurality of services during the test process (excluding invalid log information) as the operational statistics of the service during the test process.

[0012] A second aspect of the present invention provides a service publishing apparatus, comprising:

[0013] A receiving module is used to receive a service change request and determine the target service to be changed based on the service change request, wherein the system to which the target service belongs is the target system; a first setting module is used to determine the associated services that depend on the target service based on the pre-defined dependencies between multiple services, and set the status of the target service and the associated services to a changed state; a first determining module is used to obtain the association information corresponding to the service change request and determine the configuration conditions based on the association information; a changing module is used to generate change content based on the configuration conditions and change the target service and the associated services according to the change content; a testing module is used to build a test case library to test the changed target service and associated services, and set the changed target service and associated services to a pending release state based on the test results; a release module is used to obtain the program file and configuration file of the target service and release the service according to the program file and configuration file.

[0014] Optionally, in a first implementation of the second aspect of the present invention, the service publishing device further includes: a second determining module, configured to determine the service dependencies of the target service test scenario based on parameter transmission information between services during the test process; a recording module, configured to record operational statistics of the service test scenario during the test process, wherein the operational statistics characterize the operational characteristics of the service test scenario during the test process; a clustering module, configured to cluster the operational statistics of all service test scenarios to obtain at least one cluster; and a merging module, configured to merge the service dependencies of each service test scenario within each cluster to obtain the service dependencies of the cluster; and merge the service dependencies of the at least one cluster to obtain the dependencies between the plurality of services.

[0015] Optionally, in a second implementation of the second aspect of the present invention, the testing module includes: a construction unit, configured to construct a test case library for synchronously testing the function and performance of the target service; a testing unit, configured to execute test cases in the test case library in parallel when the target service is released to the public, to test the target service and obtain test results; an analysis unit, configured to analyze the test results and generate a functional result analysis report and a performance result analysis report of the target system; and a setting unit, configured to set the target service and the associated service to a pending release state based on the functional result analysis report and the performance result analysis report.

[0016] Optionally, in a third implementation of the second aspect of the present invention, the publishing module is specifically used to: obtain the program file and configuration file of the target service; generate an image file of the target service based on the program file and configuration file; and publish the service based on the image file.

[0017] Optionally, in a fourth implementation of the second aspect of the present invention, the service publishing device further includes: an acquisition module for acquiring dependencies between multiple systems; a third determination module for determining associated systems that have dependencies on the target system based on the dependencies between the multiple systems; a sending module for sending the changed content to the associated system and setting the status of the associated system to known; and a second setting module for acquiring all services contained in the associated system and setting the status of the services to changed state.

[0018] Optionally, in the fifth implementation of the second aspect of the present invention, the acquisition module is specifically used to: receive user requests through the target system and assign a tracking ID to each user request; listen to requests sent by each system to other systems and record the listening results of each system as logs; and collect statistics on the logs of each system to obtain the dependencies between different systems.

[0019] Optionally, in a sixth implementation of the second aspect of the present invention, the recording module is specifically used to: obtain log information of the plurality of services during the testing process; take the log information of the plurality of services during the testing process that is not an interface running error as invalid log information of the plurality of services during the testing process; and take the running statistics information of each service in the log information of the plurality of services during the testing process other than invalid log information as the running statistics information of the service during the testing process.

[0020] A third aspect of the present invention provides a service publishing device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line;

[0021] The at least one processor invokes the instructions in the memory to cause the service publishing device to execute the service publishing method described above.

[0022] A fourth aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the service publishing method described above.

[0023] The technical solution provided by this invention involves: identifying the target service to be changed; setting the status of the target service and its dependent services to a changed state based on pre-defined dependencies between multiple services; obtaining the associated information corresponding to the service change request and determining configuration conditions; generating change content based on the configuration conditions and modifying the target service and its dependent services accordingly; testing the changed target service and its dependent services and setting them to a pending release state based on the test results; obtaining the program file and configuration file of the target service and releasing the service based on these files. This solution achieves inter-system notification and response by changing service status, solving the technical problem of upstream and downstream systems being unable to synchronize changes during system release and improving system service release efficiency. Attached Figure Description

[0024] Figure 1 This is a schematic diagram of the first embodiment of the service publishing method of the present invention;

[0025] Figure 2 A schematic diagram of a second embodiment of the service publishing method of the present invention;

[0026] Figure 3 A schematic diagram of a third embodiment of the service publishing method of the present invention;

[0027] Figure 4 This is a schematic diagram of the fourth embodiment of the service publishing method of the present invention;

[0028] Figure 5 This is a schematic diagram of the fifth embodiment of the service publishing method of the present invention;

[0029] Figure 6 This is a schematic diagram of the first embodiment of the service publishing device of the present invention;

[0030] Figure 7 This is a schematic diagram of a second embodiment of the service publishing device of the present invention;

[0031] Figure 8 This is a schematic diagram of an embodiment of the service publishing device of the present invention. Detailed Implementation

[0032] This invention provides a service publishing method, apparatus, device, and storage medium. The technical solution of this invention first determines the target service to be modified; based on pre-defined dependencies between multiple services, the target service and its dependent services are set to a modified state; association information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are modified according to the change content; the modified target service and related services are tested, and based on the test results, the modified target service and related services are set to a pending-publishing state; the program file and configuration file of the target service are obtained, and service publishing is performed according to the program file and the configuration file. This solution achieves inter-system notification and response by changing service states, solving the technical problem that upstream and downstream systems cannot synchronize changes during system change publishing, and improving the efficiency of system service publishing.

[0033] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 The first embodiment of the service publishing method in this invention includes:

[0035] 101. Receive service change requests and determine the target service to be changed based on the service change requests;

[0036] In this embodiment, a service change request is received, and the target service to be changed is determined based on the request. Services include, but are not limited to, interfaces, tables, domain names, NAS, and other file information. An application system or multiple related application systems may implement relevant functions through service (interface) calls. The target service is a service to be orchestrated and / or published in the current runtime environment.

[0037] 102. Based on the pre-defined dependencies between multiple services, identify the related services that depend on the target service, and set the status of the target service and related services to the changed state.

[0038] In this embodiment, based on the pre-defined dependencies between multiple services, associated services that depend on the target service are identified, and the status of the target service and associated services is set to a changed state. Here, "service" refers to various services required in a computer to support various functions; some services can also be manually enabled or disabled to manage corresponding functions.

[0039] Dependencies can exist between various components of a system, especially between classes, packages, modules, and services. There are three basic forms of dependency: direct dependencies, such as Service1 depending on Service2, are the easiest to identify and manage; indirect dependencies are a derivative of direct dependencies—when Service1 depends on Service2, and Service2 depends on Service3, Service1 has an indirect dependency on Service3; and circular dependencies are mutual dependencies between Service1 and Service2. Circular dependencies are sometimes not as easy to identify as depicted in the diagram because multiple components that create circular dependencies may simultaneously have various direct and indirect dependencies.

[0040] From the perspective of fault tolerance, service dependencies can be divided into weak dependencies and strong dependencies. If a microservice fails to provide service, the entire business process that depends on it cannot execute properly; this is a strong dependency. In other words, a strong dependency is the basic unit for the normal operation of a service. Weak dependencies, on the other hand, do not have this limitation. For services such as message sending, if the service fails to provide functionality, the core business process can still operate normally.

[0041] 103. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information;

[0042] In this embodiment, the associated information corresponding to the service change request is obtained, and configuration conditions are determined based on the associated information. When a terminal connects to a server, and the server needs to perform a service change, it must send a service change notification to the connected terminal before the service change. The terminal can receive the service change notification from the server, allowing it to immediately know the change operation the server is about to perform and respond to the server change operation in the shortest possible time. This eliminates the latency problem of relying solely on heartbeat detection to check the connection status, thus reducing data loss. Furthermore, the server only performs the service change operation after the terminal receives the service change notification within a predetermined time, ensuring that data requests sent by the terminal can be returned normally, further reducing data loss.

[0043] 104. Generate change content based on configuration conditions, and make changes to the target service and related services according to the change content;

[0044] In this embodiment, change content is generated based on configuration conditions, and the target service is modified according to the change content. For example, the main publishing system initiates a service change process, each dependent system confirms the change, and a unified release is performed. Target system A initiates a service change, selects its own publishing system in the assurance system, selects the service to be changed, and sets the service status to "Changed." It checks whether there are any subordinate systems that depend on system A's service, whether there are any superior systems that will also affect this service, and checks whether the status of related [systems and services] is unknown (obtaining all upstream and downstream systems that depend on system A, and checking the status of the upstream and downstream systems and services). Subordinate system B that depends on system A's service, after discovering that its upstream system A has changed, needs to set its own status to "Known" in system A's service change process. It also sets the services in system B that need corresponding adjustments to the "Changed" status. Furthermore, it checks whether there are any downstream systems that depend on system B's service, and whether there are any upstream systems that will affect this service. If so, check if the status of the related systems and services is unknown, and so on for subsequent dependent systems; for related change systems, after testing is completed, the service status needs to be set to pending release to ensure that the system updates the progress of this service in the change process; when the progress of the change process is 100%, release can be scheduled.

[0045] For example, if the [A-test service] in system A changes, select system A, list all its services using system code, and select the A-test service. Using the dependency table, record the service code: a0001, and the downstream service code: b0001, listing service b0001 (if there are multiple downstream services, list them all using this method), displaying the status of service b0001 as [Unknown]. Edit the content of this change for service A-test, setting the service status to [Changed], and setting the main process ID for this change: 202011200001a0001001 (year, month, day + system code + service code + serial number). This will generate a record with the main change ID: 202011200001a0001001, the changed service code: a0001, the status [Changed], and the changed content. A message recording this change and the process ID will also be sent to the downstream systems. This completes the service change notification for system A.

[0046] After logging in, downstream system B will display a change notification from upstream system A on its page. Upon receiving the notification, system B will assess the impact on its services and maintain the service changes. It will select system B, choose service b0001, fill in the change details, and enter the main process number sent by system A. The relationship table will list all services dependent on system B. A record will be generated with the change master ID: 202011200001a0001001, change service code: b0001, status [Changed], and change details. Simultaneously, the change notification from system A will be confirmed via the confirmation button. At this point, the status of system B's service in system A's service change list will be changed to [Known] (corresponding to [Unknown] above). The change notification and response from downstream system B is now complete. Subsequent dependent systems will follow the same procedure until the final system.

[0047] Once the development and testing of service a0001 is complete, its status needs to be set to "Pending Release." This will update the status of service a0001 (process number 202011200001a0001001) to "Pending Release." This process is repeated for other services on process number 202011200001a0001001 after their development and testing are completed. When all services on process number 202011200001a0001001 are in the "Pending Release" status, a release date can be agreed upon for all services to be released together. This completes the process from change to release.

[0048] 105. Build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release status based on the test results;

[0049] In this embodiment, a test case library is built to test the modified target service and related services, and the modified target service and related services are set to a pending release state based on the test results. In this embodiment, the test case library is mainly used to manage test cases, and the creation and daily maintenance of test cases for each service (interface) can be completed in the test case library.

[0050] The backend system service is tested as soon as it is released to the public, which is during the development phase of the backend system service. This changes the traditional testing process of the backend system. Furthermore, when testing the backend system service, test cases from the test case library are executed in parallel. The backend system service is called through the test cases to test the backend system service.

[0051] 106. Obtain the program files and configuration files of the target service, and publish the service based on the program files and configuration files.

[0052] In this embodiment, the program file and configuration file of the target service are obtained, and the service is published based on the program file and configuration file. The image file, generated from the program file and configuration file, is used to provide the target service. The program file and configuration file are processed according to preset procedures and packaged into an image file of the target service to facilitate the creation of an environment image for the target service to run.

[0053] In this embodiment, when a system service changes, the corresponding service's status needs to be set to a changed state, i.e., the initial state. Downstream systems that depend on this service being changed are listed, and each downstream system also has a corresponding status for this change. The specific content of the change is also appended. Each release generates a release process number, recording the change content of each system and its change status. The status of each system is recorded in the release progress of this process. In principle, release can only proceed when the change status reaches 100%.

[0054] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves notification and response between systems by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0055] Please see Figure 2 The second embodiment of the service publishing method in this invention includes:

[0056] 201. Receive service change requests and determine the target service to be changed based on the service change requests;

[0057] 202. Based on the parameter transfer information between services during the test of the target service test scenario, determine the service dependencies of the target service test scenario;

[0058] In this embodiment, for any one of the multiple services, the service dependencies are determined based on the parameter transmission information between services during the testing process. An application system or multiple related application systems implement relevant functions through service (interface) calls. Each function or a combination of functions constitutes a business application scenario, and the scenario for testing related services (interfaces) under each business application scenario is called a service (interface) test scenario.

[0059] In this embodiment, for the first service, if the parameter transmission information of the first service indicates that the parameter output by the first service is the parameter input by the second service, then it is determined that the second service depends on the first service; if the parameter transmission information of the first service indicates that the parameter input by the first service is the parameter output by the third service, then it is determined that the first service depends on the third service; the first service, the second service, and the third service are all services among the services in the service testing scenario.

[0060] It should be noted that the service dependencies in a service testing scenario can be referred to as a single service dependency. The meaning of the parameter output by the first service being the parameter input by the second service can be: the value of the parameter input by the second service is assigned based on the parameter output by the first service. Similarly, the meaning of the parameter input by the first service being the parameter output by the third service can be: the value of the parameter input by the first service is assigned based on the parameter output by the third service.

[0061] 203. Obtain log information from multiple services during the testing process;

[0062] In this embodiment, log information from multiple services during the testing process is acquired. This log information records every detail of the system's operation and plays a crucial role in the system's stable operation. By reviewing the server's log information, administrators can promptly identify the cause of server failures.

[0063] 204. Log messages that are not related to interface runtime errors in the log information of multiple services during the testing process will be treated as invalid log messages of multiple services during the testing process;

[0064] In this embodiment, log information that is not related to service runtime errors in the logs of multiple services during the testing process is considered invalid log information for those services during the testing process. These logs, also known as system logs, record information about hardware, software, and system problems, and also monitor events occurring in the system. Users can use them to check the cause of errors or look for traces left by attackers during attacks. System logs include system logs, application logs, and security logs.

[0065] 205. Take the runtime statistics of each service in the log information (excluding invalid log information) during the testing process of multiple services as the runtime statistics of the service during the testing process;

[0066] In this embodiment, the runtime statistics of each service during the testing process, excluding invalid log information, are used as the runtime statistics of the service during the testing process. Specifically, the runtime statistics of the multiple service test scenarios are the runtime statistics of each service test scenario after removing invalid log information from the log information of the multiple service test scenarios during the testing process. Therefore, only the runtime statistics of log information containing interface execution errors are retained, resulting in more accurate runtime statistics and facilitating the analysis of service test scenarios caused by interface errors.

[0067] 206. Cluster the runtime statistics of all service test scenarios to obtain at least one cluster;

[0068] In this embodiment, the runtime statistics of all service test scenarios are clustered to obtain at least one cluster. Before clustering, data cleaning can be performed on the log information of the multiple service test scenarios during the testing process. This is because the runtime log information monitored and collected by the background collector for test cases is not necessarily the log information of interest. For example, the log information to be extracted here can be service (interface) fields with clustering characteristics and additional statistical results. Generally, these service (interface) fields are universal and necessary for all services (interfaces) and can be marked for attention. For additional statistical results, system function coverage and system database table coverage can be highlighted for attention. Furthermore, invalid log information can be filtered out based on this highlighted information. Invalid log information refers to log information of non-service (interface) runtime errors, such as invalid log information generated by the application system of the service under test not enabling process communication or service (interface) parameters not being sent correctly.

[0069] 207. For each cluster in at least one cluster, merge the service dependencies of each service test scenario within the cluster to obtain the service dependencies of the cluster.

[0070] In this embodiment, for each cluster within at least one cluster, the service dependencies of each service test scenario within the cluster are merged to obtain the service dependency relationship of the cluster. Specifically, the running data points of K service test scenarios out of N service test scenarios are selected as the K centroids of the K clusters. The distances between the running data points of the N service test scenarios and the K centroids are determined according to a preset distance calculation rule. Based on a preset cluster partitioning rule and the distances between the running data points of the N service test scenarios and the K initial centroids, the running data points of the service test scenarios within the K clusters are determined. When the running data points of the service test scenarios within the K clusters converge, the K clusters are considered as the at least one cluster, thus obtaining the service dependency relationship of the cluster.

[0071] 208. Merge the service dependencies of at least one cluster to obtain the dependencies between multiple services;

[0072] In this embodiment, the service dependencies of at least one cluster are merged to obtain the dependencies between multiple services. Specifically, for each of the at least one cluster, the service dependencies of each service test scenario within that cluster are merged to obtain the service dependencies of that cluster; and the process of merging the service dependencies of the at least one cluster to obtain the service dependencies between the multiple service test scenarios is also included.

[0073] 209. Based on the pre-defined dependencies between multiple services, identify the related services that depend on the target service, and set the status of the target service and related services to the changed state.

[0074] 210. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information;

[0075] 211. Generate change content based on configuration conditions, and make changes to the target service and related services according to the change content;

[0076] 212. Build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release status based on the test results;

[0077] 213. Obtain the program files and configuration files of the target service, and publish the service based on the program files and configuration files.

[0078] Steps 201 and 209-213 in this embodiment are similar to steps 101-106 in the first embodiment, and will not be repeated here.

[0079] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves inter-system notification and response by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0080] Please see Figure 3 The third embodiment of the service publishing method in this invention includes:

[0081] 301. Receive service change requests and determine the target service to be changed based on the service change requests;

[0082] 302. Based on the pre-defined dependencies between multiple services, identify the related services that depend on the target service, and set the status of the target service and related services to the changed state.

[0083] 303. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information;

[0084] 304. Generate change information based on configuration conditions, and make changes to the target service and related services according to the change information;

[0085] 305. Build a test case library for synchronous functional and performance testing of the changed target service and related services;

[0086] In this embodiment, a test case library is constructed to perform synchronous functional and performance testing on the modified target service and related services. The test case library is primarily used to manage test cases, allowing for the creation and routine maintenance of test cases for each service (interface). The backend system supports internally defined basic data types for the test cases in the library.

[0087] 306. When the modified target service and related services are released to the public, test cases in the test case library are executed in parallel to test the modified target service and related services and obtain test results.

[0088] In this embodiment, when the modified target service and related services are released to the public, test cases in the test case library are executed in parallel to test the modified target service and related services, and test results are obtained. Specifically, the backend system service is tested during its development phase, when it is ready for public release. This changes the traditional testing process for backend systems. Furthermore, the testing of the backend system service employs the parallel execution of test cases from the test case library, using these test cases to call and test the backend system service.

[0089] 307. Analyze the test results and generate a functional results analysis report and a performance results analysis report for the target system;

[0090] In this embodiment, the test results are analyzed to generate a functional result analysis report and a performance result analysis report for the target system. Specifically, after testing the backend system services, the test results are analyzed, including both functional and performance analyses. When analyzing the functionality of the test results, the execution results of the corresponding test cases can be analyzed. When analyzing the performance of the test results, the response time of the corresponding test cases, the service's business transaction volume, and resource utilization can be analyzed.

[0091] 308. Based on the functional results analysis report and the performance results analysis report, set the changed target service and related services to the pending release status;

[0092] In this embodiment, based on the functional result analysis report and the performance result analysis report, the modified target service and related services are set to a pending release status. Specifically, after analyzing the test results of the backend system services, a functional result analysis report and a performance result analysis report are generated simultaneously. These reports can be in a single report or in separate reports; this embodiment does not impose any limitations. The target service and related services are then set to a pending release status.

[0093] 309. Obtain the program files and configuration files of the target service, and publish the service based on the program files and configuration files.

[0094] Steps 301-304 and 309 in this embodiment are similar to steps 101-104 and 106 in the first embodiment, and will not be described again here.

[0095] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves inter-system notification and response by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0096] Please see Figure 4 The fourth embodiment of the service publishing method in this invention includes:

[0097] 401. Receive service change requests and determine the target service to be changed based on the service change requests;

[0098] 402. Based on the pre-defined dependencies between multiple services, identify the related services that depend on the target service, and set the status of the target service and related services to the changed state.

[0099] 403. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information;

[0100] 404. Generate change information based on configuration conditions, and then modify the target service and related services according to the change information;

[0101] 405. Build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release status based on the test results;

[0102] 406. Obtain the program files and configuration files of the target service;

[0103] In this embodiment, the program files and configuration files of the target service are obtained. The target service is a service to be orchestrated and / or published in the current runtime environment. It can be an AI service that has matured through deep learning training, or other services. Other services refer to the smallest service unit in the current runtime environment. The program files for the target service vary depending on its attributes. For example, for model-type services, the program file is the service model file, including computation graphs, data flows, and other models; for application-type services, the program file is the application's program code package.

[0104] The configuration file contains parameters for the target service, such as the framework used by the target service and a list of input / output parameters that conform to the preset interface specifications.

[0105] 407. Generate the image file of the target service based on the program files and configuration files;

[0106] In this embodiment, an image file of the target service is generated based on the program file and configuration file. The image file, generated from the program file and configuration file, is used to provide the target service. The program file and configuration file are processed and packaged into the image file of the target service to facilitate the creation of an environment image for the target service to run.

[0107] 408. Publish the service based on the image file.

[0108] In this embodiment, service publishing is performed based on the image file. Specifically, a deployment package is generated based on the service configuration information in the service engineering package, and the service is deployed and published using this deployment package. If a WebService is being published, a corresponding service description file is generated based on the service configuration information in the service engineering package.

[0109] Steps 401-405 in this embodiment are similar to steps 101-105 in the first embodiment, and will not be repeated here.

[0110] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves inter-system notification and response by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0111] Please see Figure 5 The fifth embodiment of the service publishing method in this invention includes:

[0112] 501. Receive a service change request and determine the target service to be changed based on the service change request;

[0113] 502. Based on the pre-defined dependencies between multiple services, identify the related services that depend on the target service, and set the status of the target service and related services to the changed state.

[0114] 503. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information;

[0115] 504. Generate change information based on configuration conditions, and make changes to the target service and related services according to the change information;

[0116] 505. Receive user requests through the target system and assign a tracking ID to each user request;

[0117] In this embodiment, the target system receives user requests and assigns a tracking ID to each user request. This embodiment uses a user's loan request as an example. User a applies for a loan or credit limit increase to system A through a terminal application or other means. System A can be an information verification system. After receiving user a's request, system A assigns a tracking ID to the request. Simultaneously, system A performs a preliminary verification of the information provided by user a to determine if the user's information is accurate and meets the request conditions. If the verification is successful, user a's request is sent to system B. When sending the request to system B, system A includes the assigned tracking ID (ID) T1 in the request, which is sent to system B along with the request. System B can be a specific information verification system used to further verify the information provided by the user and the information collected by the financial institution from a large database based on the user's identity, assigning a corresponding credit rating and sending the credit limit request to system D. Simultaneously, system B sends the request to system D. Since the request is made by the same user, the tracking ID is the same and is sent to system D along with the request.

[0118] System D can be a loan approval system. Based on the user's information and credit rating previously sent by other systems, it determines the user's loan amount and generates a corresponding contract for the user to view and sign. Simultaneously, it sends a loan disbursement request to System P. System D also sends a request to System P. Since this request originates from the same user, the tracking identifier is the same, and the request is sent to System P along with the original request. System P can be an external lending institution, such as a bank. Upon receiving the loan request, it disburses the loan according to the corresponding conditions. This completes the user's loan application process. Furthermore, the systems involved by the user from requesting the loan to receiving the loan are all recorded by tracking identifier T1.

[0119] 506. Listen for requests sent by each system to other systems and record the listening results of each system as a log.

[0120] In this embodiment, requests sent by each system to other systems are monitored, and the monitoring results of each system are recorded as logs. Specifically, when a user sends a loan request to system A, system A sends a request to system B and simultaneously sends the generated tracking identifier T1 to system B. Typically, a monitoring program, such as a plugin, can be installed on each system to monitor the system's output interface and record the monitored requests sent to other systems. This monitoring program can record the tracking ID contained in the request, i.e., T1, the request sender, and the request receiver. It also records the time the request was sent; for example, when system A sends a request to system B202, the monitoring program records that system A sent a data retrieval request to system B at a certain moment.

[0121] 507. Analyze the logs of each system to obtain the dependencies between different systems;

[0122] In this embodiment, logs from each system are analyzed to obtain the dependencies between different systems. Specifically, in this embodiment, the logs recorded by tracking identifier T1 are analyzed first to obtain the dependencies between systems, i.e., system A depends on system B, system B depends on system D, and system D depends on system P. Then, the logs recorded by tracking identifier T2 are analyzed to obtain the dependencies between systems.

[0123] 508. Based on the dependencies between multiple systems, identify the related systems that are dependent on the target system;

[0124] In this embodiment, the associated systems that depend on the target system are determined based on the dependencies between multiple systems. Specifically, a pre-defined dependency table is used to examine the dependencies between various systems within the multi-system program. Based on these dependencies, the associated systems that depend on the target system are determined. For example, consider a user's loan request: User A submits a loan or credit limit increase request to system A201 via a terminal application. System A can be an information verification system. After receiving User A's request, System A assigns a tracking identifier (ID) to the request. Simultaneously, System A processes the user's request accordingly, such as performing a preliminary verification of the information provided by User A to determine if the information is accurate and meets the request conditions. If the verification passes, User A's request is sent to system B. Therefore, there is a dependency between system A and system B.

[0125] 509. Send the changes to the associated system and set the status of the associated system to known;

[0126] In this embodiment, the changed content is sent to the associated systems, and the status of the associated systems is set to "known". The changed content of the target system is sent to the associated systems that depend on the target system, and the status of the associated systems is also set to "known". For example, if a downstream system discovers that the target system of the change is an upstream system, it sets the status of the upstream system to "known" [already aware, and has made corresponding adjustments], and sets the changed services in its own system to the "[changed]" status, describes the changed content in the remarks, and checks whether the status of downstream systems that depend on its changed services is "[unknown]". This process continues until the final end system. If the changed system is an intermediate system, this change will affect the upstream system. Similarly, the services of the corresponding upstream system that will be affected will be listed, and their status will be set to "unknown". After seeing the change in the downstream system, the upstream system needs to set the downstream system to "known" and change the status of its corresponding affected services to "[changed]", and check whether the status of the system calling the changed service is "[unknown]". Subsequent dependent systems follow the same procedure.

[0127] 510. Retrieve all services contained in the associated system and set the status of the services to "changed".

[0128] In this embodiment, all services contained in the associated system are obtained, and the status of these services is set to "changed". The associated system refers to systems that depend on the target system and will make corresponding adjustments due to changes in the target system. The associated system also includes many services, including but not limited to interfaces (containing domain names or IPs and complete routing information), tables (IPs and corresponding database names, table names [not all need to be provided, but only those called by other systems, with user-defined additions, deletions, and modifications, and those queried by others]), NAS (addresses and corresponding file information), and other file information.

[0129] 511. Build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release status based on the test results;

[0130] 512. Obtain the program files and configuration files of the target service, and publish the service based on the program files and configuration files.

[0131] Steps 501-504 and 511-512 in this embodiment are similar to steps 101-106 in the first embodiment, and will not be repeated here.

[0132] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves notification and response between systems by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0133] The service publishing method in the embodiments of the present invention has been described above. The service publishing apparatus in the embodiments of the present invention will be described below. Please refer to [link / reference]. Figure 6 The first embodiment of the service publishing device in this invention includes:

[0134] The receiving module 601 is used to receive a service change request and determine the target service to be changed according to the service change request, wherein the system to which the target service belongs is the target system;

[0135] The first setting module 602 is used to determine the associated services that have a dependency relationship with the target service based on the pre-set dependency relationship between multiple services, and set the status of the target service and the associated services to a changed state;

[0136] The first determining module 603 is used to obtain the association information corresponding to the service change request, and determine the configuration conditions based on the association information;

[0137] The change module 604 is used to generate change content based on the configuration conditions, and to change the target service and the associated service according to the change content;

[0138] The testing module 605 is used to build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release state based on the test results;

[0139] The publishing module 606 is used to obtain the program file and configuration file of the target service, and to publish the service based on the program file and configuration file.

[0140] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves inter-system notification and response by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0141] Please see Figure 7 A second embodiment of the service publishing device in this invention specifically includes:

[0142] The receiving module 601 is used to receive a service change request and determine the target service to be changed according to the service change request, wherein the system to which the target service belongs is the target system;

[0143] The first setting module 602 is used to determine the associated services that have a dependency relationship with the target service based on the pre-set dependency relationship between multiple services, and set the status of the target service and the associated services to a changed state;

[0144] The first determining module 603 is used to obtain the association information corresponding to the service change request, and determine the configuration conditions based on the association information;

[0145] The change module 604 is used to generate change content based on the configuration conditions, and to change the target service and the associated service according to the change content;

[0146] The testing module 605 is used to build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release state based on the test results;

[0147] The publishing module 606 is used to obtain the program file and configuration file of the target service, and to publish the service based on the program file and configuration file.

[0148] In this embodiment, the service publishing device further includes:

[0149] The second determining module 607 is used to determine the service dependency relationship of the target service test scenario based on the parameter transmission information between services during the test of the target service test scenario.

[0150] The recording module 608 is used to record the running statistics of the service test scenario during the test process, wherein the running statistics characterize the running characteristics of the service test scenario during the test process;

[0151] Clustering module 609 is used to cluster the runtime statistics of all the service test scenarios to obtain at least one cluster.

[0152] The merging module 610 is used to merge the service dependencies of each service test scenario within each of the at least one cluster to obtain the service dependency relationship of the cluster; and to merge the service dependency relationships of the at least one cluster to obtain the dependency relationship between the multiple services.

[0153] In this embodiment, the test module 605 includes:

[0154] Construction unit 6051 is used to construct a test case library for synchronous functional and performance testing of the target service;

[0155] Test unit 6052 is used to execute test cases in the test case library in parallel when the target service is released to the public, to test the target service and obtain test results;

[0156] Analysis unit 6053 is used to analyze the test results and generate a functional result analysis report and a performance result analysis report of the target system;

[0157] Setting unit 6054 is used to set the target service and the associated service to a pending release state based on the functional result analysis report and the performance result analysis report.

[0158] In this embodiment, the publishing module 606 is specifically used for:

[0159] Obtain the program files and configuration files of the target service;

[0160] Based on the program file and configuration file, generate the image file of the target service;

[0161] Based on the image file, the service is published.

[0162] In this embodiment, the service publishing device further includes:

[0163] Module 611 is used to obtain the dependencies between multiple systems;

[0164] The third determining module 612 is used to determine the associated systems that are dependent on the target system based on the dependencies between the multiple systems;

[0165] The sending module 613 is used to send the changed content to the associated system and set the status of the associated system to known.

[0166] The second setting module 614 is used to obtain all services contained in the associated system and set the status of the services to a changed state.

[0167] In this embodiment, the acquisition module 611 is specifically used for:

[0168] The system receives user requests from the target system and assigns a tracking ID to each user request.

[0169] Listen for requests sent from each system to other systems and record the listening results of each system as a log.

[0170] Analyze the logs of each system to obtain the dependencies between different systems.

[0171] In this embodiment, the recording module 608 is specifically used for:

[0172] Obtain log information of the aforementioned services during the testing process;

[0173] Log information that is not related to interface operation errors in the log information of the multiple services during the testing process will be regarded as invalid log information of the multiple services during the testing process.

[0174] The runtime statistics of each service in the log information (excluding invalid log information) during the testing process are used as the runtime statistics of the service during the testing process.

[0175] In this embodiment of the invention, by determining the target service to be changed, and based on the pre-defined dependencies between multiple services, the status of the target service and its dependent services is set to a changed state; the associated information corresponding to the service change request is obtained, and configuration conditions are determined; change content is generated based on the configuration conditions, and the target service and related services are changed according to the change content; the changed target service and related services are tested, and based on the test results, the changed target service and related services are set to a pending release state; the program file and configuration file of the target service are obtained, and the service is released according to the program file and the configuration file. This solution achieves notification and response between systems by changing the service status, solving the technical problem that upstream and downstream systems cannot synchronize change releases during system change releases, and improving the efficiency of system service releases.

[0176] above Figure 6 and Figure 7The service publishing device in this embodiment of the invention will be described in detail from the perspective of modular functional entities. The service publishing equipment in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0177] Figure 8 This is a schematic diagram of a service publishing device 800 provided in an embodiment of the present invention. The service publishing device 800 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 810 (e.g., one or more processors) and a memory 820, and one or more storage media 830 (e.g., one or more mass storage devices) for storing application programs 833 or data 832. The memory 820 and storage media 830 can be temporary or persistent storage. The program stored in the storage media 830 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the service publishing device 800. Furthermore, the processor 810 may be configured to communicate with the storage media 830 and execute the series of instruction operations in the storage media 830 on the service publishing device 800 to implement the steps of the service publishing method provided in the above-described method embodiments.

[0178] The service publishing device 800 may also include one or more power supplies 840, one or more wired or wireless network interfaces 850, one or more input / output interfaces 860, and / or one or more operating systems 831, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 8 The service publishing device structure shown does not constitute a limitation on the service publishing device provided in this application. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0179] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of the above-described service publishing method.

[0180] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0181] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0182] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A service publishing method, characterized in that, The service publishing method includes: Receive a service change request, and determine the target service to be changed based on the service change request, wherein the system to which the target service belongs is the target system; Based on the pre-defined dependencies between multiple services, identify the associated services that depend on the target service, and set the status of the target service and the associated services to a changed state. Obtain the associated information corresponding to the service change request, and determine the configuration conditions based on the associated information; Based on the configuration conditions, change content is generated, and the target service and the associated service are changed according to the change content; Obtain dependencies between multiple systems; Based on the dependencies between the multiple systems, identify the associated systems that are dependent on the target system; The changes are sent to the associated system, and the status of the associated system is set to known. Upon receiving the changes, the associated system sets the status of services affected by the changes to a changed state and checks whether the status of downstream systems dependent on the affected services is unknown. When a downstream system exists with an unknown status, the changes are sent to that downstream system, and the status of that downstream system is set to known, so that the changes propagate hierarchically along system dependencies until the final system is reached. Obtain all services contained in the associated system and set the status of the services to a changed state; A test case library is built to test the changed target service and related services, and the changed target service and related services are set to a pending release state based on the test results; Obtain the modified program file and configuration file of the target service, and publish the service based on the program file and configuration file.

2. The service publishing method according to claim 1, characterized in that, Before determining the associated services that depend on the target service based on the pre-defined dependencies between multiple services, and setting the states of the target service and the associated services to a changed state, the method further includes: Based on the parameter transmission information between services during the testing process of the target service test scenario, the service dependencies of the target service test scenario are determined. Record the operational statistics of the service test scenario during the test process, wherein the operational statistics characterize the operational characteristics of the service test scenario during the test process; Cluster the runtime statistics of all the service test scenarios to obtain at least one cluster; For each of the at least one clusters, the service dependencies of each service test scenario within the cluster are merged to obtain the service dependencies of the cluster. The service dependencies of the at least one cluster are merged to obtain the dependencies between the multiple services.

3. The service publishing method according to claim 1, characterized in that, The process of building a test case library to test the modified target service and related services, and setting the modified target service and related services to a pending release state based on the test results, includes: Construct a test case library to perform synchronous functional and performance testing on the modified target service and related services; When the modified target service and related services are released to the public, the test cases in the test case library are executed in parallel to test the modified target service and related services and obtain the test results. The test results are analyzed to generate a functional results analysis report and a performance results analysis report for the target system. Based on the functional results analysis report and the performance results analysis report, the modified target service and related services are set to a pending release status.

4. The service publishing method according to claim 1, characterized in that, The step of obtaining the modified target service's program file and configuration file, and publishing the service based on the program file and configuration file, includes: Obtain the modified program files and configuration files of the target service; Based on the program file and configuration file, generate the image file of the target service; Based on the image file, the service is published.

5. The service publishing method according to claim 1, characterized in that, The acquisition of dependencies between multiple systems includes: The system receives user requests from the target system and assigns a tracking ID to each user request. Listen for requests sent from each system to other systems and record the listening results of each system as a log. Analyze the logs of each system to obtain the dependencies between different systems.

6. The service publishing method according to claim 2, characterized in that, The recorded statistical information of the service test scenario during the test process includes: Obtain log information of the aforementioned services during the testing process; Log information that is not related to interface operation errors in the log information of the multiple services during the testing process will be regarded as invalid log information of the multiple services during the testing process. The runtime statistics of each service in the log information (excluding invalid log information) during the testing process are used as the runtime statistics of the service during the testing process.

7. A service publishing device, characterized in that, The service publishing device includes: A receiving module is used to receive service change requests and determine the target service to be changed based on the service change requests, wherein the system to which the target service belongs is the target system; The first setting module is used to determine the associated services that are dependent on the target service based on the pre-defined dependencies between multiple services, and set the status of the target service and the associated services to a changed state. The first determining module is used to obtain the association information corresponding to the service change request, and determine the configuration conditions based on the association information; The change module is used to generate change content based on the configuration conditions, and to change the target service and the associated service according to the change content; The acquisition module is used to obtain the dependencies between multiple systems; The third determining module is used to determine the associated systems that are dependent on the target system based on the dependencies between the multiple systems; A sending module is used to send the changed content to the associated system and set the status of the associated system to known; wherein, after receiving the changed content, the associated system sets the status of the service affected by the changed content to a changed state, and detects whether the status of the downstream system that depends on the affected service is unknown; when there is a downstream system with an unknown status, the changed content is sent to the downstream system and the status of the downstream system is set to known, so that the changed content propagates step by step along the system dependency relationship until the end system; The second setting module is used to obtain all services contained in the associated system and set the status of the services to a changed state. The testing module is used to build a test case library to test the changed target service and related services, and set the changed target service and related services to a pending release state based on the test results; The publishing module is used to obtain the program file and configuration file of the modified target service, and to publish the service based on the program file and configuration file.

8. A service publishing device, characterized in that, The service publishing device includes: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the service publishing device to perform the steps of the service publishing method as described in any one of claims 1-6.

9. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the service publishing method as described in any one of claims 1-6.

Images