Digital-analog fusion service orchestration gateway running method and system based on development platform

Abstract

The application relates to the technical field of development platforms and service arrangement, and discloses a digital-analog fusion service arrangement gateway operation method and system based on a development platform, wherein the method comprises the following steps: establishing a topology skeleton according to development platform configuration, generating node execution units corresponding to each logical node and establishing a binding relationship; generating execution binding information according to the topology skeleton and the current binding relationship and executing service arrangement; when service configuration changes, generating a new node execution unit of a target logical node, judging whether the topology skeleton needs to be updated according to data interface requirements of the new and old node execution units; when the topology skeleton does not need to be updated, locally adjusting the binding relationship of the target logical node, so that an arrangement instance that has been started before updating continues to operate according to the original execution binding information, and an arrangement instance that is started after updating adopts the updated binding relationship. Therefore, the application can reduce the influence range of service updating and maintain the execution stability of in-transit service arrangement.

Description

Technical Field

[0001] This invention relates to the field of development platform and service orchestration technology, and in particular to a method and system for operating a digital-analog fusion service orchestration gateway based on a development platform. Background Technology

[0002] As enterprise development platforms increasingly centralize services such as data querying, knowledge retrieval, data analysis, and model reasoning, service orchestration methods that involve multiple services working together sequentially, in parallel, or conditionally to complete a single business task are becoming widely adopted. Development platforms typically set up a service center to register various application services, with a unified gateway handling authentication, service invocation, and operational management.

[0003] In related technologies, orchestration relationships and the specific service call implementations of each node are usually stored together in an orchestration file or an orchestration execution object. When the version, access address, or parameter handling method of a certain service changes, the entire orchestration object can easily be regenerated or reloaded. Furthermore, if a service update occurs during the runtime of an orchestration instance, the executing instance may use different execution implementations on the preceding and following nodes; waiting for all old instances to finish before deployment will delay the deployment of the new service. Therefore, it is necessary to improve the locality of service orchestration updates and the stability of orchestration execution in transit within a dynamic development platform environment. Summary of the Invention

[0004] To address the related technical issues, this application provides a method and system for operating a digital-analog fusion service orchestration gateway based on a development platform.

[0005] This application provides a method for operating a digital-analog fusion service orchestration gateway based on a development platform, including: Obtain the development platform configuration, establish a topology skeleton based on the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton, and establish a binding relationship; Upon receiving a service orchestration request, the system generates execution binding information based on the topology skeleton and the current binding relationship, and invokes the execution units of each node according to the execution binding information to complete the service orchestration. When a change in the service configuration of the target service is detected, a new node execution unit corresponding to the target logical node is generated, and the topology skeleton is determined to be updated based on the data interface requirements of the new and old node execution units. If so, the target logical node is bound to the new node execution unit; wherein, orchestration instances that were started before the update continue to execute according to the original execution binding information, and orchestration instances started after the update execute according to the updated binding relationship.

[0006] This application also provides a data-analog fusion service orchestration gateway operating system based on a development platform, including: The configuration processing module is used to obtain the development platform configuration, establish a topology skeleton according to the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton, and establish a binding relationship. The orchestration execution module is used to receive service orchestration requests, generate execution binding information based on the topology skeleton and the current binding relationship, and call the execution units of each node according to the execution binding information to complete service orchestration. The change processing module is used to generate a new node execution unit corresponding to the target logical node when a change in the service configuration of the target service is detected, and to determine whether the topology skeleton needs to be updated based on the data interface requirements of the new and old node execution units. The binding update module is used to bind the target logical node to the new node execution unit when the topology skeleton needs to be updated; wherein, the orchestration instance that was started before the update continues to execute according to the original execution binding information, and the orchestration instance that was started after the update executes according to the updated binding relationship.

[0007] In this embodiment, the orchestration relationship and data transmission location between logical nodes are stored through a topology skeleton, and the node execution unit stores the specific service calls and data processing methods. When the internal implementation of a data service or model service changes, but its data interface requirements for orchestration relationships remain unchanged, only a new node execution unit for the corresponding logical node can be generated, and the binding relationship of the logical node can be updated, so that the unchanged logical nodes and topology relationships can continue to be used.

[0008] Simultaneously, each orchestration instance, upon creation, forms execution binding information based on the then-current binding relationships, and continues to determine the node execution unit according to this execution binding information until the orchestration instance ends. Thus, updates to common binding relationships affect subsequently created orchestration instances, while already started orchestration instances can continue to use the node execution unit selected during their creation, reducing the impact of ongoing service updates on the orchestration process.

[0009] Furthermore, by comparing the data interface requirements of the old and new node execution units, it is possible to distinguish between changes in the internal implementation of the service and changes in orchestration data relationships. Local binding updates are performed when input and output data requirements remain unchanged; when data interface requirements change, the topology skeleton is adjusted, thus adapting the scope of service updates to the actual changes in technical content. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating the operation method of the digital-analog fusion service orchestration gateway based on the development platform in an embodiment of this application.

