Request processing method and device based on Dubbo framework

Abstract

The present application provides a request processing method and device based on the Dubbo framework, which can be used in the financial field or other technical fields. The method includes: obtaining a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework; encapsulating the service request into a Dubbo request and sending it to a Dubbo service module; obtaining the business processing result data generated by the Dubbo service module according to the Dubbo request; and sending the business processing result data to the application server. The device is used to execute the above method. The request processing method and device based on the Dubbo framework provided in the embodiment of the present application can achieve the technical goal of providing Dubbo services to applications based on non-Dubbo frameworks as service providers based on the Dubbo framework.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a request processing method and device based on the Dubbo framework. Background Art

[0002] Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions and SOA service governance solutions. Currently, both service providers and service callers must rely on the Dubbo framework in Dubbo applications. Summary of the Invention

[0003] In response to the problems in the prior art, the embodiments of the present application provide a request processing method and device based on the Dubbo framework, which can at least partially solve the problems in the prior art.

[0004] On the one hand, this application proposes a request processing method based on the Dubbo framework, including:

[0005] Obtaining a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework;

[0006] Encapsulate the service request into a Dubbo request and send it to the Dubbo service module;

[0007] Obtain the business processing result data generated by the Dubbo service module according to the Dubbo request;

[0008] The business processing result data is sent to the application server.

[0009] On the other hand, this application proposes a request processing device based on the Dubbo framework, including:

[0010] A first acquisition module is configured to acquire a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework;

[0011] A first sending module, configured to encapsulate the service request into a Dubbo request and then send the request to a Dubbo service module;

[0012] A second acquisition module is used to obtain the business processing result data generated by the Dubbo service module according to the Dubbo request;

[0013] The second sending module is used to send the business processing result data to the application server.

[0014] An embodiment of the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor. When the processor executes the program, the steps of the request processing method based on the Dubbo framework described in any of the above embodiments are implemented.

[0015] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the request processing method based on the Dubbo framework described in any of the above embodiments are implemented.

[0016] The Dubbo framework-based request processing method and apparatus provided in embodiments of the present application obtain a service request sent by a first application through an application server, wherein the first application is built on a non-Dubbo framework; encapsulates the service request into a Dubbo request and sends it to a Dubbo service module; obtains the business processing result data generated by the Dubbo service module based on the Dubbo request; and sends the business processing result data to the application server. This enables a Dubbo framework-based application to act as a service provider and provide Dubbo services to non-Dubbo framework-based applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work. In the drawings:

[0018] Figure 1 This is a flowchart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0019] Figure 2 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0020] Figure 3 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0021] Figure 4 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0022] Figure 5 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0023] Figure 6 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0024] Figure 7 This is a partial flow chart of a request processing method based on the Dubbo framework provided in an embodiment of the present application.

[0025] Figure 8 This is a schematic diagram of the overall application architecture of the InboundAdapter provided in one embodiment of the present application.

[0026] Figure 9 This is a schematic diagram of the application architecture of the InboundAdapter provided in one embodiment of the present application based on the custom protocol SIH of Dubbo.

[0027] Figure 10 This is a flowchart of an encoding and decoding method based on the SIH TCP transmission protocol provided in an embodiment of the present application.

[0028] Figure 11 This is a structural diagram of a request processing device based on the Dubbo framework provided in one embodiment of the present application.

[0029] Figure 12 This is a schematic diagram of the physical structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0030] To make the purpose, technical solutions, and advantages of the embodiments of the present application more clearly understood, the embodiments of the present application are further described in detail below with reference to the accompanying drawings. The illustrative embodiments of the present application and their descriptions are used to explain the present application but are not intended to limit the present application. It should be noted that, unless there is a conflict, the embodiments and features in the embodiments of the present application can be arranged in any order.

[0031] The terms “first,” “second,” etc. used herein do not specifically refer to an order or sequence, nor are they intended to limit this application. They are merely used to distinguish elements or operations described with the same technical terms.

[0032] The words “include,” “including,” “have,” “contain,” etc. used in this document are open-ended terms, meaning including but not limited to.

[0033] As used herein, "and / or" includes any and all permutations of the items described.

[0034] To better understand this application, the following is a detailed introduction to the research background of this application:

[0035] Dubbo: A distributed service framework dedicated to providing high-performance and transparent RPC remote service call solutions and SOA service governance solutions.

[0036] DSF: ICBC's distributed service platform based on Dubbo provides registration center, service gateway, monitoring and management functions for service-oriented applications, enabling service consumers to quickly find and use services and monitor and manage the service call process.

[0037] For an application based on the Dubbo framework (assuming the application is named InboundAdapter), if it needs to communicate with another application not based on the Dubbo framework (assuming the application is named SIH), and the communication parties have the following limitations:

[0038] (1) SIH is implemented in C++ and does not use the Dubbo framework;

[0039] (2) The communication protocol is TCP;

[0040] (3) SIH always acts as the server, and all callers act as clients;

[0041] (4) InboundAdapter accesses SIH as the service responder, and the communication mode adopts asynchronous response;

[0042] (5) For each SIH application, the maximum number of connections allowed is limited;

[0043] (6) The client and SIH use a long connection;

[0044] (7) The client periodically sends heartbeat data to SIH. If SIH does not receive the heartbeat data sent by the client for three consecutive cycles, it is considered that the client is offline and SIH actively closes the connection. If the client does not receive the heartbeat feedback data sent by SIH for three consecutive cycles, it is considered that the connection is unavailable and the client actively closes the connection and creates a new one.

