Multi-gateway fusion architecture system for data sharing

Abstract

The invention belongs to the technical field of service gateways, and particularly relates to a multi-gateway fusion architecture system for data sharing, an interface user requests for an available gateway address to a resource management system, the resource management system returns the available gateway address to the interface user, and the interface user performs data sharing according to the obtained gateway address. The resource management system initiates service calling to a corresponding service gateway, the service gateway processes a request and generates a log, the log is transmitted to the log processing system through a message queue cluster, the log processing system performs cleaning, filtering and information merging operation on the received log, and the resource management system is responsible for managing and monitoring the state of the service gateway; the architecture system is provided with a multi-gateway unified authentication specification and a service interface agent specification; the service gateways of a plurality of different manufacturers can be accessed at the same time, and when the gateway of one manufacturer has the problem which cannot be solved, service calling is smoothly switched to the service gateway of the standby manufacturer, so that the capability of the sharing platform for providing services to the outside in a high-concurrency scene is ensured.

Description

Technical Field

[0001] The present invention belongs to the technical field of service gateways, and in particular relates to a multi-gateway fusion architecture system for data sharing. Background Art

[0002] The service gateway has core functions such as routing forwarding, load balancing, authentication filtering, etc., and can integrate service governance, request forwarding fuse mechanism, service aggregation and other functions to optimize service provision capabilities. In the government information sharing and exchange platform, the most common, easiest to use, and most real-time data is generally provided to the outside world in the form of service interfaces. The service gateway is the only way for the service-using department to call the original service interface provided by the service-providing department. The stability, high concurrency and high availability of the service gateway are crucial to the platform.

[0003] For service calls, the service provider department must first register the service metadata information on the shared exchange platform. After the service calling department obtains the service metadata information through the shared exchange platform, it can apply online or offline to obtain the service use rights. After obtaining the service use rights, the using department completes the call of the original service of the providing department through the service gateway provided by the shared exchange platform. With the growth of business volume and the diversification of business scenarios, the service gateways of the existing shared exchange platforms in various places often have unstable service agents, slow service responses, and increased error rates under high business concurrency. Through problem analysis, the current gateway architecture design mainly has the following problems: 1) High service call pressure and difficult service support. When the service concurrent call volume is very large, the service gateway will often have problems such as gateway routing failure and untimely service key refresh. The service gateways of the shared exchange platform are basically the service interfaces of various government departments. The protocols, message formats, and access methods used by these service interfaces are very different. Therefore, after the service gateway acts as a proxy service, it is inevitable that the service call will fail due to incomplete gateway program design. Usually, after a service proxy error occurs, a gateway node will switch to other gateway nodes or gateway nodes in another cloud center. However, since the gateway programs on these nodes are provided by one manufacturer, the same error usually occurs on other gateway nodes. 2) The service gateway is highly coupled with the upper-level business system. At present, it can be clearly seen from the service interface call process that many business functions related to service application review, service interface metadata management, service call audit, etc. have been added to the service gateway, resulting in a very high coupling between the service gateway and the upper-level business system of the platform. 3) The technical architecture of a single service gateway is single. Here, a single service gateway refers to a service gateway that relies solely on a single manufacturer to provide interface proxy services to the outside world. The single technical architecture of a single service gateway is the biggest problem in many current shared exchange platforms. In the field of government data sharing and exchange, the basic working mode of interface call is that the service provider registers its own service to the shared exchange platform, and the service caller calls the service from the shared exchange platform. The shared exchange platform only plays the role of intermediary forwarding. In this case, the traditional single service gateway architecture has obvious defects: after the service gateway proxy has problems, it cannot be smoothly switched in the production environment. Summary of the invention

[0004] When a service caller calls a service from a shared exchange platform, the traditional single service gateway architecture cannot achieve smooth switching in a production environment after a problem occurs in the service gateway agent. The present invention provides a multi-gateway fusion architecture system for data sharing.

