A communication method, apparatus, system, and electronic device based on the Thrift framework.

Abstract

This application provides a communication method, apparatus, system, and electronic device based on the Thrift framework. The method, applied to a server, includes: receiving a bus message from a service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained after processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol; matching the bus message with the current service registry in the application cache to obtain detailed information of the matched atomic service, and invoking the atomic service based on the detailed information to obtain a service response message, and returning the service response message to the client via the service bus, so that the client can perform business processing based on the service response message.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a communication method, apparatus, system and electronic device based on the Thrift framework. Background Technology

[0002] With the rise of microservices, distributed frameworks have become the mainstream approach for building business systems across industries. A common method for interaction between distributed systems is through Remote Procedure Call (RPC) frameworks to achieve inter-service communication. Conventionally, this can be achieved using… Figure 1 The RPC framework diagram shown illustrates that, specifically, the server defines the Service Application Programming Interface (Service API) and implements the corresponding business logic. The client makes local calls by importing the Service API dependency, thereby ignoring the details of inter-system network communication.

[0003] Among related technologies, common RPC frameworks include RESTful API, Dubbo, Thrift, gRPC, and ZeroMQ, all of which are relatively mature and have been applied to the construction of business systems in various industries. While RPC frameworks simplify communication between nodes in distributed systems and improve system scalability and reliability, in system production and development activities, a large number of inter-system calls typically need to be defined in APIs. These APIs are often constantly changing or unpredictable; therefore, it is difficult to achieve complete compatibility with each API change, requiring redeployment and upgrades of both the server and client programs, making it difficult to achieve compatibility without redeployment and upgrades of both the server and client. Summary of the Invention

[0004] This application provides a communication method, apparatus, system, and electronic device based on the Thrift framework to optimize the application building process. The relevant technical solutions provided by this application are as follows:

[0005] Firstly, embodiments of this application provide a communication method based on the Thrift framework, applied to a server, including:

[0006] Receive bus messages from the service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained after processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol.

[0007] The bus message is matched with the current service registry in the application cache to obtain the detailed information of the matched atomic service. The atomic service is then invoked based on the detailed information to obtain a service response message. The service response message is then returned to the client via the service bus so that the client can perform business processing based on the service response message.

[0008] In one possible implementation, prior to receiving the bus message from the service bus, the method further includes:

[0009] After the server starts, if it is necessary to dynamically register the service to be published, the corresponding business function shall be implemented according to the implementation interface provided by the server, and the module corresponding to the implementation of the corresponding business function shall be uploaded to the specified dependency directory for running the service to be published.

[0010] The service to be published is loaded through the dynamic loading interface of the management console provided by the server, so that the client can call the service to be published through the service bus.

[0011] In one possible implementation, during the server startup process, the method further includes:

[0012] Load all service registration information from the service registry into the application cache, and determine whether the service to be published exists in all the service registration information;

[0013] If it does not exist, and the service to be published is marked for automatic registration, then the service to be published will be automatically registered to the service registry and flushed into the application cache.

[0014] In one possible implementation, after determining whether the service to be published exists in all service registration information, the method further includes:

[0015] If the service to be published does not exist and is marked as manually registered, the user is prompted to manually register the service to be published to the service registry and refresh the application cache.

[0016] In one possible implementation, the fixed API interface protocol includes mandatory service call information consisting of service version, environment encoding, service source, service type, service definition, permission policy, service call extension information, service serialization triplet, request body, and response body.

[0017] Secondly, embodiments of this application provide a communication device based on the Thrift framework, applied to a server, including:

[0018] A receiving unit is configured to receive bus messages from a service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained by processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol.

[0019] The processing unit is configured to match the bus message with the current service registry in the application cache, obtain detailed information of the matched atomic service, call the atomic service based on the detailed information, obtain a service response message, and return the service response message to the client via the service bus, so that the client can perform business processing based on the service response message.

[0020] In one possible implementation, before the receiving unit receives a bus message from the service bus, the apparatus further includes a loading unit, the loading unit being configured to:

[0021] After the server starts, if it is necessary to dynamically register the service to be published, the corresponding business function shall be implemented according to the implementation interface provided by the server, and the module corresponding to the implementation of the corresponding business function shall be uploaded to the specified dependency directory for running the service to be published.

[0022] The service to be published is loaded through the dynamic loading interface of the management console provided by the server, so that the client can call the service to be published through the service bus.