[0045] (8) SIH provides the IP address of the cluster, and Dubbo-based applications need to implement load balancing strategies;

[0046] (9) For the IP address of the cluster provided by SIH, Dubbo-based applications need to support dynamic expansion, that is, dynamically add or delete corresponding TCP connections according to the change of the IP address of the SIH cluster without restarting.

[0047] The existing communication protocols and Consumer role definitions of the Dubbo framework cannot support the above requirements.

[0048] Based on the Dubbo framework, this application follows the SPI extension mechanism of the Dubbo framework and customizes a set of RPC protocols (assuming the protocol name is SIH protocol). In the SIH protocol, the service consumer not only has the functions of the service consumer itself, but also has the functions of the service provider role.

[0049] Among them, in the service discovery link, InboundAdapter, as the consumer of SIH, subscribes to a mockService for service discovery and implements functions such as TCP connection creation, connection reconnection, heartbeat management, and dynamic increase and decrease of services. SIH is not aware of this mockService.

[0050] During the service call phase, the InboundAdapter publishes a ProviderService using the SIH protocol, receives the request message sent by the SIH over a TCP connection, encapsulates the SIH request message into a Dubbo request during the encoding and decoding phase, and then transfers it through the Dubbo inbound process to the providerMethod of the ProviderService, where the business processing is completed. Again, the SIH is unaware of this ProviderService.

[0051] The main points of this application include:

[0052] (1) Define a virtual Dubbo service: Since the service discovery and service call of the Dubbo framework need to be based on services, and the SIH system does not have this set of service models of the Dubbo framework, it is necessary to let the Dubbo Consumer subscribe to and call a virtual service. The name of this service can be arbitrary.

[0053] (2) Define a specific Dubbo service: define a Dubbo service ProviderService for processing actual business;

[0054] (3) Extending RegistryFactory: The Dubbo framework subscribes to services from the service registry by default. When the service address changes, Dubbo will dynamically adjust the Invoker to support the dynamic changes of the service provider. Since SIH does not use the Dubbo framework, it is not possible to register services with the service registry. In order to support the dynamic change feature of SIH, it is necessary to extend RegistryFactory and connect to the Apollo configuration center to implement service discovery, so as to support the dynamic increase and decrease of SIH's TcpServer;

[0055] (4) Extended Protocol: Customize and implement the SihProtocol class, SihInvoker class, and SihExporter class to connect to the TCP data exchange protocol of SIH;

[0056] (5) Extend Codec2: Implement the SihCodec class to complete the encoding and decoding of the SIH protocol.

[0057] Encode implementation: When sending a message to SIH, first determine whether the message is a request or a response to distinguish whether it is an access message, a heartbeat message, or a service message. Then encode it according to SIH requirements. Finally, encapsulate the message and send it.

[0058] Decode implementation: When receiving a message from the SIH, it first needs to be unpacked to resolve the packet sticking problem. Then, based on the message content, it needs to distinguish between service request messages and access and heartbeat response messages. Finally, the service message is converted into a request object for processing, and the access response and heartbeat response are converted into a response object for processing.

[0059] (6) Extended Exchanger: This is mainly to adapt to the SIH heartbeat protocol. A lot of new code is added, including the following classes:

[0060] SihHeaderExchangeChannel class: used to manage Netty's channel, mainly including functions such as sending messages, receiving messages, and closing channels;

[0061] SihHeaderExchangeClient class: used to encapsulate SihHeaderExchangeChannel;

[0062] SihHeaderExchanger: used as the SPI extension class of Exchanger;

[0063] SihHeartBeatTask: used to send heartbeat messages;

[0064] ReconnectTimerTask: Once the channel is closed or the channel does not receive a heartbeat return message, a reconnection operation will be triggered.

[0065] The following is a detailed introduction to the request processing method and device based on the Dubbo framework provided by this application:

[0066] The execution subject of the request processing method based on the Dubbo framework provided in the embodiment of the present application includes but is not limited to a computer.

[0067] Figure 1 This is a flowchart of a request processing method based on the Dubbo framework provided in an embodiment of the present application. Figure 1 As shown, the embodiment of the present application provides a request processing method based on the Dubbo framework, including:

[0068] S101. Obtain a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework;

[0069] S102: Encapsulate the service request into a Dubbo request and send it to the Dubbo service module;

[0070] S103. Obtain business processing result data generated by the Dubbo service module according to the Dubbo request;

[0071] S104: Send the business processing result data to the application server.

[0072] Specifically, taking the above-mentioned application InboundAdapter based on the Dubbo framework and the application SIH based on the non-Dubbo framework as examples, in the service call link, the InboundAdapter server receives the service request sent by the SIH server, encapsulates the SIH service request into a Dubbo request in the encoding and decoding stage, and then sends the Dubbo request to the Dubbo service module. The Dubbo service module is composed of Figure 8 The departure system shown in Figure 1 is also built on the Dubbo framework and provides business processing functionality. The Dubbo service module generates business processing result data based on the Dubbo request and returns it to the InboundAdapter server, which then returns the business processing result data to the SIH server. This achieves the technical goal of enabling Dubbo-based applications to act as service providers for non-Dubbo-based applications.

[0073] like Figure 2 As shown, in some embodiments, encapsulating the service request into a Dubbo request and sending it to the Dubbo service module includes:

[0074] S1021. Decode the service request according to a preset transmission protocol specification to obtain a request message;

[0075] S1022. Determine the message type of the request message according to the message content of the request message;