[0005] The technical solution of the present invention provides a multi-gateway fusion architecture system for data sharing, including a resource management system, a message queue cluster, a log processing system and multiple service gateways; The interface user requests the resource management system for an available gateway address, and the resource management system returns the available gateway address to the interface user. The interface user initiates a service call to the corresponding service gateway based on the obtained gateway address. The service gateway processes the request and generates a log. The log is transmitted to the log processing system through the message queue cluster. The log processing system cleans, filters and merges the received logs. At the same time, the resource management system is responsible for managing and monitoring the status of the service gateway. The architecture system sets unified authentication specifications for multiple gateways and service interface proxy specifications; All service gateways registered in the resource management system follow consistent service interface proxy specifications; the multi-gateway unified authentication specification is the process specification for the service gateway to verify the identity and authority of the caller when the interface user initiates a service call to the service gateway.

[0006] As a further limitation of the technical solution of the present invention, the data provider registers the data interface in the resource management system and defines the interface call specifications and requirements during registration. The data manager performs a preliminary interface call test in the resource management system. After the test passes, the test is published in the resource management system. After the publication is successful, the resource management system sends interface metadata information to each service gateway.

[0007] As a further limitation of the technical solution of the present invention, the resource management system is responsible for receiving interface metadata registration requests from each service gateway, and the metadata may include the name, function description, parameter type, and calling method of the interface; for each registered interface metadata, the resource management system assigns a unique identifier to it, and classifies and stores the registered interface metadata; The resource management system generates service metadata information based on the registered and stored interface metadata. At the same time, the resource management system also generates authorization subscription information and dynamic access tokens. The authorization subscription information is used to determine the service gateway's access rights to a specific interface, and the dynamic access token is used for the service gateway's identity authentication when calling the interface. The resource management system sends the generated service metadata information, authorization subscription information and dynamic access token to each service gateway.

[0008] As a further limitation of the technical solution of the present invention, the resource management system defines permissions for each interface, and according to the role and function of the service gateway, the resource management system allocates corresponding interface permissions to each service gateway, encodes the allocated permission information, and forms authorized subscription information.

[0009] As a further limitation of the technical solution of the present invention, the interface user searches for the required interface information in the resource management system and submits an interface use application. The data manager and the data provider review and approve the interface use application in the interface management system in turn. After the review is passed, the resource management system generates a key for the interface call and sends the available gateway address and the call key to the interface user. At the same time, the resource management system also sends the application authorization information and the key to the service gateway.

[0010] As a further limitation of the technical solution of the present invention, after the interface user receives the usable gateway address and interface call key, it initiates an interface call request to the service gateway. The service gateway verifies the caller's identity and call key in turn. After the verification, it routes the interface to the original interface of the data provider. The original interface returns the result to the service gateway, and the service gateway returns the result to the data user.

[0011] As a further limitation of the technical solution of the present invention, the data call log generated by the process of the data user initiating an interface call, the service gateway receiving the interface call request and verifying the request, the gateway routing and forwarding the request to the original provider of the interface after verification, the original provider feeding back the result to the service gateway, and the gateway encapsulating the result and returning it to the data user is stored in the message queue cluster in real time to generate a consumption log, which is sent to the log processing system and consumed by the log processing system in a timely manner. The log processing system merges the logs based on the interface unique identifier and the call step number to finally form a complete call log.

[0012] As a further limitation of the technical solution of the present invention, the service interface proxy specification includes: All service gateways must be registered in the resource management system. During the registration process, the service gateway needs to provide its own metadata to the resource management system; the resource management system assigns a unique identifier to each service gateway; After receiving the request, the service gateway checks the authorization authentication field in the request header, identifies and parses the type and specific token value of the authorization token; for the authorization authentication information contained in the request body, the service gateway should parse it according to the agreed format and extract the corresponding authorization token and API key information; As a further limitation of the technical solution of the present invention, the service interface proxy specification also includes: The resource management system regularly monitors the running status of the service gateway and determines whether the gateway is faulty through the heartbeat mechanism and request response time indicators; the service gateway itself has a fault detection mechanism and reports to the resource management system in a timely manner when a fault occurs; When the resource management system detects a service gateway failure, it should immediately notify the interface user; after receiving the notification, the interface user should quickly switch the service call to the normal service gateway based on the new available gateway address provided by the resource management system; during the switching process, the service interface proxy specification should ensure that the transmission and verification method of the authorization and authentication information remains unchanged to achieve smooth switching.