[0023] In one possible implementation, during the server startup process, the apparatus further includes a registration unit, the registration unit being used for:

[0024] Load all service registration information from the service registry into the application cache, and determine whether the service to be published exists in all the service registration information;

[0025] If it does not exist, and the service to be published is marked for automatic registration, then the service to be published will be automatically registered to the service registry and flushed into the application cache.

[0026] In one possible implementation, after the registration unit determines whether the service to be published exists among all service registration information, the registration unit is further configured to:

[0027] If the service to be published does not exist and is marked as manually registered, the user is prompted to manually register the service to be published to the service registry and refresh the application cache.

[0028] Thirdly, embodiments of this application provide a remote procedure call system, including:

[0029] A client, a server, and a service bus that are communicatively connected to the client and the server, respectively; wherein:

[0030] The client is configured to send service request messages to the service bus;

[0031] The service bus is configured to process the service request message and obtain a bus message; wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, and the bus message is a message with the same protocol format as the fixed API interface protocol;

[0032] The server is configured to receive the bus message, match the bus message with the current service registry in the application cache, obtain detailed information of the matched atomic service, and call the atomic service based on the detailed information to obtain a service response message. The server then returns the service response message to the client via the service bus so that the client can perform business processing based on the service response message.

[0033] Fourthly, embodiments of this application provide an electronic device, including:

[0034] Memory, used to store computer programs;

[0035] When a processor executes a computer program stored in the memory, it implements the steps of the method described in any of the preceding descriptions.

[0036] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program for causing a computer to perform the steps of the method described in any of the preceding claims.

[0037] Sixthly, embodiments of this application provide a computer program product, the computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in any of the above descriptions.

[0038] The beneficial effects of the embodiments of this application are as follows:

[0039] This application provides a communication method, apparatus, system, and electronic device based on the Thrift framework. A service bus with a fixed API interface protocol is constructed based on the Thrift framework, and the bus messages are set to the same protocol format as the fixed API interface protocol. When the server receives a bus message from the service bus, it can match the bus message with the current service registry in the application cache to obtain detailed information about the matched atomic service. Based on this detailed information, the server can call the atomic service and obtain a service response message. Then, the server returns the service response message to the client via the service bus, allowing the client to perform business processing based on the service response message. In other words, there is no need to update or upgrade the server's service calls; simply matching the bus message with the service registry is sufficient for service calls. The entire process does not require redeploying and restarting the server, thus optimizing the application building process. Attached Figure Description

[0040] Figure 1 This is a schematic diagram of a commonly used RPC framework;

[0041] Figure 2 This is a diagram illustrating one method of implementing RPC calls to server-side business logic.

[0042] Figure 3 A flowchart of one method of the communication method based on the Thrift framework provided in the embodiments of this application;

[0043] Figure 4 A schematic diagram of one protocol format of the service bus in the communication method based on the Thrift framework provided in the embodiments of this application;

[0044] Figure 5 This is a schematic diagram illustrating one method of RPC calls via a service bus using an SDK in a Thrift-based communication method provided in this application embodiment.

[0045] Figure 6 This is one schematic diagram illustrating the processing details of the service bus server SDK in the communication method based on the Thrift framework provided in the embodiments of this application;

[0046] Figure 7 In order to be in Figure 3 Flowchart of one of the methods preceding step S101;

[0047] Figure 8 A flowchart illustrating one method of the Thrift-based communication method provided in this application during the server startup process;

[0048] Figure 9This is a schematic diagram illustrating one method of service registration and loading in a communication method based on the Thrift framework provided in an embodiment of this application.

[0049] Figure 10 A schematic diagram of one structure of a communication device based on the Thrift framework provided in an embodiment of this application;

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

[0051] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0052] The terms "first" and "second" in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising" and any variations thereof are intended to cover non-exclusive protection. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. The term "multiple" in this application can mean at least two, for example, two, three, or more, and the embodiments of this application do not impose limitations.

[0053] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These embodiments should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solutions of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0054] The acquisition, transmission, storage, and use of data in this application all comply with relevant national laws and regulations.

[0055] Before introducing the communication method, apparatus, system and electronic device based on the Thrift framework provided in the embodiments of this application, some technical terms involved in the embodiments of this application will be explained for ease of understanding.

