Service publishing method

Abstract

The invention provides a service publishing method, which is applied to a service publishing component and comprises the following steps: constructing service metadata of atlas service based on service configuration information in a received service publishing request; persistently storing the service metadata into a preset database so as to configure and register the atlas service; and generating routing configuration information based on the service metadata, and calling a management interface of the flow gateway to synchronize the routing configuration information to the flow gateway, so that the flow gateway updates a service routing table according to the routing configuration information and exposes the atlas service to the outside, thereby realizing centralized management, standard access and one-key release of the atlas service, and improving the service efficiency. The service publishing efficiency and consistency are improved, and the operation and maintenance complexity and the technical threshold are reduced; and meanwhile, by decoupling the service gateway and the flow gateway, hierarchical management of operation logic and flow control is realized, and the maintainability and security of the system are enhanced.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a service publishing method. Background Technology

[0002] With the widespread application of knowledge graph technology, graph services for scenarios such as entity relationship querying, semantic search, and intelligent recommendation are gradually increasing. In actual deployments, knowledge graph services are usually provided externally in the form of standardized interfaces, supporting cross-system calls and integration. However, due to limitations such as scattered interfaces, cumbersome registration processes, and high configuration complexity, how to achieve rapid deployment, unified registration, and efficient management of graph services has become an urgent problem to be solved. Summary of the Invention

[0003] This disclosure provides a service publishing method to at least partially address one of the technical problems in the related art. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a service publishing method is provided, applied to a service publishing component, comprising: responding to receiving a service publishing request forwarded by a business gateway, constructing service metadata for a graph service based on service configuration information in the service publishing request; wherein the service publishing request is generated by a client in response to a service publishing operation; persistently storing the service metadata in a preset database to configure and register the graph service; generating routing configuration information based on the service metadata, and calling a management interface of a traffic gateway to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates its service routing table according to the routing configuration information and exposes the graph service externally.

[0004] According to a second aspect of the present disclosure, a service publishing apparatus is provided, applied to a service publishing component, comprising: a receiving module, configured to, in response to receiving a service publishing request forwarded by a business gateway, construct service metadata for a graph service based on service configuration information in the service publishing request; wherein the service publishing request is generated by a client in response to a service publishing operation; a registration module, configured to persistently store the service metadata in a preset database to configure and register the graph service; and a synchronization module, configured to generate routing configuration information based on the service metadata, and call the management interface of a traffic gateway to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates its service routing table according to the routing configuration information and exposes the graph service externally.

[0005] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement a service publishing method as described in the first aspect of the present disclosure.

[0006] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, enables the electronic device to perform a service publishing method as described in the first aspect of the present disclosure.

[0007] According to a fifth aspect of the present disclosure, a computer program product is provided, comprising: a computer program that, when executed by a processor, implements the service publishing method as described in the first aspect of the present disclosure.

[0008] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In this technical solution, upon receiving a service publication request forwarded by the business gateway, service metadata for the graph service is constructed based on the service configuration information in the service publication request, thus achieving a structured description of key service attributes. By persistently storing this service metadata in a pre-set database, the graph service's configuration registration in the service center is completed, ensuring the traceability and availability of service configuration. Furthermore, based on this service metadata, corresponding routing configuration information is generated and synchronized to the traffic gateway by calling its management interface, triggering an update of its internal service routing table. This allows the graph service to be exposed externally and accessed by legitimate requests. This mechanism constructs a fully automated service publication process, achieving centralized management, standard access, and one-click publication of the graph service, improving service deployment efficiency and consistency, and reducing operational complexity and technical barriers. Simultaneously, by decoupling the business gateway and the traffic gateway, layered governance of operational logic and traffic control is achieved, enhancing system maintainability and... Security: When synchronizing routing configuration information to the traffic gateway by calling its management interface, multiple key fields in the service metadata are encapsulated to generate a routing request object compatible with the traffic gateway's management interface communication protocol. This object is then synchronized to the traffic gateway via its management interface, triggering a dynamic update to the service routing table, significantly improving the accuracy and efficiency of routing configuration. Furthermore, since routing configuration information is automatically registered during the service deployment phase, new or modified services can take effect in real time, enhancing system agility and maintainability. In addition, during the generation of routing configuration information based on service metadata, corresponding plugin configuration information can also be generated. This plugin configuration information is then synchronized to the traffic gateway via its management interface. Upon receiving the plugin configuration information, the traffic gateway dynamically loads the relevant functional plugins, enabling them to take effect in the request processing flow and achieving operational management of the graph service.