[0013] As a further limitation of the technical solution of the present invention, the multi-gateway unified authentication specification includes: The interface user initiates the application registration operation and submits a registration request to the resource management system. The resource management system forwards the registration request to the resource application and review system. The resource application and review system generates an interface identifier and applies for the interface to the unified authorization system, passing the AppKey, interface identifier and session identifier. The unified authorization system calls the interface to obtain the AppKey. After successful acquisition, the AppKey is returned to the resource application and review system. The resource application and review system sends the AppKey to the interface user. The interface user uses the AppKey to perform a signing operation, passing the timestamp, interface identifier and session identifier to obtain the signature. The interface user requests the unified authorization system to obtain the dynamic token appSecret. The unified authorization system generates appSecret and sends it to the interface user. The interface user uses appSecret to perform a signing operation, passing the interface identifier and session identifier to obtain a signature. The interface user initiates a request to the service gateway, passes the signature information, the service gateway verifies the signature, forwards the request to the interface provider, the interface provider responds to the request and returns the result to the service gateway, and finally the service gateway returns the result to the interface user.

[0014] The beneficial effects of the technical solution of the present invention are: the service gateway is decoupled from the upper-layer business system, so that the gateway can focus on routing forwarding, request verification and other core functions of the gateway. At the same time, based on the unified service gateway access data sharing exchange platform standard, the data sharing platform can simultaneously access the service gateways of multiple different manufacturers. When a manufacturer's gateway encounters an unsolvable problem, the service call is smoothly switched to the service gateway of the backup manufacturer, ensuring the ability of the sharing platform to provide external services in high-concurrency scenarios, and achieving stability, reliability and high responsiveness of service calls. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solution of the present invention, the accompanying drawings required for use in the description will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative work.

[0016] Figure 1 A schematic diagram of an architecture system provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0017] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical scheme of the present invention will be clearly and completely described below in conjunction with the drawings in this specific embodiment. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of them. Based on the embodiments in this patent, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this patent.

[0018] like Figure 1 As shown, an embodiment of the present invention provides a multi-gateway fusion architecture system for data sharing, including a resource management system, a message queue cluster, a log processing system and multiple service gateways (service gateway 1, service gateway 2, service gateway 3, service gateway n); The interface user requests the resource management system for an available gateway address, and the resource management system returns the available gateway address to the interface user. The interface user initiates a service call to the corresponding service gateway based on the obtained gateway address. The service gateway processes the request and generates a log. The log is transmitted to the log processing system through the message queue cluster. The log processing system cleans, filters and merges the received logs. At the same time, the resource management system is responsible for managing and monitoring the status of the service gateway. The architecture system sets unified authentication specifications for multiple gateways and service interface proxy specifications; All service gateways registered in the resource management system follow consistent service interface proxy specifications; the multi-gateway unified authentication specification is the process specification for the service gateway to verify the identity and authority of the caller when the interface user initiates a service call to the service gateway.

[0019] In some embodiments, the data provider registers the data interface in the resource management system and defines the interface call specifications and requirements during registration. The data manager performs a preliminary interface call test in the resource management system. After the test passes, the data is published in the resource management system. After the publication is successful, the resource management system sends interface metadata information to each service gateway.

[0020] In the embodiment of the present invention, the resource management system is responsible for receiving interface metadata registration requests from each service gateway. The metadata may include the name, function description, parameter type, and calling method of the interface. For each registered interface metadata, the resource management system assigns a unique identifier to it, and classifies and stores the registered interface metadata. The resource management system generates service metadata information based on the registered and stored interface metadata. At the same time, the resource management system also generates authorization subscription information and dynamic access tokens. The authorization subscription information is used to determine the service gateway's access rights to a specific interface, and the dynamic access token is used for the service gateway's identity authentication when calling the interface. The resource management system sends the generated service metadata information, authorization subscription information and dynamic access token to each service gateway.

[0021] Specifically, the resource management system defines permissions for each interface, which includes determining the types of operations that can be performed by each interface (such as reading, writing, deleting, etc.), as well as the scope of resources that can be accessed. For example, for a data query interface, it may be defined as only allowing reading of data in a specific database table. According to the role and function of the service gateway, the resource management system assigns the corresponding interface permissions to each service gateway. This process may be based on a pre-set service gateway configuration file or manual configuration by the administrator. For example, a service gateway dedicated to data query will only be assigned access rights to data query-related interfaces. The resource management system encodes the assigned permission information to form authorized subscription information. This encoding method can adopt a specific format, such as JSON or XML, for easy storage and transmission. The generated authorized subscription information will be stored in the database of the resource management system and sent to the corresponding service gateway when needed.