[0056] Thrift framework: It is a remote procedure call framework used for scalable and cross-language service development. It combines a powerful software stack and code generation engine to build efficient services that can be seamlessly integrated across multiple programming languages.

[0057] Service bus: A middleware tool for building distributed systems. It provides a mechanism for decoupling and asynchronous communication, enabling different services to communicate with each other, achieving loose coupling and high scalability of the system.

[0058] Service message producer: Responsible for generating service messages and sending them to the service bus.

[0059] Service message consumer: Responsible for receiving service messages from the service bus and performing business processing.

[0060] Service Proxy: Responsible for receiving, transmitting, routing, and parsing service messages into monolithic application service calls.

[0061] Protobuf framework: A data structure serialization and deserialization framework.

[0062] In view of this, this application provides a communication method, apparatus, system and electronic device based on the Thrift framework to optimize the application building process.

[0063] like Figure 3 As shown in the figure, this application embodiment provides a communication method based on the Thrift framework, applied to the server side, including:

[0064] S101: Receive a bus message from the service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained after processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol.

[0065] In the specific implementation process, firstly, a service bus is constructed based on the Thrift framework. This service bus has a fixed API interface protocol defined based on the Thrift framework. This service bus can receive service request messages from clients and process these service request messages to obtain bus messages. These bus messages have the same protocol format as the fixed API interface protocol.

[0066] For example, the fixed API interface protocol could be `var invoke(Event event)`, where `Event` is the service invocation request message, i.e., the bus message. In one exemplary embodiment, the fixed protocol format of the bus message could be as follows: Figure 4 As shown, the fixed protocol format includes service version, environment encoding, service source, service type, service definition, permission policy, service call extended information, service serialization triple (Method, Request, Response), and request body PayLoad. Of course, the specific content of the fixed protocol format can be set according to the actual application's requirements for mandatory service call information; this is not limited here. For example, for a fixed API interface protocol, the memory usage of the service version and service type in the protocol header can be set to 3 bits, and the memory usage of other header information can be defined according to actual needs to reduce the overall event body size.

[0067] Furthermore, in this embodiment, Thrift is used as the RPC framework to implement a service bus. Service bus messages undergo secondary protocol definition and encoding / decoding to dynamically match system services for cross-system service calls. The service bus is essentially a fixed service interface within the RPC API, whose input parameters are fixed internal service protocols.

[0068] S102: Match the bus message with the current service registry in the application cache to obtain the detailed information of the matched atomic service, and call the atomic service based on the detailed information to obtain the service response message. Then, return the service response message to the client via the service bus so that the client can perform business processing based on the service response message.

[0069] In practice, after the server receives the bus message from the service bus, it can match the bus message with the current service registry in the application cache to obtain detailed information about the matched atomic services. For example, Table 1 shows the detailed information table of the matched atomic services.

[0070] Service Identifier Service type Service A Atomic services Service B Combination services

[0071] Table 1

[0072] As shown in Table 1, Service A is an atomic service, while Service B is a composite service. It's important to note that a composite service is an orchestrated service composed of multiple atomic services. For example, Service B is composed of multiple atomic services. After obtaining the detailed information of the matched atomic services, the services can be invoked based on this information to obtain service response messages. Furthermore, the server can return the service response messages to the client via the service bus, allowing the client to perform business processing based on these messages. In this way, when a client remotely invokes a new service from the server, there's no need to update or upgrade the server's service calls; simply matching the bus messages with the service registry is sufficient to initiate the service call. The entire process eliminates the need to redeploy and restart the server, thus optimizing the application development process.

[0073] Furthermore, in RPC integration testing across different teams or enterprises using common RPC frameworks, it's necessary to repeatedly confirm API coordinates and maintain and align the corresponding API-related messages. For example, in mainstream system construction using Java as the programming language and microservices as the underlying framework, regardless of whether an MVC or DDD domain-based architecture is adopted, such as... Figure 2 As shown, the development of an RPC API service typically involves multiple layers, including a service provision layer, a business implementation layer, and a data persistence layer. This results in a simple business scenario requiring the development of a complex, multi-layered, bloated source code from the bottom up. By employing the Thrift-based communication method provided in this embodiment, the client and server interface with the service bus, simplifying the server's calling logic. This eliminates the need to code different programs for different services, reducing the amount of source code required. In this embodiment, RPC calls can be implemented using the Thrift framework, which boasts high performance and cross-language compatibility. Choosing Thrift as the RPC communication framework ensures compatibility with clients and servers in different languages. Furthermore, to reduce transmission costs, interface requests are serialized using protobuf, while the actual service request data is transmitted via JSON, and the request response is serialized using JSON. The server exposes an SDK for clients to access the service bus and call services. The SDK encapsulates basic encoding / decoding, serialization, compression, and protocol-related functions such as filling in default request information and reading configuration information. Clients rely on the SDK and need to fill in basic service information and the actual request body to call the service.