[0076] S1023. If the message type of the request message is a service request message, encapsulate the request message into a Dubbo request and send it to the Dubbo service module.

[0077] Specifically, taking the aforementioned custom remote procedure call (RPC) protocol SIH as an example, after the InboundAdapter server receives a service request from the SIH server, it first needs to unpack it to resolve the packet sticking problem. Then, it decodes the request message (SIH message) according to the SIH TCP transport protocol specification. It then distinguishes whether the message is a service request message or an access and heartbeat response message based on the message content. If it is a service request message, the message is encapsulated into a Dubbo request and submitted to the DSF framework for processing.

[0078] like Figure 3 As shown, in some embodiments, if the message type of the request message is a service request message, encapsulating the request message into a Dubbo request and sending it to the Dubbo service module includes:

[0079] S10231. If the message type of the request message is a service request message, confirm the Dubbo service module to be called according to the name of the Dubbo service module in the request message;

[0080] S10232. Use the generalized gateway to simulate the service consumer and send a Dubbo request to the Dubbo service module.

[0081] Specifically, taking the above SIH protocol as an example, after receiving the SIH service request, the processing logic is as follows:

[0082] (1) Parse the SIH request message according to the SIH message exchange standard;

[0083] (2) Verify input parameters;

[0084] (3) Receive the request through the simulated ProviderService.providerMethod method and start the processing process;

[0085] (4) Find the Dubbo service module that needs to be called through the value of the Dubbo service module name field, use the generalized gateway GenericService to simulate the Consumer end to send an RPC request to the Dubbo service module, synchronously block the current thread, and wait for the result to be returned (the default timeout is 5s).

[0086] like Figure 4 As shown, in some embodiments, sending the business processing result data to the application server includes:

[0087] S1041. Construct a response message according to the business processing result data and the preset transmission protocol specification;

[0088] S1042: Send the response message to the application server.

[0089] Specifically, continuing to take the above SIH protocol as an example, after the above step (4), the processing logic is as follows:

[0090] (5) Receive the return data from Dubbo service;

[0091] (6) Constructing the SIH response message in accordance with the SIH message exchange standard;

[0092] (7) Send the constructed message to the caller.

[0093] like Figure 5 As shown, in some embodiments, the method further includes:

[0094] S105. Obtain a list of IP addresses of application servers pushed by the configuration center, wherein the IP addresses of the application servers are maintained in the configuration center;

[0095] S106. Register the virtual service with the registration center according to the IP address list of the application server;

[0096] S107: Subscribe to the virtual service.

[0097] Specifically, in the service discovery phase, InboundAdapter, as the consumer of SIH, subscribes to a mockService for service discovery and implements functions such as TCP connection creation, connection reconnection, heartbeat management, and dynamic increase and decrease of services. SIH is not aware of this mockService.

[0098] The DSF framework is based on Dubbo and subscribes to services from the service registry by default. When the service address changes, Dubbo will dynamically adjust the Invoker to support dynamic changes in service providers.

[0099] Because SIH doesn't use the DSF framework, it can't register services with the service registry. To support the dynamic changes of SIH TcpServers, it's necessary to extend RegistryFactory and connect to the Apollo configuration center to implement service discovery, supporting the dynamic addition and removal of TCP servers. Specifically, the IP address configuration of the TCP server is subscribed to the configuration center. The endpoint then registers and subscribes to a virtual service with the registry based on the IP address list pushed by the configuration center.

[0100] like Figure 6 As shown, in some embodiments, registering the virtual service with the registration center according to the IP address list of the application server includes:

[0101] S1061, determining a uniform resource locator list of virtual services according to the IP address list;

[0102] S1062: Register the virtual service to a registration center according to the uniform resource locator list.

[0103] Specifically, the uniform resource locator list (URL) of the virtual service is determined according to the IP address list pushed by the configuration center, and then the DSF framework registers the virtual service with the registration center according to the virtual service URL.

[0104] like Figure 7 As shown, in some embodiments, the method further includes:

[0105] S108: Obtain the latest application server IP address list pushed by the configuration center;

[0106] S109: Update the uniform resource locator list of the virtual service according to the latest IP address list.

[0107] Specifically, the IP address configuration of the TCP Server is subscribed to from the configuration center. When the IP address changes, the configuration center pushes the changed IP address list. The end updates the URL of the virtual service based on the latest IP address list. Then, the DSF framework dynamically updates the Invoker based on the changes in the virtual service URL.

[0108] The implementation logic is as follows:

[0109] (1) Maintain the IP address list of SIH Tcp Server in the Apollo configuration center, for example:

[0110] travelsky.adapter.connectAddress[0]=sih: / / 10.221.157.180:80 / com.gykj.adapter.client.sih.consumer.ConsumerService? connections=1;

[0111] (2) The outgoing end subscribes to the IP address list of the SIH TCP Server from the Apollo configuration center;

[0112] (3) When the SIH TCP Server changes, maintain the IP address list on the Apollo configuration center;

[0113] (4) The Apollo configuration center pushes the changed IP address list to the extended SIH registration center;

[0114] (5) Monitor the Apollo configuration center and update the local IP address list cache immediately upon receiving a new IP address list;

[0115] (6) The extended SIH registry updates the URL list of the virtual service based on the IP address list;

[0116] (7) Dubbo updates the Invoker corresponding to the virtual service based on the updated URL list.

[0117] In some embodiments, after subscribing to the virtual service, the method further includes: sending a service request to an application server of a second application, wherein the second application is built based on a non-Dubbo framework.

