Service subscription method and apparatus based on Dubbo framework

Abstract

This application provides a service subscription method and apparatus based on the Dubbo framework, which can be used in the financial field or other technical fields. The method includes: obtaining a list of application server IP addresses pushed by a configuration center, wherein the application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework; registering a virtual service with a registration center according to the application server IP address list; and subscribing to the virtual service. The apparatus is used to execute the above method. The service subscription method and apparatus based on the Dubbo framework provided in this application embodiment realizes communication between a service provider based on a non-Dubbo framework and a service caller based on the Dubbo framework.

Description

Technical Field

[0001] This application relates to the financial or other technical fields, specifically to a service subscription method and apparatus based on the Dubbo framework. Background Technology

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

[0003] To address the problems in the prior art, this application provides a service subscription method and apparatus based on the Dubbo framework, which can at least partially solve the problems existing in the prior art.

[0004] On one hand, embodiments of this application provide a service subscription method based on the Dubbo framework, including:

[0005] Get the list of application server IP addresses pushed by the configuration center, where the application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework;

[0006] Register virtual services with the registry center based on the list of application server IP addresses;

[0007] Subscribe to the virtual service.

[0008] On the other hand, embodiments of this application provide a service subscription device based on the Dubbo framework, including:

[0009] The acquisition module is used to acquire a list of application server IP addresses pushed by the configuration center. The application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework.

[0010] The registration module is used to register virtual services with the registration center based on the list of IP addresses of the application server;

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

[0012] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the service subscription method based on the Dubbo framework described in any of the above embodiments.

[0013] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the service subscription method based on the Dubbo framework described in any of the above embodiments.

[0014] The service subscription method and apparatus based on the Dubbo framework provided in this application take the Dubbo-based application OutboundAdapter and the non-Dubbo-based application SIH as examples. Since SIH does not use the DSF framework, it cannot register services with the service registry. OutboundAdapter is essentially a consumer of the DSF framework. In order to interface with the SIH system, a "virtual" DSF service is designed, allowing the OutboundAdapter to subscribe to and call it, thus realizing communication between the non-Dubbo-based service provider and the Dubbo-based service caller. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0016] Figure 1 This is a flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0017] Figure 2 This is a partial flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0018] Figure 3 This is a partial flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0019] Figure 4 This is a partial flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0020] Figure 5 This is a partial flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0021] Figure 6 This is a partial flowchart illustrating a service subscription method based on the Dubbo framework provided in one embodiment of this application.

[0022] Figure 7 This is a schematic diagram of the overall application architecture of OutboundAdapter provided in one embodiment of this application.

[0023] Figure 8 This is a schematic diagram of the architecture of the DFS framework provided in one embodiment of this application.

[0024] Figure 9 This is a flowchart illustrating an encoding and decoding method based on the SIH TCP transmission protocol provided in an embodiment of this application.

[0025] Figure 10 This is a schematic diagram of the structure of a service subscription device based on the Dubbo framework provided in an embodiment of this application.

[0026] Figure 11 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit this application. It should be noted that, unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily arranged.

[0028] The terms “first,” “second,” etc., used in this document are not intended to specifically refer to order or sequence, nor are they used to limit this application; they are merely used to distinguish elements or operations described using the same technical terms.

[0029] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0030] The term "and / or" as used in this document includes any or all of the items mentioned.

[0031] To better understand this application, the research background of this application will be introduced in detail below:

[0032] Dubbo: A distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions.

[0033] DSF: A distributed service platform implemented by ICBC based on Dubbo, providing service-oriented applications with functions such as a registration center, service gateway, and monitoring and management, enabling service consumers to quickly find and use services, and realizing the monitoring and management of the service call process.

[0034] For an application based on the Dubbo framework (let's assume the application name is OutboundAdapter), if it needs to communicate with another non-Dubbo application (let's assume the application name is SIH) via TCP protocol, and the two parties have the following limitations:

[0035] 1. SIH is implemented in C++ and does not use the Dubbo framework;

[0036] 2. The communication protocol is TCP.

[0037] 3. SIH acts as the server, and OutboundAdapter acts as the service access point to access SIH. The communication method is synchronous response.

[0038] 4. The client periodically sends heartbeat data to SIH;