[0009] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0010] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0011] Figure 1 This is a flowchart illustrating the service publishing method shown in the first embodiment of this disclosure; Figure 2 This is a flowchart illustrating the service publishing method shown in the second embodiment of this disclosure; Figure 3This is a flowchart illustrating the service publishing method shown in the third embodiment of this disclosure; Figure 4 This is a flowchart illustrating the service publishing method shown in the fourth embodiment of this disclosure; Figure 5 This is a flowchart illustrating the service publishing method shown in the fifth embodiment of this disclosure; Figure 6 This is a schematic diagram illustrating the service publishing and service invocation principles shown in the embodiments of this disclosure; Figure 7 This is a schematic diagram of the service management interface of the business gateway shown in the embodiments of this disclosure; Figure 8 This is a schematic diagram of the service publishing configuration interface shown in the embodiments of this disclosure; Figure 9 This is a schematic diagram of the service publishing device shown in the sixth embodiment of this disclosure; Figure 10 This is a schematic diagram of the structure of an electronic device shown in an exemplary embodiment of the present disclosure. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0013] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure 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 of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0014] It should be noted that the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in the technical solution disclosed herein are all carried out with the consent of the user, and all comply with the provisions of relevant laws and regulations, and do not violate public order and good morals.

[0015] Traffic gateways (such as Kong), as open-source, high-performance application programming interface (API) gateways, possess capabilities such as service registration, routing forwarding, and plugin extension, and are widely used in microservice architectures. However, the use of traffic gateways still requires manual configuration of services, routes, plugins, etc., especially in knowledge graph scenarios, where diverse interface structures and complex parameter configurations result in low deployment efficiency and high maintenance costs, severely restricting the flexible access and unified management of knowledge graph services.

[0016] To address any of the above issues, this disclosure proposes a service publishing method.

[0017] The service publishing method of this disclosure is described below with reference to the accompanying drawings.

[0018] Figure 1 This is a flowchart illustrating the service publishing method shown in the first embodiment of this disclosure. It should be noted that this embodiment applies to a service publishing component.

[0019] like Figure 1 As shown, the service publishing method includes steps 101 to 103, as detailed below: Step 101: In response to receiving a service publication request forwarded by the business gateway, construct the service metadata of the graph service based on the service configuration information in the service publication request.

[0020] The service publishing request is generated by the client in response to the service publishing operation.

[0021] To achieve unified management of graph services, one possible approach is to parse the service publication request forwarded by the business gateway upon receiving it, extracting the service configuration information contained within. This service configuration information includes, but is not limited to, key attributes such as service name, API path, request method, authentication type, and backend service address. Based on the extracted configuration information, it is organized into structured service metadata. This service metadata can be represented in data formats such as JSON, YAML, or objects, and is used to uniformly describe the semantic definition, invocation contract, and management attributes of graph services, providing a data foundation for subsequent service registration, route generation, and unified governance.

[0022] It should be noted that the service publishing request is triggered by the user completing the graph service configuration operation on the client's front-end page. The configuration operation may include, but is not limited to, filling in the interface path, authentication method, parameter mapping rules, etc. Then, it is initially verified and forwarded through the business gateway (giengraph-gateway). This mechanism transforms user operations into standardized service publishing instructions, which can effectively prevent illegal or incorrectly formatted service publishing requests from causing system anomalies and realize a unified entry point for service configuration information.

[0023] In some embodiments, such as Figure 2 As shown, step 101 may include steps 1011 to 1012, as follows: Step 1011: Determine the running cluster to which the map service belongs based on the environment identifier in the service configuration information.

[0024] Among them, the environment identifier is used to indicate the deployment environment of the map service.

[0025] To achieve accurate deployment and resource isolation of the graph service across multiple environments, as an example, during the service release process, the target deployment environment of the graph service is identified by parsing the environment identifiers contained in the service configuration information. For example, the environment identifier "prod" represents a production environment, "test" represents a testing environment, and "dev" represents a development environment. Each environment identifier corresponds to independent operational requirements and security policies. Then, based on the environment identifier, the actual running cluster that matches it is found and determined from a pre-defined cluster mapping table. The running cluster is a computing unit with independent resource isolation and a running environment, such as a Kubernetes cluster, a virtual machine group, a namespace in a container cloud platform, or cloud instances in different geographical regions.

[0026] Step 1012: Generate the access address of the graph service in the deployment environment based on the network topology information and the backend service address in the service configuration information of the running cluster.

[0027] To ensure accurate generation of access addresses for the graph service across different deployment environments, the system dynamically resolves and generates an actual accessible address suitable for the deployment environment of the graph service by combining the network topology of the current running cluster and the backend service address (e.g., service name and service port) provided in the service configuration. For example, if the user-configured backend service address is graph-service:8080, this backend service address is expanded to a complete address conforming to the cluster's naming conventions and communication mechanisms, based on the network environment of the running cluster.

[0028] The network topology includes, but is not limited to: cluster intranet domain name rules, service discovery mechanisms, namespace or tenant isolation configurations, etc. This information collectively determines the complete addressing format required for inter-service communication, ensuring that the generated access addresses strictly adhere to the target cluster's internal communication protocol, and guaranteeing that traffic gateways or other callers can correctly establish connections. Step 1013: Generate a service information object based on the service configuration information, access address, and parameter rules defined in the preset interface template.

[0029] Among them, the service information object is used to represent the service metadata of the graph service.

