CN115883633A

CN115883633A - Dubbo frame-based request processing method and device

Info

Publication number: CN115883633A
Application number: CN202211589280.5A
Authority: CN
Inventors: 单德祥; 孙凌浩
Original assignee: Industrial and Commercial Bank of China Ltd ICBC; ICBC Technology Co Ltd
Current assignee: Industrial and Commercial Bank of China Ltd ICBC; ICBC Technology Co Ltd
Priority date: 2022-12-12
Filing date: 2022-12-12
Publication date: 2023-03-31

Abstract

The application provides a request processing method and device based on a Dubbo frame, which can be used in the financial field or other technical fields. The method comprises the following steps: acquiring a service request sent by a first application through an application server, wherein the first application is constructed based on a non-Dubbo framework; packaging the service request into a Dubbo request and sending the Dubbo request to a Dubbo service module; acquiring service processing result data generated by the Dubbo service module according to the Dubbo request; and sending the service processing result data to the application server. The device is used for executing the method. The method and the device for processing the request based on the Dubbo frame can achieve the technical aim that the application based on the Dubbo frame serves as a service provider to provide Dubbo service for the application based on the non-Dubbo frame.

Description

Request processing method and device based on Dubbo framework

Technical Field

The application relates to the technical field of computers, in particular to a request processing method and device based on a Dubbo framework.

Background

Dubbo is a distributed service framework that is dedicated to providing high performance and transparent RPC remote service invocation schemes, as well as SOA service governance schemes. With current Dubbo framework applications, both the service provider and the service invoker must rely on the Dubbo framework.

Disclosure of Invention

For the problems in the prior art, embodiments of the present application provide a request processing method and apparatus based on a Dubbo frame, which can at least partially solve the problems in the prior art.

On one hand, the application provides a request processing method based on a Dubbo frame, which comprises the following steps:

acquiring a service request sent by a first application through an application server, wherein the first application is constructed based on a non-Dubbo framework;

packaging the service request into a Dubbo request and sending the Dubbo request to a Dubbo service module;

acquiring service processing result data generated by the Dubbo service module according to the Dubbo request;

and sending the service processing result data to the application server.

On the other hand, the application provides a request processing device based on a Dubbo frame, comprising:

the system comprises a first acquisition module, a second acquisition module and a first application module, wherein the first acquisition module is used for acquiring a service request sent by a first application through an application server, and the first application is constructed based on a non-Dubbo framework;

the first sending module is used for packaging the service request into a Dubbo request and then sending the Dubbo request to the Dubbo service module;

the second acquisition module is used for acquiring the service processing result data generated by the Dubbo service module according to the Dubbo request;

and the second sending module is used for sending the service processing result data to the application server.

The embodiments of the present application further provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the steps of the method for processing a request based on a Dubbo framework according to any of the embodiments when executing the program.

The embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the steps of the request processing method based on the Dubbo framework according to any of the above embodiments.

According to the request processing method and device based on the Dubbo framework, a service request sent by a first application through an application server is obtained, wherein the first application is built based on a non-Dubbo framework; packaging the service request into a Dubbo request and sending the Dubbo request to a Dubbo service module; acquiring service processing result data generated by the Dubbo service module according to the Dubbo request; and sending the service processing result data to the application server. The technical goal of providing a non-Dubbo frame based application with Dubbo services as a service provider can be achieved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts. In the drawings:

fig. 1 is a schematic flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 2 is a schematic partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 3 is a schematic partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 4 is a schematic partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 5 is a schematic partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 6 is a partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 7 is a partial flowchart of a request processing method based on a Dubbo framework according to an embodiment of the present application.

Fig. 8 is a schematic diagram of a general application architecture of the inbounddapter according to an embodiment of the present application.

Fig. 9 is a schematic diagram of an application architecture of a Dubbo-based custom protocol SIH for inbounddadapter according to an embodiment of the present application.

Fig. 10 is a flowchart illustrating an encoding and decoding method based on the SIH TCP transport protocol according to an embodiment of the present application.

Fig. 11 is a schematic structural diagram of a request processing apparatus based on a Dubbo framework according to an embodiment of the present application.

Fig. 12 is a schematic physical structure diagram of an electronic device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the embodiments of the present application more apparent, the embodiments of the present application are further described in detail below with reference to the accompanying drawings. The exemplary embodiments and descriptions of the present application are provided herein to explain the present application and not to limit the present application. It should be noted that the embodiments and features of the embodiments in the present application may be arbitrarily ordered with respect to each other without conflict.

The terms "first," "second," "8230," "8230," and the like as used herein do not particularly denote any order or sequence, nor are they used to limit the present application, but rather are used to distinguish one element from another element or operation described in the same technical language.

As used herein, the terms "comprising," "including," "having," "containing," and the like are open-ended terms that mean including, but not limited to.

As used herein, "and/or" includes any or all of the ordering of the described things.

For a better understanding of the present application, the following detailed description is given of the research background of the present application:

dubbo: the distributed service framework aims to provide a RPC remote service calling scheme with high performance and transparency and an SOA service governance scheme.