[0011] Figure 2 This is a schematic diagram of the development platform and service orchestration gateway operation architecture for embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the topology skeleton, node execution units, and binding relationships in an embodiment of this application.

[0013] Figure 4 This is a schematic diagram illustrating the process of generating and using binding information in an embodiment of this application.

[0014] Figure 5 This is a schematic diagram of the service configuration change processing flow for an embodiment of this application.

[0015] Figure 6 This is a schematic diagram illustrating the execution of a version update and in-transit orchestration instance in this application embodiment.

[0016] Figure 7 This is a schematic diagram of the node execution unit update timing in a specific example of an embodiment of this application.

[0017] Figure 8 This is a schematic diagram illustrating the results of continuously orchestrating tasks in a specific example of an embodiment of this application.

[0018] Figure 9 This is a schematic diagram of the structure of the digital-analog fusion service orchestration gateway operating system based on the development platform, as described in this application embodiment. Detailed Implementation

[0019] In various embodiments of this application, relatively stable logical execution relationships and specific service call implementations in a service orchestration are managed separately. The development platform first establishes a topology skeleton and generates node execution units for each logical node in the topology skeleton, associating the logical nodes with the currently used node execution units through binding relationships. Upon arrival of a service orchestration request, the gateway forms execution binding information for the corresponding orchestration instance based on the then-current valid binding relationships. When the service configuration changes, new node execution units are generated only for the affected target logical nodes, and the data interface requirements of the new and old node execution units are used to determine whether the original topology skeleton can be maintained. If it can be maintained, the binding relationships of the target logical nodes are updated, allowing the new and old orchestration instances to run according to their respective execution relationships.

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments.

[0021] The method for operating a data-analog fusion service orchestration gateway based on a development platform provided in this application can be applied to the service orchestration gateway in an enterprise unified development platform, or to independent gateway devices or gateway clusters connected to the service registry center of the development platform. The development platform can set up an MCP service center or a service center with the same service registration capabilities to register the platform's data query, knowledge retrieval, data analysis, and model inference capabilities as standard services or tools, and record the corresponding service configurations.

[0022] like Figure 1 As shown, the method provided in this application embodiment includes steps S100 to S400.

[0023] Step S100: Obtain the development platform configuration, establish a topology skeleton according to the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton and establish a binding relationship.

[0024] Here, the development platform configuration describes the invocation conditions of registered services in the development platform and the organization of different services in orchestration tasks. The development platform configuration can be generated by the development platform control plane and distributed to the service orchestration gateway, or it can be actively read by the service orchestration gateway from the service registry and orchestration configuration storage area. When the development platform configuration is updated, the updated services and their corresponding configuration content can be recorded, enabling the gateway to identify the specific affected logical nodes.

[0025] In this embodiment of the application, step S100 specifically includes: obtaining the development platform configuration, reading service registration information and orchestration configuration from the development platform configuration; wherein, the orchestration configuration includes node relationship data and node configuration data; establishing a topology skeleton based on the node relationship data; wherein, the topology skeleton is configured to store the node relationships and data positions between logical nodes; generating node execution units corresponding to each logical node based on the service registration information and the node configuration data, and establishing a binding relationship between each logical node and the corresponding node execution unit.

[0026] Specifically, service registration information describes the service capabilities within the development platform that can be invoked by the gateway. After a service completes registration, a service identifier and a corresponding tool identifier are assigned, and the currently available version, access method, and input / output description of the service are saved. In the implementation using the MCP service center, each application service can register as an invokeable tool according to the MCP specification; when using other standard tool interfaces or internal enterprise service specifications, as long as the gateway can determine the invocation method of the target service based on the registration content, the processing method of this embodiment can also be used.

[0027] like Figure 2As shown, in one executable implementation, the development platform includes a service center, orchestration configuration management, a unified service orchestration gateway, and runtime control functions. External callers send service orchestration requests to the unified service orchestration gateway. After performing a call permission check, the unified service orchestration gateway schedules the corresponding service based on the orchestration configuration and the service registration information provided by the service center. The runtime control functions can be further used to view node call status and issue management information such as service start / stop or traffic control to the gateway. This embodiment mainly addresses how the orchestration runtime objects within the gateway are organized and how they are switched when service configurations are updated.

[0028] Node relationship data is used to describe the execution organization relationships between logical nodes in a service orchestration. For example, node relationship data can specify that two data service nodes run in parallel, and that a model service node must wait for the aforementioned data service nodes to complete before it runs. Node relationship data can also describe conditional branches and subsequent nodes after multiple branches converge. In practical applications, node relationship data can be implemented using directed relational data, process configuration data, or other data structures that can characterize the execution sequence of nodes.

[0029] Node configuration data describes the specific execution implementation currently used by a logical node. Node configuration data may include the service identifier, service version, input data conversion method, output data writing method, and service call adaptation content corresponding to the logical node. The above content can collectively serve as the data required to generate the node execution unit. Different development platforms may use different field names and storage structures, which this application does not limit.