[0118] Specifically, in the process of subscribing to the virtual service, a connection is created between each application server based on the IP address of each application server. When it is necessary to call the service of a certain application, for example, when calling the service of a second application, a service request is sent to the application server of the second application. The second application is built based on a non-Dubbo framework, thus realizing the practice of using an application based on the Dubbo framework (this application) as a service consumer.

[0119] To better understand this application, the following describes the request processing method based on the Dubbo framework provided by this application through a specific embodiment. The complete technical solution is as follows:

[0120] 1. InboundAdapter Design

[0121] The overall application architecture of InboundAdapter is as follows Figure 8 As shown. InboundAdapter internal structure description:

[0122] 1. As a service consumer, considering that its functions are very similar to those of a DSF consumer, and the DSF framework itself has very flexible expansion capabilities (SPI mechanism of the Dubbo framework), the design supports SIH's private communication protocol and Apollo-based service discovery protocol through SPI extension. The specific design plan is shown below.

[0123] 2. When acting as a service provider, encapsulate the request sent by the SIH Server into a Dubbo request during the encoding and decoding phase, and then perform business processing according to the Dubbo request processing flow.

[0124] InboundAdapter calling process description:

[0125] 1. The SIH TCP service sends a service request message to the InboundAdapter through the SIH TCP Server.

[0126] 2. The InboundAdapter receives the service request message, decodes it according to the SIH TCP transport protocol specification, and then encapsulates the SIH message into a DSF frame request and submits it to the DSF framework for processing;

[0127] 3. The DSF framework calls the reply method of requestExchangerHandler in SIH Protocol, and calls ProviderService in the reply method;

[0128] 4. In the ProviderService method, dynamically build the GenericService based on the DSF framework according to the caller's request parameters, call the $invoke method of the GenericService instance, call the Dubbo service, and wait for the result;

[0129] 5. The Dubbo service performs business processing and returns the results;

[0130] 6. After receiving the result returned by the Dubbo service, GenericService returns the result to SIH TcpServer;

[0131] In addition to connecting to the SIH TCP Server as a SIH service consumer and implementing functions such as TCP connection creation, connection reconnection, heartbeat management, and dynamic increase and decrease of services, the InboundAdapter also needs to receive service request messages sent from the SIH TCPServer. In other words, the access end also needs to have the capabilities of an SIH service provider.

[0132] To meet the requirements of both being an SIH service consumer and an SIH service provider, the InboundAdapter is designed as follows:

[0133] 1. When InboundAdapter starts, as the SIH service consumer, it regards the SIH server cluster as a "virtual" Dubbo service, subscribes to the service, and implements functions such as TCP connection creation, connection reconnection, heartbeat management, and dynamic increase and decrease of services;

[0134] 2. During the InboundAdapter's operation, as an SIH service provider, it exposes a ProviderService in the JVM to handle service requests from the SIH server. When it receives an SIH request message, it treats it as a call to the ProviderService in the local JVM, converts the SIH request into a Dubbo request, and transfers it to the ProviderService for subsequent processing, thus achieving the handover between the IO request thread and the business processing thread.

[0135] The application architecture of InboundAdapter based on Dubbo's custom protocol SIH is as follows Figure 9 As shown:

[0136] 1. As a service consumer, subscribe to the SIH service cluster

[0137] 1) Configure the dubbo-comsumer.xml file and publish the service consumer

[0138] 2. As a service provider, use the SIH protocol to expose the mockservice service in the JVM

[0139] 1) Configure the dubbo-provider.xml file and publish the service provider

[0140] 2) Implementing the exposer of SIH protocol service

[0141] 3) Convert SIH request into call to mockProvider

[0142] Determine whether the SIH message is a request message or a response message;

[0143] If it is a request message, create an invocation for the mockProvider;

[0144] Finally, generalize the call to DSF's service in mockProvider.

[0145] 2. InboundAdapter specific implementation

[0146] 2.1 Extending RegistryFactory

[0147] The DSF framework is based on Dubbo and subscribes to services from the service registry by default. When the service address changes, Dubbo will dynamically adjust the Invoker to support dynamic changes in service providers.

[0148] Because SIH does not use the DSF framework, it cannot register services with the service registry. To support the dynamic change of SIH TcpServer, it is necessary to extend RegistryFactory and connect to the Apollo configuration center to implement service discovery and support dynamic addition and removal of TCP servers.

[0149] Subscribe to the IP address configuration of the TCP Server from the configuration center. When the IP address changes, the configuration center pushes the changed IP address list. The access end updates the URL of the virtual service based on the latest IP address list. Then, the DSF framework dynamically updates the Invoker based on the change of the virtual service URL.

[0150] The implementation logic is as follows:

[0151] 1. Maintain the IP address list of SIH Tcp Server in the Apollo configuration center, for example:

[0152] travelsky.adapter.connectAddress[0]=sih: / / 10.221.157.180:80 / com.gykj.adapter.client.sih.consumer.ConsumerService? connections=1;

[0153] 2. The outgoing end subscribes to the IP address list of the SIH TCP Server from the Apollo Configuration Center;

[0154] 3. When the SIH TCP Server changes, maintain the IP address list on the Apollo configuration center;

[0155] 4. The Apollo Configuration Center pushes the changed IP address list to the extended SIH registration center;

[0156] 5. Monitor the Apollo configuration center and update the local IP address list cache immediately upon receiving a new IP address list;

[0157] 6. The extended SIH registry updates the URL list of the virtual service based on the IP address list;