And (3) DSF: the distributed service platform realized by the industrial and commercial bank based on Dubbo provides functions of a registration center, a service gateway, monitoring management and the like for service application, so that service consumers can quickly search and use services, and the monitoring and management of a service calling process are realized.

For an application based on the Dubbo framework (assuming that the application name is InboundAdapter), if communication needs to be performed with another application (assuming that the application name is SIH) which is not the Dubbo framework, the following limiting factors exist between the two communication parties:

(1) SIH is realized by C + +, and a Dubbo frame is not adopted;

(2) The communication protocol is a TCP protocol;

(3) The SIH is always used as a server side, and all calling parties are used as client sides;

(4) The InboundAdapter is used as a service responder to access the SIH, and the communication mode adopts asynchronous response;

(5) For each SIH application, there is a limit to the maximum number of connections allowed;

(6) The client is in long connection with the SIH;

(7) The client side sends heartbeat data to the SIH periodically, if the SIH does not receive the heartbeat data sent by the client side for 3 continuous periods, the client side is considered not to be on-line, and the SIH closes the connection actively; if the client does not receive heartbeat feedback data sent by the SIH for 3 continuous periods, the connection is considered to be unavailable, the client actively closes the connection, and a new connection is created again;

(8) The SIH provides the IP address of the cluster, and the Dubbo-based application needs to realize a load balancing strategy;

(9) For the IP address of the cluster provided by the SIH, the application based on the Dubbo needs to support dynamic extension, that is, under the condition that no restart is needed, according to the IP address change of the SIH cluster, the corresponding TCP connection is dynamically added or deleted.

Above these requirements, the existing communication protocol and Consumer role definitions of the Dubbo framework are not supportable.

The application is based on a Dubbo framework, follows an SPI (serial peripheral interface) extension mechanism of the Dubbo framework, and defines a set of RPC (remote procedure call) protocol (supposing that the protocol name is SIH protocol). In the SIH protocol, the service Consumer has the function of the service Provider in addition to the function of the service Consumer itself.

In the service discovery link, the InboundAdapter serves as a consumer of the SIH, subscribes a mockService for service discovery, and realizes functions of TCP connection establishment, connection reconnection, heartbeat management, dynamic service increase and decrease and the like, and the SIH does not sense the mockService.

In the service calling link, the InboundAdapter issues a ProviderService by an SIH protocol, receives a request message sent by the SIH through a TCP connection, encapsulates the request message of the SIH into a Dubbo request in the coding and decoding stage, then transfers the Dubbo request into a providerMethod of the ProviderService through an inbound flow stream of the Dubbo, and completes service processing in the method. Also, the SIH does not perceive this ProviderService.

The main points of this application mainly include:

(1) Defining a virtual Dubbo service: since service discovery, service invocation and the like of the Dubbo framework need to be performed based on services, and the SIH system does not have the set of service model of the Dubbo framework, a virtual service needs to be subscribed and invoked by the subscriber of the Dubbo, and the name of the service can be arbitrary;

(2) Define specific Dubbo services: defining a Dubbo service ProviderService for processing actual service;

(3) Extended RegistryFactory: the Dubbo framework subscribes to services from the service registry by default. When the address of the service changes, the ducbo dynamically adjusts the explorer to support the dynamic change of the service provider. Since the SIH does not employ the Dubbo framework, it is not possible to register a service with a service registry. In order to support the characteristic of the dynamic change of the SIH, the Registryfactor needs to be expanded, service discovery is realized by butting against an Apollo configuration center, and the Tcp Server for dynamically increasing and reducing the SIH is supported;

(4) Expanding the Protocol: the method comprises the steps of self-defining and realizing SihProtocol, sihInvoker and SihExporter, and butting TCP data exchange protocols of SIH;

(5) Extended Codec2: and realizing the SihCodec class and finishing the coding and decoding of the SIH protocol.

The encode is realized as follows: when sending a message to the SIH, firstly, whether the msg is a request or a response is judged to distinguish an access message, a heartbeat message or a service message. And then encoded according to the SIH requirements. Finally, packaging and sending the message;

decode implementation: when receiving the message from the SIH, unpacking is firstly needed to solve the problem of packet sticking. Then, the service request message or the access and heartbeat response message is distinguished according to the message content. Finally, converting the service message into a request object for processing, and converting the access response and the heartbeat response into a response object for processing;

(6) Extension exchange: the method mainly aims to adapt to the heartbeat protocol of SIH, more new codes are added, and the method specifically comprises the following classes:

SihHeaderExchangeChannel class: the channel for managing the Netty mainly comprises the functions of sending messages, receiving messages, closing the channel and the like;

the SihHeaderExchangeClient class: used for packaging SihHeaderExchangeChannel;

SihHeaderExchanger: the SPI extension class used as exchange;

SihHeartTask: for sending heartbeat messages;

ReconnectTimerTask: and once the channel is closed or the heartbeat return message is not received by the channel, the reconnection operation is triggered.

The method and device for processing requests based on a Dubbo frame provided by the application are described in detail as follows:

the execution subject of the request processing method based on the Dubbo framework provided by the embodiment of the application includes but is not limited to a computer.

Fig. 1 is a schematic flowchart of a request processing method based on a Dubbo frame provided in an embodiment of the present application, and as shown in fig. 1, the request processing method based on the Dubbo frame provided in the embodiment of the present application includes:

s101, acquiring a service request sent by a first application through an application server, wherein the first application is constructed based on a non-Dubbo framework;

s102, packaging the service request into a Dubbo request and sending the Dubbo request to a Dubbo service module;

s103, acquiring service processing result data generated by the Dubbo service module according to the Dubbo request;

and S104, sending the service processing result data to the application server.

Specifically, taking the above-mentioned Dubbo framework-based application inboandapter and non-Dubbo framework-based application SIH as examples, in the service invocation link, the inboandapter server receives the service request sent by the SIH server, encapsulates the service request of the SIH into a Dubbo request in the coding and decoding stage, and then sends the Dubbo request to the Dubbo service module, which is provided by the departure system shown in fig. 8, and the departure system is also constructed based on the Dubbo framework and is used for providing a service processing function. And the Dubbo service module generates service processing result data according to the Dubbo request and returns the service processing result data to the InboundAdapter server, and the InboundAdapter server returns the service processing result data to the SIH server. To this end, the technical goal of providing a Dubbo service for a non-Dubbo frame based application as a service provider is achieved.

As shown in fig. 2, in some embodiments, the encapsulating the service request into a Dubbo request and sending the Dubbo request to the Dubbo service module includes:

s1021, decoding the service request according to a preset transmission protocol specification to obtain a request message;

s1022, determining the message type of the request message according to the message content of the request message;

and S1023, if the message type of the request message is a service request message, packaging the request message into a Dubbo request and sending the Dubbo request to a Dubbo service module.

Specifically, for example, in the above-mentioned customized Remote Procedure Call (RPC) protocol SIH protocol, after receiving a service request from the SIH server, the inbounddapper server first needs to unpack to solve the problem of sticky packets, then decodes according to the standard of the SIH TCP transmission protocol to obtain a request message (SIH message), and then distinguishes whether the service request message is a service request message or an access and heartbeat response message according to the content of the message. If the service request message is the service request message, the message is packaged into a Dubbo request and submitted to the DSF framework for processing.

As shown in fig. 3, 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 then sending the Dubbo request to the Dubbo service module includes:

s10231, if the message type of the request message is a service request message, determining a Dubbo service module to be called according to the name of the Dubbo service module in the request message;

and S10232, simulating the service consumer by using the generalization gateway to send a Dubbo request to the Dubbo service module.

Specifically, taking the above SIH protocol as an example, after receiving a service request of the SIH, the processing logic is as follows:

(1) Analyzing the SIH request message according to the SIH message exchange standard;

(2) Checking input parameters;

(3) Receiving a request by a simulated Provider service Provider method, and starting a processing flow;

(4) Finding the Dubbo service module needing to be called according to the value of the Dubbo service module name field, simulating a Consumer end by using a generalization gateway GenericService to send an RPC request to the Dubbo service module, synchronously blocking the current thread, and waiting for the result to return (the default is overtime for 5 s).

As shown in fig. 4, in some embodiments, the sending the service processing result data to the application server includes:

s1041, according to the service processing result data, establishing a response message according to the preset transmission protocol standard;

s1042, sending the response message to the application server.

Specifically, continuing with the above SIH protocol as an example, after step (4), the processing logic is as follows:

(5) Receiving return data of the Dubbo service;

(6) Constructing an SIH response message according to an SIH message exchange standard;

(7) And sending the constructed message to a calling party.

As shown in fig. 5, in some embodiments, the method further comprises:

s105, acquiring an IP address list of an application server pushed by a configuration center, wherein the IP address of the application server is maintained in the configuration center;

s106, registering virtual service to a registration center according to the IP address list of the application server;

s107, subscribing the virtual service.

Specifically, in a service discovery link, an inboundbeacon is used as a consumer of the SIH, subscribes to a mockService for service discovery, and realizes functions of TCP connection creation, connection reconnection, heartbeat management, dynamic service increase and decrease and the like, and the SIH does not sense the mockService.

The DSF framework is based on the Dubbo implementation, subscribing to services from the service registry by default. When the address of the service changes, the Dubbo will dynamically adjust the explorer to support the dynamic change of the service provider.

Since the SIH does not employ the DSF framework, it cannot register a service with a service registry. In order to support the characteristic that the SIH Tcp Server changes dynamically, a registry factor needs to be extended to realize service discovery by interfacing with an Apollo configuration center so as to support the dynamic increase and decrease of the Tcp Server. Specifically, the configuration center subscribes the IP address configuration of the Tcp Server, and the receiving end registers the virtual service to the registration center according to the IP address list pushed by the configuration center and subscribes the virtual service.

As shown in fig. 6, in some embodiments, the registering the virtual service with the registry according to the IP address list of the application server includes:

s1061, determining a uniform resource locator list of the virtual service according to the IP address list;