[0030] When building the topology skeleton based on node relationship data, the gateway generates multiple logical nodes and stores the node relationships between these logical nodes, as well as the data locations used for data transfer between nodes. The topology skeleton represents the logical nodes existing in the current service orchestration, the operational relationships between logical nodes, and the direction of node data transfer. The topology skeleton can form independent data objects and can be managed through topology versioning.

[0031] In simple terms, a logical node represents the location where a certain service capability is used at the orchestration level, and it can persist across multiple service versions. For example, logical node N3 represents "risk model analysis". When the model is upgraded from V1 to V2, logical node N3 and its preceding and following relationships in the orchestration can be retained. Whether V1 or V2 is used is determined by the node execution unit bound to N3.

[0032] In this embodiment of the application, the digital modeling service corresponding to the service registration information includes a data service and a model service; the topology skeleton stores the node relationships and data locations between logical nodes, and the node execution unit stores service call information and data mapping information; the service call information is used to call the digital modeling service, and the data mapping information is used to convert between the data location and the call data of the digital modeling service.

[0033] Here, data services refer to services that generate or process business data, such as data querying, knowledge retrieval, data analysis, or data processing services; model services refer to services that can perform model calculations based on input data and generate model outputs, such as machine learning inference services or large language model services. In practical applications, an orchestration can also include business operation services, such as services that write analysis results into business systems. Data-model fusion is mainly manifested in the fact that the data generated by the data services is provided to the model services through data locations in the topological skeleton, and the output of the model services can continue to serve as input for subsequent data services or business services.

[0034] Data locations are used to define the data transmission relationships between logical nodes in the topology skeleton. For example, the output of data service node N1 can be written to data location D1, the output of knowledge retrieval node N2 can be written to data location D2, and the input of model node N3 is configured to read from D1 and D2. In this way, N3 only cares about whether there is data that meets the requirements in D1 and D2 at the topology level, without having to directly store the network address currently being called by N1 or N2.

[0035] The node execution unit primarily undertakes the specific execution tasks. For example... Figure 3 As shown, execution units U11, U21, and U31 can be generated for logical nodes N1, N2, and N3 respectively, and binding relationships between N1 and U11, N2 and U21, and N3 and U31 can be established. The topology skeleton T1 continues to record the node relationships between N1, N2, and N3, while execution content such as service version, service address, and parameter mapping is stored in the corresponding node execution units.

[0036] Service call information is used to enable node execution units to determine which registered services need to be invoked and how to complete the call. For example, service call information can record the tool identifier and service version, and reference the location of the instance that can currently access the target service. For services that use HTTP, RPC, or MCP tool invocation methods, the call data generated by the node execution unit can be converted into a request that the target service can accept through the corresponding adapter.

[0037] Data mapping information is used to handle differences between data locations in the topology skeleton and specific service parameters. For example, D1 in the topology skeleton represents unified customer business data. Model-V1 might require this data to be placed in a parameter named customerData, while Model-V2 might adjust the corresponding parameter name to businessData. As long as the new node execution unit can use the data mapping information to retrieve data from the same data location D1 and form businessData according to the new service requirements, this internal parameter change itself does not need to cause a change in the topology skeleton.

[0038] In one executable implementation, each node execution unit has a unique execution unit identifier. After a node execution unit is generated, the service version used, call adaptation information, and data mapping information can be associated and stored together with the execution unit identifier. A logical node can retain multiple historical node execution units so that orchestration instances that have already been started can still find the execution implementation used when they were created.

[0039] The binding relationship is a set of associated data stored independently of the topology skeleton and node execution units. For example, the current binding relationship B1 can record N1 corresponding to U11, N2 corresponding to U21, and N3 corresponding to U31. When updating the node execution unit of N3 to U32, only the binding item corresponding to N3 needs to be modified, and the topology skeleton T1 and the existing execution units of N1 and N2 do not need to be regenerated.

[0040] It should be noted that in this application, the topology skeleton is used to describe a stable logical orchestration structure, and the node execution unit is used to describe the specific service execution implementation currently adopted by a logical node. Both can be stored in the same database, or they can be stored separately in the orchestration configuration storage area and the execution unit storage area. As long as the binding relationship between the logical node and the node execution unit can be modified individually without synchronously modifying the entire topology skeleton, the processing described in this application can be achieved.

[0041] Step S200: Receive a service orchestration request, generate execution binding information based on the topology skeleton and the current binding relationship, and call the execution units of each node according to the execution binding information to complete the service orchestration.

[0042] Here, service orchestration requests can be sent by external business systems, intelligent applications, or other applications within the development platform. These requests can carry an identifier for the orchestration to be invoked, as well as the input data required for this business process. The gateway can complete authentication and access permission checks before orchestration execution; only after successful authentication will the corresponding orchestration instance be created.