[0022] The resource management system will select a suitable token generation algorithm. Common algorithms include the HMAC (Hash-based Message Authentication Code) algorithm based on symmetric keys and the RSA (Rivest-Shamir-Adleman) algorithm based on asymmetric keys. The selection is based on the security requirements and performance requirements of the system. According to the selected algorithm, the resource management system generates the corresponding key. For symmetric key algorithms, a shared key is generated; for asymmetric key algorithms, a pair of public and private keys are generated. The generated key will be securely stored in the resource management system to ensure that only authorized modules can access it. Dynamic access tokens usually contain some key information, such as service gateway identification, token validity period, permission verification information, etc. According to security requirements, the resource management system may encrypt the token content to prevent the token content from being tampered with. For algorithms based on asymmetric keys, the private key can also be used to sign the token so that the service gateway can use the public key for verification. The generated dynamic access token will be sent to the corresponding service gateway. When the service gateway calls the interface, it needs to submit the token to the resource management system for verification.

[0023] In some embodiments, the interface user searches for the required interface information in the resource management system and submits an interface usage application. The data manager and the data provider review and approve the interface usage application in the interface management system in turn. After the review is passed, the resource management system generates a key for the interface call and sends the available gateway address and the call key to the interface user. At the same time, the resource management system also sends the application authorization information and the key to the service gateway.

[0024] After receiving the usable gateway address and interface call key, the interface user initiates an interface call request to the service gateway. The service gateway verifies the caller's identity and call key in turn. After the verification, the route forwarding interface is sent to the original interface of the data provider. The original interface returns the result to the service gateway, and the service gateway returns the result to the data user.

[0025] The interface user enters relevant keywords (such as interface function, data type, etc.) through the query interface provided by the resource management system to find the required interface information. After finding a suitable interface, fill in the interface use application form in the resource management system, which may contain the user's basic information, purpose of use, expected call frequency, etc. The resource management system pushes the interface use application to the data manager. The data manager logs in to the interface management system to view the application details. According to internal policies and data security requirements, the data manager evaluates the rationality of the application. If it meets the requirements, the application is approved; if it does not meet the requirements, it is rejected and the reason is noted, and feedback is given to the interface user. The application approved by the data manager will be transferred to the data provider. The data provider also views the application content in the interface management system. The data provider considers its own data provision capabilities, load conditions and other factors to decide whether to agree to the interface use application. After approval, the application enters the resource management system to generate a secret key. For approved applications, the resource management system uses a secure random algorithm to generate an interface call secret key. The resource management system selects a suitable gateway address from the available gateway list and packages the gateway address and the interface call secret key. The resource management system sends the packaged information to the interface user, and sends the application authorization information and secret key to the corresponding service gateway. The sending method can be through a secure network connection, such as HTTPS, to ensure the confidentiality and integrity of information transmission.

[0026] After receiving the gateway address and interface call key, the interface user builds an interface call request according to the agreed protocol (such as RESTful API). The request contains authentication information such as the user identity and interface call key, and then sends the request to the specified service gateway. After receiving the interface call request, the service gateway first verifies the identity of the caller. This may involve checking whether the user identity is in the authorization list by comparing it with the authorization information issued by the resource management system. Next, the service gateway verifies the validity of the interface call key by matching and verifying it with the previously received key. After the identity and key verification is passed, the service gateway forwards the request route to the original interface of the data provider according to the interface information in the request. During the forwarding process, the service gateway may perform some necessary format conversion on the request or add additional routing information.

[0027] After the original interface of the data provider receives the request forwarded by the service gateway, it performs the corresponding data query or operation and generates the result. The original interface returns the result to the service gateway. After receiving the result, the service gateway performs simple processing on the result (such as logging) to ensure that the result format meets the requirements of the interface user. Finally, the service gateway returns the result to the interface user, completing an interface call process.

