Method for enabling API gateway to adapt to multiple protocols and message formats

Abstract

The invention discloses a method for enabling an API gateway to adapt to multiple protocols and message formats, and the method comprises the steps: creating a maven engineering project, and generating an interface Java Bean according to a configured interface csv file; issuing an interface, and generating an interface jar packet; the API gateway adds channel configuration parameters; micro-service application codes are written; packaging the micro-service application, and starting the micro-service application; aPI gateway routing configuration information is added; and the Java Bean packet and the ai-gateway-ce-bridge packet are copied to an external packet path of a server where the gateway is located. According to the gateway-to-micro-service communication method and system, multi-network communication protocols such as HTTP, TCP, RabbitMQ and Webspphere MQ are supported, multiple message formats such as a fixed-length format, a variable-length format, an XML format, a JSON format and a 8583 format are supported, and only a fixed transmission protocol and a fixed message format need to be adopted from the gateway to the micro-service, so that developers do not need to consider that the micro-service is compatible with the multiple message formats.

Description

Technical Field

[0001] The present invention belongs to the field of communication technology, and specifically is a method for an API gateway to adapt to multiple protocols and message formats. Background Art

[0002] With the popularization and development of mobile Internet, more and more enterprises have begun to transform to the Internet and migrate their services and businesses to online platforms. As the number of customers continues to increase, the architecture of these online businesses is also constantly evolving and changing. From the initial monolithic application architecture, it has gradually transitioned to a more flexible microservice architecture. At the same time, cluster and distributed technologies have also become standard in technical practice.

[0003] When building the basic platform of microservice architecture, API Gateway is an indispensable core component. It provides a unified interface for a group of microservices, so that the client does not need to know all the details of the microservices. However, many application projects face the parallel system of old and new architectures (monolithic architecture and microservice architecture coexist) due to various reasons such as overly complex business and excessive workload of comprehensive reconstruction. When facing these heterogeneous systems, Spring Cloud Gateway, which originally only supports HTTP protocol JSON format messages for unified interface calls, becomes less applicable.

[0004] To solve this problem, most systems usually bypass the API gateway and deploy a service specifically responsible for connecting to other heterogeneous systems, namely the protocol / message conversion server in the above figure. Although this processing method can achieve connection with heterogeneous systems, it also brings other problems. For example, it increases the complexity of the system architecture, resulting in overly complex transaction links; it is impossible to uniformly govern services, resulting in the need to repeatedly develop similar functions in the system, such as load balancing, current limiting, etc.

[0005] Spring Cloud Gateway natively only provides HTTP protocol access, and does not natively support access to requests for non-HTTP protocols. To solve the problem of non-HTTP protocol access, most systems now usually bypass the API gateway and deploy a service specifically responsible for connecting to other heterogeneous systems. This approach has the following disadvantages:

[0006] 1. The call link increases. Since a service is deployed before the API gateway to handle protocol conversion and message conversion, for the microservice architecture, it undoubtedly increases the transaction link and makes the system more complex.

[0007] 2. Increased consumption of server resources. Since a service is added before the API gateway, deploying the service requires additional application of new server resources, which will increase the hardware resource cost of the project.

[0008] 3. The access methods provided to the outside are not unified. For non-HTTP protocol requests, protocol conversion services are required, while for HTTP protocol requests, API gateway services are directly used, and the docking methods are also not unified.

[0009] 4. Service control and governance issues: The protocol conversion service does not have the API gateway current limiting and circuit breaking functions. If there is a malicious attack, it may directly cause the protocol conversion service to crash. Summary of the invention

[0010] In view of the above problems, the present invention is proposed to provide a method for an API gateway to adapt to multiple protocols and message formats, which overcomes the above problems or at least partially solves the above problems.

[0011] To achieve the above object, the present invention adopts the following technical solutions:

[0012] A method for adapting an API gateway to multiple protocols and message formats, the method comprising:

[0013] Create a Maven project and generate an interface Java Bean based on the configured interface csv file;

[0014] Publish the interface and generate the interface jar package;

[0015] API Gateway adds channel configuration parameters;

[0016] Write microservice application code;

[0017] Package the microservice application and start the microservice application;

[0018] Add API gateway routing configuration information;

[0019] Copy the Java Bean package and api-gateway-ce-bridge package to the external package path of the server where the gateway is located.

[0020] Optionally, the method includes starting an API gateway and sending a non-http request message to a channel listening port configured in a yml configuration file of the API gateway to verify whether the transaction is successfully routed to the application microservice.

[0021] Optionally, use the development tool IntelliJ IDEA to install the interface management tool beanMaker plug-in, and use the beanMaker plug-in to generate an interface Java Bean based on the configured interface csv file.

[0022] Optionally, an interface jar package is generated through a beanMaker plug-in, and the jar package contains the parameter type, length, and name of the interface input and output parameters that require message conversion.

[0023] Optionally, the channel configuration parameters include channel name, listening port, message format, encoding and number of threads.