[0043] In this embodiment of the application, step S200 specifically includes: receiving the service orchestration request, reading the currently valid topology skeleton and the current binding relationship; according to the logical nodes in the topology skeleton, obtaining the node execution unit corresponding to each logical node from the current binding relationship, and writing the obtained correspondence into the execution binding information; determining the logical node to be executed according to the topology skeleton, obtaining the corresponding node execution unit from the execution binding information, calling the corresponding service through the obtained node execution unit, and continuing to schedule the logical nodes in the topology skeleton according to the call result until the service orchestration is completed.

[0044] Specifically, when creating an orchestration instance, the gateway reads the currently valid topology skeleton. For example, if the current valid topology version is T1, it also reads the binding relationship B1 currently used by T1. The gateway queries B1 one by one according to the logical nodes that appear in T1 to obtain the node execution units actually used in this orchestration instance, and writes these correspondences into the execution binding information of this orchestration instance.

[0045] like Figure 4 As shown, the execution binding information of the common binding relationship B1 and the orchestration instance P1 belong to different runtime data. After P1 is created, it can record the execution correspondences of its topology skeleton T1, N1 to U11, N2 to U21, and N3 to U31. Subsequently, even if the common binding relationship changes to B2, P1 still obtains the corresponding node execution unit from its own execution binding information.

[0046] In this embodiment of the application, the execution binding information is generated when the orchestration instance is created and remains unchanged until the orchestration instance ends. It should be noted that changes to the current binding relationship that occur after the execution binding information is generated will not change the correspondence between logical nodes and node execution units in the execution binding information.

[0047] Here, "remaining unchanged" means that the correspondence between the logical nodes that influence the selection of node execution units and the node execution units remains determined during the current orchestration instance's execution. The node execution state of the orchestration instance itself, the data stored in the data location, and the abnormal state can change during the running process, without affecting the maintenance of the execution binding relationship in this embodiment.

[0048] With the above approach, the execution engine does not need to retrieve the latest node execution unit from the public binding relationship each time a logical node is scheduled. The execution engine first determines the logical node that meets the execution conditions based on the topology skeleton, and then reads the node execution unit corresponding to that logical node from the execution binding information of this orchestration instance.

[0049] For example, N1 and N2 execute in parallel, and N3 depends on both N1 and N2. After the gateway creates P1, it can schedule N1 and N2 simultaneously. After N1's U11 completes the data query, it writes the result to D1 according to the data mapping information. After N2's U21 completes the knowledge retrieval, it writes the result to D2. When both D1 and D2 satisfy the input conditions of N3, the execution engine obtains the corresponding U31 for N3 from the execution binding information of P1. U31 reads the input data from D1 and D2, performs parameter transformation on the data, and calls the model service.

[0050] After the model service returns the results, U31 converts the model output into the data format required by the topology skeleton based on its own data mapping information and writes it to the corresponding output data location of N3. The execution engine continues to check the execution conditions of subsequent logical nodes according to the topology skeleton until there are no logical nodes yet to be executed that meet the conditions, thus completing this service orchestration.

[0051] For conditional branching scenarios, the topology skeleton can record the branch conditions and the subsequent logical nodes corresponding to different branches. After the current node completes execution, the execution engine determines the satisfied branch conditions based on its output data and then schedules the logical nodes in the corresponding branches. Branches that are not actually entered do not need to call the corresponding node execution unit.

[0052] For parallel nodes, the gateway can create node execution tasks for multiple logical nodes that meet the execution conditions. Different node execution tasks still obtain execution units from the execution binding information of the same orchestration instance. Therefore, updates to the common binding relationship during parallel execution will not change the node execution unit originally selected by any logical node in the already created instance.

[0053] In one executable implementation, execution binding information can also record the topology version and binding version to support subsequent runtime traceability. For example, P1 records T1 and B1, and P2 records T1 and B2. When it is necessary to query historical business results, the actual topology version and binding version used can be determined through orchestration instances, and then the corresponding node execution unit and service version can be obtained.

[0054] In practical applications, when a node execution unit calls the target service and a timeout occurs or the service becomes temporarily unavailable, it can retry, terminate the current branch, or return to an abnormal status according to the corresponding service's preset exception handling method. The above exception handling does not change the execution unit correspondence in the execution binding information; when it is necessary to switch service versions, it can be handled according to subsequent steps S300 and S400.

[0055] Step S300: When a change in the service configuration of the target service is detected, a new node execution unit corresponding to the target logical node is generated, and the topology skeleton is determined to be updated based on the data interface requirements of the new and old node execution units.

[0056] Here, service configuration changes can include changes to the target service version, the actual access location, the method of handling call parameters, or the service input / output structure. After the service center completes the modification of the service registration information, it can send service change information to the gateway; the gateway can also identify the affected target services and target logical nodes based on the changes in the development platform configuration version.