[0028] In some embodiments, the data call logs generated by the process of the data user initiating an interface call, the process of the service gateway receiving the interface call request and verifying the request, the process of the gateway routing and forwarding the request to the original provider of the interface after verification, the process of the original provider feeding back the result to the service gateway, and the gateway encapsulating the result and returning it to the data user are stored in the message queue cluster in real time to generate a consumption log, which is sent to the log processing system and consumed by the log processing system in a timely manner. The log processing system merges the logs based on the interface unique identifier and the call step number to finally form a complete call log.

[0029] In the embodiment of the present invention, when constructing an interface call request, the data user generates a call initiation log locally. The log content should at least include the interface unique identifier (such as interface ID), call step number (indicating the call initiation step), data user identifier, request initiation time, request parameters (whether to be fully recorded can be determined based on security policies), etc. The log is sent to the specified topic (such as "interface - call - logs") in the message queue cluster through the message queue client (such as Kafka Producer, RabbitMQ Publisher, etc.).

[0030] When the service gateway receives an interface call request, a receiving request log is generated. The log contains information such as the interface unique identifier, the next call step number (indicating the receiving request step), the data user identifier, the request receiving time, and the request source IP. When the caller identity authentication starts, an authentication start log is generated to record the interface unique identifier, the next call step number, the authentication start time, etc. After the identity authentication is completed, an authentication result log is generated to record the interface unique identifier, the next call step number, the authentication result (pass / fail), the verification time, etc. When the call key verification starts, a key verification start log is generated to record the interface unique identifier, the next call step number, the key verification start time, etc. After the key verification is completed, a key verification result log is generated to record the interface unique identifier, the next call step number, the key verification result (pass / fail), the verification time, etc. Send each of the above logs to the "interface - call - logs" topic of the message queue cluster in sequence.

[0031] When the verification is passed and the routing forwarding is ready, a routing forwarding log is generated. The log contains information such as the unique interface identifier, the next step number of the call, the data consumer identifier, the original provider address of the forwarding target, and the forwarding time. The log is sent to the "interface - call - logs" topic of the message queue cluster.

[0032] When the original provider has processed the request and is ready to return the result, a result return log is generated. The log contains information such as the unique interface identifier, the next step number of the call, the data consumer identifier, the result generation time, and the result status (success / failure). The log is sent to the "interface - call - logs" topic of the message queue cluster.

[0033] When the service gateway receives the result returned by the original provider, it generates a result reception log. The log contains information such as the unique identifier of the interface, the number of the next step to be called, the time when the result was received, and the size of the result, and is sent to the "interface - call - logs" topic of the message queue cluster.

[0034] Before encapsulating the result, generate an encapsulation start log to record the interface unique identifier, the number of the next step to be called, the encapsulation start time, and other information. After encapsulation is completed, generate an encapsulation completion log to record the interface unique identifier, the number of the next step to be called, the encapsulation completion time, the format of the encapsulated data, and other information. Before returning the result to the data user, generate a result return log to record the interface unique identifier, the number of the next step to be called, the data user identifier, the return time, and other information. Send the above three logs to the "interface - call - logs" topic of the message queue cluster in sequence.

[0035] After receiving the log messages of the above steps, the message queue cluster distributes these messages to the corresponding consumers (i.e., the log processing system) according to its own consumption mechanism. During the distribution process, the message queue cluster can record consumption logs, such as the consumption time and consumption status (success / failure) of each message. Consumption logs can be stored in the log storage structure inside the message queue cluster, or sent to a dedicated log storage system (such as Elasticsearch) for further analysis.

[0036] As a consumer of the message queue, the log processing system continuously listens to the "interface - call - logs" topic. When the log processing system receives a log message, it groups the logs belonging to the same interface call according to the interface unique identifier and call step number in the log. Sort the logs in each group by the call step number. Merge the sorted logs into a complete call log. For example, all log fields can be merged into a JSON object to form a log that fully records the entire interface call process.

[0037] Finally, the merged complete call log is stored in a database (such as MySQL, MongoDB, etc.) for subsequent query and audit.