[0074] It should be noted that, as Figure 5As shown in this embodiment, after the client sends a service request message, the client SDK can encapsulate and compress the service request message, and serialize the message body of the actual request to obtain the processed message. This reduces network and interface processing pressure and transmission costs. The client's service discovery and invocation are based on existing Thrift framework functionalities. Furthermore, the server SDK can perform parsing, security verification, deserialization, and routing forwarding on messages obtained after processing via the service bus, thereby enabling RPC calls. For example, the compression and parsing of the service request message are implemented based on protobuf serialization, and the message body of the actual request is serialized using JSON format.

[0075] Furthermore, the server relies on the SDK to parse the bus messages and obtain the actual service call information. For example, the actual service call information includes the service version, service method name, service request body, and service response protocol. Then, it can match the service registration information in the application cache to obtain the detailed information of the matched atomic service. Then, the bus message can be distributed through the proxy forwarding and routing module, starting an independent thread to call the specific atomic service and complete the service call. In practical implementation, multiple internal instances can be used to call the various atomic services in the composite service in parallel. For example... Figure 6 This illustrates one exemplary embodiment of internal multi-instance forwarding. (Still combined with...) Figure 6 As shown, the server matches the bus message with Table 1 in the application cache to obtain the detailed information of the matched service B. Service B is a composite service, which includes two atomic services. One of the atomic services in service B is called by internal instance 1, and the other atomic service in service B is called by internal instance 2.

[0076] It should be noted that when the client and server use different registry centers, the server, after receiving the bus message, selects whether to perform internal multi-instance forwarding processing based on the obtained load information during proxy processing.

[0077] In the embodiments of this application, such as Figure 7 As shown, before step S101: receiving a bus message from the service bus, the method further includes:

[0078] S201: After the server starts, if it is necessary to dynamically register the service to be published, the corresponding business function shall be implemented according to the implementation interface provided by the server, and the module corresponding to the implementation of the corresponding business function shall be uploaded to the specified dependency directory for running the service to be published.

[0079] S202: The service to be published is loaded through the dynamic loading interface of the management console provided by the server, so that the client can call the service to be published through the service bus.

[0080] In the specific implementation process, steps S201 to S202 are implemented as follows:

[0081] First, after the server starts, if it needs to dynamically register services to be published, it implements the corresponding business functions according to the implementation structure provided by the server, and uploads the modules corresponding to these business functions to the specified dependency directory for running the service to be published. Then, it loads the service to be published through the dynamic loading interface provided by the server's management console. In this way, the client can call the service to be published through the service bus. For example, in Java, class information can be loaded by scanning new JARs using `appClassLoader`. In C, DLLs can be loaded using `LoadLibrary`. That is to say, when adding different types of services (such as services to be published or services to be launched) to the server, atomic services can be dynamically loaded as plugins, and the entire process does not require restarting the server.

[0082] It should be noted that when triggering service loading, you also need to choose whether to automatically register the service to the service registry or manually enter service information for dynamic service registry updates. Once the service to be published is loaded into the application, the service proxy list in the service bus can be updated, allowing the service to be published to be invoked by the service proxies.

[0083] In the embodiments of this application, such as Figure 8 As shown, during the server startup process, the method further includes:

[0084] S301: Load all service registration information from the service registry into the application cache, and determine whether the service to be published exists in all service registration information;

[0085] S302: If it does not exist, and the service to be published is marked for automatic registration, then the service to be published will be automatically registered to the service registry and flushed into the application cache.

[0086] In the specific implementation process, combined with Figure 9 The service registration and loading diagram shown explains the specific implementation process of steps S301 to S302.

[0087] First, during the server startup process, all service registration information is loaded from the service registry into the application cache. When the program scans the marked service information during startup, it determines whether there is a service to be published among all the service registration information. If it does not exist and the service to be published is marked as automatically registered, then the service to be published is automatically registered to the service registry and flushed into the application cache.