[0158] 7. Dubbo updates the Invoker corresponding to the virtual service according to the updated URL list.

[0159] Extending RegistryFactory mainly includes the following classes:

[0160] 1. SihRegistry class

[0161] (1) Customize the SihRegistry class and inherit the FailbackRegistry class.

[0162] (2) This class mainly uses ApolloClient to obtain the SIH TCP Server server list from the Apollo configuration center and monitors changes to the SIH TCP Server server list;

[0163] (3) When the SIH TCP Server server list changes, the URL list of the virtual service is dynamically updated.

[0164] (4) Dubbo updates the Invoker corresponding to the virtual service according to the updated URL list to achieve dynamic changes in the service provider.

[0165] 2. SihRegistryFactory class

[0166] (1) Customize the SihRegistryFactory class and inherit the AbstractRegistryFactory class.

[0167] (2) This class serves as the SihRegistry factory class, and is mainly used to create and return SihRegistry objects based on URLs.

[0168] 3. SpringBootApolloRefreshConfig class

[0169] (1) Add a SpringBootApolloRefreshConfig as an Apollo monitoring event. Once the IP address list of the SIH Tcp Server pushed by Apollo is monitored, the local cache of the IP address list is updated immediately.

[0170] 2.2 Extending Invoker

[0171] Customize the SihInvoker class, inherit the com.alibaba.dubbo.rpc.protocol.AbstractInvoker class, implement the construction method and rewrite the doInvoke method.

[0172] SihInvoker enables SihProtocol to have the role of Consumer, that is, as a client, it sends connection initialization messages and heartbeat messages to SIH TCPServer and receives the returned processing results.

[0173] 1. Function description of construction method:

[0174] (1) Call the parent class's constructor;

[0175] (2) The SIH system divides the nodes it interacts with (essentially, the peers of each TCP connection) into two categories: one that actively sends transactions to the SIH system and receives responses, and the other that passively receives requests from the SIH system and returns results, without actively sending transactions. To support this feature, a special process is required in the SihInvoker class. In the constructor, an identity is first sent to the SIH system for each TCP connection, and the invoker is set to be available after the SIH system returns a confirmation message.

[0176] 2. Function description of doInvoke method:

[0177] (1) Construct an RpcInvocation object;

[0178] (2) Select an available ExchangeClient from the ExchangeClient array based on the load balancing policy;

[0179] (3) Using ExchangeClient to send TCP requests

[0180] (4) Receive the returned result;

[0181] 2.3 Extending Exporter

[0182] Customize the SihExporter class, inherit the com.alibaba.dubbo.rpc.protocol.AbstractExporter class, and implement the construction method and unexport method.

[0183] SihExporter enables SihProtocol to have the role of Provider, that is, as a server, it receives the service request message sent by SIH TCPServer and returns the processing result.

[0184] 1. Function description of construction method:

[0185] (1) Call the parent class's constructor;

[0186] (2) Add the SihExporter object to the cache exporterMap, with the key format being group / interface:version;

[0187] 2. Function description of unexport method:

[0188] (1) Call the unexport method of the parent class;

[0189] (2) Delete the SihExporter object from the cache exporterMap;

[0190] 2.4 Extending the Protocol

[0191] Customize the SihProtocol class, inherit the com.alibaba.dubbo.rpc.protocol.AbstractProtocol class, override the refer method, override the export method, and implement the getClients method.

[0192] 1. Refer method function description:

[0193] (1) Create a SihInvoker object based on the input interface type and URL and add it to the invokers cache.

[0194] 2. Export method function description:

[0195] (1) Create a SihExporter object based on the input AbstractProxyInvoker object. The AbstractProxyInvoker object is a proxy class for a specific local service and implements the com.alibaba.dubbo.rpc.Invoker interface.

[0196] 3. Function description of getClients method:

[0197] (1) Obtain the number of connections of the SIH TCP virtual service from the configuration center;

[0198] (2) Create ExchangeClient objects in sequence according to the number of connections, and establish TCP connections with SIH TCPServer;

[0199] (3) Store the created ExchangeClient object in an array for use by SihInvoker.

[0200] In addition, in the SihProtocol class, customize the ExchangeHandler anonymous class and inherit the com.alibaba.dubbo.remoting.exchange.support.ExchangeHandlerAdapter class.

[0201] The ExchangeHandler anonymous class is a core function of this extended Protocol. It specifically implements the Provider role of SihProtocol, that is, as a server, it receives business request messages sent by SIH TCP Server and returns the processing results.

[0202] ExchangeHandler mainly implements the reply method:

[0203] 1. Description of reply method function:

[0204] (1) Find the corresponding SihExporter according to ServiceKey;

[0205] (2) Obtain the proxy object AbstractInvoker of the local service method from SihExporter;

[0206] (3) Call the invoke method of AbstractInvoker to complete the service call;

[0207] (4) Return the service processing result.

[0208] 2.5 Extended Codec2

[0209] The SIH TCP transport protocol format is as follows:

[0210] 4 bytes 1 byte 4 bytes content magic cmd length content

[0211] 1. Magic: The field length is 4 bytes (32 bits), used to distinguish protocols

[0212] Fixed value: SIHX

[0213] 2. cmd: This field is 1 byte (8 bits) long and is used to indicate the message type. 0xA indicates access authentication, 0xB indicates heartbeat, and 0x3 indicates service message.

[0214] 0xA0: Access SIH request message, initiated by the client

[0215] 0xA1: Response message corresponding to SIH access request