[0038] In some embodiments, all service gateways registered in the resource management system need to follow a consistent service interface proxy specification to ensure that when a gateway fails, users can quickly and smoothly switch service gateways and continue service calls. The service call specification describes how to pass authorization and authentication information when the interface user uses the service interface. After receiving the call request, the service gateway should parse the authorization and authentication information in this format and perform verification. The service interface proxy specification includes: All service gateways must be registered in the resource management system. During the registration process, the service gateway needs to provide its own metadata to the resource management system; the resource management system assigns a unique identifier to each service gateway; After receiving the request, the service gateway checks the authorization authentication field in the request header, identifies and parses the type and specific token value of the authorization token; for the authorization authentication information contained in the request body, the service gateway should parse it according to the agreed format and extract the corresponding authorization token and API key information; The resource management system regularly monitors the running status of the service gateway and determines whether the gateway is faulty through the heartbeat mechanism and request response time indicators; the service gateway itself has a fault detection mechanism and reports to the resource management system in a timely manner when a fault occurs; When the resource management system detects a service gateway failure, it should immediately notify the interface user; after receiving the notification, the interface user should quickly switch the service call to the normal service gateway based on the new available gateway address provided by the resource management system; during the switching process, the service interface proxy specification should ensure that the transmission and verification method of the authorization and authentication information remains unchanged to achieve smooth switching.

[0039] In some embodiments, the multi-gateway unified authentication specification includes: The interface user initiates the application registration operation and submits a registration request to the resource management system. The resource management system forwards the registration request to the resource application and review system. The resource application and review system generates an interface identifier and applies for the interface to the unified authorization system, passing the AppKey, interface identifier and session identifier. The unified authorization system calls the interface to obtain the AppKey. After successful acquisition, the AppKey is returned to the resource application and review system. The resource application and review system sends the AppKey to the interface user. The interface user uses the AppKey to perform a signing operation, passing the timestamp, interface identifier and session identifier to obtain the signature. The interface user requests the unified authorization system to obtain the dynamic token appSecret. The unified authorization system generates appSecret and sends it to the interface user. The interface user uses appSecret to perform a signing operation, passing the interface identifier and session identifier to obtain a signature. The interface user initiates a request to the service gateway, passes the signature information, the service gateway verifies the signature, forwards the request to the interface provider, the interface provider responds to the request and returns the result to the service gateway, and finally the service gateway returns the result to the interface user.

[0040] It should be noted that the log processing system implements the service call audit and service call monitoring functions. By formulating a unified log recording specification, the service gateways of various manufacturers will record the service call logs in accordance with the specification when acting as service agents. The log collection component is used to collect the logs of multiple gateways in real time and put them into the message queue. The log processing system pulls the service call logs from the message queue cluster for cleaning and filtering; it also obtains service business information from the resource management system, associates and merges the service call logs to obtain the service call records, and uses big data analysis related technologies to implement multi-faceted statistical analysis of service calls.

[0041] The above description of the disclosed embodiments enables one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A multi-gateway fusion architecture system for data sharing, characterized in that: Includes resource management system, message queue cluster, log processing system and multiple service gateways; The interface user requests the resource management system for an available gateway address, and the resource management system returns the available gateway address to the interface user. The interface user initiates a service call to the corresponding service gateway based on the obtained gateway address. The service gateway processes the request and generates a log. The log is transmitted to the log processing system through the message queue cluster. The log processing system cleans, filters and merges the received logs. At the same time, the resource management system is responsible for managing and monitoring the status of the service gateway. The architecture system sets unified authentication specifications for multiple gateways and service interface proxy specifications; All service gateways registered in the resource management system follow consistent service interface proxy specifications; The multi-gateway unified authentication specification is a process specification for the service gateway to verify the identity and authority of the caller when the interface user initiates a service call to the service gateway.

2. The multi-gateway converged architecture system for data sharing according to claim 1, characterized in that: The data provider registers the data interface in the resource management system and defines the interface call specifications and requirements during registration. The data manager conducts a preliminary interface call test in the resource management system. After the test is passed, it is published in the resource management system. After a successful release, the resource management system sends interface metadata information to each service gateway.

3. The multi-gateway converged architecture system for data sharing according to claim 2, characterized in that: The resource management system is responsible for receiving interface metadata registration requests from various service gateways. The metadata may include the interface name, function description, parameter type, and calling method. For each registered interface metadata, the resource management system assigns a unique identifier and classifies and stores the registered interface metadata. The resource management system generates service metadata information based on the registered and stored interface metadata; At the same time, the resource management system also generates authorization subscription information and dynamic access tokens. The authorization subscription information is used to determine the service gateway's access rights to a specific interface, and the dynamic access token is used for the service gateway's identity authentication when calling the interface. The resource management system sends the generated service metadata information, authorization subscription information and dynamic access token to each service gateway.