[0057] In this embodiment, step S300 specifically includes: when a change in the service configuration of a target service is detected, reading the changed service configuration of the target service, generating a new node execution unit based on the changed service configuration; obtaining the data interface requirements corresponding to the new node execution unit and the original node execution unit respectively, and comparing the input data requirements and output data requirements represented by the data interface requirements; when the input data requirements and output data requirements of the new node execution unit and the original node execution unit are the same, determining that the topology skeleton does not need to be updated; otherwise, updating the topology skeleton according to the data interface requirements of the new node execution unit.

[0058] like Figure 5 As shown, after detecting a service configuration change, the gateway first locates the target logical node based on the relationship between the service and the logical node, and then generates a new node execution unit only for the target logical node. The original node execution unit is retained at this stage, and its current binding relationship is also temporarily maintained, so that production orchestration requests can still be created and executed normally according to the execution relationship before the update.

[0059] Specifically, the method for generating new node execution units can be the same as that for generating node execution units in step S100. The gateway reads the new call information of the target service from the changed service configuration and generates a new node execution object in combination with the data mapping configuration of the logical node. For example, Model-V1 originally corresponded to U31, and after updating to Model-V2, a new U32 is generated. At this time, U31 and U32 have different execution unit identifiers.

[0060] After generating U32, the gateway needs to determine whether U32 can continue to serve as the execution implementation of the original logical node N3 in the topology skeleton T1. To this end, the old and new node execution units each have corresponding data interface requirements. These data interface requirements describe the data that the node execution unit must read when facing the topology skeleton, as well as the data it can generate for the topology skeleton.

[0061] In this embodiment, the input data requirements are characterized by the input position and corresponding data type read by the node execution unit, and the output data requirements are characterized by the output position and corresponding data type written by the node execution unit; when any input position, output position, or corresponding data type changes, the corresponding data interface requirements are determined to be different.

[0062] For example, U31 reads data from D1 and D2, where D1 is a customer business data object and D2 is a knowledge retrieval result object. After processing, U31 writes a risk analysis result object to D3. If U32 also reads the same type of data from D1 and D2 and writes the same type of data to D3, then its input and output data requirements are the same as those of U31.

[0063] In the above scenario, even if the service address of Model-V2 has changed, its internal parameter name has been changed from customerData to businessData, or the model instance itself has been replaced, as long as U32 can digest these changes through its own service call information and data mapping information, and the data relationship shown by N3 to the topology skeleton has not changed, the gateway can determine that T1 does not need to be updated.

[0064] For example, besides D1 and D2, Model-V2 must also read the historical transaction sequence D4 to complete inference, thus adding a new input location to U32's input data requirements. The execution conditions for N3 in the original T1 did not specify D4, nor was a preceding node capable of generating D4 configured; therefore, U32 cannot directly replace U31. In this case, the gateway establishes a new topology version based on U32's data interface requirements and adds the data relationships used to generate D4.

[0065] Similarly, if the new model changes the original risk analysis result object into two output objects with independent business meanings, and subsequent nodes need to use these two output objects respectively, then the output data requirements of the new node execution unit have changed. The gateway can update the data location of the topology skeleton and the corresponding successor node relationships, and then establish node binding relationships for the new topology skeleton.

[0066] By comparing input and output positions and their corresponding data types, the decision to update the topology skeleton can be based on the actual data boundaries of the orchestration nodes. Changes to the internal implementation of services are handled by the node execution units, while changes affecting upstream and downstream data relationships are handled by the topology skeleton, thus allowing these two types of changes to be processed separately.

[0067] In practical applications, input or output locations can be represented by a unified data location identifier. Data types can be determined by the data structure description defined by the development platform. For example, for structured objects, the corresponding field structure description can be stored; for text content, the text type and encoding requirements can be recorded; for model output objects, the corresponding standard output structure identifier in the development platform can be recorded.

[0068] Furthermore, after the new node execution unit is generated and passes the data interface requirements comparison, availability verification can be performed before the formal switchover. For example, for services that declare support for test calls, the new node execution unit can be called using preset test inputs, and it can be confirmed that it can return data that meets the output data requirements within the preset response time; for services that are not suitable for generating real business operations, only the call connection and parameter conversion results can be verified.

[0069] For example, three consecutive test calls can be executed on U32, each time generating the risk analysis result object required by D3 within the preset response time. If the required output structure cannot be generated in one of the calls, the binding relationship of the target logical node will not be switched, and U31 will continue to accept new orchestration instances. The above three calls are only one implementation parameter; in other implementation methods, the preset number of verifications can be set according to service stability requirements.

[0070] Step S400: If yes, then bind the target logical node to the new node execution unit; wherein, orchestration instances that were started before the update continue to execute according to the original execution binding information, and orchestration instances started after the update execute according to the updated binding relationship.

[0071] Here, after step S300 determines that the new node execution unit still meets the requirements of the original topology skeleton, only the association between the target logical node and the node execution unit needs to be modified. The node execution units of other logical nodes and the original topology skeleton continue to be used, thereby controlling the scope of this update to the target logical node that has undergone actual changes.