[0216] 0xB0: Heartbeat request, initiated by the client

[0217] 0xB1: Heartbeat response, replied by SIH

[0218] 0x31: Synchronous request

[0219] 0x32: Asynchronous request

[0220] 0x33: Synchronous response

[0221] 0x34: Reserved

[0222] 0x35: Asynchronous response

[0223] 0x36: One-way message

[0224] 0x37: Reserved

[0225] 0x38: Reserved

[0226] 0x39: Reserved

[0227] 3. Length: The field length is 4 bytes (32 bits), which is used to indicate the length of the entire message.

[0228] Message length: 4 bytes, maximum supported: 2147483647 (about 1.9 GB), do not exceed 512 KB when in use;

[0229] length=header length+content length.

[0230] 4. Content: The content of the message. The content varies depending on the cmd.

[0231] In order to achieve communication with SIH TCP Server, it is necessary to implement the parsing of SIH TCP transmission protocol format in the Dubbo framework.

[0232] like Figure 10 As shown, the custom SihCodec class implements the encode and decode methods in the com.alibaba.dubbo.remoting.Codec2 interface to complete the encoding and decoding of the SIH TCP transport protocol.

[0233] 1. encode method

[0234] encode method function description:

[0235] (1) First, when sending a message to the SIH, it is determined whether the message is a request or a response to distinguish whether it is an access message, a heartbeat message, or a service message.

[0236] (2) Then, encode according to SIH requirements.

[0237] (3) Finally, the message is encapsulated and sent.

[0238] The encode method processing logic is as follows:

[0239] (1) The msg type is used to distinguish whether it is an access request message, a heartbeat request message or a service response message.

[0240] (2) If the msg type is Request, indicating that it is an access request message or a heartbeat request message, then:

[0241] First, read the access request message or heartbeat request message content from the Request object.

[0242] Then, an SIH TCP request message is constructed according to the SIH TCP transmission protocol format.

[0243] Finally, it is sent to the SIH TCP Server through a TCP connection.

[0244] (3) If msg is of type Response, indicating that it is a service response message, then:

[0245] First, get the response corresponding to the request based on the key stored in cmdCache

[0246] Then, the corresponding response cmd is returned according to the request cmd value. If no result is found, a synchronous response is returned by default.

[0247] Finally, the SIH TCP response message is constructed according to the SIH TCP transmission protocol format and sent to the SIH TCP Server through the TCP connection.

[0248] 2. decode method

[0249] Decode method function description:

[0250] (1) First, receive the message from SIH, unpack it, and solve the problem of sticky packets.

[0251] (2) Then, the service request message or the access and heartbeat response message is distinguished according to the message content.

[0252] (3) Finally, the service message is converted into a request object for processing, and the access response and heartbeat response are converted into a response object for processing.

[0253] The decode method processing logic is as follows:

[0254] (1) First, read up to 4 bytes from the buffer and determine whether each character is SIHX.

[0255] (2) If the message does not begin with SIHX, it indicates that the message is an illegal message. If there are still unread messages at this time, read the remaining messages.

[0256] Determine whether the following conditions exist in the read message: substring SIHX, the last digit is S, the last two digits are SI, the last three digits are SIH, and the last four digits are SIHX.

[0257] If the above situation does not exist, it indicates that the message read this time is an illegal message. No processing is done, it is skipped directly, and null is returned.

[0258] If the above situation exists, it indicates that the string between the message header and the position where the substring appears is an illegal message and is skipped without processing. The readerIndex of the buffer is set to the position where the substring appears so that processing can continue in the next loop.

[0259] (3) If the message starts with S, SI, SIH or SIHX, determine whether the readable message length is less than 9.

[0260] If the readable message length is less than or equal to 9, it indicates that the read SIH message content does not contain 1 byte of CMD and 4 bytes of Length, and it is necessary to continue reading the subsequent message content. In this case, NEED_MORE_INPUT is returned directly.

[0261] If the readable message length is greater than 9, it indicates that the read SIH message content already contains 1 byte of CMD and 4 bytes of length. Then, the unpacking process begins, the message is parsed normally, and subsequent processing continues.

[0262] (4) Determine whether the length of the readable message in the buffer is greater than or equal to the content length represented by length in the SIH message.

[0263] If readable is less than length, it means that only part of the SIH message has been read and it is necessary to continue reading the subsequent SIH message content. In this case, NEED_MORE_INPUT is returned directly.

[0264] If readable is greater than or equal to length, read the message content of length length and continue subsequent processing.

[0265] (5) For the content read this time, determine whether the last character in the business content is 0x0A.

[0266] If it is not 0x0A, you need to parse the content to see if there is SHIX. If so, the previous requests are invalid and null is returned directly.

[0267] If it is 0x0A, it proves that no message is lost and the message is normal. Continue with subsequent processing.

[0268] (6) Finally, the result returned by cmd is confirmed to be an access verification message, a heartbeat message, or a service message.

[0269] If it is an access verification message or heartbeat message, you need to retrieve the requestId from the cache, construct a Response object, and then return the Response.

[0270] If it is a business message, you need to parse the business object, extract the requestId from the callbackdata, construct a Request object, and then return the Request.

[0271] 2.6 Extending Exchanger

[0272] The main purpose of extending Exchanger related classes is to adapt to the SIH heartbeat protocol, which mainly includes the following classes:

[0273] 1. SihHeaderExchangeChannel class

[0274] (1) Customize the SihHeaderExchangeChannel class and implement the ExchangeChannel interface.