4. The multi-gateway converged architecture system for data sharing according to claim 3, characterized in that: The resource management system defines permissions for each interface. According to the role and function of the service gateway, the resource management system allocates the corresponding interface permissions to each service gateway, encodes the allocated permission information, and forms authorized subscription information.

5. The multi-gateway converged architecture system for data sharing according to claim 4, characterized in that: The interface user searches for the required interface information in the resource management system and submits an application for interface use. The data manager and data provider review and approve the application in the interface management system in turn. After the review is passed, the resource management system generates a key for the interface call and sends the available gateway address and call key to the interface user. At the same time, the resource management system also sends the application authorization information and key to the service gateway.

6. The multi-gateway converged architecture system for data sharing according to claim 5, characterized in that: After receiving the usable gateway address and interface call key, the interface user initiates an interface call request to the service gateway. The service gateway verifies the caller's identity and call key in turn. After the verification, the route forwarding interface is sent to the original interface of the data provider. The original interface returns the result to the service gateway, and the service gateway returns the result to the data user.

7. The multi-gateway converged architecture system for data sharing according to claim 6, characterized in that: The data call logs generated by the process of the data user initiating an interface call, the service gateway receiving the interface call request and verifying the request, the gateway routing and forwarding the request to the original provider of the interface after verification, the original provider feeding back the result to the service gateway, and the gateway encapsulating the result and returning it to the data user are stored in the message queue cluster in real time to generate consumption logs, which are sent to the log processing system and consumed by the log processing system in a timely manner. The log processing system merges the logs based on the interface unique identifier and the call step number to finally form a complete call log.

8. The multi-gateway converged architecture system for data sharing according to claim 7, characterized in that: The service interface proxy specification includes: All service gateways must be registered in the resource management system. During the registration process, the service gateway needs to provide its own metadata to the resource management system; the resource management system assigns a unique identifier to each service gateway; After receiving the request, the service gateway checks the authorization authentication field in the request header, identifies and parses the type of authorization token and the specific token value; for the authorization authentication information contained in the request body, the service gateway should parse it according to the agreed format and extract the corresponding authorization token and API key information.

9. The multi-gateway converged architecture system for data sharing according to claim 8, characterized in that: The service interface proxy specification also includes: The resource management system regularly monitors the running status of the service gateway and determines whether the gateway is faulty through the heartbeat mechanism and request response time indicators; the service gateway itself has a fault detection mechanism and reports to the resource management system in a timely manner when a fault occurs; When the resource management system detects a service gateway failure, it should immediately notify the interface user; after receiving the notification, the interface user should quickly switch the service call to the normal service gateway based on the new available gateway address provided by the resource management system; during the switching process, the service interface proxy specification should ensure that the transmission and verification method of the authorization and authentication information remains unchanged to achieve smooth switching.

10. The multi-gateway converged architecture system for data sharing according to claim 8, characterized in that: The unified authentication specifications for multiple gateways include: The interface user initiates the application registration operation and submits a registration request to the resource management system. The resource management system forwards the registration request to the resource application and review system. The resource application and review system generates an interface identifier and applies for the interface to the unified authorization system, passing the AppKey, interface identifier and session identifier. The unified authorization system calls the interface to obtain the AppKey. After successful acquisition, the AppKey is returned to the resource application and review system. The resource application and review system sends the AppKey to the interface user. The interface user uses the AppKey to perform a signing operation, passing the timestamp, interface identifier and session identifier to obtain the signature. The interface user requests the unified authorization system to obtain the dynamic token appSecret. The unified authorization system generates appSecret and sends it to the interface user. The interface user uses appSecret to perform a signing operation, passing the interface identifier and session identifier to obtain a signature. The interface user initiates a request to the service gateway, passes the signature information, the service gateway verifies the signature, forwards the request to the interface provider, the interface provider responds to the request and returns the result to the service gateway, and finally the service gateway returns the result to the interface user.

Images