Communication method, device and system based on Thrift framework and electronic equipment
By using the Thrift framework to build a fixed API interface protocol service bus in a distributed system and matching the service registry, the compatibility problem caused by frequent API changes is solved, and the service call and optimization application construction process can be achieved without restarting the server.
Patent Information
- Application Number
- CN202411648715.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-18
- Publication Date
- 2025-03-21
- Estimated Expiration
- 2044-11-18
AI Technical Summary
In distributed systems, frequent API changes and uncertainties in the communication between services make it difficult for the system to achieve full compatibility, and usually requires redeployment and upgrade of the server and client.
Using a communication method based on the Thrift framework, a service bus with a fixed API interface protocol is built, and the bus messages are matched with the service registry in the application cache to realize service calls.
There is no need to update or upgrade the service call on the server side. Just match the bus message with the service registry to realize the service call. The entire process does not require republishing and restarting the server, thus optimizing the process of building the application.
Smart Images

Figure CN119676284A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computer technology, and in particular to a communication method, device, system and electronic equipment based on a thrift framework. Background Art
[0002] With the rise of microservices, the application of distributed frameworks has become the mainstream of building business systems in the industry. The common means of interaction between distributed systems is to achieve inter-service communication through the Remote Procedure Call Protocol (RPC) framework technology. Figure 1 As shown in the RPC framework schematic diagram, specifically, a service application programming interface (Service API) is defined on the server side, and the business logic corresponding to the Service API is implemented. The client side introduces the Service API dependency for local calls, thereby ignoring the details of network communication between systems.
[0003] In the related technologies, common RPC frameworks include RESTful API, Dubbo, Thrift, gRPC, zeroMQ, etc., which are relatively mature and have been applied in the construction of business systems in various industries. Although the use of RPC frameworks simplifies the communication between nodes in distributed systems and improves the scalability and reliability of the system. However, in system production and R&D activities, there are usually a large number of calls between systems that need to be defined in the API, and these APIs are often constantly changing or uncertain; in this case, it is difficult to achieve full compatibility every time the API changes, and the Sever and Client programs must be redeployed and upgraded, and it is difficult to do without redeploying and upgrading the Sever and Client. Summary of the invention
[0004] The embodiment of the present application provides a communication method, device, system and electronic device based on the thrift framework, which is used to optimize the process of building applications. The relevant technical solutions provided by the embodiment of the present application are as follows:
[0005] In a first aspect, an embodiment of the present application provides a communication method based on a thrift framework, which is applied to a server, including:
[0006] 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 the service bus processes a service request message from a client, 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 detailed information of the matched atomic service, and the atomic service is called based on the detailed information to obtain a service response message, and the service response message is returned to the client via the service bus, so that the client performs business processing based on the service response message.
[0008] In one possible implementation manner, before receiving the bus message from the service bus, the method further includes:
[0009] After the server is started, if it is necessary to dynamically register the service to be published, the corresponding business function is implemented according to the implementation interface provided by the server, and the module corresponding to the corresponding business function is uploaded to the designated dependency directory running the service to be published;
[0010] The service to be published is loaded through the management station dynamic loading interface 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] Loading all service registration information from the service registration table to the application cache, and determining whether the to-be-published service exists in all service registration information;
[0013] If it does not exist, and the service to be published is marked as automatically registered, the service to be published is automatically registered to the service registration table and flushed into the application cache.
[0014] In one possible implementation manner, after determining whether the to-be-published service exists in all service registration information, the method further includes:
[0015] If it does not exist, and the service to be published is marked as manually registered, the user is prompted to manually register the service to be published to the service registration table and flush it into the application cache.
[0016] In one possible implementation, the protocol format of the fixed API interface protocol includes mandatory service call information consisting of service version, environment code, service source, service type, service definition, authority policy, service call extension information, service serialization triplet, request body, and response body.
[0017] In a second aspect, an embodiment of the present application provides a communication device based on a thrift framework, which is applied to a server, including:
[0018] A receiving unit, configured to receive 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 the service bus processes a service request message from a client, and the bus message has the same protocol format as the fixed API interface protocol;
[0019] A processing unit is used to match the bus message with the current service registration table 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, and return the service response message to the client via the service bus, so that the client performs business processing based on the service response message.
[0020] In one possible implementation manner, before the receiving unit receives the bus message from the service bus, the device further includes a loading unit, and the loading unit is used to:
[0021] After the server is started, if it is necessary to dynamically register the service to be published, the corresponding business function is implemented according to the implementation interface provided by the server, and the module corresponding to the corresponding business function is uploaded to the designated dependency directory running the service to be published;
[0022] The service to be published is loaded through the management station dynamic loading interface provided by the server, so that the client can call the service to be published through the service bus.
[0023] In one possible implementation manner, during the startup process of the server, the device further includes a registration unit, and the registration unit is used to:
[0024] Loading all service registration information from the service registration table to the application cache, and determining whether the to-be-published service exists in all service registration information;
[0025] If it does not exist, and the service to be published is marked as automatically registered, the service to be published is automatically registered to the service registration table and flushed into the application cache.
[0026] In one possible implementation manner, after the registration unit is used to determine whether the to-be-published service exists in all service registration information, the registration unit is further used to:
[0027] If it does not exist, and the service to be published is marked as manually registered, the user is prompted to manually register the service to be published to the service registration table and flush it into the application cache.
[0028] In a third aspect, an embodiment of the present application provides a remote procedure call system, including:
[0029] A client, a server, and a service bus connected to the client and the server respectively; wherein:
[0030] The client is configured to send a service request message to the service bus;
[0031] The service bus is configured to process the service request message to 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 having 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, and return the service response message to the client via the service bus, so that the client performs business processing based on the service response message.
[0033] In a fourth aspect, an embodiment of the present application provides an electronic device, including:
[0034] Memory, used to store computer programs;
[0035] The processor is used to implement the method steps described in any one of the above items when executing the computer program stored in the memory.
[0036] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and the computer program is used to enable a computer to execute the method steps described in any one of the above items.
[0037] In a sixth aspect, an embodiment of the present application provides a computer program product, which includes: a computer program code, and when the computer program code runs on a computer, the computer executes any of the above methods.
[0038] The beneficial effects of the embodiments of the present application are as follows:
[0039] The embodiment of the present application provides a communication method, device, system and electronic device based on the thrift framework, constructs a service bus with a fixed API interface protocol based on the thrift framework, and sets the bus message to the same protocol format as the fixed API interface protocol; in this way, after the server receives the bus message from the service bus, the bus message can be matched with the current service registry in the application cache, thereby obtaining the detailed message of the matched atomic service, and the atomic service can be called based on the detailed information to obtain a service response message; then, the server 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. In other words, there is no need to update and upgrade the service call of the server, and the service call can be realized by matching the bus message with the service registry, and the whole process does not need to re-publish and restart the server, thereby optimizing the process of building applications. BRIEF DESCRIPTION OF THE DRAWINGS
[0040] Figure 1 This is the schematic diagram of the commonly used RPC framework;
[0041] Figure 2 This is a schematic diagram of one of the RPC call server business implementations;
[0042] Figure 3 A flow chart of one of the methods of the communication method based on the thrift framework provided in an embodiment of the present application;
[0043] Figure 4 A schematic diagram of a protocol format of a service bus in a communication method based on a thrift framework provided in an embodiment of the present application;
[0044] Figure 5 A schematic diagram of one of the communication methods based on the thrift framework provided in the embodiment of the present application, which relies on SDK to make RPC calls through the service bus;
[0045] Figure 6 A schematic diagram of one of the processing details of the service bus server SDK in the communication method based on the thrift framework provided in the embodiment of the present application;
[0046] Figure 7 For Figure 3 One of the method flow charts before step S101;
[0047] Figure 8 A flow chart of one of the methods in the server startup process of the communication method based on the thrift framework provided in an embodiment of the present application;
[0048] Fig. 9A schematic diagram of one of the service registration and loading in the communication method based on the thrift framework provided in an embodiment of the present application;
[0049] Fig.10 A schematic diagram of a structure of a communication device based on a thrift framework provided in an embodiment of the present application;
[0050] Fig.11 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0051] In order to make the purpose, technical scheme and advantages of the present application clearer, the technical scheme in the embodiment of the present application will be clearly and completely described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application. In the absence of conflict, the embodiments in the present application and the features in the embodiments can be arbitrarily combined with each other. In addition, although the logical order is shown in the flow chart, in some cases, the steps shown or described can be performed in an order different from that here.
[0052] The terms "first" and "second" in the specification and claims of the present application and the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the term "comprising" and any of their variations are intended to cover non-exclusive protection. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units that are not listed, or optionally also includes other steps or units inherent to these processes, methods, products or devices. "Multiple" in the present application can mean at least two, for example, two, three or more, and the embodiments of the present application are not limited.
[0053] The following is a description of exemplary embodiments of the present application in conjunction with the accompanying drawings, including various details of the embodiments of the present application to facilitate understanding, which should be considered as merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the present application. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description. It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, which should be considered as exemplary, and their purpose is only to illustrate the feasibility of the implementation of the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.
[0054] In the technical solution of this application, the acquisition, transmission, storage, and use of data are in compliance with the requirements of relevant national laws and regulations.
[0055] Before introducing the communication method, device, system and electronic device based on the thrift framework provided in the embodiments of the present application, in order to facilitate understanding, some technical terms involved in the embodiments of the present application are first explained.
[0056] Thrift framework: is a remote procedure call framework for scalable and cross-language service development. It combines a powerful software stack and a code generation engine to build efficient services that are seamlessly integrated across multiple programming languages.
[0057] Service Bus: A middleware tool for building distributed systems. It provides a decoupling and asynchronous communication mechanism, 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, delivering, routing and parsing service messages into monolithic application service calls.
[0061] Protobuf framework: data structure serialization and deserialization framework.
[0062] In view of this, the present application provides a communication method, device, system and electronic device based on the thrift framework, which are used to optimize the application construction process.
[0063] like Figure 3 As shown, the embodiment of the present application provides a communication method based on the thrift framework, which is applied to the server, including:
[0064] S101: 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 the service bus processes a service request message from a client, and the bus message has the same protocol format as the fixed API interface protocol;
[0065] In the specific implementation process, first, a service bus is constructed based on the thrift framework, and the service bus has a fixed API interface protocol defined based on the thrift framework; the service bus can receive service request messages from the client and can also process the service request messages to obtain bus messages; the bus messages have the same protocol format as the fixed API interface protocol.
[0066] Exemplarily, the fixed API interface protocol may be var invoke(Event event); wherein Event is the request message for the service call, i.e., the bus message. In one exemplary embodiment, the fixed protocol format of the bus message may be as follows: Figure 4 As shown, the fixed protocol format includes service version, environment code, service source, service type, service definition, permission policy, service call extension information, service serialization triplet (Method, Request, Response), and request body PayLoad. Of course, the specific content of the fixed protocol format can also be set according to the actual application's needs for the required information for service calls, which is not limited here. Exemplarily, 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 other header information can define the occupied memory length according to actual conditions to reduce the occupancy of the entire Event body.
[0067] In addition, in the embodiment of the present application, thrift is used as the RPC framework to implement the service bus, the service bus message performs secondary protocol definition and encoding and decoding, and dynamically matches system services for cross-system service calls. The service bus is actually a fixed service interface in the RPC API, and the input parameter of the interface is a fixed internal service protocol.
[0068] S102: Match the bus message with the current service registration table 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 performs business processing based on the service response message.
[0069] In the specific implementation process, after receiving the bus message from the service bus, the server can match the bus message with the current service registration table in the application cache to obtain the detailed information of the matched atomic service. For example, Table 1 shows the detailed information table of the matched principle service.
[0070] Service Logo Service Type AService Atomic Services BService Combination of services
[0071] Table 1
[0072] As shown in Table 1, the service type of service A is atomic service; the service type of service B is composite service. It should be noted that a composite service is a service composed of multiple atomic services. Exemplarily, service B is composed of multiple atomic services. After obtaining the detailed information of the matched atomic service, the atomic service can be called based on the detailed information to obtain a service response message. Moreover, the server can also 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. In this way, when the client remotely calls a new service from the server, there is no need to update and upgrade the service call of the server. It only needs to match the bus message with the service registry to realize the service call. The entire process does not require re-publishing and restarting the server, thereby optimizing the process of building applications.
[0073] Moreover, when conducting RPC joint debugging activities across different teams or enterprises based on common RPC frameworks, it is necessary to repeatedly confirm the coordinates of the API and maintain the alignment of corresponding API-related messages. For example, in the mainstream system construction with Java as the programming language and microservices as the basic framework, whether the MVC architecture or the DDD domain division architecture is adopted, such as Figure 2 As shown, the development of an RPC API service is mostly divided into multiple layers of implementation such as service provision layer, business implementation layer, and data persistence layer, resulting in a very simple business scenario, which requires the development of multiple layers of bloated source code from the bottom up. Due to the communication method based on the thrift framework provided by the embodiment of the present application, the client and the server dock the service bus, thereby simplifying the call logic of the server, and there is no need to encode different programs for different services, reducing the amount of source code writing. In the embodiment of the present application, RPC calls can be implemented based on the thrift framework, wherein the thrift framework has the characteristics of high performance and cross-language. The thrift framework is selected as the RPC communication framework, which can be compatible with different language clients and server landings. Moreover, in order to reduce the transmission cost, the interface request is serialized through protobuf, the service real request data is transmitted through json, and the request response is serialized through json. The server opens the SDK to the outside world for the client to access the service bus call service, and the SDK encapsulates the basic encoding and decoding, serialization, compression, and filling request default information, reading configuration information and other protocol-related functions. The client relies on the SDK and needs to fill in the service basic information and the real request body for service calls.
[0074] It should be noted that if Figure 5As shown, in an embodiment of the present application, after the client sends a service request message, the service request message can be encapsulated and compressed through the client SDK, and the message body of the real request can be serialized to obtain the processed message. In this way, the network and interface processing pressure is reduced, and the transmission cost is reduced. The service discovery and call of the client are based on the existing functions of the thrift framework. Moreover, the message obtained after processing by the service bus can be parsed, security checked, deserialized, routed and forwarded through the server SDK, thereby realizing RPC calls. Exemplarily, the compression and parsing of the service request message is realized based on protobuf serialization, and the message body of the real request is serialized in json format.
[0075] In addition, the server relies on the SDK to parse the bus message to obtain the real service call information. For example, the real service call information includes service version, service method name, service request body, service response protocol and other information. Then, you can match the service registration information in the application cache to obtain detailed information about the matched atomic service. Then, you can distribute the bus message through the proxy forwarding routing module, pull up an independent thread to call the specific atomic service, and complete the service call. In the specific implementation process, each atomic service in the composite service can be called in parallel through multiple internal instances. Figure 6 FIG. 1 is an exemplary embodiment of internal multi-instance forwarding. Figure 6 As shown, the server matches the bus message with Table 1 in the application cache (Cache) to obtain detailed information of the matched B service; wherein, the B service is a composite service, which includes two atomic services; one of the atomic services in the B service is called by the internal instance 1, and the other atomic service in the B service is called by the internal instance 2.
[0076] It should be noted that, in the case where the client and the server use different registration centers respectively, after receiving the bus message, the server chooses whether to forward the internal multiple instances based on the load information obtained during proxy processing.
[0077] In the embodiments of the present application, Figure 7 As shown, before step S101: receiving a bus message from a service bus, the method further includes:
[0078] S201: After the server is started, if it is necessary to dynamically register the service to be published, the corresponding business function is implemented according to the implementation interface provided by the server, and the module corresponding to the corresponding business function is uploaded to the designated dependency directory for running the service to be published;
[0079] S202: Load the service to be published through the management station dynamic loading interface 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, the specific implementation process of step S201 to step S202 is as follows:
[0081] First, after the server is started, if it is necessary to dynamically register the service to be released, the corresponding business functions are implemented according to the implementation structure provided by the server, and the modules corresponding to the corresponding business functions are uploaded to the specified dependency directory for running the service to be released; then, the service to be released is loaded through the dynamic loading interface of the management console provided by the server; in this way, the client can call the service to be released through the service bus. Taking the Java language as an example, the class information can be loaded by scanning the new jar through appClassLoder. Taking the C language as an example, the DLL can be loaded through LoadLibrary for service loading. In other words, when adding different types of services to the server (for example, services to be released, services to be launched), atomic services can be dynamically loaded as plug-ins, 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 the service information to update the dynamic service registry. Once the service to be published is loaded into the application, the service proxy list in the service bus can be updated, so that the service to be published can be called by the service proxy.
[0083] In the embodiments of the present application, Figure 8 As shown, during the startup process of the server, the method further includes:
[0084] S301: Load all service registration information from the service registration table to the application cache, and determine whether the to-be-published service exists in all service registration information;
[0085] S302: If it does not exist, and the service to be published is marked as automatically registered, the service to be published is automatically registered in the service registration table and flushed into the application cache.
[0086] In the specific implementation process, combined with Fig. 9 The service registration and loading schematic diagram shown explains the specific implementation process of step S301 to step S302.
[0087] First, during the server startup process, all service registration information will be loaded from the service registry to the application cache. During the startup process, when the program scans the marked service information, it determines whether there is a service to be published in all the service registration information; if not, and the service to be published is marked as automatic registration, the service to be published will be automatically registered to the service registry and flushed into the application cache.
[0088] Secondly, in step S301: after determining whether the to-be-published service exists in all service registration information, the method further includes:
[0089] If it does not exist, and the service to be published is marked as manually registered, the user is prompted to manually register the service to be published to the service registration table and flush it into the application cache.
[0090] If the service to be published does not exist in all service registration information and is marked as manually registered, the user is prompted to manually register the service to be published in the service registry and flush it into the application cache. In the specific implementation process, only when the service to be published is registered in the service registry can it be loaded into the server later, thereby providing a guarantee for the client to call the service to be published through the service bus.
[0091] In the embodiment of the present application, the protocol format of the fixed API interface protocol includes mandatory service call information consisting of service version, environment code, service source, service type, service definition, permission policy, service call extension information, service serialization triple, request body, and response body. Of course, the specific content of the fixed protocol format can also be set according to the actual application's needs for mandatory service call information, which is not limited here.
[0092] Based on the same inventive concept, Fig.10 As shown, the embodiment of the present application also provides a communication device based on the thrift framework, which is applied to the server, including:
[0093] A receiving unit 10 is used to receive 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 the service bus processes a service request message from a client, and the bus message has the same protocol format as the fixed API interface protocol;
[0094] The processing unit 20 is used to match the bus message with the current service registration table 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, and return the service response message to the client via the service bus, so that the client performs business processing based on the service response message.
[0095] In the embodiment of the present application, before the receiving unit 10 receives the bus message from the service bus, the device further includes a loading unit, and the loading unit is used to:
[0096] After the server is started, if it is necessary to dynamically register the service to be published, the corresponding business function is implemented according to the implementation interface provided by the server, and the module corresponding to the corresponding business function is uploaded to the designated dependency directory running the service to be published;
[0097] The service to be published is loaded through the management station dynamic loading interface provided by the server, so that the client can call the service to be published through the service bus.
[0098] In the embodiment of the present application, during the startup process of the server, the device further includes a registration unit, and the registration unit is used to:
[0099] Loading all service registration information from the service registration table to the application cache, and determining whether the to-be-published service exists in all service registration information;
[0100] If it does not exist, and the service to be published is marked as automatically registered, the service to be published is automatically registered to the service registration table and flushed into the application cache.
[0101] In one possible implementation manner, after the registration unit is used to determine whether the to-be-published service exists in all service registration information, the registration unit is further used to:
[0102] If it does not exist, and the service to be published is marked as manually registered, the user is prompted to manually register the service to be published to the service registration table and flush it into the application cache.
[0103] Based on the same inventive concept, an electronic device is also provided in the embodiment of the present application, and the electronic device can implement the functions of the aforementioned communication method based on the thrift framework, referring to Fig.11 , the electronic device comprises:
[0104] Memory 100, used for storing computer programs;
[0105] The processor 200 is used to implement the steps of the communication method based on the thrift framework as described in any of the above items when executing the computer program stored in the memory.
[0106] The specific connection medium between the processor 200 and the memory 100 is not limited in the embodiment of the present application. Fig.11 In the example, the processor 200 and the memory 100 are connected via a bus 300. The bus 300 is connected to the memory 100 via a bus 300. Fig.11 The bus 300 is represented by a bold line, and the connection between other components is only for schematic illustration and is not intended to be limiting. The bus 300 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 Only one thick line is used in the figure, but it 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, and there is no limitation on the name.
[0107] In the embodiment of the present application, the memory 100 stores instructions that can be executed by the processor 200. When the processor 200 executes the computer program stored in the memory 100, the communication method based on the thrift framework discussed above can be executed. The processor 200 can implement Fig.10 The functions of each module are shown in the figure.
[0108] Among them, the processor 200 is the control center of the device, and can use various interfaces and lines to connect various parts of the entire control device, and through running or executing computer programs stored in the memory 100 and calling data stored in the memory 100, the various functions of the device and process data, thereby monitoring the device as a whole.
[0109] In one possible design, the processor 200 may include one or more processing units, and the processor 200 may integrate an application processor and a modem processor, wherein the application processor mainly processes an operating system, a user interface, and application programs, and the modem processor mainly processes wireless communications. In some embodiments, the processor 200 and the memory 100 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on separate chips.
[0110] The 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. The memory 100 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. Alternatively, the memory 100 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 100 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.
[0111] By designing and programming the processor, the code corresponding to the communication method based on the thrift framework introduced in the above embodiment can be fixed into the chip, so that the chip can execute the steps of the communication method based on the thrift framework discussed above when running. How to design and program the processor is a technology well known to those skilled in the art and will not be described here.
[0112] Based on the same inventive concept, an embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, and the computer program is used to enable a computer to execute the steps of the communication method based on the thrift framework discussed above.
[0113] In some possible implementations, various aspects of the communication method based on the thrift framework provided in the present application can also be implemented in the form of a program product, which includes program code. When the program product is run on the device, the program code is used to enable the control device to execute the steps of the communication method based on the thrift framework according to various exemplary embodiments of the present application described above in this specification.
[0114] The embodiment of the present application provides a communication method, device, system and electronic device based on the thrift framework, constructs a service bus with a fixed API interface protocol based on the thrift framework, and sets the bus message to the same protocol format as the fixed API interface protocol; in this way, after the server receives the bus message from the service bus, the bus message can be matched with the current service registry in the application cache, thereby obtaining the detailed message of the matched atomic service, and the atomic service can be called based on the detailed information to obtain a service response message; then, the server 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. In other words, there is no need to update and upgrade the service call of the server, and the service call can be realized by matching the bus message with the service registry, and the whole process does not need to re-publish and restart the server, thereby optimizing the process of building applications.
[0115] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.
[0116] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.
[0117] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.
[0118] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.
[0119] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.
Claims
1. A communication method based on thrift framework, applied to a server, characterized in that: include: 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 the service bus processes a service request message from a client, 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 detailed information of the matched atomic service, and the atomic service is called based on the detailed information to obtain a service response message, and the service response message is returned to the client via the service bus, so that the client performs business processing based on the service response message.
2. The method according to claim 1, characterized in that Before receiving the bus message from the service bus, the method further includes: After the server is started, if it is necessary to dynamically register the service to be published, the corresponding business function is implemented according to the implementation interface provided by the server, and the module corresponding to the corresponding business function is uploaded to the designated dependency directory running the service to be published; The service to be published is loaded through the management station dynamic loading interface provided by the server, so that the client can call the service to be published through the service bus.
3. The method according to claim 2, characterized in that During the server startup process, the method further includes: Loading all service registration information from the service registration table to the application cache, and determining whether the to-be-published service exists in all service registration information; If it does not exist, and the service to be published is marked as automatically registered, the service to be published is automatically registered to the service registration table and flushed into the application cache.
4. The method according to claim 3, characterized in that After determining whether the to-be-published service exists in all service registration information, the method further includes: If it does not exist, and the service to be published is marked as manually registered, the user is prompted to manually register the service to be published to the service registration table and flush it into the application cache.
5. The method according to any one of claims 1 to 4, characterized in that: The protocol format of the fixed API interface protocol includes mandatory service call information consisting of service version, environment code, service source, service type, service definition, authority policy, service call extension information, service serialization triplet, request body, and response body.
6. A communication device based on thrift framework, applied to a server, characterized in that: include: A receiving unit, configured to receive 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 the service bus processes a service request message from a client, and the bus message has the same protocol format as the fixed API interface protocol; A processing unit is used to match the bus message with the current service registration table 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, and return the service response message to the client via the service bus, so that the client performs 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 connected to the client and the server respectively; wherein: The client is configured to send a service request message to the service bus; The service bus is configured to process the service request message to 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 having 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, and return the service response message to the client via the service bus, so that the client performs business processing based on the service response message.
8. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to implement the method steps as described in any one of claims 1 to 5 when executing the computer program stored in the memory.
9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is used to enable a computer to execute the method steps according to any one of claims 1 to 5.
10. A computer program product, characterized in that The computer program product comprises: a computer program code, and when the computer program code is run on a computer, the computer is enabled to execute the method according to any one of claims 1 to 5.
Citation Information
Patent Citations
Data collecting self-organizing architecture construction based on enterprise service bus
CN101364924A
Multitask concurrent executive system and method for hybrid network service
CN101741850A
Thrift protocol-based remote process calling apparatus, method and system
CN107301098A
Testing method, device and equipment for server and computer readable storage medium
CN108650149A
Remote calling method and device, computer equipment and storage medium
CN112181681A