[0039] In addition to the aforementioned limitations, if one wishes to utilize the mature and stable features of the Dubbo framework, such as TCP connection creation, connection reconnection, heartbeat management, and dynamic addition and removal of services, then the existing protocols of the Dubbo framework cannot support these features.

[0040] This application, based on the Dubbo framework and following the Dubbo framework's SPI extension mechanism, defines a custom RPC protocol (assuming the protocol name is SIH protocol). Within the SIH protocol, a service consumer role is implemented, enabling communication with non-Dubbo framework applications via the native TCP protocol.

[0041] The main points of this application include:

[0042] 1. Define a virtual Dubbo service: Since the service discovery and service invocation of the Dubbo framework are based on services, and the SIH system does not have this service model of the Dubbo framework, it is necessary to let the Dubbo Consumer subscribe to and invoke a virtual service. The name of this service can be arbitrary.

[0043] 2. Extending RegistryFactory: The Dubbo framework subscribes to services from the service registry by default. When a service's address changes, Dubbo dynamically adjusts the Invoker to support these changes. Since SIH does not use the Dubbo framework, it cannot register services with the service registry. To support SIH's dynamic changes, RegistryFactory needs to be extended to interface with the Apollo configuration center for service discovery, enabling the dynamic addition and removal of SIH's TCP servers.

[0044] 3. Extend Protocol: Implement custom SihProtocol and SihInvoker classes to interface with SIH's TCP data exchange protocol;

[0045] 4. Extend Codec2: Implement the SihCodec class to complete the encoding and decoding of the SIH protocol.

[0046] (1) Encode implementation: When sending TCP connection initialization messages, heartbeat messages, and service messages to SIH, encode and send them according to SIH requirements;

[0047] (2) Decode implementation: When receiving response messages from SIH, decrypt and process them according to SIH requirements;

[0048] 5. Extend Exchanger: This is mainly to adapt to the SIH heartbeat protocol, and involves a significant amount of new code, specifically including the following classes:

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

[0050] (2) The SihHeaderExchangeClient class: is used to encapsulate the SihHeaderExchangeChannel;

[0051] (3) SihHeaderExchanger: Used as an SPI extension class for Exchanger;

[0052] (4) SihHeartBeatTask: Used to send heartbeat messages;

[0053] (5) ReconnectTimerTask: A reconnection operation will be triggered if the channel is closed or the channel does not receive a heartbeat return message.

[0054] The following provides a detailed description of the service subscription method and apparatus based on the Dubbo framework provided in this application:

[0055] The execution subject of the service subscription method based on the Dubbo framework provided in this application embodiment includes, but is not limited to, a computer.

[0056] Figure 1 This is a flowchart illustrating a service subscription method based on the Dubbo framework provided in an embodiment of this application, as shown below. Figure 1 As shown in the embodiment of this application, a service subscription method based on the Dubbo framework is provided, including:

[0057] S101. Obtain the list of application server IP addresses pushed by the configuration center, wherein the application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework.

[0058] S102. Register the virtual service with the registration center according to the list of IP addresses of the application server;

[0059] S103. Subscribe to the virtual service.

[0060] Specifically, taking the Dubbo-based application OutboundAdapter and the non-Dubbo-based application SIH as examples, since SIH does not use the DSF framework, it cannot register services with the service registry. OutboundAdapter is essentially a consumer of the DSF framework. To interface with the SIH system, a "virtual" DSF service is designed, allowing the OutboundAdapter to subscribe to and invoke it, thus enabling communication between the non-Dubbo-based service provider and the Dubbo-based service caller.

[0061] like Figure 2 As shown, in some embodiments, registering the virtual service with the registry center based on the application server's IP address list includes:

[0062] S1021. Determine the Uniform Resource Locator (URL) list for the virtual service based on the IP address list;

[0063] S1022. Register the virtual service to the registry center according to the Uniform Resource Locator list.

[0064] Specifically, the Uniform Resource Locator (URL) list of virtual services is determined based on the IP address list pushed by the configuration center, and then the virtual service is registered with the registration center based on the virtual service URL.

[0065] like Figure 3 As shown, in some embodiments, the method further includes:

[0066] S104. Obtain the latest list of application server IP addresses pushed by the configuration center;