[0275] (2) This class is mainly used to manage Netty's channel, and use the channel to send heartbeat messages, receive heartbeat messages, close channels, and other functions.

[0276] 2. SihHeaderExchangeClient class

[0277] (1) Customize the SihHeaderExchangeClient class and implement the ExchangeClient interface.

[0278] (2) Encapsulate SihHeaderExchangeChannel in the construction method.

[0279] (3) Rewrite the reconnect method and add the function of sending initial connection information to the SIH TCP Server after the connection is established.

[0280] (4) Implement the startHeatbeatTimer method and stopHeartbeatTimer method to start or stop the heartbeat timing task.

[0281] (5) Implement the startReconnectTimer method and stopReconnectTimer method to start or stop the reconnection timer task.

[0282] 3. SihHeaderExchanger class

[0283] (1) Customize the SihHeaderExchanger class, implement the Exchanger interface, and serve as the SPI extension class of Exchanger.

[0284] (2) Rewrite the connect method to create and return a SihHeaderExchangeClient object.

[0285] (3) Rewrite the bind method to create and return the HeaderExchangeServer object.

[0286] 4. SihHeartBeatTask class

[0287] (1) Customize the SihHeartBeatTask class, implement the Runnable interface, and use it as the SPI extension class of Exchanger.

[0288] (2) Rewrite the run method to send heartbeat messages.

[0289] 1. ReconnectTimerTask class

[0290] (1) Customize the ReconnectTimerTask class, implement the Runnable interface, and use it as the SPI extension class of Exchanger.

[0291] (2) Rewrite the run method. Once the channel is closed or the channel does not receive a heartbeat return message, a reconnection operation will be triggered.

[0292] 2.7 Service Provider Implementation

[0293] After receiving the SIH service request, the processing logic is as follows:

[0294] 1. Parse the SIH request message according to the SIH Message Exchange Standard;

[0295] 2. Verify input parameters;

[0296] 3. Receive the request through the simulated ProviderService.providerMethod method and start the processing flow;

[0297] 4. Find the Dubbo service to be called through the value of the Dubbo service name field, use the generic gateway GenericService to simulate the Consumer side to send an RPC request to the Dubbo service, synchronously block the current thread, and wait for the result to be returned (the default timeout is 5 seconds);

[0298] 5. Receive the return data from the Dubbo service;

[0299] 6. Construct SIH request message according to SIH message exchange standard;

[0300] 7. Send the constructed message to the caller.

[0301] The technical solution provided in this embodiment enables the Consumer in the Dubbo framework to transform from a single service consumer to a dual-role service consumer and service provider. This transformation provides a technical reference for some special scenarios of Dubbo applications, including the following:

[0302] 1. The client system always acts as the server, and all callers act as clients;

[0303] 2. InboundAdapter connects to the customer system as a service responder and provides Dubbo services to customers as a service provider;

[0304] 3. The customer system does not use the Dubbo framework;

[0305] 4. The client system communication protocol is TCP protocol;

[0306] Figure 11 This is a schematic diagram of the structure of a request processing device based on the Dubbo framework provided in one embodiment of the present application. Figure 11 As shown, the embodiment of the present application proposes a request processing device based on the Dubbo framework, including:

[0307] A first acquisition module 21 is configured to acquire a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework;

[0308] A first sending module 22 is used to encapsulate the service request into a Dubbo request and send it to the Dubbo service module;

[0309] The second acquisition module 23 is used to obtain the business processing result data generated by the Dubbo service module according to the Dubbo request;

[0310] The second sending module 24 is configured to send the service processing result data to the application server.

[0311] An embodiment of the present application provides a request processing device based on the Dubbo framework. Taking the above-mentioned application InboundAdapter based on the Dubbo framework and the application SIH based on the non-Dubbo framework as examples, in the service call link, the InboundAdapter server receives the service request sent by the SIH server, encapsulates the SIH service request into a Dubbo request in the encoding and decoding stage, and then sends the Dubbo request to the Dubbo service module. The Dubbo service module is provided by the departure system, which is also built based on the Dubbo framework and is used to provide business processing functions. The Dubbo service module generates business processing result data based on the Dubbo request and returns it to the InboundAdapter server. The InboundAdapter server returns the business processing result data to the SIH server. At this point, the technical goal of the application based on the Dubbo framework as a service provider to provide Dubbo services for applications based on the non-Dubbo framework has been achieved.

[0312] In some embodiments, the first sending module is specifically configured to:

[0313] Decoding the service request according to a preset transmission protocol specification to obtain a request message;

[0314] Determining the message type of the request message according to the message content of the request message;

[0315] If the message type of the request message is a service request message, the request message is encapsulated into a Dubbo request and sent to the Dubbo service module.

[0316] In some embodiments, if the message type of the request message is a service request message, the first sending module encapsulates the request message into a Dubbo request and then sends the request to the Dubbo service module, including:

[0317] If the message type of the request message is a service request message, confirm the Dubbo service module to be called according to the name of the Dubbo service module in the request message;

[0318] Use the generalized gateway to simulate the service consumer to send Dubbo requests to the Dubbo service module.

[0319] In some embodiments, the second sending module is specifically configured to:

[0320] Constructing a response message according to the business processing result data and the preset transmission protocol specification;

[0321] Send the response message to the application server.

[0322] In some embodiments, the apparatus further comprises:

[0323] A third acquisition module is used to obtain a list of IP addresses of application servers pushed by the configuration center, wherein the IP addresses of the application servers are maintained in the configuration center;