[0030] To achieve standardized modeling and unified management of graph service metadata, as an example, service configuration information, access address, and parameter rules defined in the preset interface template are integrated to create a structured service information object. The service information object exists in a unified data model form, such as a JSON object, YAML structure, or class instance in a programming language, which can fully describe the attributes, behaviors, and invocation methods of the graph service.

[0031] The preset interface template defines the standard parameter rules that service publishing must follow, which may include: required fields, data type constraints, default values, enumeration ranges (such as protocol types HTTP / HTTPS), etc. These rules are used to validate and complete user input to ensure that the generated service information objects conform to the platform specifications.

[0032] In summary, the runtime cluster to which the graph service belongs is determined based on the environment identifier in the service configuration information, enabling service deployment to be allocated to the corresponding execution environment and achieving resource isolation and differentiated policy management between different environments. Furthermore, by combining the network topology information of the runtime cluster with the backend service address in the service configuration, an actual accessible address suitable for the current deployment environment is dynamically generated, ensuring the accuracy and reachability of the service call path and avoiding request failures due to address resolution errors. Further, by integrating the service configuration information, the generated access address, and the parameter rules defined in the preset interface template, a structured service information object is constructed. This object fully represents the service metadata of the graph service in a unified data model form, covering not only basic attributes but also integrating environmental context and standardized constraints, significantly enhancing the accuracy, maintainability, and cross-environment adaptability of the graph service deployment.

[0033] Step 102: Persistently store the service metadata in a preset database to configure and register the graph service.

[0034] To improve the traceability and reusability of service configuration, one possible approach is to persistently store the completed service metadata in a pre-defined database, such as a relational database like MySQL or PostgreSQL, to complete the configuration registration of the graph service. It should be noted that this database serves as a service registry, recording the metadata of all published services and supporting operations such as querying, updating, and version management.

[0035] In some embodiments, such as Figure 3 As shown, step 102 may include steps 1021 to 1024, as follows: Step 1021: Extract multiple secondary key fields from the service metadata.

[0036] To achieve persistent storage and unified management of graph service configuration information, as an example, a set of key attribute fields for persistent storage, namely multiple secondary key fields, are extracted from the service metadata of the graph service. It should be noted that the secondary key fields include, but are not limited to: service name, API path, deployment environment identifier, version number, creation time, and project ID, which can be used to fully describe the key information of the graph service in the configuration management dimension.

[0037] Step 1022: Convert multiple secondary key fields into data records that adapt to the table structure of the database.

[0038] Furthermore, as an example, the extracted secondary key fields are formatted and transformed according to the predefined table structure of the service configuration table in the target database to generate a structured data record. It should be noted that this transformation process may include field type mapping, field name alignment, default value filling and null value handling, etc., to ensure that the generated data record meets the database constraints and can be written correctly.

[0039] Step 1023: Generate a composite primary key based on multiple second key fields; wherein, the composite primary key is used to identify data records.

[0040] To achieve efficient management of service configurations, several fields with unique combination characteristics are selected from multiple secondary key fields, such as service name, deployment environment identifier, and version number. The selected secondary fields are concatenated or hashed to generate a composite primary key. It should be noted that this composite primary key can serve as a unique identifier for data records, used to distinguish the same service instance under different environments or versions in the database.

[0041] Step 1024: Based on the composite primary key, write the data record into the service configuration table of the database to configure and register the graph service.

[0042] To achieve effective management of service configuration information, as an example, a generated composite primary key is used as a unique index to insert or update formatted data records into the service configuration table in the database. It should be noted that if the composite primary key already exists, an update operation is performed to reflect the latest configuration; otherwise, an add operation is performed. Through this write action, the configuration information of the graph service is registered with the service center, completing configuration registration and providing a data foundation for subsequent query, synchronization, and governance operations.

[0043] In this embodiment, after the data record of the graph service is successfully written into the service configuration table, a corresponding release history record can be generated. This release history record may include key fields such as service name, change content, operation time, operator, deployment environment, and version information. Furthermore, this release history record can be persistently stored in a release history table specifically maintained by the service release component. This release history table is used to record every service configuration change event of the graph service in a complete and orderly manner throughout its entire lifecycle, such as service configuration registration and service configuration update. This enables full-process tracking of service release behavior, supports problem backtracking and version comparison, and effectively improves the traceability of service management and the reliability of operation and maintenance.

[0044] In summary, by extracting multiple secondary key fields from the service metadata, the key configuration attributes of the graph service were accurately captured. These fields were then converted into data records adapted to the database table structure, ensuring that the service configuration information met the format requirements for persistent storage and improving the compatibility and correctness of data writing. A composite primary key was generated based on these secondary key fields, using multi-dimensional attribute combinations to form a unique identifier, avoiding primary key conflicts between service instances in different deployment scenarios and ensuring data independence and distinguishability. Finally, based on this composite primary key, the data records were written to the service configuration table in the database, achieving the registration and unified management of configuration information, and improving the automation level of service registration and data consistency.