[0067] S105. Update the Uniform Resource Locator (URL) list of the virtual service according to the latest list of IP addresses.

[0068] Specifically, the system subscribes to the TCP server's IP address configuration from the configuration center. When an IP address changes, the configuration center pushes a list of changed IP addresses. The outgoing end updates the virtual service's URL based on the latest IP address list, and then the DSF framework dynamically updates the Invoker based on the changes in the virtual service's URL. The reference implementation logic is as follows:

[0069] 1. Maintain the list of SIH TCP Server IP addresses in the Apollo configuration center, for example:

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

[0071] 2. The outgoing end subscribes to the list of IP addresses of the SIH TCP Server from the Apollo configuration center;

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

[0073] 4. The Apollo configuration center pushes the list of changed IP addresses to the extended SIH registry center;

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

[0075] 6. The expanded SIH registry updates the list of virtual service URLs based on the list of IP addresses;

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

[0077] like Figure 4 As shown, in some embodiments, after subscribing to the virtual service, the method further includes:

[0078] S106. Obtain the service request sent by the external Dubbo service;

[0079] S107. Send the service request to the application server.

[0080] Specifically, the external Dubbo service calls the OutboundAdapter's access service through the DSF framework; the access service receives the service request from the external Dubbo service and then sends the service request to the application server.

[0081] like Figure 5 As shown, in some embodiments, sending the service request to the application server includes:

[0082] S1061. Construct a request message according to the service request and in accordance with the custom transmission protocol specification;

[0083] S1062. Send the request message to the application server.

[0084] Specifically, the SIH TCP request message is constructed according to the SIH TCP transport protocol specification, and finally sent to the SIH TCP Server through a TCP connection.

[0085] like Figure 6 As shown, in some embodiments, after sending the service request to the application server, the method further includes:

[0086] S108. Obtain the response message generated by the application server based on the request message;

[0087] S109. Decode the response message according to the custom transmission protocol specification to obtain the service processing result data;

[0088] S110. Send the business processing result data to the external Dubbo service.

[0089] Specifically, after encoding the message and sending it to the backend SIH service, it also receives a response; after decoding the received response message according to the custom transmission protocol specification, the resulting business processing data is fed back to the external Dubbo service.

[0090] In some embodiments, an application based on the Dubbo framework (e.g., an application OutboundAdapter) communicates with another non-Dubbo application (e.g., an application SIH) via the TCP protocol. Sending the request message to the application server includes: sending the request message to the application server via a TCP connection; obtaining the response message generated by the application server based on the request message includes: obtaining the response message sent by the application server via the TCP connection, wherein the response message is generated by the application server based on the request message.

[0091] To better understand this application, a specific embodiment is provided below to illustrate the service subscription method based on the Dubbo framework provided in this application. The complete technical solution is as follows:

[0092] I. OutboundAdapter Design Scheme

[0093] The overall application architecture of OutboundAdapter is as follows: Figure 7 The internal structure of OutboundAdapter is shown below:

[0094] When accessing the SIH TCP Server as a client, considering that its function is very similar to that of a DSF consumer, and that the DSF framework itself has very flexible extensibility (the SPI mechanism of the Dubbo framework), the design is to support SIH's private communication protocol and the service discovery protocol based on Apollo through SPI extension. The specific design scheme is as follows.

[0095] OutboundAdapter call flow description:

[0096] 1. External Dubbo services call the OutboundAdapter's access service through the DSF framework;

[0097] 2. The access service receives the request message from the external Dubbo service and then forwards the message to the outgoing module (which is essentially a consumer of the DSF framework);

[0098] 3. The outgoing module calls a mock interface according to the standard DSF consumer call mode. The DSF framework will encode the message and send it to the backend SIH service and receive the response. The entire call adopts synchronous mode.

[0099] 4. As a consumer, the outgoing module also subscribes to the Apollo registry center to enable service discovery, supporting the dynamic addition and reduction of TCP server connections.

[0100] OutboundAdapter is essentially a consumer of the DSF framework. In order to interface with the SIH system, it is designed as follows:

[0101] 1. Design a "virtual" DSF service that allows the receiving end to subscribe to and call;

[0102] 2. Extend the DSF framework to adapt to the SIH protocol.

