CN115134398A - Method and system for realizing universal RPC gateway - Google Patents
Method and system for realizing universal RPC gateway Download PDFInfo
- Publication number
- CN115134398A CN115134398A CN202211059329.6A CN202211059329A CN115134398A CN 115134398 A CN115134398 A CN 115134398A CN 202211059329 A CN202211059329 A CN 202211059329A CN 115134398 A CN115134398 A CN 115134398A
- Authority
- CN
- China
- Prior art keywords
- metadata
- rpc
- gateway
- service
- request information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/14—Routing performance; Theoretical aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
The application discloses a method and a system for realizing a universal RPC gateway, which mainly relate to the technical field of gateway realization and are used for solving the problems that the http request of the existing front-end page and the communication configuration of the rear-end rcp service are complex, the function is single, the application level can not be used as a unit for management and use, and the like. The method comprises the following steps: collecting RPC basic metadata and pushing the RPC basic metadata to a metadata center, and automatically creating a routing configuration corresponding to application data by a gateway based on the application data in the RPC basic metadata; according to the POST request information, further determining basic metadata corresponding to the POST request information; acquiring a service address corresponding to the basic metadata, and further generalizing and calling an interface method corresponding to the client and the service address; and after the interface method is called, acquiring a return result of the client through the gateway, and sending the return result to the front end. By the method, the routing configuration of the application level is automatically acquired, the extended metadata is conveniently configured, and the flexibility and convenience of configuration are improved.
Description
Technical Field
The application relates to the technical field of gateway implementation, in particular to a method and a system for implementing a universal RPC gateway.
Background
With the development of services, micro-services are selected to replace the original monomer architecture. RPC is preferred for inter-service calls due to its high performance. Under a front-end and back-end separation scene, the problem of communication between an http request of a front-end page and a back-end rcp service needs to be considered.
At present, the method for solving the problem of communication between the http request of the front-end page and the rcp service of the back-end mainly comprises the following steps: (1) adding a controller service between the front-end page and the RPC back-end service, and transferring the http request to an RPC interface; (2) adding a gateway layer between a front-end page and RPC rear-end service, and using RPC to generally call a transfer http request to an RCP interface; (3) and a gateway layer is added between the front-end page and the RPC back-end service, RPC is used for generalization call to transfer an http request to the RCP interface, and the PC interface configuration is obtained from service discovery, so that the routing configuration is reduced.
However, the above method needs to manually define the routing relationship between each back-end service RPC interface and the http interface, is complex in configuration and single in function, cannot be used in a scene without service discovery, and can only use the interface as a unit, and cannot be managed and used by using the application level as a unit.
Disclosure of Invention
Aiming at the defects in the prior art, the invention provides a method and a system for realizing a universal RPC gateway, so as to solve the technical problems.
In a first aspect, the present application provides a method for implementing a generic RPC gateway, the method comprising: collecting micro-service RPC basic metadata through a service SDK, pushing the micro-service RPC basic metadata to a metadata center, and calling a metadata center interface through a gateway to acquire/synchronize the RPC basic metadata; based on application data in RPC basic metadata, automatically creating routing configuration corresponding to the application data; after receiving POST request information uploaded by a front end, a gateway determines routing configuration according to the POST request information, and further determines basic metadata corresponding to the POST request information; calling service discovery or presetting extension configuration through a gateway to obtain a service address corresponding to basic metadata, and further generalizing and calling an interface method corresponding to a client and the service address; and after the interface method is called, acquiring a return result of the client through the gateway, and processing the return result so as to send the processed return result to the front end.
Further, collecting the micro service RPC basic metadata through the service SDK and pushing the metadata to the metadata center, specifically comprising: scanning a preset service code corresponding to the micro-service through the service SDK, acquiring a method defined in a unified preset RPC frame interface, analyzing to obtain basic metadata, and pushing the basic metadata to a metadata center through a preset metadata pushing interface.
Further, the method further comprises: acquiring manually configured routing configuration through a preset configuration data management interface; wherein the manually configured routing configuration overrides the automatically created routing configuration.
Further, before determining the routing configuration according to the POST request information, the method further comprises: carrying out black and white list verification and authentication verification on the POST request information in sequence according to the preset extended metadata so as to complete the verification of the POST request information; and carrying out context configuration parameters on the POST request information through a preset extension element number.
Further, the preset extension metadata is divided into route extension metadata and center extension metadata; the method further comprises the following steps: configuring routing extension metadata in routing configuration through a preset configuration file; modifying/newly adding center extended metadata through a preset metadata center management page; wherein the route extension metadata takes precedence over the central extension metadata.
Further, the basic metadata comprises protocol information, version information and interface paths; determining routing configuration according to the POST request information, and further determining basic metadata corresponding to the POST request information, wherein the method specifically comprises the following steps: determining routing configuration according to a routing name defined in POST request information; and determining basic metadata corresponding to the POST request information through routing configuration and protocol information, version information and path suffixes defined in the POST request information.
Further, processing the returned result to send the processed returned result to the front end, specifically including: performing field name conversion/filtering/adding on the returned result by an analysis method defined in the preset extended metadata; packaging the analyzed return result by a packaging method defined in the preset extended metadata; and carrying out serialization processing on the packaged return result by a preset serialization processing method.
In a second aspect, the present application provides a system for implementing a generic RPC gateway, the system comprising: the system comprises a creating module, a service SDK module and a metadata center, wherein the creating module is used for collecting micro-service RPC basic metadata through the service SDK and pushing the micro-service RPC basic metadata to the metadata center, and calling a metadata center interface through a gateway to acquire/synchronize the RPC basic metadata; based on application data in RPC basic metadata, automatically creating routing configuration corresponding to the application data; the determining module is used for determining routing configuration according to the POST request information after the gateway receives the POST request information uploaded by the front end, and further determining basic metadata corresponding to the POST request information; the calling module is used for calling service discovery or presetting extension configuration through the gateway, acquiring a service address corresponding to the basic metadata, and further generalizing and calling the client and an interface method corresponding to the service address; and the return module is used for acquiring the return result of the client through the gateway after the interface method is called, processing the return result and sending the processed return result to the front end.
As can be appreciated by those skilled in the art, the present invention has at least the following beneficial effects:
the method acquires the basic metadata through a unified and preset RPC frame interface. Because the RPC frame interface can be compatible with various programming languages, the service SDK compatible with various frames is realized, and the method can be used in a multi-frame scene.
The gateway is used for transferring the front-end http request to the RPC method under the scene of front-end and back-end separation, and a redundant controller intermediate layer is not needed; the gateway can automatically sense RPC service metadata (basic metadata) through a metadata center, application-level route configuration is provided by default, and route configuration workload is greatly reduced.
And the invention provides various enhanced functions by the configuration of the extended metadata, and the user can conveniently configure the extended metadata through the interface and the route configuration, thereby improving the flexibility and the convenience of the configuration.
Drawings
Some embodiments of the disclosure are described below with reference to the accompanying drawings, in which:
fig. 1 is a flowchart of a method for implementing a generic RPC gateway according to an embodiment of the present application.
Fig. 2 is a schematic diagram of an internal structure of a system for implementing a generic RPC gateway according to an embodiment of the present application.
Detailed Description
It should be understood by those skilled in the art that the embodiments described below are only preferred embodiments of the present disclosure, and do not mean that the present disclosure can be implemented only by the preferred embodiments, which are merely intended to explain the technical principles of the present disclosure and not to limit the scope of the present disclosure. All other embodiments that can be derived by one of ordinary skill in the art from the preferred embodiments provided by the disclosure without undue experimentation will still fall within the scope of the disclosure.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.
The technical solutions proposed in the embodiments of the present application are described in detail below with reference to the accompanying drawings.
The embodiment of the present application further provides a method for implementing a generic RPC gateway, and as shown in fig. 1, the method provided in the embodiment of the present application mainly includes the following steps:
step 110, collecting and pushing micro-service RPC basic metadata to a metadata center through a service SDK, and calling a metadata center interface through a gateway to acquire/synchronize RPC basic metadata; and automatically creating the routing configuration corresponding to the application data based on the application data in the RPC basic metadata.
It should be noted that the RPC base metadata includes: RPC framework type, application name, interface path, method name, method parameter information, protocol type, version, enable flag, etc.
The "collection of the micro-service RPC basic metadata by the service SDK and pushing to the metadata center" may specifically be: scanning a preset service code corresponding to the micro-service through the service SDK, acquiring a method defined in a unified preset RPC frame interface, analyzing to obtain basic metadata, and pushing the basic metadata to a metadata center through a preset metadata pushing interface. Typically, the base metadata will be pushed after the RPC service boot is complete.
The "calling the metadata center interface through the gateway to obtain/synchronize RPC basic metadata" may specifically be: after the gateway is started, the gateway calls the metadata center interface to obtain the RPC basic metadata, and starts a timing task to regularly pull the latest basic metadata for synchronization, generally, the RPC basic metadata does not frequently change under the test and production environments, so that the timing synchronization time interval can be set to be longer, for example, 1 hour.
The "application data" in the "routing configuration corresponding to the application data is automatically created based on the application data in the RPC base metadata" may be an application name. Those skilled in the art will appreciate that by providing application level routing configuration by default based on the application data in the RPC base metadata, the routing configuration effort can be greatly reduced. The specific method for creating the routing configuration may be implemented by an existing method, and the present application is not limited to this.
And step 120, after receiving the POST request information uploaded by the front end, the gateway determines the routing configuration according to the POST request information, and further determines the basic metadata corresponding to the POST request information.
It should be noted that the routing configuration is divided into an application-level routing configuration and an interface-level routing configuration. The condition/method for creating the application-level routing configuration is detailed in step 110, and the condition/method for creating the interface-level routing configuration is an existing method, which is not limited herein. Since there is a case where one routing configuration corresponds to a plurality of basic metadata (for example, a plurality of basic metadata correspond to a routing configuration of the same application level), after the routing configuration is determined, the basic metadata needs to be defined again according to POST request information.
The step may specifically be: determining routing configuration according to the routing name defined in the POST request information; and after the POST request information is successfully matched with the routing configuration, determining the basic metadata corresponding to the POST request information through the routing configuration and the protocol information, the version information and the path suffix defined in the POST request information. Specifically, by: and searching the basic metadata which accords with the rule by the protocol + the application name/the interface name + the path suffix of the http request + the RPC interface version information. And when the version information is a null value, the first matched version is used by default.
In addition, the method for acquiring the route configuration is not limited to automatic generation. Generally, the gateway creates a default application-level routing configuration for all acquired applications after acquiring basic metadata from the metadata center, does not need to additionally configure routing information manually, supports manual configuration at the same time, and acquires the manually configured routing configuration (including an application level and an interface level) through a preset configuration data management interface, that is, the application can simultaneously support manually configured application-level and interface-level routing configurations, and the manually configured routing is prior to the default configuration.
In addition, before the routing configuration is determined according to the POST request information, the POST application information can be checked and context configuration can be carried out. The specific process can be as follows: carrying out black and white list verification and authentication verification on the POST request information in sequence according to the preset extended metadata so as to complete the verification of the POST request information; and carrying out context configuration parameters on the POST request information through a preset extension element number.
It should be noted that the preset extension metadata is an extension to the basic metadata, and includes (including but not limited to): the application level metadata acts on all interface methods of a certain application, and comprises the following steps: black and white lists, authentication check types, custom request return data structures, RPC context information configuration, application addresses (URLs, used when no service is found, obtainable with the underlying metadata via SDK). Interface level metadata, applied to all methods of the interface (of a certain class in the java implementation), comprising: black and white list, authentication check type, user-defined request return data structure, and RPC context information configuration. Method level metadata, applied to a single interface method, comprising: black and white lists, authentication check types, custom request return data structures, RPC context information configuration, field name conversion/filtering/addition. The same type of configuration, namely black and white list, authentication check type, self-defined request return data structure, and the configuration priority is application level < interface level < method level.
The preset extension metadata may be preset by a person skilled in the art, or preset extension metadata at an application/interface level may be configured in the routing configuration through a preset configuration file (based on an acquisition manner, also referred to as routing extension metadata), where the preset configuration file includes the routing extension metadata, and the person skilled in the art may determine specific contents in the preset configuration file according to actual requirements; the preset extended metadata (based on an acquisition mode, also called as central extended metadata) can be modified/newly added through a preset metadata center management page, and the method meets the requirement of a user on flexibility. Further, the route extension metadata takes precedence over the central extension metadata.
Step 130, calling service discovery or presetting extension configuration through the gateway to obtain a service address corresponding to the basic metadata, and further generalizing and calling an interface method corresponding to the client and the service address.
The interface method corresponding to the client and the service address is further generalized and called, and may specifically be: and generalizing and calling the client according to a preset type frame and/or a specified frame constructed according to the basic metadata, and calling the interface method.
And step 140, after the interface method is called, acquiring a return result of the client through the gateway, and processing the return result to send the processed return result to the front end.
It should be noted that, processing the return result to send the processed return result to the front end may specifically be: performing field name conversion/filtering/adding on the returned result by an analysis method defined in the preset extended metadata; packaging the analyzed return result by a packaging method defined in the preset extended metadata; and carrying out serialization processing on the packaged return result by a preset serialization processing method. The parsing method, the packing method and the predetermined serialization processing method may be implemented by existing methods or technologies, and the present application is not limited herein.
Based on the above description, those skilled in the art can understand that the present application provides SDKs of multiple frameworks and multiple programming languages by defining a unified metadata interface, which is suitable for scenarios of multiple frameworks and multiple programming languages. By actively collecting the micro-service RPC basic metadata by using the SDK, the gateway automatically senses and synchronizes the RPC basic metadata at regular time, application-level routing configuration is defaulted, and routing configuration work is greatly reduced. The method has the advantages that the metadata center management page is provided for expanding RPC basic metadata, various enhancement functions are provided, the routing level expansion metadata configuration is supported, and the flexibility and the convenience of configuration are improved.
In addition, fig. 2 is a general RPC gateway implementation system according to an embodiment of the present disclosure. As shown in fig. 2, the system provided in the embodiment of the present application mainly includes:
the creation module 210 is configured to collect micro-service RPC basic metadata through the service SDK, push the micro-service RPC basic metadata to the metadata center, and call a metadata center interface through the gateway to obtain/synchronize RPC basic metadata; based on application data in RPC basic metadata, automatically creating a route configuration corresponding to the application data;
the determining module 220 is configured to determine, according to POST request information, routing configuration after the gateway receives POST request information uploaded by the front end, and further determine basic metadata corresponding to the POST request information;
a calling module 230, configured to call service discovery or preset extension configuration through a gateway, obtain a service address corresponding to the basic metadata, and further generalize an interface method corresponding to the client and the service address;
and the returning module 240 is configured to, after the interface method is called, obtain a return result of the client through the gateway, process the return result, and send the processed return result to the front end.
So far, the technical solutions of the present disclosure have been described in connection with the foregoing embodiments, but it is easily understood by those skilled in the art that the scope of the present disclosure is not limited to only these specific embodiments. The technical solutions in the above embodiments can be split and combined, and equivalent changes or substitutions can be made on related technical features by those skilled in the art without departing from the technical principles of the present disclosure, and any changes, equivalents, improvements, and the like made within the technical concept and/or technical principles of the present disclosure will fall within the protection scope of the present disclosure.
Claims (8)
1. A method for realizing a universal RPC gateway is characterized by comprising the following steps:
collecting micro-service RPC basic metadata through a service SDK, pushing the micro-service RPC basic metadata to a metadata center, and calling a metadata center interface through a gateway to acquire/synchronize the RPC basic metadata; based on application data in RPC basic metadata, automatically creating a routing configuration corresponding to the application data;
after receiving POST request information uploaded by a front end, a gateway determines routing configuration according to the POST request information, and further determines basic metadata corresponding to the POST request information;
calling service discovery or preset expansion configuration through a gateway to obtain a service address corresponding to the basic metadata, and further generalizing and calling an interface method corresponding to a client and the service address;
and after the interface method is called, acquiring a return result of the client through the gateway, and processing the return result so as to send the processed return result to the front end.
2. The method of claim 1, wherein the collection of the micro-service RPC base metadata by the SDK and the pushing to the metadata center comprises:
scanning a preset service code corresponding to the micro service through the service SDK, acquiring a method defined in a unified preset RPC frame interface, analyzing to obtain basic metadata, and pushing the basic metadata to a metadata center through a preset metadata pushing interface.
3. The method of claim 1, further comprising:
acquiring manually configured routing configuration through a preset configuration data management interface; wherein the manually configured routing configuration overrides the automatically created routing configuration.
4. The method of claim 1, wherein prior to determining a routing configuration based on the POST request message, the method further comprises:
carrying out black and white list verification and authentication verification on the POST request information in sequence according to the preset extended metadata so as to complete the verification of the POST request information;
and carrying out context configuration parameters on the POST request information through a preset extension element number.
5. The method of claim 4, wherein the pre-set extension metadata is divided into routing extension metadata and center extension metadata;
the method further comprises the following steps:
configuring routing extension metadata in routing configuration through a preset configuration file;
modifying/newly adding center extended metadata through a preset metadata center management page; wherein the route extension metadata takes precedence over the hub extension metadata.
6. The method of claim 1, wherein the base metadata includes protocol information, version information, and interface path;
determining routing configuration according to the POST request information, and further determining basic metadata corresponding to the POST request information, wherein the method specifically comprises the following steps:
determining routing configuration according to the routing name defined in the POST request information;
and determining basic metadata corresponding to the POST request information through routing configuration and protocol information, version information and path suffixes defined in the POST request information.
7. The method for implementing a generic RPC gateway as claimed in claim 1, wherein the processing of the returned result to send the processed returned result to the front end includes:
performing field name conversion/filtering/adding on the returned result by an analysis method defined in the preset extended metadata;
packaging the analyzed return result by a packaging method defined in the preset extended metadata;
and carrying out serialization processing on the packaged return result by a preset serialization processing method.
8. A generic RPC gateway implementation system, the system comprising:
the creation module is used for collecting and pushing micro-service RPC basic metadata to a metadata center through a service SDK (software development kit), and calling a metadata center interface through a gateway to acquire/synchronize RPC basic metadata; based on application data in RPC basic metadata, automatically creating a routing configuration corresponding to the application data;
the determining module is used for determining routing configuration according to POST request information after the gateway receives the POST request information uploaded by the front end, and further determining basic metadata corresponding to the POST request information;
the calling module is used for calling service discovery or presetting extension configuration through the gateway, acquiring a service address corresponding to the basic metadata, and further generalizing and calling an interface method corresponding to the client and the service address;
and the return module is used for acquiring the return result of the client through the gateway after the interface method is called, processing the return result and sending the processed return result to the front end.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211059329.6A CN115134398A (en) | 2022-08-30 | 2022-08-30 | Method and system for realizing universal RPC gateway |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211059329.6A CN115134398A (en) | 2022-08-30 | 2022-08-30 | Method and system for realizing universal RPC gateway |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115134398A true CN115134398A (en) | 2022-09-30 |
Family
ID=83387959
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211059329.6A Pending CN115134398A (en) | 2022-08-30 | 2022-08-30 | Method and system for realizing universal RPC gateway |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115134398A (en) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110191164A (en) * | 2019-05-20 | 2019-08-30 | 中国工商银行股份有限公司 | Distributed Services access system and method |
| CN112350873A (en) * | 2020-11-25 | 2021-02-09 | 中国工商银行股份有限公司 | Application service information processing method, application service calling method, device and system |
| CN113438317A (en) * | 2021-07-08 | 2021-09-24 | 数字广东网络建设有限公司 | Gateway data processing method and device |
| CN113572689A (en) * | 2021-09-24 | 2021-10-29 | 深圳市信润富联数字科技有限公司 | Microservice gateway management method, system, device, readable storage medium and product |
| US20220083407A1 (en) * | 2020-09-16 | 2022-03-17 | Zscaler, Inc. | Selectively exposing Application Programming Interfaces dynamically for microservices |
-
2022
- 2022-08-30 CN CN202211059329.6A patent/CN115134398A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110191164A (en) * | 2019-05-20 | 2019-08-30 | 中国工商银行股份有限公司 | Distributed Services access system and method |
| US20220083407A1 (en) * | 2020-09-16 | 2022-03-17 | Zscaler, Inc. | Selectively exposing Application Programming Interfaces dynamically for microservices |
| CN112350873A (en) * | 2020-11-25 | 2021-02-09 | 中国工商银行股份有限公司 | Application service information processing method, application service calling method, device and system |
| CN113438317A (en) * | 2021-07-08 | 2021-09-24 | 数字广东网络建设有限公司 | Gateway data processing method and device |
| CN113572689A (en) * | 2021-09-24 | 2021-10-29 | 深圳市信润富联数字科技有限公司 | Microservice gateway management method, system, device, readable storage medium and product |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109618005B (en) | Method for calling server and proxy server | |
| CN109889551B (en) | Method for accessing intelligent hardware to Internet of things cloud platform | |
| EP3399715B1 (en) | Protocol conversion method, platform, and protocol conversion gateway | |
| CN110990047B (en) | Fusion method and device for multiple microservice architectures | |
| CN112035317B (en) | Micro-service link monitoring method, device, equipment and medium | |
| US8139509B2 (en) | Installation and management of mobile device [{S]} configuration | |
| CN111078504A (en) | Distributed call chain tracking method and device, computer equipment and storage medium | |
| CN113572689A (en) | Microservice gateway management method, system, device, readable storage medium and product | |
| US8769101B2 (en) | Method, apparatus and system for processing composite service and replacing service and invoking service | |
| US8326913B2 (en) | Method and system for service contract discovery | |
| EP3974960A1 (en) | Method and system for automated testing of web service apis | |
| CN112231120A (en) | Service access method and device | |
| CN114756306A (en) | Service calling method, device, equipment and storage medium | |
| CN111414261B (en) | Cross-network calling method and device of distributed system and related components | |
| CN100405760C (en) | Method and system for providing web services from a service environment with a gateway | |
| CN109600381B (en) | Interface adaptation method, device and system | |
| CN113014621B (en) | In-vehicle communication system and method based on HTTP (hyper text transport protocol) | |
| CN112104640B (en) | Data processing method, device and equipment of gateway and readable storage medium | |
| CN102571688A (en) | Device, system and method for synchronizing browser bookmark | |
| CN115134398A (en) | Method and system for realizing universal RPC gateway | |
| CN109672732B (en) | Interface adaptation method, device and system | |
| CN111787097A (en) | Interface message conversion configuration method, interface message conversion method and equipment | |
| CN116647552A (en) | Service processing method and system in heterogeneous micro-service cluster, terminal and storage medium | |
| CN108052380B (en) | Business function docking method and device, computer equipment and storage medium | |
| CN107846300B (en) | Method and device for providing service interface |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20220930 |
|
| RJ01 | Rejection of invention patent application after publication |