[0045] Step 103: Generate routing configuration information based on service metadata, and call the management interface of the traffic gateway to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates the service routing table according to the routing configuration information and exposes the graph service to the outside world.

[0046] To achieve automated publishing and unified access management of graph services, one possible approach is to automatically generate routing configuration information that conforms to the specifications of a traffic gateway (such as Kong) based on key fields in the service metadata, such as API path, upstream service address, and protocol type. The routing configuration information typically includes: route path, upstream service address, request method restrictions, etc. Then, by calling its management interface, the routing configuration information is pushed to the traffic gateway. After receiving the configuration, the traffic gateway loads it into the runtime environment and dynamically updates its internal service routing table, so that newly published graph services can be exposed to the outside world immediately and respond to legitimate external requests.

[0047] In some embodiments, such as Figure 4 As shown, step 103 includes steps 1031 to 1032, as follows: Step 1031: Encapsulate multiple first key fields in the service metadata to generate a routing request object that is compatible with the communication protocol of the management interface of the traffic gateway; wherein, the routing request object is used to carry the routing configuration information of the graph service.

[0048] To achieve protocol compatibility and synchronization between the routing configuration of the graph service and different traffic gateways, as an example, during the service publication process, several key fields, namely the first key fields, are extracted from the service metadata of the graph service. These fields are then formatted and encapsulated according to the data structure and communication protocol required by the target traffic gateway management interface to generate a structured routing request object. It should be noted that this object conforms to the input specifications of the traffic gateway management API and is used to carry complete routing configuration information. The first key fields may include, but are not limited to, API path, upstream service address, request method, protocol type, retry strategy, etc.

[0049] Step 1032: Call the management interface of the traffic gateway and send a routing request object to synchronize the routing configuration information to the traffic gateway so that the traffic gateway can update the service routing table according to the routing configuration information.

[0050] To achieve dynamic exposure and real-time activation of the graph service, as an example, the generated routing request object is submitted to the traffic gateway as a payload by calling the management interface exposed by the traffic gateway. After receiving the routing request object, the traffic gateway parses the routing configuration information and synchronously updates the service routing table maintained by the traffic gateway at runtime. After the update is completed, the traffic gateway can identify and match the service call request of the external client for the newly published graph service, and correctly forward the service call request to the corresponding backend service instance, so as to make the graph service available to the outside world.

[0051] The service routing table is updated using the following steps: Perform format validity and access permission checks on the route request object; To ensure secure access and reliable processing of the graph service routing configuration, as an example, after the traffic gateway receives the routing request object, it first performs format validity checks, including verifying the integrity of the JSON structure, the existence of required fields, the correctness of field types, and whether the API path conforms to the specifications. At the same time, it performs access permission checks to confirm whether the entity initiating the service publishing request has the authority to add or modify the routing configuration, preventing unauthorized operations.

[0052] (2) Write the routing request object into the persistent configuration storage of the traffic gateway to update the routing rule records in the persistent configuration storage; To achieve reliable storage and persistent management of the routing configuration for the graph service, as an example, after the routing request object has passed the format validity and access permission verification, the data access layer writes the routing request object to the persistent configuration storage of the traffic gateway, performs an update operation, and overwrites or adds the corresponding routing rule record in the storage.

[0053] (3) Load the updated routing rule records from the persistent configuration storage into the service routing table in the memory of the traffic gateway to update the service routing table.

[0054] To achieve dynamic activation and efficient request matching for the network graph service, as an example, the traffic gateway reads the latest written routing rule record from the persistent configuration storage and loads it into the service routing table in runtime memory. It's important to note that this service routing table is used to quickly match client requests with target backend services during the request processing phase and forward the request to the corresponding target instance.

[0055] Furthermore, to achieve refined operation and management of the graph service, during the process of generating routing configuration information based on service metadata, corresponding plugin configuration information can also be generated. This plugin configuration information defines the enabling status and specific parameters of various functional plugins associated with the traffic gateway, such as whether to enable JWT (a type of identity credential format) authentication, rate limiting threshold settings, Internet Protocol (IP) access control policies, and request header transformation rules. Then, by calling the traffic gateway's management interface, this plugin configuration information is synchronized to the traffic gateway. After receiving the configuration, the traffic gateway binds the plugin configuration information to the corresponding service or route and dynamically loads the relevant functional plugins, enabling them to take effect in the request processing flow and achieving operation and management of the graph service.

[0056] In summary, by encapsulating multiple key fields in the service metadata to generate a routing request object compatible with the traffic gateway management interface communication protocol, standardized encapsulation and automated transmission of service configuration information can be achieved. This routing request object, as a structured data carrier, fully carries the routing configuration information of the graph service and synchronizes it to the traffic gateway by calling the traffic gateway's management interface, triggering its dynamic update of the service routing table. This avoids formatting errors, omissions, or inconsistencies caused by manual input, significantly improving the accuracy and synchronization efficiency of routing configuration. At the same time, since the routing information is automatically registered during the service release phase, new or changed services can take effect in real time, enhancing the system's agility and maintainability.