[0103] The core of the design is the extension of the DSF framework. In general, the outgoing end needs to interface with Apollo as the registry center, adapt to the SIH message protocol, and adapt to the SIH heartbeat mechanism. Its architecture diagram is as follows: Figure 8 As shown.

[0104] II. Specific Implementation of OutboundAdapter

[0105] 1. Virtual Dubbo service

[0106] Since the Dubbo framework's service discovery and service invocation are all based on services, and the SIH system does not have this service model of the Dubbo framework, the outgoing end needs to subscribe to and invoke a virtual service, and the name of this service can be arbitrary.

[0107] Define a virtual service interface, MockService, which serves as the stub for the service provided by the Sih TCP Server within the Dubbo framework. Since this interface is only used as a service reference, a concrete implementation class is not required.

[0108] The MockService interface contains a mockMethod method, which is defined as follows:

[0109] Input parameters: Request type Object and message type int.

[0110] Output parameter: A collection of type Map;

[0111] 2. Extend RegistryFactory

[0112] The DSF framework is implemented based on Dubbo and subscribes to services from the service registry by default. When a service's address changes, Dubbo dynamically adjusts the Invoker to support the dynamic changes in service providers.

[0113] Since SIH does not use the DSF framework, it cannot register services with the service registry. To support the dynamic change of SIH TcpServers, the RegistryFactory needs to be extended to interface with the Apollo configuration center to implement service discovery, thus supporting the dynamic addition and removal of TcpServers.

[0114] The system subscribes to the TCP server's IP address configuration from the configuration center. When an IP address changes, the configuration center pushes a list of changed IP addresses. The outgoing end updates the virtual service's URL based on the latest IP address list, and then the DSF framework dynamically updates the Invoker based on the changes in the virtual service's URL. The reference implementation logic is as follows:

[0115] (1) Maintain the list of SIH TCP Server IP addresses in the Apollo configuration center, for example:

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

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

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

[0119] (4) The Apollo configuration center pushes the list of changed IP addresses to the extended SIH registry center;

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

[0121] (6) The extended SIH registry updates the list of virtual service URLs based on the list of IP addresses;

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

[0123] The extended RegistryFactory mainly includes the following classes:

[0124] (1) SihRegistry class

[0125] 1) Define a custom SihRegistry class that inherits from the FailbackRegistry class.

[0126] 2) This class mainly uses ApolloClient to obtain the SIH TCP Server list from the Apollo configuration center and listens for changes in the SIH TCP Server list;

[0127] 3) When the SIH TCP Server list changes, the list of virtual service URLs is dynamically updated.

[0128] 4) Dubbo updates the Invoker corresponding to the virtual service based on the updated URL list to enable dynamic changes in the service provider.

[0129] (2) SihRegistryFactory class

[0130] 1) Define a custom SihRegistryFactory class that inherits from the AbstractRegistryFactory class.

[0131] 2) This class serves as the SihRegistry factory class, primarily used to create and return SihRegistry objects based on the URL.

[0132] (3)SpringBootApolloRefreshConfig class

[0133] Add a new SpringBootApolloRefreshConfig as an Apollo listener event. Once the list of IP addresses of the SIH TCP Server pushed by Apollo is detected, the local cache of the IP address list will be updated immediately.

[0134] 3. Extend Invoker

[0135] Create a custom SihInvoker class that inherits from the com.alibaba.dubbo.rpc.protocol.AbstractInvoker class, implement the constructor, and override the doInvoke method.

[0136] SihInvoker enables SihProtocol to function as a Consumer, acting as a client to send connection initialization messages, heartbeat messages, and service messages to the SIH TCPServer, and to receive the returned processing results.

[0137] (1) Description of the constructor function:

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

[0139] 2) The SIH system classifies the nodes it interacts with (essentially the peer of each TCP connection) into two categories: one actively sends transactions to the SIH system and receives responses, while the other passively receives requests from the SIH system and returns results without actively sending transactions. To support this characteristic, a special handling is required in the SihInvoker class. Specifically, in the constructor, an identity information is first sent to the SIH system for each TCP connection, and the invoker is only made available after the SIH system returns an acknowledgment message.

[0140] (2) Description of the doInvoke method:

[0141] 1) Construct an RpcInvocation object;