[0024] Optionally, the interface Java Bean is used to define the transaction interface message format, message length, and message type.

[0025] Optionally, api-gateway-ce-bridge is the API gateway bridging module, which introduces a communication engine into the API gateway, adds a bridging module, receives TCP, RabbitMQ, and WebsphereMQ protocol requests from client applications, parses the request data and converts it into a context object that complies with the API gateway interface specification, and calls up the HTTP processor, thereby completing the entire process from protocol entry to HTTP exit adapted by the communication engine.

[0026] Optionally, the communication engine adds a TCP2HTTP endpoint adapter class, an APIGATEWAY adapter interface and an adapter context class. The TCP2HTTP endpoint adapter class bridges the URL routing mechanism of the API gateway through the APIGATEWAY adapter interface, and the adapter context encapsulates the TCP channel and message conversion interface.

[0027] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0028] 1. The API gateway of the present invention supports multiple protocols within the process. The API gateway loads a bridge adapter to enable communication to support multiple network communication protocols such as HTTP, TCP (short connection and asynchronous long connection), RabbitMQ, WebsphereMQ, etc., so that application developers do not have to consider too much about the differences in the various protocols that do not communicate between different systems. At the same time, because it is within the process, the call links between microservices are greatly reduced.

[0029] 2. The API gateway of the present invention supports multiple messages within the process. The API gateway loads a bridge adapter to enable communication to support multiple message formats including fixed-length format, variable-length format, XML format, JSON format, 8583 format, etc. The gateway to the microservice only needs to use a fixed message format, so that developers do not need to consider the problem of microservice compatibility with multiple message formats.

[0030] 3. The present invention is extensible and has protocol extension points, which is convenient for subsequent expansion or functional enhancement of the API gateway and for meeting the requirements of different protocols between different application systems. The present invention supports componentization, and the API gateway bridge adapter is a separate component. There is no strong coupling between the components, and application developers can freely customize the required gateway bridge adapter components in the configuration. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 A flowchart of a method for adapting an API gateway to multiple protocols and message formats provided in an embodiment of the present application;

[0032] Figure 2 A schematic diagram of the connection relationship between the various parts of the API gateway provided in the embodiment of the present application. DETAILED DESCRIPTION

[0033] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0034] See also Figure 1 This embodiment provides a method for an API gateway to adapt to multiple protocols and message formats, the method comprising the following steps:

[0035] S1. Create a Maven project and generate an interface Java Bean based on the configured interface csv file.

[0036] Use the development tool IntelliJ IDEA to install the interface management tool beanMaker plug-in, and use the beanMaker plug-in to generate an interface Java Bean based on the configured interface csv file.

[0037] The interface Java Bean is used to define the transaction interface message format, message length and message type.

[0038] S2. Publish the interface and generate the interface jar package.

[0039] Generate an interface jar package through the beanMaker plug-in. The jar package contains the parameter type, length and name of the interface input and output parameters that need to be converted into messages. The unpacking and assembly during subsequent transaction forwarding are all dependent on this jar package.

[0040] S3, API Gateway adds channel configuration parameters.

[0041] The channel configuration parameters include information such as channel name, listening port, message format, encoding and number of threads.

[0042] S4. Write microservice application code.

[0043] Write microservice application code. Since the gateway does not use HTTP protocol to access transactions, the path of @serviceMapping in the service is configured as "system name / transaction code". The system name here is consistent with the systemName parameter configuration of the corresponding channel under loongeasy.comm-engine.server in the API gateway yml configuration file in the figure above.

[0044] S5. Package the microservice application and start the microservice application.

[0045] S6. Add API gateway routing configuration information to ensure that the gateway can correctly route transactions to microservice applications based on path matching when forwarding transactions.

[0046] S7. Copy the Java Bean package and the api-gateway-ce-bridge package to the external package path of the server where the gateway is located.

[0047] api-gateway-ce-bridge is the API gateway bridging module. It introduces a communication engine into the API gateway, adds a bridging module, receives TCP, RabbitMQ, and WebsphereMQ protocol requests from client applications, parses the request data and converts it into a context object that complies with the API gateway interface specification, and calls up the HTTP processor, thereby completing the entire process from protocol entry to HTTP exit adapted by the communication engine.

[0048] The communication engine adds a TCP2HTTP endpoint adapter class, an APIGATEWAY adapter interface and an adapter context class. The TCP2HTTP endpoint adapter class bridges the URL routing mechanism of the API gateway through the APIGATEWAY adapter interface, and the adapter context encapsulates the TCP channel and the message conversion interface.

[0049] S8. Start the API gateway and send a non-http request message to the channel listening port configured in the API gateway yml configuration file to verify whether the transaction is successfully routed to the application microservice.