[0057] In some embodiments, such as Figure 5 As shown, after step 103, steps 105 to 107 may also be included, as detailed below: Step 105: In response to receiving a service call request for the graph service, extract the caller identifier carried in the service call request; wherein, the caller identifier is used to identify the caller that sent the service call request.

[0058] When a third-party system user initiates a service call request to the graph service, the service call request first reaches the traffic gateway. The traffic gateway, as a unified entry point, parses the request header, query parameters, or specific fields in the JWT token of the service call request to extract the caller identifier used to uniquely identify the source of the call. The caller identifier may include application ID, tenant number, user account, or device fingerprint, etc., to distinguish the identities of different clients.

[0059] Step 106: Based on the caller's identifier, authenticate the caller and perform flow control on the caller's request frequency according to a preset strategy.

[0060] Furthermore, after obtaining the caller's identifier, the traffic gateway performs authentication based on the loaded functional plugins. For example, the authentication plugin verifies the validity of the identifier, confirming that it is registered in the system and has not expired. Then, it triggers the rate limiting plugin, which queries the preset traffic policy (such as "maximum 100 requests per second") based on the identifier and uses a sliding window or token bucket algorithm to count the current request frequency in real time. If authentication fails or the request frequency exceeds the limit, the traffic gateway directly returns an error code and refuses to forward the request.

[0061] Step 107: If the identity authentication is successful and the request frequency does not exceed the preset threshold, then the service call is initiated to the graph service according to the parameter information in the service call request, and the call result is returned to the caller.

[0062] To effectively prevent unauthorized access and overload risks, as a possible implementation, if identity authentication is successful and the request frequency does not exceed a preset threshold, it indicates that the service call request has passed security verification and access control. Then, based on the parameter information carried in the service call request, a call instruction conforming to the target service communication protocol format is created and a remote call is initiated to the actual running graph service provider instance. After the graph service completes processing and returns a response result, the result is encapsulated and directly sent back to the caller who originally initiated the request.

[0063] To achieve unified access and secure invocation of graph services, as an example, after the traffic gateway completes identity authentication and rate limiting verification, it forwards the service call request to the business gateway based on the stored routing rules. The business gateway retrieves the parameter mapping rules corresponding to the service from the service publishing component and performs format adaptation such as field renaming and type conversion on the request parameters in the service call request to generate input parameters that conform to the graph service interface specification. For example, according to the field mapping relationship, data type conversion strategy, and filling rules defined in the parameter mapping rules, the original call parameters in the service call request are rewritten in a structured manner. For example, the source parameter name is converted to the target field according to the field mapping relationship, and the parameter value is format adapted according to the data type conversion strategy, such as converting string numeric values ​​to integers and parsing date strings into timestamps, and adding default values ​​according to the filling rules. The converted parameters generated after processing are consistent with the interface contract defined by the graph service in terms of structure, naming, and type. Then, the business gateway initiates a remote call to the actual running graph service provider instance. After the graph service completes processing and returns response data, the business gateway sends the result back to the traffic gateway, which finally returns it to the original caller.

[0064] It should be noted that the parameter mapping rules are generated by the service publishing component during the service registration process based on the preset graph service interface template and parameter filling mechanism, and then registered with the business gateway.

[0065] In other words, parameter mapping rules are automatically generated by the service publishing component during the graph service registration phase. Specifically, the service publishing component generates a complete parameter mapping configuration based on a preset standard interface template (such as the REST API specification) and a parameter population mechanism, which may include, but is not limited to, field mapping strategies, expression engines, or rule engines, combined with service metadata. This configuration is then registered or synchronized to the business gateway. This mechanism enables centralized management and automated distribution of mapping rules, avoiding manual configuration errors and ensuring consistency and maintainability of parameter processing across multiple services.

[0066] In other words, when the graph service is launched or updated, the service registration process is executed through the service publishing component. During this process, the service publishing component automatically constructs a service contract based on a preset graph service interface template. At the same time, combined with parameter filling mechanisms, such as field alias mapping, default value injection, expression evaluation, regular expression extraction, and type conversion strategies, the service publishing component automatically generates a complete set of parameter mapping rules. These parameter mapping rules define how the original parameters in external call requests are renamed, transformed, and recombined to adapt to the internal interface of the graph service. After the parameter mapping rules are generated, the service publishing component actively registers or synchronizes these rules to the business gateway, enabling the business gateway to perform format conversion on actual service call requests at runtime according to these rules.

[0067] The service publishing method of this disclosure constructs service metadata for a graph service based on the service configuration information in the service publishing request when a service publishing request is received from a business gateway, thus achieving a structured description of key service attributes. By persistently storing this service metadata in a preset database, the configuration registration of the graph service in the service center is completed, ensuring the traceability and availability of the service configuration. Furthermore, corresponding routing configuration information is generated based on this service metadata and synchronized to the traffic gateway by calling its management interface, triggering an update of its internal service routing table. This allows the graph service to be exposed externally and accessed by legitimate requests. This mechanism constructs a fully automated service publishing process, achieving centralized management, standard access, and one-click publishing of graph services. This not only improves service deployment efficiency and consistency but also significantly reduces operational complexity and technical barriers. Simultaneously, by decoupling the business gateway and the traffic gateway, layered governance of operational logic and traffic control is achieved, enhancing the maintainability and security of the system.