[0142] 2) Based on the load balancing strategy, select an available ExchangeClient from the ExchangeClient array;

[0143] 3) Use ExchangeClient to send TCP requests

[0144] 4) Receive the returned results.

[0145] 4. Extend Exporter

[0146] Since SihProtocol does not require implementing the Provider role, it does not extend the Exporter interface.

[0147] 5. Extend Protocol

[0148] Create a custom SihProtocol class that inherits from com.alibaba.dubbo.rpc.protocol.AbstractProtocol, override the refer method, override the export method, and implement the getClients method.

[0149] (1) Description of the refer method:

[0150] Based on the input interface type and URL, create a SihInvoker object and add it to the invokers cache.

[0151] (2) Description of the export method:

[0152] Since it is only acting as a service consumer and does not need to implement the local service call, it directly returns null;

[0153] (3) Description of the getClients method:

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

[0155] 2) Based on the number of connections, create ExchangeClient objects sequentially and establish TCP connections with SIHTCPServer;

[0156] 3) Store the created ExchangeClient objects in an array for use by SihInvoker.

[0157] 6. Extend Codec2

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

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

[0160] (1) magic: Field length 4 bytes (32 bits), used for protocol differentiation

[0161] Fixed value: SIHX

[0162] (2) cmd: Field length 1 byte (8 bits), used to indicate the message type. Among them, 0xA* access verification related, 0xB* heartbeat related, 0x3* business message.

[0163] 0xA0: SIH access request message, initiated by the client.

[0164] 0xA1: The response message corresponding to the SIH access request.

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

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

[0167] 0x31: Synchronization Request

[0168] 0x32: Asynchronous Request

[0169] 0x33: Synchronous Response

[0170] 0x34: Reserved

[0171] 0x35: Asynchronous response

[0172] 0x36: One-way message

[0173] 0x37: Reserved

[0174] 0x38: Reserved

[0175] 0x39: Reserved

[0176] (3) length: The field length is 4 bytes (32 bits), used to represent the length of the entire message.

[0177] Message length: 4 bytes, maximum supported size: 2147483647 (approximately 1.9G), do not exceed 512KB during use.

[0178] length=header length+content length

[0179] (4) content: The message content section. The content varies depending on the cmd.

[0180] To enable communication with the SIH TCP Server, it is necessary to implement the parsing of the SIH TCP transport protocol format within the Dubbo framework.

[0181] like Figure 9 As shown, a custom SihCodec class is defined, which implements the encode and decode methods in the com.alibaba.dubbo.remoting.Codec2 interface to complete the encoding and decoding of the SIH TCP transmission protocol.

[0182] (1) Encode method

[0183] Description of the encode method:

[0184] 1) First, when sending messages to SIH, access messages, heartbeat messages and service messages need to be encoded in accordance with SIH requirements.

[0185] 2) Finally, the message is encapsulated and sent.

[0186] The encode method's processing logic is as follows:

[0187] Since access request messages, heartbeat request messages, and business response messages are all encapsulated as Request type, the processing logic is as follows:

[0188] First, read the message content from the Request object.

[0189] Then, construct the SIH TCP request message according to the SIH TCP transport protocol format.

[0190] Finally, it is sent to the SIH TCP Server via a TCP connection.

[0191] (2) decode method

[0192] Description of the decode method:

[0193] 1) First, receive messages from SIH, unpack them, and resolve the packet merging issue.

[0194] 2) Then, distinguish between business request messages and access and heartbeat response messages based on the message content.

[0195] 3) Finally, the business message response, access response, and heartbeat response are converted into response objects for processing. The decode method's processing logic is as follows:

[0196] 1) First, read up to 4 bytes from the buffer, and check if each character is SIHX. 2) If the message does not start with SIHX, it is considered an invalid message. If there are still unread messages, read the remaining messages.

[0197] Determine if the following conditions exist in the read message: substring SIHX, last character is S, last two characters are SI, last three characters are SIH, and last four characters are SIHX.

[0198] If none of the above conditions apply, it indicates that the message read is an illegal message and no action will be taken.

[0199] Skip directly and return null.

[0200] 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 it is skipped without processing. The buffer's readerIndex is set to the position where the substring appears so that processing can continue in the next loop.

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

[0202] If the readable message length is less than or equal to 9, it means 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 will be returned directly.