[0324] A registration module, configured to register a virtual service with a registration center according to the IP address list of the application server;

[0325] The subscription module is used to subscribe to the virtual service.

[0326] In some embodiments, the registration module is specifically configured to:

[0327] Determine a uniform resource locator list of virtual services based on the IP address list;

[0328] The virtual service is registered in a registration center according to the uniform resource locator list.

[0329] In some embodiments, the apparatus further comprises:

[0330] A fourth acquisition module is used to obtain the latest application server IP address list pushed by the configuration center;

[0331] An updating module is used to update the uniform resource locator list of the virtual service according to the latest IP address list.

[0332] In some embodiments, the device further includes: a third sending module, configured to send a service request to an application server of a second application, wherein the second application is constructed based on a non-Dubbo framework.

[0333] The embodiments of the apparatus provided in the embodiments of the present application can be specifically used to execute the processing flow of the above-mentioned method embodiments. Its functions will not be described in detail here, and reference can be made to the detailed description of the above-mentioned method embodiments.

[0334] It should be noted that the request processing method and device based on the Dubbo framework provided in the embodiments of the present application can be used in the financial field, and can also be used in any technical field other than the financial field. The embodiments of the present application do not limit the application field of the request processing method and device based on the Dubbo framework.

[0335] Figure 12 A schematic diagram of the physical structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 12 As shown, the electronic device may include: a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other via the communication bus 304. The processor 301 may call the logic instructions in the memory 303 to execute the method described in any of the above embodiments.

[0336] In addition, the logic instructions in the above-mentioned memory 303 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0337] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided by the above-mentioned method embodiments.

[0338] This embodiment provides a computer-readable storage medium, which stores a computer program. The computer program enables the computer to execute the methods provided by the above method embodiments.

[0339] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0340] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0341] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0342] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0343] In the description of this specification, reference to the terms "one embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any appropriate manner in any one or more embodiments or examples.

[0344] The specific embodiments described above further illustrate the purpose, technical solutions and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A request processing method based on the Dubbo framework, applied to an application InboundAdapter based on the Dubbo framework, characterized in that: include: Obtaining a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework; Encapsulate the service request into a Dubbo request and send it to the Dubbo service module; Obtaining the business processing result data generated by the Dubbo service module according to the Dubbo request; Sending the business processing result data to the application server; Wherein, during the operation of the application InboundAdapter, the application InboundAdapter is the service provider of the first application, and the step of encapsulating the service request into a Dubbo request and sending it to the Dubbo service module includes: Decoding the service request according to a preset transmission protocol specification to obtain a request message; Determine the message type of the request message according to the message content of the request message; If the message type of the request message is a service request message, the request message is encapsulated into a Dubbo request and sent to the Dubbo service module; Wherein, when the application InboundAdapter is started, the application InboundAdapter is a service consumer of the first application, and the method further includes: Obtain a list of IP addresses of application servers pushed by a configuration center, wherein the IP addresses of the application servers are maintained in the configuration center; Registering the virtual service with the registration center according to the IP address list of the application server; Subscribe to the virtual service.

2. The method according to claim 1, characterized in that If the message type of the request message is a service request message, encapsulating the request message into a Dubbo request and sending it to the Dubbo service module includes: If the message type of the request message is a service request message, confirm the Dubbo service module to be called according to the name of the Dubbo service module in the request message; Use the generalized gateway to simulate the service consumer to send Dubbo requests to the Dubbo service module.

3. The method according to claim 1, characterized in that The sending the business processing result data to the application server comprises: Constructing a response message according to the business processing result data and the preset transmission protocol specification; The response message is sent to the application server.

4. The method according to claim 1, characterized in that The registering the virtual service with the registration center according to the IP address list of the application server includes: Determine a uniform resource locator list of virtual services according to the IP address list; The virtual service is registered in a registration center according to the uniform resource locator list.

5. The method according to claim 4, characterized in that The method further comprises: Obtain the latest application server IP address list pushed by the configuration center; The uniform resource locator list of the virtual service is updated according to the latest IP address list.

6. The method according to any one of claims 1, 4 to 5, characterized in that: After subscribing to the virtual service, the method further includes: Send a service request to an application server of a second application, wherein the second application is built based on a non-Dubbo framework.

7. A request processing device based on the Dubbo framework, configured in an application InboundAdapter based on the Dubbo framework, characterized in that: include: A first acquisition module, used to acquire a service request sent by a first application through an application server, wherein the first application is built based on a non-Dubbo framework; A first sending module, used for encapsulating the service request into a Dubbo request and sending it to a Dubbo service module; A second acquisition module is used to obtain the business processing result data generated by the Dubbo service module according to the Dubbo request; A second sending module, used to send the business processing result data to the application server; Wherein, during the operation of the application InboundAdapter, the application InboundAdapter is a service provider of the first application, and the first sending module is specifically used for: Decoding the service request according to a preset transmission protocol specification to obtain a request message; Determine the message type of the request message according to the message content of the request message; If the message type of the request message is a service request message, the request message is encapsulated into a Dubbo request and sent to the Dubbo service module; Wherein, when the application InboundAdapter is started, the application InboundAdapter is a service consumer of the first application, and the device further includes: A third acquisition module is used to acquire a list of IP addresses of application servers pushed by the configuration center, wherein the IP addresses of the application servers are maintained in the configuration center; A registration module, used to register the virtual service with a registration center according to the IP address list of the application server; The subscription module is used to subscribe to the virtual service.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images