[0068] To clearly illustrate the above embodiments, examples are given below.

[0069] For example, such as Figure 6 As shown, the service publishing method of this disclosure embodiment may include the following steps: 1. Publish / Edit → Business Gateway (giengraph-gateway) like Figure 7 As shown, the administrator can publish or edit the external exposure information of the graph service by clicking the "Publish Service" button in the service management interface of the business gateway. After clicking the "Publish Service" button, the administrator will be redirected to the "Service Publishing" interface, as follows. Figure 8 As shown, the administrator selects the graph, graph version, and available APIs in the "Service Publishing Configuration" interface. Available APIs include, but are not limited to: graph statement query, relationship query, node query, algorithm query, path query, and common neighbor query.

[0070] 2. Business Gateway → Service Publishing Component (giengraph-svc-publish) Furthermore, the business gateway will synchronize or submit service configuration information (such as interface templates and parameter mapping rules) to the service publishing component.

[0071] 3. Service Publishing Components → MySQL Database Then, the service metadata (such as interface definition, mapping rules, version information, etc.) is persistently stored in a MySQL database to configure and register the image service.

[0072] 4. Service Publishing Components → Traffic Gateway The service publishing component pushes security-related configurations such as authentication policies, rate limiting rules, and routing rules to the KONG traffic gateway, enabling the KONG traffic gateway to expose graph services to the outside world and perform authentication, frequency control, and routing forwarding on service call requests.

[0073] After the service is published, such as Figure 6 As shown, a service call may include the following steps: 5. Third-party system users → Traffic gateway Third-party system users initiate service call requests to the KONG traffic gateway; the service call request may carry information such as URL, parameters, and authentication token.

[0074] 6. Traffic Gateway → Service Gateway After the traffic gateway completes the authentication (auth) and rate limit for the service call, if the service call request is valid, it will forward the service call request to the business gateway.

[0075] 7. Parameter Mapping → Service Gateway Load preset parameter mapping rules from the database or cache, perform structured rewriting of request parameters (field mapping, type conversion, autofill), and generate conversion parameters adapted to the graph service.

[0076] 8. Service Invocation → Graph Services (giengraph-services) Construct a call message (such as JSON or HTTP request body) that conforms to the graph service interface contract using the transformed parameters, and call the backend graph service (giengraph-services) over the network.

[0077] Corresponding to the service publishing method provided in the above embodiments, this disclosure also provides a service publishing apparatus. Since the service publishing apparatus provided in this disclosure corresponds to the service publishing method provided in the above embodiments, the implementation of the service publishing method is also applicable to the service publishing apparatus provided in this disclosure, and will not be described in detail in this disclosure.

[0078] Figure 9 This is a schematic diagram of the service publishing device shown in the sixth embodiment of this disclosure.

[0079] like Figure 9 As shown, the service publishing device 900 includes: a receiving module 910, a registration module 920, and a synchronization module 930.

[0080] The receiving module 910 is used to respond to a service publishing request forwarded by the business gateway and construct service metadata for the graph service based on the service configuration information in the service publishing request; wherein the service publishing request is generated by the client in response to the service publishing operation; the registration module 920 is used to persistently store the service metadata in a preset database to configure and register the graph service; the synchronization module 930 is used to generate routing configuration information based on the service metadata and call the management interface of the traffic gateway to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates the service routing table according to the routing configuration information and exposes the graph service to the outside world.

[0081] As one possible implementation, the receiving module 910 is used to determine the running cluster to which the graph service belongs based on the environment identifier in the service configuration information; wherein the environment identifier is used to indicate the deployment environment of the graph service; generate the access address of the graph service in the deployment environment based on the network topology information of the running cluster and the backend service address in the service configuration information; and generate a service information object based on the service configuration information, the access address and the parameter rules defined in the preset interface template; wherein the service information object is used to represent the service metadata of the graph service.

[0082] As one possible implementation, the synchronization module 930 is used to encapsulate multiple first key fields in the service metadata to generate a route request object that is compatible with the communication protocol of the management interface of the traffic gateway. The route request object is used to carry the routing configuration information of the graph service. The management interface of the traffic gateway is called to send the route request object to synchronize the routing configuration information to the traffic gateway so that the traffic gateway can update the service routing table according to the routing configuration information.

[0083] As one possible implementation, the update module updates the service routing table using the following steps: validating the format and access permissions of the routing request object; in response to the routing request object passing the format and access permission checks, writing the routing request object into the persistent configuration storage of the traffic gateway to update the routing rule records in the persistent configuration storage; and loading the updated routing rule records from the persistent configuration storage into the service routing table in the memory of the traffic gateway to update the service routing table.