s1062, registering the virtual service to a registry according to the uniform resource locator list.

Specifically, a uniform resource locator list (URL) of the virtual service is determined from a list of IP addresses pushed by the configuration center, and then the DSF framework registers the virtual service with the registry according to the URL of the virtual service.

As shown in fig. 7, in some embodiments, the method further comprises:

s108, acquiring a latest application server IP address list pushed by the configuration center;

and S109, updating the uniform resource locator list of the virtual service according to the latest IP address list.

Specifically, the configuration center subscribes the IP address configuration of a Tcp Server, when the IP address changes, the configuration center pushes a changed IP address list, the connection-output end updates the URL of the virtual service according to the latest IP address list, and then the DSF framework dynamically updates the explorer according to the change of the URL of the virtual service.

The implementation logic is as follows:

(1) The list of IP addresses for the SIH Tcp Server is maintained in an Apollo configuration center, for example:

travelsky.adapter.connectAddress[0]＝sih://10.221.157.180:80/com.gykj.adapter.client.sih.consumer.ConsumerServiceconnections＝1；

(2) The method comprises the steps that an output end subscribes an IP address list of an SIH Tcp Server from an Apollo configuration center;

(3) When the SIH Tcp Server changes, an IP address list on an Apollo configuration center is maintained;

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

(5) Monitoring an Apollo configuration center, and immediately updating a local IP address list cache once receiving a new IP address list;

(6) The extended SIH registration center updates the URL list of the virtual service according to the IP address list;

(7) And updating the explorer corresponding to the virtual service by the Dubbo according to the updated URL list.

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

Specifically, in the process of subscribing the virtual service, a connection is created between each application server and each IP address of each application server, and when a service of a certain application needs to be invoked, for example, when a service of a second application needs to be invoked, a service request is sent to an application server of the second application, and the second application is constructed based on a non-Dubbo framework, so far, the practice of using an application (the present application) based on the Dubbo framework as a service consumer (consumer) is realized.

For better understanding of the present application, the request processing method based on the Dubbo framework provided in the present application is described below by a specific embodiment. The complete technical scheme is as follows:

1. InboundAdapter design scheme

The overall application architecture of the inbounddapter is shown in fig. 8. Description of the internal structure of InboundAdapter:

1. when the service consumer is considered to be a service consumer, the function of the service consumer is very similar to that of a DSF consumer, and the DSF framework has very flexible expansion capability (SPI mechanism of Dubbo framework), so a private communication protocol supporting SIH through SPI expansion and an Apollo-based service discovery protocol are designed, and a specific design scheme is shown below.

2. When the service provider is used, the request sent by the SIH Server is encapsulated into a Dubbo request in the encoding and decoding stage, and then the service processing is carried out according to the Dubbo request processing flow.

Description of the calling flow of InboundAdapter:

1. the SIH Tcp service sends a service request message to an InboundAdapter through an SIH Tcp Server;

2. the method comprises the steps that an InboundAdapter access end receives a service request message, decodes the service request message according to the SIH TCP transmission protocol specification, and then packages the SIH message into a request of a DSF framework and submits the request to the DSF framework for processing;

3. the DSF framework calls a reply method of a requestExchangerHandler in SIH Protocol, and calls ProviderService in the reply method;

4. dynamically constructing GenericService based on a DSF framework according to request parameters of a calling party in the ProviderService method, calling a $ invoke method of a GenericService instance, calling a Dubbo service, and waiting for a result;

5. the Dubbo service performs business processing and returns a result;

6. after receiving the result returned by the Dubbo service, the GenericService returns the result to the SIH Tcp Server;

since the inbounddapper is to be used as an SIH service consumer to connect to an SIH TCP Server, to implement functions such as TCP connection creation, connection reconnection, heartbeat management, and dynamic service increase and decrease, the inbounddapper also needs to receive a service request packet sent from the SIH TCP Server, that is, the access end also needs to have the capability of an SIH service provider.

To satisfy the two requirements of the SIH service consumer role and the SIH service provider role at the same time, the inbounddapter is designed as follows:

1. when the InboundAdapter is started, the InboundAdapter is used as an SIH service consumer, an SIH server cluster is regarded as a virtual dubbo service, service subscription is carried out, and functions of TCP connection creation, connection reconnection, heartbeat management, dynamic service increase and decrease and the like are realized;

2. during the operation of the inbounddaemon, as an SIH service provider, a ProviderService is exposed in the JVM to process a service request from the SIH server. When the SIH request message is received, the SIH request is uniformly considered as the invocation of ProviderService in the local JVM, the SIH request is converted into a Dubbo request and is transmitted to the ProviderService for subsequent processing, and the connection of an IO request thread and a service processing thread is realized.

The application architecture of Dubbo-based custom protocol SIH of inbounddapter is shown in fig. 9:

1. subscribing to SIH service clusters as service consumers

1) Xml document, publishing service consumer

2. Exposing mockservice service using SIH protocol in JVM as service provider

1) Xml document, distribution service provider

2) Exposure device for realizing SIH protocol service