[0072] In this embodiment, step S400 specifically includes: generating a new binding version based on the current binding relationship; replacing the binding item of the target logical node in the new binding version with the new node execution unit, while retaining the binding items of other logical nodes; after the new binding version is generated, switching the currently valid binding version to the new binding version; for service orchestration requests received after the new binding version takes effect, generating execution binding information based on the new binding version; for orchestration instances that have already generated execution binding information before the new binding version takes effect, continuing to run according to the execution binding information until the orchestration instance ends.

[0073] Specifically, assuming T1 currently corresponds to binding version B1, B1 includes N1 to U11, N2 to U21, N3 to U31, and N4 to U41. After the new node execution unit U32 of N3 is processed by step S300, it can copy the existing binding items in B1 and only adjust the binding items of N3 from U31 to U32, thereby forming a new binding version B2.

[0074] like Figure 6 As shown, during the formation of B2, the currently valid binding version remains B1, so newly arriving orchestration requests during this period can still read B1 completely. Once all bindings in B2 have been generated, the currently valid binding version is switched from B1 to B2 all at once. For any orchestration instance, the binding version read during its creation can only be either the complete B1 or the complete B2, avoiding reading intermediate binding states that are still being modified.

[0075] After B2 takes effect, newly received orchestration requests create an orchestration instance P2. P2 generates execution binding information based on B2, where N3 corresponds to U32. For P1, which was created before B2 took effect, N3 in its execution binding information still corresponds to U31. Even if P1 has not yet executed to N3 when B2 takes effect, it will continue to call U31 when it subsequently enters N3.

[0076] Therefore, the node execution implementation of the same orchestration instance will not be replaced due to changes in the common binding version during runtime. At the same time, the new node execution unit U32 can immediately take over the newly created orchestration instance after B2 takes effect, without waiting for all old orchestration instances to finish before it can be put into use.

[0077] The above approach is particularly suitable for long-duration model inference or data analysis tasks. For example, if P1 has completed N1 and N2 and is preparing to execute N3, and at this point the model service completes a version update, P1 still uses U31 to complete its originally determined Model-V1 call, and subsequently P2 uses U32 to execute Model-V2, thus ensuring that the nodes before and after P1 maintain the same set of execution implementations as when they were created.

[0078] In this embodiment, for orchestration instances that have generated execution binding information before the new binding version takes effect, the execution binding information continues to run until the orchestration instance ends. This includes: when generating the execution binding information, recording the usage relationship between the node execution unit in the execution binding information and the corresponding orchestration instance; when the orchestration instance ends, releasing the usage relationship corresponding to the orchestration instance; and stopping the original node execution unit when the original node execution unit does not belong to the current valid binding version and there is no unfinished orchestration instance that has a usage relationship with the original node execution unit.

[0079] Here, the usage relationship is used to determine whether an old node execution unit that has exited the current binding version is still being used by a running orchestration instance. When P1 is created and execution binding information is generated, the system can add usage records for P1 to U11, U21, U31, and U41 respectively. After P1 ends, the usage record corresponding to P1 is removed.

[0080] Once B2 takes effect, U31 is no longer a currently valid bound version. However, if P1 or other orchestration instances created earlier than B2 still have a usage record for U31, then U31 remains executable. This way, even if U31 has stopped accepting new orchestration instances, it will not affect the continued operation of orchestration instances in transit.

[0081] Once the last in-transit orchestration instance referencing U31 has finished, the system can stop U31 if the currently active binding version B2 and all other active binding versions no longer use U31. The stopping process may include releasing execution objects, adaptation configurations, and cached resources used only by U31.

[0082] It should be noted that if multiple node execution units share the same underlying communication connection or public service instance, when an older node execution unit is stopped, only its dedicated resources can be released, while shared resources are retained as long as they are still used by other node execution units. The specific resource management granularity can be determined based on the software architecture of the service orchestration gateway.

[0083] In cases where an orchestration instance terminates abnormally, its corresponding usage relationship can also be terminated. For example, if an orchestration instance is terminated by the system after exceeding the preset maximum runtime, the corresponding usage relationship can be terminated after the termination status is recorded to prevent instances that have lost their actual business processing significance from occupying old node execution units for an extended period of time.

[0084] In one feasible implementation, after an orchestration instance ends, the gateway can also record the topology version, binding version, and the actual execution unit corresponding to each logical node used in this execution. This allows the gateway to restore the specific execution version used at the time of the previous orchestration instance, should the service platform undergo continuous service updates.

[0085] For model services, the model version information corresponding to the node execution unit can be further saved in the runtime log; for data services, the corresponding data tool version can be saved. This information is used for subsequent problem localization and runtime auditing, and does not require changes to the topology skeleton or the execution binding information's execution method.

[0086] The steps S100 to S400 will be further explained below with reference to a complete application example.

[0087] A group's unified development platform sets up a data service center and a model service center, and provides risk analysis services through a service orchestration gateway. The topology skeleton T1 has four logical nodes: N1 acquires customer business data, N2 acquires institutional knowledge data, N3 executes risk model analysis, and N4 writes the model analysis results into the business system. N1 and N2 can execute in parallel; N3 executes after N1 and N2 have completed, and N4 executes after N3 has completed.