[0084] As one possible implementation, the synchronization module 930 is also used to obtain plugin configuration information; wherein, the plugin configuration information is generated based on service metadata; the plugin configuration information is used to define the activation status and parameters of the functional plugins associated with the traffic gateway; the plugin configuration information is synchronized to the traffic gateway so that the traffic gateway can dynamically load functional plugins based on the plugin configuration information to manage the operation of the graph service.

[0085] As one possible implementation, the registration module 920 is used to extract multiple second key fields from the service metadata; convert the multiple second key fields into data records that adapt to the table structure of the database; generate a composite primary key based on the multiple second key fields; wherein the composite primary key is used to identify the data record; and write the data record into the service configuration table of the database based on the composite primary key to configure and register the graph service.

[0086] As one possible implementation, the registration module 920 is also used to: generate a release history of the graph service in response to writing data records to the service configuration table; and persistently store the release history in the release history table of the service release component; wherein the release history table is used to record service configuration change events of the graph service.

[0087] As one possible implementation, the traffic gateway uses the following modules to perform the following operations: extraction module, verification module, and invocation module.

[0088] The extraction module is used to extract the caller identifier carried in the service call request in response to a received service call request for the graph service; wherein the caller identifier is used to identify the caller that sent the service call request; the verification module is used to authenticate the caller based on the caller identifier and perform flow control on the caller's request frequency according to a preset strategy; the calling module is used to initiate a service call to the graph service according to the parameter information in the service call request if the authentication is successful and the request frequency does not exceed a preset threshold, and return the call result to the caller.

[0089] As one possible implementation, after receiving the service call request forwarded by the traffic gateway, the processing module performs the following operations: obtains the preset parameter mapping rules; based on the parameter mapping rules, converts the format of the call parameters in the service call request to obtain the converted parameters adapted to the graph service; wherein, the parameter mapping rules are generated by the service publishing component during the service registration process based on the preset graph service interface template and parameter filling mechanism, and are registered to the business gateway.

[0090] As one possible implementation, the processing module is also used to structurally rewrite the call parameters in the service call request according to the field mapping relationship, data type conversion strategy and filling rules defined in the parameter mapping rules, so as to obtain the conversion parameters; wherein, the conversion parameters are used to generate a call message that adapts to the graph service interface contract, and the call message is used to initiate a service call to the graph service.

[0091] The service publishing apparatus of this disclosure constructs service metadata for a graph service based on the service configuration information in the service publishing request when it receives a service publishing request forwarded by the business gateway, thereby achieving a structured description of key service attributes. By persistently storing this service metadata in a preset database, the configuration registration of the graph service in the service center is completed, ensuring the traceability and availability of the service configuration. Furthermore, based on the service metadata, corresponding routing configuration information is generated and synchronized to the traffic gateway by calling its management interface, triggering the gateway to update its internal service routing table. This allows the graph service to be exposed externally and accessed by legitimate requests. The above mechanism constructs a fully automated service publishing process, realizing centralized management, standard access, and one-click publishing of graph services. This not only improves service deployment efficiency and consistency but also significantly reduces operational complexity and technical barriers. At the same time, by decoupling the business gateway and the traffic gateway, layered governance of operational logic and traffic control is achieved, enhancing the maintainability and security of the system.

[0092] In an exemplary embodiment, an electronic device is also proposed.

[0093] The electronic devices include: processor; Memory used to store processor-executable instructions; The processor is configured to execute instructions to implement the service publishing method as presented in any of the foregoing embodiments.

[0094] As an example, Figure 10 This is a schematic diagram of the structure of an electronic device 1000 as shown in an exemplary embodiment of this disclosure, as follows: Figure 10 As shown, the aforementioned electronic device 1000 may further include: The memory 1010 and processor 1020 are connected by a bus 1030, which connects different components (including the memory 1010 and the processor 1020). The memory 1010 stores a computer program, which implements the service publishing method described in this embodiment when the processor 1020 executes the program.

[0095] Bus 1030 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0096] Electronic device 1000 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 1000, including volatile and non-volatile media, removable and non-removable media.

[0097] The memory 1010 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1040 and / or cache memory 1050. The electronic device 1000 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 1060 may be used to read and write non-removable, non-volatile magnetic media (…). Figure 10 Not shown; usually referred to as a "hard drive"). Although Figure 10 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 1030 via one or more data media interfaces. Memory 1010 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this disclosure.

[0098] A program / utility 1080 having a set (at least one) of program modules 1070 may be stored in, for example, memory 1010. Such program modules 1070 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 1070 typically perform the functions and / or methods described in the embodiments of this disclosure.

[0099] Electronic device 1000 can also communicate with one or more external devices 1090 (e.g., keyboard, pointing device, display 1091, etc.), and with one or more devices that enable a user to interact with the electronic device 1000, and / or with any device that enables the electronic device 1000 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 1092. Furthermore, electronic device 1000 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 1093. As shown, network adapter 1093 communicates with other modules of electronic device 1000 via bus 1030. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 1000, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0100] The processor 1020 performs various functional applications and data processing by running programs stored in the memory 1010.