3) Translating SIH requests into calls to mockProvider

Judging whether the SIH message is a request message or a response message;

if the request message is the request message, establishing a call invocation of the mockProvider;

and finally, generalizing and calling the service of the DSF in the mockProvider.

2. Specific implementation of InboundAdapter

2.1 extended RegistryFactory

The DSF framework is based on the Dubbo implementation, subscribing to services from the service registry by default. When the address of the service changes, the ducbo dynamically adjusts the explorer to support the dynamic change of the service provider.

Since the SIH does not adopt the DSF framework, it is not able to register a service with the service registry. In order to support the characteristic that the SIH Tcp Server changes dynamically, a registry factor needs to be extended to realize service discovery by interfacing with an Apollo configuration center so as to support the dynamic increase and decrease of the Tcp Server.

Subscribing the IP address configuration of a Tcp Server from a configuration center, pushing a changed IP address list by the configuration center after the IP address is changed, updating the URL of the virtual service by a receiving-outputting terminal according to the latest IP address list, and dynamically updating the explorer by a DSF framework according to the change of the URL of the virtual service.

The implementation logic is as follows:

1. the list of IP addresses for the SIH Tcp Server is maintained in an Apollo configuration center, for example:

2. the method comprises the steps that an access terminal subscribes an IP address list of an SIH Tcp Server from an Apollo configuration center;

3. when the SIH Tcp Server changes, an IP address list on an Apollo configuration center is maintained;

4. apollo configuration center pushing changed IP addresses listing to an extended SIH registry;

5. monitoring an Apollo configuration center, and immediately updating a local IP address list cache once receiving a new IP address list;

6. the extended SIH registration center updates the URL list of the virtual service according to the IP address list;

7. and the Dubbo updates the explorer corresponding to the virtual service according to the updated URL list.

The extended registry factory mainly comprises the following classes:

1. SihRegistry class

(1) And self-defining the SihRegistry class and inheriting the FailbackRegistry class.

(2) The method mainly comprises the steps that an Apolloclient is used for obtaining an SIH TCP Server list from an Apollo configuration center, and the change condition of the SIH TCP Server list is monitored;

(3) And when the SIH TCP Server list changes, dynamically updating the URL list of the virtual service.

(4) And the Dubbo updates the corresponding explorer of the virtual service according to the updated URL list so as to realize the dynamic change of the service provider.

2. SihRegistry factory class

(1) And self-defining the SihRegistryFactory class and inheriting the AbstractRegistryFactory class.

(2) This class, as the sihRegistry factory class, is used primarily to create and return the sihRegistry object from the URL.

3. SpringBootPolorRefreshConfig class

(1) And adding a new SpringBootPolollRefreshConfig as a monitoring event of Apollo, and immediately updating the local cache of the IP address list once monitoring the IP address list of the SIH Tcp Server pushed by Apollo.

2.2 extended explorer

And self-defining a SihInvoker class, inheriting a com, alibaba, dubbo, rpc, protocol, abstract Invoker class, and realizing a construction method and a rewriting doInvoke method.

The SihInvoker enables the SihProtocol to have the role of a subscriber, namely, the SihInvoker serves as a client, sends a connection initialization message and a heartbeat message to the SIH TCP Server, and receives a returned processing result.

1. The construction method comprises the following steps:

(1) Calling a construction method of a parent class;

(2) The SIH system performs identity division on nodes (essentially opposite ends of each TCP connection) interacting with the SIH system, wherein one node only actively sends a transaction to the SIH system and receives the transaction, and the other node only passively receives a request of the SIH system and returns a result, and does not actively send the transaction. In order to support the characteristic, a special process needs to be performed in the sihinvoke class, that is, an identity message is sent to the SIH system for each TCP link in the constructor, and the invoker is set to be available after the SIH system returns an acknowledgement message.

2. doInvoke method functional description:

(1) Constructing an RpcInvitation subject;

(2) Selecting an available ExchangeClient from the array of the exchangeclients according to a load balancing strategy;

(3) Sending TCP requests using an exchangeable client

(4) Receiving a returned result;

2.3 extended Exporter

And self-defining a SihExporter class, inheriting a com.

The SihOxporter enables the SihProtocol to have the role of Provider, namely the SihOxporter serves as a Server, receives a service request message sent by the SIH TCP Server and returns a processing result.

1. The construction method comprises the following functional description:

(1) Calling a construction method of a parent class;

(2) Adding the SihExporter object into a cache exportMap, wherein the key format is group/interface: version;

2. description of unexport method function:

(1) Calling a unexport method of a parent class;

(2) Deleting the SihExporter object from the cached exporterMap;

2.4 extended Protocol

The method comprises the steps of self-defining a SihProtocol class, inheriting a com, alibaba, dubbo, rpc, protocol, abstract protocol, rewriting a refer method, rewriting an export method and realizing a getClients method.

1. Functional description of the refer method:

(1) And according to the input interface type and the URL, creating a SihInvoker object and adding the SihInvoker object into invokers cache.

2. Export method function description:

(1) From the input abstract proxyiexplorer object, a SihExporter object is created. The abstract ProxyInvoker object is an agent class of local specific services, and a com.

3. getClients method functional description:

(1) Acquiring connections of SIH TCP virtual service from a configuration center;

(2) Sequentially creating an exchangeable object according to the connection number of connections, and creating a TCP connection with an SIH TCP Server;

(3) And storing the created ExchangeClient object in an array for the SihInvker to use.

In addition, in the sip protocol class, the custom exchange handler anonymous class inherits the com.

The exchange handler anonymity class is a core function of the expansion Protocol, and specifically realizes the function of the Provider role of the SihProtocol, namely the exchange handler anonymity class is used as a Server, receives a service request message sent by the SIH TCP Server and returns a processing result.

The exchange handler mainly implements a replay method:

1. reply method functional description:

(1) Searching a corresponding SihExporter according to the ServiceKey;

(2) Acquiring a proxy object Abstract explorer of a local service method from the SihExporter;

(3) Invoking an invoke method of an abstract explorer to complete service invocation;

(4) And returning a service processing result.

2.5 extended Codec2

The SIH TCP transport protocol format is as follows:

4bytes	1byte	4bytes	content
				magic	cmd	length	content

1. magic: field length 4 bytes (32 bits) for protocol differentiation

Fixed value: SIHX

2. cmd: the field length is 1byte (8 bits) and is used for indicating the message type. Wherein, 0xA is access verification correlation, 0xB is heartbeat correlation, and 0x3 is service message.

0xA0, accessing SIH request message, initiated by client

0xA1 response message corresponding to SIH access request

A 0xB0 heartbeat request initiated by the client

0xB1: the heartbeat responding by SIH

0x31: synchronization request

0x32: asynchronous requests

0x33: synchronous acknowledgement

0x34: retention

0x35 asynchronous response

0x36 unidirectional message

0x37 Retention

0x38 Retention

0x39 Retention

3. length: a field length of 4 bytes (32 bits) for indicating the length of the entire message

The message length is 4 bytes, the maximum support is 2147483647 (about 1.9G), and the message length does not exceed 512K when in use;

length＝header length+content length。

4. content: the content part of the message is different according to the difference of cmd and the content

In order to realize communication with the SIH TCP Server, parsing of the SIH TCP transport protocol format needs to be realized in the Dubbo framework.

As shown in fig. 10, the SihCodec class is customized, the encode and decode methods in the com.

1. encode method

Description of the function of the encode method:

(1) Firstly, when a message is sent to the SIH, whether the msg is a request or a response is judged to distinguish the message is an access message, a heartbeat message or a service message.

(2) Then, encoding is performed according to the SIH requirements.

(3) And finally, encapsulating and sending the message.

The encode method processing logic is as follows:

(1) And distinguishing an access request message, a heartbeat request message or a service response message through the msg type.

(2) If the msg is of a Request type, indicating that the msg is an access Request message or a heartbeat Request message, then:

firstly, reading the content of an access Request message or a heartbeat Request message from a Request object.

And then constructing an SIH TCP request message according to the SIH TCP transmission protocol format.

And finally, sending the data to the SIH TCP Server through a TCP connection.

(3) If the msg is of a Response type, indicating that the msg is a service Response message, then:

firstly, according to the key reserved in the cmdCache, acquiring response corresponding to the request

And then, returning a corresponding cmd of response according to the cmd value of the request, and if the query is not successful, returning a synchronous response by default.

And finally, constructing an SIH TCP response message according to the SIH TCP transmission protocol format, and sending the SIH TCP response message to the SIH TCP Server through TCP connection.

2. decode method

description of decode method function:

(1) Firstly, receiving a message from the SIH, unpacking the message and solving the problem of packet sticking.

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

(3) And finally, converting the service message into a request object for processing, and converting the access response and the heartbeat response into a response object for processing.

The decode method processing logic is as follows:

(1) Firstly, the content of at most 4 bytes is read from the buffer, and whether each character is SIHX or not is judged in sequence.

(2) If the message is not the message at the beginning of the SIHX, the message is an illegal message. And if the unread messages exist at the moment, reading the rest messages.

Judging whether the following conditions exist in the read message: the substring SIHX, the last bit is S, the last two bits are SI, the last three bits are SIH, and the last four bits are SIHX.

If the situation does not exist, the read message is an illegal message, processing is not carried out, the read message is directly skipped over, and then null is returned.

If the situation exists, the character string from the message header to the position where the sub character string appears is indicated to be an illegal message, and the illegal message is not processed and is directly skipped. The readerIndex of buffer is set to the position where the substring appears so that the processing continues in the next loop.

(3) And if the message is the message at the beginning of the S, SI, SIH or SIHX, judging whether the length of the readable message is less than 9.

If the Length of the readable message is less than or equal to 9, which indicates that the read content of the SIH message does not contain CMD with 1byte and Length with 4 bytes, and the subsequent message content NEEDs to be continuously read, directly returning to NEED _ MORE _ INPUT.

And if the length of the readable message is more than 9, which indicates that the read content of the SIH message already contains 1-byte CMD and 4-byte length, unpacking, normally analyzing the message, and continuing the subsequent processing.