[0203] If the length of the readable message is greater than 9, it means that the read SIH message content already contains 1 byte of CMD and 4 bytes of length. Then, the message is unpacked, parsed normally, and processed further.

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

[0205] 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 content of subsequent SIH messages. In this case, NEED_MORE_INPUT will be returned directly.

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

[0207] For the content read this time, determine whether the last value of the business content is 0x0A.

[0208] If it's not 0x0A, you need to parse whether the content contains SHIX. If it does, all previous requests are invalid, and you should return null directly.

[0209] If it is 0x0A, it means that no message was lost, the message is normal, and further processing can continue.

[0210] Finally, retrieve the requestId from the cache, construct a Response object, and then return the Response.

[0211] 7. Extend Exchanger

[0212] Extending the Exchanger-related classes is mainly to adapt to the SIH heartbeat protocol, and mainly includes the following classes:

[0213] (1) SihHeaderExchangeChannel class

[0214] 1) Define a custom SihHeaderExchangeChannel class that implements the ExchangeChannel interface.

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

[0216] (2) SihHeaderExchangeClient class

[0217] 1) Define a custom SihHeaderExchangeClient class that implements the ExchangeClient interface.

[0218] 2) Encapsulate SihHeaderExchangeChannel in the constructor.

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

[0220] 4) Implement the startHeatbeatTimer and stopHeartbeatTimer methods to start or stop the heartbeat timer task.

[0221] 5) Implement the startReconnectTimer and stopReconnectTimer methods to start or stop the reconnect timer task.

[0222] (3) SihHeaderExchanger class

[0223] 1) Define a custom SihHeaderExchanger class that implements the Exchanger interface and serves as the SPI extension class for Exchanger.

[0224] 2) Override the connect method to create and return a SihHeaderExchangeClient object.

[0225] 3) Override the bind method to create and return a HeaderExchangeServer object.

[0226] (4) SihHeartBeatTask class

[0227] 1) Define a custom SihHeartBeatTask class that implements the Runnable interface and serves as the SPI extension class for Exchanger.

[0228] 2) Override the run method to send heartbeat messages.

[0229] (5) ReconnectTimerTask class

[0230] 1) Define a custom ReconnectTimerTask class that implements the Runnable interface and uses it as an extension class for Exchanger's SPI.

[0231] 2) Override the run method to trigger a reconnection operation if the channel is closed or fails to receive a heartbeat message.

[0232] 8. Connection Creation

[0233] SIH's TCP Server technical specifications:

[0234] (1) SIH TCP Server acts as the server, and all callers act as clients;

[0235] (2) There is a limit to the maximum number of connections allowed for each SIH TCP Server;

[0236] (3) The client uses a persistent connection with the SIH TCP Server;

[0237] (4) The client periodically sends heartbeat data to the SIH TCP Server. If the SIH TCP Server does not receive heartbeat data from the client for three consecutive cycles, it considers the client to be offline and the SIH TCP Server will actively close the connection. If the client does not receive heartbeat feedback data from the SIH TCP Server for three consecutive cycles, it considers the connection to be unusable, the client will actively close the connection and recreate a new connection.

[0238] (5) SIH provides the IP address of the TCPServer cluster, and the adaptation layer needs to implement a load balancing strategy;

[0239] (6) For the IP address of the TCPServer cluster provided by SIH, the adaptation layer needs to support dynamic expansion, that is, the adaptation layer can dynamically add or delete the corresponding TCP connection according to the change of the IP address of the TCPServer cluster without restarting.

[0240] In accordance with the above technical specifications, the OutboundAdapter adopts the following approach in its outgoing implementation:

[0241] (1) SihHeaderExchangeClient is the TcpClient defined in the Dubbo extended protocol SihProtocol;

[0242] (2) Create multiple TcpClients in SihProtocol. Each TcpClient maintains one long TCP connection and cannot exceed the maximum number of connections allowed by TcpServer.

[0243] (3) The SihHeaderExchangeClient's business thread pool uses a custom shared thread pool. N SihHeaderExchangeClient instances share one thread pool;

[0244] (4) After the TcpClient long connection is created, the Dubbo Invoker is built. During the construction process, an initialization message needs to be sent through the TcpClient. Only after the TcpServer returns a confirmation message can the TcpClient be considered to have been successfully created.