[0101] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the service publishing method of this disclosure embodiment, and will not be repeated here.

[0102] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory including instructions that can be executed by a processor of an electronic device to perform the service publishing method proposed in any of the above embodiments. Optionally, the computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0103] In an exemplary embodiment, a computer program product is also provided, including a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the service publishing method proposed in any of the above embodiments.

[0104] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0105] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A service publishing method characterized by comprising: The application is applied to a service publishing component, comprising: In response to receiving a service publishing request forwarded by a traffic gateway, service metadata of a graph service is constructed based on service configuration information in the service publishing request, wherein the service publishing request is generated by a client in response to a service publishing operation; The service metadata is stored in a preset database to configure and register the graph service; Based on the service metadata, routing configuration information is generated, and a management interface of the traffic gateway is called to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates a service routing table according to the routing configuration information, and exposes the graph service to the outside.

2. The method of claim 1, wherein, The service metadata of the graph service is constructed based on the service configuration information in the service publishing request, comprising: According to the environment identifier in the service configuration information, the running cluster to which the graph service belongs is determined; wherein the environment identifier is used to indicate the deployment environment of the graph service; According to the network topology information of the running cluster and the backend service address in the service configuration information, the access address of the graph service in the deployment environment is generated; According to the service configuration information, the access address and the parameter rules defined in the preset interface template, a service information object is generated; The service information object is used to represent the service metadata of the graph service.

3. The method of claim 1, wherein, Based on the service metadata, routing configuration information is generated, and a management interface of the traffic gateway is called to synchronize the routing configuration information to the traffic gateway, so that the traffic gateway updates a service routing table according to the routing configuration information, and exposes the graph service to the outside, comprising: A plurality of first key fields in the service metadata are encapsulated to generate a routing request object adapted to the communication protocol of the management interface of the traffic gateway; wherein the routing request object is used to carry the routing configuration information of the graph service; The management interface of the traffic gateway is called to send the routing request object to synchronize the routing configuration information to the traffic gateway; wherein the routing configuration information is used for the traffic gateway to update the service routing table and expose the graph service to the outside.

4. The method of claim 3, wherein, The service routing table is updated by the following steps: The routing request object is subjected to format legality and access permission check; In response to the routing request object passing the format legality and access permission check, the routing request object is written into the persistent configuration storage of the traffic gateway to update the routing rule record in the persistent configuration storage; The updated routing rule record is loaded from the persistent configuration storage to the service routing table in the memory of the traffic gateway to update the service routing table.

5. The method of claim 3, wherein, The method further comprises: Obtaining plug-in configuration information; wherein the plug-in configuration information is generated according to the service metadata; the plug-in configuration information is used to define the enabled state and parameters of a functional plug-in associated with the traffic gateway; The plug-in configuration information is synchronized to the traffic gateway, so that the traffic gateway dynamically loads the functional plug-in based on the plug-in configuration information to manage the running of the graph service.

6. The method of claim 1, wherein, The service metadata is stored in a preset database to configure and register the graph service, including: extracting a plurality of second key fields in the service metadata; converting the plurality of second key fields into data records adapted to a table structure of the database; generating a composite primary key based on the plurality of second key fields; wherein the composite primary key is used to identify the data records; based on the composite primary key, writing the data records into a service configuration table of the database to configure and register the graph service.

7. The method of claim 6, wherein, The method further includes: in response to writing the data records into the service configuration table, generating a release history record of the graph service; persistently storing the release history record into a release history table of the service release component; wherein the release history table is used to record service configuration change events of the graph service.

8. The method according to any one of claims 1 to 7, characterized in that, The traffic gateway is further configured to perform the following operations: in response to receiving a service call request for the graph service, extracting a caller identifier carried in the service call request; wherein the caller identifier is used to identify a caller sending the service call request; based on the caller identifier, performing identity authentication on the caller and performing traffic control on a request frequency of the caller according to a preset policy; if the identity authentication passes and the request frequency does not exceed a preset threshold, initiating a service call to the graph service according to parameter information in the service call request, and returning a call result to the caller.

9. The method of claim 8, wherein, After the business gateway receives the service call request forwarded by the traffic gateway, the following operations are performed: obtaining a preset parameter mapping rule; based on the parameter mapping rule, performing format conversion on the call parameters in the service call request to obtain converted parameters adapted to the graph service; wherein the parameter mapping rule is generated by the service release component based on a preset graph service interface template and a parameter filling mechanism during service registration, and is registered to the business gateway.

10. The method of claim 9, wherein, The format conversion of the call parameters in the service call request based on the parameter mapping rule to obtain converted parameters adapted to the graph service includes: according to the field mapping relationship, the data type conversion strategy and the filling rule defined in the parameter mapping rule, structurally rewriting the call parameters in the service call request to obtain the converted parameters; wherein the converted parameters are used to generate a call message adapted to the graph service interface contract, and the call message is used to initiate a service call to the graph service.

Images