(4) And judging whether the readable message length readable in the buffer is greater than or equal to the content length represented by the length in the SIH message.

If the readable is smaller than length, which indicates that only part of SIH message is read and the content of the subsequent SIH message NEEDs to be continuously read, directly returning NEED _ MORE _ INPUT.

And if the readable is more than or equal to the length, reading the message content with the length, and continuing the subsequent processing.

(5) And judging whether the content read this time is 0x0A or not.

If the content is not 0x0A, it needs to analyze whether the content has SHIX, if so, the previous invalid request is returned to null directly.

If the message is 0x0A, the message is proved to be normal without losing the message, and the subsequent processing is continued.

(6) And finally, confirming whether the returned result is an access verification message, a heartbeat message or a service message according to the cmd.

If the access verification message and the heartbeat message exist, the requestId needs to be taken out from the cache, a Response object is constructed, and then the Response is returned.

If the message is a service message, the Request Id needs to be extracted from the callback data by analyzing the service object, the Request object is constructed, and then the Request is returned.

2.6 extended exchange

The extension exchange related class is mainly used for adapting to the heartbeat protocol of the SIH, and mainly comprises the following classes:

1. SihHeaderExchangchannel class

(1) And self-defining the SihHeaderExchangeChannel type to realize an ExchangeChannel interface.

(2) The channel type is mainly used for managing a channel of Netty, and has the functions of sending heartbeat messages, receiving the heartbeat messages, closing the channel and the like by using the channel.

2. SihHeaderExchangeClient class

(1) And self-defining the SihHeaderExchangeClient class to realize an ExchangeClient interface.

(2) The SihHeaderExchangeChannel is encapsulated in the construction method.

(3) The method for rewriting the connection adds the function of sending the initialized connection information to the SIH TCP Server after the connection is established.

(4) And realizing a startHeatbeatTimer method and a stopHeatbeatTimer method, and starting or closing the heartbeat timing task.

(5) And realizing a startReconnectTimer method and a stopReconnectTimer method, and starting or closing a reconnection timing task.

3. SihHeaderExchangers

(1) And self-defining the SihHeaderExchanger class, realizing an Exchanger interface and using the SihHeaderExchanger interface as an SPI extension class of the Exchanger.

(2) And rewriting a connect method, and creating and returning a SihHeaderExchangeClient object.

(3) And rewriting the bind method, and creating and returning a HeaderExchangeServer object.

4. SihHeartTask class

(1) And self-defining a SihHeartTask class, realizing a Runnable interface and serving as an SPI extension class of the Exchanger.

(2) A run method is rewritten to send a heartbeat message.

1. ReconnectTimerTask class

(1) And (4) customizing a ReconnectTimerTask class, realizing a Runnable interface, and using the Runnable interface as an SPI extension class of the Exchanger.

(2) And a run rewriting method triggers reconnection operation once the channel is closed or the channel cannot receive a heartbeat return message.

2.7 service provider implementation

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

1. analyzing the SIH request message according to SIH message exchange standard;

2. checking input parameters;

3. receiving a request through a simulated Provider service Provider method, and starting a processing flow;

4. finding the Dubbo service needing to be called according to the value of the Dubbo service name field, simulating a Consumer end by using a generalization gateway GenericService to send an RPC request to the Dubbo service, synchronously blocking the current thread, and waiting for the result to return (the default is overtime for 5 s);

5. receiving return data of the Dubbo service;

6. constructing an SIH request message according to an SIH message exchange standard;

7. and sending the constructed message to a calling party.

The technical solution provided by this embodiment realizes the function transition of the Consumer from a single service Consumer role to a role having both the service Consumer and the service provider simultaneously in the Dubbo framework, and the transition to some special scenarios of Dubbo application provides technical references, and the related scenarios mainly include:

1. the client system is always used as a server side, and all calling parties are used as client sides;

2. the InboundAdapter is used as a service responder to access a client system and used as a service provider to provide Dubbo service for a client;

3. the client system does not adopt a Dubbo framework;

4. the client system communication protocol is a TCP protocol;

fig. 11 is a schematic structural diagram of a request processing apparatus based on a Dubbo frame according to an embodiment of the present application, and as shown in fig. 11, the request processing apparatus based on a Dubbo frame according to the embodiment of the present application includes:

a first obtaining module 21, configured to obtain a service request sent by a first application through an application server, where the first application is built based on a non-libbo framework;

the first sending module 22 is configured to encapsulate the service request into a Dubbo request and send the Dubbo request to the Dubbo service module;

a second obtaining module 23, configured to obtain service processing result data generated by the Dubbo service module according to the Dubbo request;

a second sending module 24, configured to send the service processing result data to the application server.