[0245] (5) One Invoker corresponds to one TcpServer. One Invoker contains multiple SihHeaderExchangeClients.

[0246] (6) For multiple TcpServers, SihProtocol supports load balancing strategies, including random load balancing, round-robin load balancing, and least active load balancing.

[0247] (7) For each TcpServer with multiple SihHeaderExchangeClients, round-robin invocation of load balancing strategies is supported;

[0248] (8) Provide a virtual service MockService for the access service of OutboundAdapter, and send SIH messages to TcpServer through the mockMethod method of MockService. Refer to 6 and 7 for the load balancing strategy.

[0249] (9) Extend the SihRegistryFactory registry center to detect changes in the TcpServer in the apollo configuration center by polling, and dynamically add or delete Invokers.

[0250] (10) During the application startup process, a connection to the TCP Server is created according to the TCP Server configuration in Apollo.

[0251] 9. Connection check and reconnection

[0252] When the TCP connection is idle (i.e., no service packets are sent within a specified time interval, the default interval is 3 seconds), the client periodically sends heartbeat data to the SIH TCP Server. If the SIH TCP Server does not receive heartbeat data from the client for three consecutive cycles, it considers the client to be offline and actively closes the connection; if the client does not receive heartbeat feedback data from the SIH TCP Server for three consecutive cycles, it considers the connection unusable, the client actively closes the connection, and recreates a new connection.

[0253] According to the SIH TCP transmission protocol, set up a timed task to periodically send heartbeat requests (0xB0) and receive responses (0xB1) from the SIH TcpServer.

[0254] If no heartbeat response is received, a reconnection is required. Configure a reconnection task to reconnect after three heartbeat cycles without receiving a heartbeat response.

[0255] The technical solution provided in this embodiment realizes the creation of a new Dubbo protocol within the Dubbo framework by adopting the Dubbo SPI mechanism. This protocol enables Dubbo applications to call services of non-Dubbo applications via TCP. This transformation overcomes some existing limitations of the Dubbo framework, such as its support for only the Java language; the dependence of both service providers and service callers on the Dubbo framework; and the strong interface dependency between service providers and service callers. It provides a technical reference for some special scenarios of Dubbo applications, including:

[0256] 1. The client system does not use Java;

[0257] 2. The client's system does not use the Dubbo framework;

[0258] 3. The client system uses the TCP protocol for communication.

[0259] Figure 10 This is a schematic diagram of the structure of a service subscription device based on the Dubbo framework provided in an embodiment of this application, as shown below. Figure 10 As shown in the embodiment of this application, a service subscription device based on the Dubbo framework includes:

[0260] The acquisition module 21 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, and the application is built based on a non-Dubbo framework;

[0261] Registration module 22 is used to register virtual services with the registration center based on the list of IP addresses of the application server;

[0262] Subscription module 23 is used to subscribe to the virtual service.

[0263] This application provides a service subscription device based on the Dubbo framework. Taking the Dubbo-based application OutboundAdapter and the non-Dubbo-based application SIH as examples, since SIH does not use the DSF framework, it cannot register services with the service registry. OutboundAdapter is essentially a DSF framework consumer. To interface with the SIH system, a "virtual" DSF service is designed, allowing the OutboundAdapter to subscribe to and invoke it, thus enabling communication between the non-Dubbo-based service provider and the Dubbo-based service caller.

[0264] In some embodiments, the registration module is specifically used for:

[0265] Determine the list of Uniform Resource Locators for the virtual service based on the IP address list;

[0266] The virtual service is registered with the registry center based on the Uniform Resource Locator (URL) list.

[0267] In some embodiments, the acquisition module is further configured to: acquire the latest list of application server IP addresses pushed by the configuration center;

[0268] The apparatus further includes an update module, configured to update the Uniform Resource Locator (URL) list of the virtual service based on the latest list of IP addresses.

[0269] In some embodiments, the acquisition module is further configured to acquire service requests sent by external Dubbo services;

[0270] The device further includes a sending module for sending the service request to the application server.

[0271] In some embodiments, the sending module is specifically used for:

[0272] Based on the service request, construct a request message according to the custom transport protocol specification;

[0273] The request message is sent to the application server.