[0088] In the initial binding version B1, N1 corresponds to U11, N2 to U21, N3 to U31, and N4 to U41. U31 calls Model-V1, reads data location D1 formed by N1 and data location D2 formed by N2, and writes the risk analysis results to D3. External business systems send risk analysis requests at preset intervals, with each request creating an independent orchestration instance.

[0089] In a recent model upgrade, Model-V1 was updated to Model-V2. While the deployment location and internal parameter names of Model-V2 changed, it still used customer business data and policy knowledge data as input and generated risk analysis results with the same structure as the original model. The service center sent the updated service configuration to the gateway, which then generated a new node execution unit U32 for N3.

[0090] After comparing the data interface requirements of U31 and U32, the gateway determined that both read the same type of data from D1 and D2 and write the same type of risk analysis results to D3. Therefore, it was determined that the topology skeleton T1 does not need to be updated. Figure 7 As shown, after U32 completes generation and verification, it forms B2. B2 only switches N3 from U31 to U32, while the binding items of the other nodes remain unchanged.

[0091] Assume orchestration instance P100 is created at 10:20:00:000 and generates execution binding information based on B1; B2 takes effect at 10:20:00:350. P100 has completed N1 and N2, but has not yet entered N3. Therefore, when P100 subsequently executes N3, it will still read U31 from its own execution binding information. P101, created at 10:20:01:000, reads B2, and its N3 corresponds to U32.

[0092] like Figure 8 As shown, the execution relationship of instances before and after the update can be observed in the development and testing environment by continuously orchestrating tasks. In the example, P98, P99, and P100 are executed according to B1, while P101 and subsequent newly created instances are executed according to B2. Each instance only uses the N3 node execution unit determined when it is created. Figure 8 The data shown is used to illustrate the corresponding changes between orchestration instances and execution units, and does not represent the measured performance indicators of a specific commercial system.

[0093] In one exemplary test configuration, a test topology containing 50 logical nodes can be established, where only one model node undergoes a compatibility version update. According to the processing method of this embodiment, the update process generates a new node execution unit and forms a new binding version, while the node execution units corresponding to the remaining 49 logical nodes continue to be used. If an implementation method of regenerating the entire orchestration execution object is adopted, the update object scope covers all 50 logical nodes; when using the processing method of this embodiment, the execution object generation scope is concentrated on the single logical node that has changed, while preserving the complete topology skeleton.

[0094] If Model-V3 subsequently adds a new input D4 that must be provided by the historical transaction query service, the gateway will determine that the input data requirements of U33 and U32 are different when comparing the data interface requirements. In this case, a new topology skeleton T2 is created, adding a logical node capable of generating D4 before N3, and the binding relationships corresponding to T2 are re-established. Orchestration instances that have already started according to T1 continue to run according to their original execution binding information.

[0095] As can be seen from the complete example above, for changes such as service addresses, model versions, or internal parameter processing that can be handled by the node execution units themselves, the gateway can maintain the topology skeleton and partially replace the execution units; for changes that truly alter the upstream and downstream data relationships, the topology skeleton is then updated. The handling method for different changes is determined by the actual scope of their data impact.

[0096] To implement the above method, embodiments of this application also provide a data-analog fusion service orchestration gateway operating system based on a development platform, such as... Figure 9 As shown, the system includes: The configuration processing module 10 is used to obtain the development platform configuration, establish a topology skeleton according to the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton and establish a binding relationship. The orchestration execution module 20 is used to receive service orchestration requests, generate execution binding information based on the topology skeleton and the current binding relationship, and call the execution units of each node according to the execution binding information to complete service orchestration. The change processing module 30 is used to generate a new node execution unit corresponding to the target logical node when a change in the service configuration of the target service is detected, and to determine whether the topology skeleton needs to be updated based on the data interface requirements of the new and old node execution units. The binding update module 40 is used to bind the target logical node to the new node execution unit when the topology skeleton needs to be updated; wherein, the orchestration instance that was started before the update continues to execute according to the original execution binding information, and the orchestration instance that was started after the update executes according to the updated binding relationship.

[0097] It should be noted that the technical solutions described in the various embodiments of this application can be used in combination without conflicting with each other. The above embodiments are used to illustrate the technical principles and executable implementation of this application, and are not intended to limit the scope of protection of this application.

Claims

1. A method for operating a digital-analog fusion service orchestration gateway based on a development platform, characterized in that, The method includes the following steps: Obtain the development platform configuration, establish a topology skeleton based on the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton, and establish a binding relationship; Upon receiving a service orchestration request, the system generates execution binding information based on the topology skeleton and the current binding relationship, and invokes the execution units of each node according to the execution binding information to complete the service orchestration. When a change in the service configuration of the target service is detected, a new node execution unit corresponding to the target logical node is generated, and the topology skeleton is determined to be updated based on the data interface requirements of the new and old node execution units. If so, the target logical node is bound to the new node execution unit; wherein, orchestration instances that were started before the update continue to execute according to the original execution binding information, and orchestration instances started after the update execute according to the updated binding relationship.

2. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 1, characterized in that, The steps of obtaining the development platform configuration, establishing a topology skeleton based on the development platform configuration, generating the node execution units corresponding to each logical node in the topology skeleton, and establishing binding relationships include: Obtain the development platform configuration, and read the service registration information and orchestration configuration from the development platform configuration; wherein, the orchestration configuration includes node relationship data and node configuration data; A topology skeleton is established based on the node relationship data; wherein, the topology skeleton is configured to store the node relationships and data locations between logical nodes; Based on the service registration information and the node configuration data, a node execution unit corresponding to each logical node is generated, and a binding relationship is established between each logical node and the corresponding node execution unit.

3. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 2, characterized in that, The digital modeling services corresponding to the service registration information include data services and model services; The node execution unit stores service call information and data mapping information. The service call information is configured to call the digital modeling service, and the data mapping information is configured to convert between the data location and the call data of the digital modeling service.

4. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 1, characterized in that, The service orchestration process includes receiving a service orchestration request, generating execution binding information based on the topology skeleton and current binding relationships, and invoking the execution units of each node according to the execution binding information. Receive the service orchestration request and read the currently valid topology skeleton and current binding relationships; According to the logical nodes in the topology skeleton, obtain the node execution unit corresponding to each logical node from the current binding relationship, and write the obtained correspondence into the execution binding information; The logical nodes to be executed are determined according to the topology skeleton, the corresponding node execution units are obtained from the execution binding information, the corresponding services are called through the obtained node execution units, and the logical nodes in the topology skeleton are continued to be scheduled according to the call results until the service orchestration is completed.

5. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 4, characterized in that, The execution binding information is generated when the orchestration instance is created and remains unchanged until the orchestration instance ends.

6. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 1, characterized in that, When a change in the service configuration of the target service is detected, a new node execution unit corresponding to the target logical node is generated, and the process of determining whether the topology skeleton needs to be updated based on the data interface requirements of the old and new node execution units includes: When a change in the service configuration of a target service is detected, the changed service configuration of the target service is read, and a new node execution unit is generated based on the changed service configuration. Obtain the data interface requirements corresponding to the new node execution unit and the original node execution unit respectively, and compare the input data requirements and output data requirements represented by the data interface requirements; When the input data requirements of the new node execution unit and the original node execution unit are the same, it is determined that the topology skeleton does not need to be updated; otherwise, the topology skeleton is updated according to the data interface requirements of the new node execution unit.

7. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 6, characterized in that, The input data is required to be characterized by the input position and corresponding data type read by the node execution unit, and the output data is required to be characterized by the output position and corresponding data type written by the node execution unit.

8. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 1, characterized in that, The step of binding the target logical node to the new node execution unit includes: A new binding version is generated based on the current binding relationship. The binding items of the target logical node in the new binding version are replaced with the new node execution unit, while the binding items of other logical nodes are retained. After the new binding version is generated, the currently valid binding version will be switched to the new binding version; For service orchestration requests received after the new binding version takes effect, execution binding information is generated according to the new binding version; for orchestration instances for which execution binding information has been generated before the new binding version takes effect, the execution binding information continues to run until the orchestration instance ends.

9. The method for operating a digital-analog fusion service orchestration gateway based on a development platform as described in claim 8, characterized in that, For orchestration instances that have already generated execution binding information before the new binding version takes effect, continue running according to the execution binding information until the orchestration instance ends, including the following steps: When generating the execution binding information, the usage relationship between the node execution unit and the corresponding orchestration instance in the execution binding information is recorded; When the orchestration instance ends, the usage relationship corresponding to the orchestration instance is terminated; When the original node execution unit does not belong to the currently valid binding version, and there are no unfinished orchestration instances that have a usage relationship with the original node execution unit, the original node execution unit is stopped.

10. A data-analog fusion service orchestration gateway operating system based on a development platform, characterized in that, The system includes: The configuration processing module is used to obtain the development platform configuration, establish a topology skeleton according to the development platform configuration, generate the node execution unit corresponding to each logical node in the topology skeleton, and establish a binding relationship. The orchestration execution module is used to receive service orchestration requests, generate execution binding information based on the topology skeleton and the current binding relationship, and call the execution units of each node according to the execution binding information to complete service orchestration. The change processing module is used to generate a new node execution unit corresponding to the target logical node when a change in the service configuration of the target service is detected, and to determine whether the topology skeleton needs to be updated based on the data interface requirements of the new and old node execution units. The binding update module is used to bind the target logical node to the new node execution unit when the topology skeleton needs to be updated; wherein, the orchestration instance that was started before the update continues to execute according to the original execution binding information, and the orchestration instance that was started after the update executes according to the updated binding relationship.

Images