[0050] like Figure 2As shown, the API gateway adds a bridge adapter to support access to protocols such as TCP (short connection and asynchronous long connection), RabbitMQ, WebsphereMQ, and fixed-length, variable-length, XML, JSON, 8583, and other message formats. It converts TCP (short connection and asynchronous long connection), RabbitMQ, and WebsphereMQ interface data into JSON format (only JSON conversion is supported, otherwise the interface and implementation will be much more complicated), and forwards it to the backend microservice application via HTTP, while sharing the routing and filtering rules of the original API gateway.

[0051] This method reduces the number of server nodes such as inter-process communication and load balancing devices, and completes a series of operations such as TCP (short connection and asynchronous long connection), RabbitMQ, WebsphereMQ and other protocol access and data conversion, background service routing, response result writing back, etc. in a single process. It can be expanded by loading external packages and can be plugged in and out.

[0052] The API gateway is decoupled from the multi-protocol bridge adapter, which is implemented by loading the external jar package when the service is started. In other words, it can be loaded on demand. If the multi-protocol multi-message conversion function is used in the application, the multi-protocol bridge adapter will be loaded when the service is started. If the protocol message conversion function is not involved, it does not need to be loaded.

[0053] The API gateway of this embodiment supports multiple protocols within the process. The API gateway loads a bridge adapter to enable communication to support multiple network communication protocols such as HTTP, TCP (short connection and asynchronous long connection), RabbitMQ, WebsphereMQ, etc., so that application developers do not have to consider too much about the differences in the various protocols that do not communicate between different systems. At the same time, because it is within the process, the call links between microservices are greatly reduced.

[0054] The API gateway process of this embodiment supports multiple messages. The API gateway loads a bridge adapter to enable communication to support multiple message formats including fixed-length format, variable-length format, XML format, JSON format, 8583 format, etc. The gateway to the microservice only needs to use a fixed message format, so that developers do not need to consider the issue of microservice compatibility with multiple message formats.

[0055] This embodiment is extensible and has protocol extension points, which is convenient for subsequent expansion or functional enhancement of the API gateway. It is convenient to meet the needs of different protocols between different application systems; the present invention supports componentization, and the API gateway bridge adapter is a separate component. There is no strong coupling between the components, and the application developer can freely customize the required gateway bridge adapter component in the configuration.

[0056] The above contents are further detailed descriptions of the present invention in combination with specific preferred embodiments, and it cannot be determined that the specific implementation of the present invention is limited to these descriptions. For ordinary technicians in the technical field to which the present invention belongs, several simple deductions or substitutions can be made without departing from the concept of the present invention, which should be regarded as falling within the protection scope of the present invention.

Claims

1. A method for adapting an API gateway to multiple protocols and message formats, characterized in that: The method comprises: Create a Maven project and generate an interface Java Bean based on the configured interface CSV file; Publish the interface and generate the interface jar package; API Gateway adds channel configuration parameters; Write microservice application code; Package the microservice application and start the microservice application; Add API gateway routing configuration information; Copy the Java Bean package and api-gateway-ce-bridge package to the external package path of the server where the gateway is located.

2. The method for adapting an API gateway to multiple protocols and message formats according to claim 1, characterized in that: The method includes starting the API gateway and sending a non-http request message to the channel listening port configured in the API gateway yml configuration file to verify whether the transaction is successfully routed to the application microservice.

3. The method for adapting an API gateway to multiple protocols and message formats as described in claim 1, characterized in that: Use the development tool IntelliJ IDEA to install the interface management tool beanMaker plug-in, and use the beanMaker plug-in to generate an interface Java Bean based on the configured interface CSV file.

4. The method for adapting an API gateway to multiple protocols and message formats as described in claim 3, characterized in that: Generate an interface jar package through the beanMaker plug-in. The jar package contains the parameter type, length, and name of the interface input and output parameters that need to be converted into messages.

5. The method for adapting an API gateway to multiple protocols and message formats as claimed in claim 1, characterized in that: The channel configuration parameters include channel name, listening port, message format, encoding and number of threads.

6. The method for adapting an API gateway to multiple protocols and message formats as claimed in claim 1, characterized in that: The interface Java Bean is used to define the transaction interface message format, message length, and message type.

7. The method for adapting an API gateway to multiple protocols and message formats as claimed in claim 1, characterized in that: api-gateway-ce-bridge is the API gateway bridging module. It introduces a communication engine into the API gateway, adds a bridging module, and receives TCP, RabbitMQ, and WebsphereMQ protocol requests from client applications. It parses the request data and converts it into a context object that conforms to the API gateway interface specification. It then calls the HTTP processor, thereby completing the entire process from protocol entry to HTTP exit adapted by the communication engine.

8. The method for adapting an API gateway to multiple protocols and message formats as described in claim 7, characterized in that: The communication engine adds a TCP2HTTP endpoint adapter class, an APIGATEWAY adapter interface and an adapter context class. The TCP2HTTP endpoint adapter class bridges the URL routing mechanism of the API gateway through the APIGATEWAY adapter interface, and the adapter context encapsulates the TCP channel and message conversion interface.

Images