[0088] Secondly, in step S301: after determining whether the service to be published exists in all service registration information, the method further includes:

[0089] If the service to be published does not exist and is marked as manually registered, the user is prompted to manually register the service to be published to the service registry and refresh the application cache.

[0090] If the service to be published is not listed in any of the service registration information and is marked for manual registration, the user will be prompted to manually register the service to be published in the service registry and flush it to the application cache. In practice, only after the service to be published is registered in the service registry can it be loaded onto the server, thus ensuring that the client can call the service to be published through the service bus.

[0091] In this embodiment, the fixed API interface protocol format includes mandatory service call information consisting of service version, environment encoding, service source, service type, service definition, permission policy, service call extended information, service serialization triple, request body, and response body. Of course, the specific content of the fixed protocol format can be set according to the actual application's needs for mandatory service call information, and this is not limited here.

[0092] Based on the same inventive concept, such as Figure 10 As shown in the illustration, this application also provides a communication device based on the Thrift framework, applied to a server, including:

[0093] The receiving unit 10 is configured to receive bus messages from the service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained by processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol.

[0094] The processing unit 20 is configured to match the bus message with the current service registry in the application cache to obtain detailed information of the matched atomic service, and call the atomic service based on the detailed information to obtain a service response message, and return the service response message to the client via the service bus so that the client can perform business processing based on the service response message.

[0095] In this embodiment of the application, before the receiving unit 10 receives the bus message from the service bus, the apparatus further includes a loading unit, the loading unit being configured to:

[0096] After the server starts, if it is necessary to dynamically register the service to be published, the corresponding business function shall be implemented according to the implementation interface provided by the server, and the module corresponding to the implementation of the corresponding business function shall be uploaded to the specified dependency directory for running the service to be published.

[0097] The service to be published is loaded through the dynamic loading interface of the management console provided by the server, so that the client can call the service to be published through the service bus.

[0098] In this embodiment of the application, during the server startup process, the device further includes a registration unit, which is used for:

[0099] Load all service registration information from the service registry into the application cache, and determine whether the service to be published exists in all the service registration information;

[0100] If it does not exist, and the service to be published is marked for automatic registration, then the service to be published will be automatically registered to the service registry and flushed into the application cache.

[0101] In one possible implementation, after the registration unit determines whether the service to be published exists among all service registration information, the registration unit is further configured to:

[0102] If the service to be published does not exist and is marked as manually registered, the user is prompted to manually register the service to be published to the service registry and refresh the application cache.

[0103] Based on the same inventive concept, this application also provides an electronic device that can implement the functions of the aforementioned communication method based on the Thrift framework. (Refer to...) Figure 11 The electronic device includes:

[0104] Memory 100 is used to store computer programs;

[0105] When the processor 200 executes the computer program stored in the memory, it implements the communication method steps based on the Thrift framework as described in any of the preceding items.

[0106] This application embodiment does not limit the specific connection medium between the processor 200 and the memory 100. Figure 11 The example shown is the connection between processor 200 and memory 100 via bus 300. Bus 300 is... Figure 11 The connections between other components are indicated by thick lines and are for illustrative purposes only, not as limiting information. Bus 300 can be divided into address bus, data bus, control bus, etc., for ease of representation. Figure 11 The 300 is represented by a single thick line, but this does not mean that there is only one bus 300 or one type of bus 300. Alternatively, the processor 200 may also be called a controller; there is no restriction on the name.

[0107] In this embodiment, the memory 100 stores instructions executable by the processor 200. When the processor 200 executes the computer program stored in the memory 100, it can execute the Thrift-based communication method discussed above. The processor 200 can implement... Figure 10 The functions of each module are shown.

[0108] The processor 200 is the control center of the device. It can connect to various parts of the entire control device through various interfaces and lines. By running or executing computer programs stored in the memory 100 and calling data stored in the memory 100, it can monitor the various functions and data processing of the device as a whole.

[0109] In one possible design, processor 200 may include one or more processing units. Processor 200 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. In some embodiments, processor 200 and memory 100 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0110] Memory 100, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 100 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Alternatively, memory 100 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures, and accessible by a computer, but is not limited thereto. In the embodiments of this application, memory 100 may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0111] By designing and programming the processor, the code corresponding to the Thrift-based communication method described in the foregoing embodiments can be embedded into the chip, enabling the chip to execute the steps of the Thrift-based communication method discussed earlier during runtime. How to design and program the processor is a technique well-known to those skilled in the art and will not be elaborated upon here.