In the application example of the Dubbo frame-based request processing apparatus provided in the embodiment of the present application, taking the above Dubbo frame-based application inboandaper and non-Dubbo frame-based application SIH as examples, in a service invocation link, an inboandaper server receives a service request sent by an SIH server, encapsulates the service request of the SIH into a Dubbo request in a coding and decoding stage, and then sends the Dubbo request to a Dubbo service module, which is provided by a Dubbo service module departure system, and the departure system is also constructed based on the Dubbo frame and is used for providing a service processing function. And the Dubbo service module generates service processing result data according to the Dubbo request and returns the service processing result data to the InboundAdapter server, and the InboundAdapter server returns the service processing result data to the SIH server. Up to this point, the technical goal of providing a Dubbo service for a non-Dubbo framework based application as a service provider is achieved.

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

decoding the service request according to a preset transmission protocol standard to obtain a request message;

determining the message type of the request message according to the message content of the request message;

and if the message type of the request message is a service request message, packaging the request message into a Dubbo request and sending the Dubbo request to a Dubbo service module.

In some embodiments, if the message type of the request message is a service request message, the encapsulating the request message into a Dubbo request and sending the Dubbo request to the Dubbo service module by the first sending module includes:

if the message type of the request message is a service request message, determining a Dubbo service module to be called according to the name of the Dubbo service module in the request message;

simulating a service consumer sending a Dubbo request to the Dubbo service module using a generalization gateway.

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

constructing a response message according to the preset transmission protocol standard according to the service processing result data;

and sending the response message to the application server.

In some embodiments, the apparatus further comprises:

a third obtaining module, configured to obtain an IP address list of an application server pushed by a configuration center, where an IP address of the application server is maintained in the configuration center;

the registration module is used for registering virtual service to a registration center according to the IP address list of the application server;

and the subscription module is used for subscribing the virtual service.

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

determining a uniform resource locator list of virtual services according to the IP address list;

and registering the virtual service to a registry according to the uniform resource locator list.

In some embodiments, the apparatus further comprises:

a fourth obtaining module, configured to obtain a latest IP address list of the application server pushed by the configuration center;

and the updating module is used for updating the uniform resource locator list of the virtual service according to the latest IP address list.

In some embodiments, the apparatus further comprises: and the third sending module is used for sending the service request to an application server of a second application, wherein the second application is constructed based on a non-Dubbo framework.

The embodiments of the apparatus provided in the embodiments of the present application may be specifically configured to execute the processing flows of the foregoing method embodiments, and the functions of the apparatus are not described herein again, and refer to the detailed description of the foregoing method embodiments.

It should be noted that the request processing method and apparatus based on the Dubbo frame provided in the embodiment 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.

Fig. 12 is a schematic physical structure diagram of an electronic device according to an embodiment of the present application, and as shown in fig. 12, the electronic device may include: a processor (processor) 301, a communication Interface (communication Interface) 302, a memory (memory) 303 and a communication bus 304, wherein the processor 301, the communication Interface 302 and the memory 303 complete communication with each other through the communication bus 304. The processor 301 may call logic instructions in the memory 303 to perform a method as described in any of the embodiments above.

In addition, the logic instructions in the memory 303 may be implemented in the form of software functional units and stored in a computer readable storage medium when the logic instructions are sold or used as independent products. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The present embodiments disclose a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by a computer, enable the computer to perform the methods provided by the above-described method embodiments.

The present embodiment provides a computer-readable storage medium storing a computer program that causes a computer to execute the method provided by the above-described method embodiments.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In the description herein, reference to the description of the terms "one embodiment," "a particular embodiment," "some embodiments," "for example," "an example," "a particular example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

The above-mentioned embodiments are provided to further explain the objects, technical solutions and advantages of the present application in detail, and it should be understood that the above-mentioned embodiments are only examples of the present application and are not intended to limit the scope of the present application, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present application should be included in the scope of the present application.

Claims

1. A request processing method based on a Dubbo framework is characterized by comprising the following steps:

and sending the service processing result data to the application server.

2. The method of claim 1, wherein the encapsulating the service request into a Dubbo request and sending the Dubbo request to a Dubbo service module comprises:

decoding the service request according to a preset transmission protocol specification to obtain a request message;

3. The method of claim 2, wherein if the message type of the request message is a service request message, encapsulating the request message into a Dubbo request and then sending the Dubbo request to a Dubbo service module comprises:

4. The method of claim 2, wherein the sending the business process result data to the application server comprises:

and sending the response message to the application server.

5. The method of claim 1, further comprising:

acquiring an IP address list of an application server pushed by a configuration center, wherein the IP address of the application server is maintained in the configuration center;

registering virtual service to a registration center according to the IP address list of the application server;

subscribing to the virtual service.

6. The method of claim 5, wherein registering the virtual service with the registry according to the list of IP addresses of the application servers comprises:

7. The method of claim 6, further comprising:

acquiring a latest application server IP address list pushed by the configuration center;

and updating the uniform resource locator list of the virtual service according to the latest IP address list.

8. The method of any of claims 5 to 7, wherein after subscribing to the virtual service, the method further comprises:

sending a service request to an application server of a second application, wherein the second application is built based on a non-Dubbo framework.

9. A request processing apparatus based on a Dubbo framework, comprising:

10. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the method of any one of claims 1 to 8 when executing the computer program.

11. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 8.