[0274] In some embodiments, the acquisition module is further configured to acquire the response message generated by the application server based on the request message;

[0275] The device further includes: a decoding module, used to decode the response message according to the custom transmission protocol specification to obtain service processing result data;

[0276] The sending module is also used to send the business processing result data to the external Dubbo service.

[0277] In some embodiments, the sending module sending the request message to the application server includes:

[0278] The request message is sent to the application server via a TCP connection;

[0279] The acquisition module acquires the response message generated by the application server based on the request message, including:

[0280] Obtain the response message sent by the application server through the TCP connection, wherein the response message is generated by the application server based on the request message.

[0281] The embodiments of the apparatus provided in this application can be used to execute the processing flow of the above-described method embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the above-described method embodiments.

[0282] It should be noted that the service subscription method and apparatus based on the Dubbo framework provided in this application embodiment can be used in the financial field, or in any technical field other than the financial field. This application embodiment does not limit the application field of the service subscription method and apparatus based on the Dubbo framework.

[0283] Figure 11 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of this application, as shown below. Figure 11 As shown, the electronic device may include a processor 301, a communications interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communications interface 302, and the memory 303 communicate with each other via the communication bus 304. The processor 301 may call logical instructions in the memory 303 to execute the methods described in any of the above embodiments.

[0284] Furthermore, the logical instructions in the aforementioned memory 303 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0285] 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, and when the program instructions are executed by a computer, the computer can perform the methods provided in the above-described method embodiments.

[0286] This embodiment provides a computer-readable storage medium storing a computer program that causes the computer to perform the methods provided in the above-described method embodiments.

[0287] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can 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, etc.) containing computer-usable program code.

[0288] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0289] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0290] 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, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0291] In the description of this specification, the references to terms such as "an embodiment," "a specific embodiment," "some embodiments," "for example," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0292] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A service subscription method based on the Dubbo framework, characterized in that, Applied to Dubbo framework-based clients, including: Get the list of application server IP addresses pushed by the configuration center, where the application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework; Register virtual services with the registry center based on the list of application server IP addresses; The client subscribes to the virtual service, and after subscribing to the virtual service, a long-lived connection is established between the client and the application server. The client periodically sends heartbeat data to the application server. If the application server does not receive heartbeat data from the client for three consecutive periods, the application server closes the connection. If the client does not receive heartbeat feedback data from the client for three consecutive periods, the client closes the connection and creates a new connection.

2. The method according to claim 1, characterized in that, Registering virtual services with the registry center based on the application server's IP address list includes: Determine the list of Uniform Resource Locators for the virtual service based on the IP address list; The virtual service is registered with the registry center based on the Uniform Resource Locator (URL) list.

3. The method according to claim 2, characterized in that, The method further includes: Obtain the latest list of application server IP addresses pushed by the configuration center; Update the Uniform Resource Locator (URL) list of the virtual service based on the latest list of IP addresses.

4. The method according to claim 1, characterized in that, After subscribing to the virtual service, the method further includes: Get service requests sent by external Dubbo services; The service request is sent to the application server.

5. The method according to claim 4, characterized in that, Sending the service request to the application server includes: Based on the service request, construct a request message according to the custom transport protocol specification; The request message is sent to the application server.

6. The method according to claim 5, characterized in that, After sending the service request to the application server, the method further includes: Obtain the response message generated by the application server based on the request message; The response message is decoded according to the custom transmission protocol specification to obtain the service processing result data; The business processing result data is sent to the external Dubbo service.

7. The method according to claim 6, characterized in that, Sending the request message to the application server includes: The request message is sent to the application server via a TCP connection; The step of obtaining the response message generated by the application server based on the request message includes: Obtain the response message sent by the application server through the TCP connection, wherein the response message is generated by the application server based on the request message.

8. A service subscription device based on the Dubbo framework, characterized in that, Applied to a Dubbo-based client, for performing the method according to any one of claims 1 to 7, comprising: The acquisition module is used to acquire a list of application server IP addresses pushed by the configuration center. The application server IP addresses are maintained in the configuration center, and the application is built based on a non-Dubbo framework. The registration module is used to register virtual services with the registration center based on the list of IP addresses of the application server; The subscription module is used to subscribe to the virtual service.

9. 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, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images