[0112] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium storing a computer program that enables a computer to execute the communication method steps based on the Thrift framework discussed above.

[0113] In some possible implementations, various aspects of the Thrift-based communication method provided in this application can also be implemented as a program product, which includes program code that, when the program product is run on a device, causes the control device to perform the steps in the Thrift-based communication method according to the various exemplary embodiments of this application described above.

[0114] This application provides a communication method, apparatus, system, and electronic device based on the Thrift framework. A service bus with a fixed API interface protocol is constructed based on the Thrift framework, and the bus messages are set to the same protocol format as the fixed API interface protocol. When the server receives a bus message from the service bus, it can match the bus message with the current service registry in the application cache to obtain detailed information about the matched atomic service. Based on this detailed information, the server can call the atomic service and obtain a service response message. Then, the server returns the service response message to the client via the service bus, allowing the client to perform business processing based on the service response message. In other words, there is no need to update or upgrade the server's service calls; simply matching the bus message with the service registry is sufficient for service calls. The entire process does not require redeploying and restarting the server, thus optimizing the application building process.

[0115] 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.

[0116] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should 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 illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0117] 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.

[0118] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment 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.

[0119] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A communication method based on the Thrift framework, applied to the server side, characterized in that, include: Receive bus messages from the service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained after processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol. The bus message is matched with the current service registry in the application cache to obtain the detailed information of the matched atomic service. The atomic service is then invoked based on the detailed information to obtain a service response message. The service response message is then returned to the client via the service bus so that the client can perform business processing based on the service response message.

2. The method as described in claim 1, characterized in that, Before receiving the bus message from the service bus, the method further includes: After the server starts, if it is necessary to dynamically register the service to be published, the corresponding business function shall be implemented according to the implementation interface provided by the server, and the module corresponding to the implementation of the corresponding business function shall be uploaded to the specified dependency directory for running the service to be published. The service to be published is loaded through the dynamic loading interface of the management console provided by the server, so that the client can call the service to be published through the service bus.

3. The method as described in claim 2, characterized in that, During the server startup process, the method further includes: Load all service registration information from the service registry into the application cache, and determine whether the service to be published exists in all the service registration information; If it does not exist, and the service to be published is marked for automatic registration, then the service to be published will be automatically registered to the service registry and flushed into the application cache.

4. The method as described in claim 3, characterized in that, After determining whether the service to be published exists in all service registration information, the method further includes: If the service to be published does not exist and is marked as manually registered, the user is prompted to manually register the service to be published to the service registry and refresh the application cache.

5. The method according to any one of claims 1-4, characterized in that, The fixed API interface protocol format includes mandatory service call information consisting of service version, environment encoding, service source, service type, service definition, permission policy, service call extended information, service serialization triplet, request body, and response body.

6. A communication device based on the Thrift framework, applied to a server, characterized in that, include: A receiving unit is configured to receive bus messages from a service bus, wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, the bus message is a message obtained by processing a service request message from a client via the service bus, and the bus message has the same protocol format as the fixed API interface protocol. The processing unit is configured to match the bus message with the current service registry in the application cache, obtain detailed information of the matched atomic service, call the atomic service based on the detailed information, obtain a service response message, and return the service response message to the client via the service bus, so that the client can perform business processing based on the service response message.

7. A remote procedure call system, characterized in that, include: A client, a server, and a service bus that are communicatively connected to the client and the server, respectively; wherein: The client is configured to send service request messages to the service bus; The service bus is configured to process the service request message and obtain a bus message; wherein the service bus has a fixed API interface protocol defined based on the Thrift framework, and the bus message is a message with the same protocol format as the fixed API interface protocol; The server is configured to receive the bus message, match the bus message with the current service registry in the application cache, obtain detailed information of the matched atomic service, and call the atomic service based on the detailed information to obtain a service response message. The server then returns the service response message to the client via the service bus so that the client can perform business processing based on the service response message.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, when executing a computer program stored in the memory, implements the method steps as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that causes a computer to perform the steps of the method as described in any one of claims 1-5.

10. A computer program product, characterized in that, The computer program product includes: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of claims 1-5.

Images