Cross-language service calling method and device

Abstract

The embodiment of the invention provides a cross-language service calling method and device.The method comprises the steps that a first server side conducts parameter language conversion processing on first request data by combining a type mapping relation so as to convert the data into a data form capable of being recognized by a second server side, the problem of cross-language type compatibility is solved, and the user experience is improved. The second request data after parameter conversion is subjected to serialization processing according to a user-defined binary protocol, binary protocol data is generated and then transmitted to a second server side, and the user-defined binary protocol stipulates uniform data format specifications and communication rules; therefore, the binary protocol data can be accurately analyzed according to the customized binary protocol when the data is transmitted to the second server side using different programming languages, and the restored second request data is obtained, so that the second server side can directly call the corresponding target service based on the second request data. Therefore, cross-language service calling with high performance, low delay and high reliability is realized.

Description

Technical Field

[0001] This application relates to the field of distributed service technology, and in particular to a cross-language service invocation method and device. Background Technology

[0002] With the widespread adoption of distributed service system architectures, cross-language calls between services developed in different programming languages ​​have become a core requirement for enterprise applications. In complex business scenarios, there are often situations where cross-language services, such as Node.js front-end services and Java back-end services, need to work together. However, differences in data types, communication protocol compatibility, and performance optimization issues in different language environments make it difficult for traditional service call solutions to meet the business requirements of low latency and high reliability.

[0003] Existing cross-language service call solutions employ a combination of HTTP and JSON: the client sends serialized JSON request data via HTTP, the server parses and executes the logic, and returns a serialized JSON response. However, this solution uses HTTP as the application layer protocol, which contains a large amount of text-formatted header information and redundant fields. This not only results in larger data transmission volumes but also increases network latency due to the additional format parsing required during serialization and deserialization. Furthermore, the JSON serialized data in this solution lacks strong type constraints, requiring developers to manually handle type conversions between languages, and deserialization necessitates dynamic parsing of field types, leading to increased CPU usage.

[0004] Therefore, there is an urgent need for a low-loss and highly reliable method for cross-language service invocation. Summary of the Invention

[0005] This application provides a method and device for cross-language service invocation, which can achieve high-performance, low-latency, and high-reliability cross-language service invocation.

[0006] In a first aspect, embodiments of this application provide a cross-language service invocation method, applied to a first server in a distributed system, the distributed system including the first server and a second server, wherein the first server and the second server use different programming languages, the method comprising:

[0007] The server receives a service request triggered by a client for a target service, parses the service request, and extracts first request data corresponding to the target service from the service request; the first request data is data in a first programming language used by the first server.

[0008] Based on the type mapping relationship corresponding to the first data type of the first request data, the first request data is converted into second request data in the second programming language used by the second server, and a custom binary protocol is used to serialize the second request data to obtain first binary protocol data; the custom binary protocol is used to define the data transmission standard between the first server and the second server;

[0009] The first binary protocol data is forwarded to the second server via a TCP connection, so that the second server uses the custom binary protocol to deserialize the first binary protocol data to obtain the second request data. Based on the second request data, the target service is called to generate the first response data corresponding to the second programming language, and the second binary protocol data after serialization of the first response data is forwarded to the first server.

[0010] The second binary protocol data is deserialized to obtain the first response data;

[0011] The first response data is converted into second response data corresponding to the first programming language, and the second response data is forwarded to the client.

[0012] Secondly, embodiments of this application provide a cross-language service invocation device located at a first server in a distributed system. The distributed system includes a first server and a second server, wherein the first server and the second server use different programming languages. The device includes:

[0013] The parsing module is used to receive a service request triggered by a client for a target service, parse the service request, and extract the first request data corresponding to the target service from the service request; the first request data is data in the first programming language used by the first server;

[0014] The first conversion module is used to convert the first request data into second request data in a second programming language used by the second server based on the type mapping relationship corresponding to the first data type of the first request data, and to serialize the second request data using a custom binary protocol to obtain first binary protocol data; the custom binary protocol is used to define the data transmission standard between the first server and the second server.

[0015] The forwarding module is used to forward the first binary protocol data to the second server via a TCP connection, so that the second server uses the custom binary protocol to deserialize the first binary protocol data to obtain the second request data, calls the target service based on the second request data, generates the first response data corresponding to the second programming language, and forwards the second binary protocol data serialized from the first response data to the first server.

[0016] The processing module is used to deserialize the second binary protocol data to obtain the first response data;

[0017] The second conversion module is used to convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0018] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores a computer program, and when the computer program is executed by the processor, the processor can at least implement the cross-language service invocation method as described in the first aspect.

[0019] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor of an electronic device, enables the processor to at least implement the cross-language service invocation method as described in the first aspect.

[0020] Fifthly, embodiments of this application provide a computer program product, including: a computer program or instructions, which, when executed by a processor of an electronic device, enable the processor to at least implement the cross-language service invocation method as described in the first aspect.

[0021] Sixthly, embodiments of this application provide a cross-language service invocation method applied to a second server in a distributed system, the distributed system including a first server and a second server, wherein the first server and the second server use different programming languages, the method comprising:

[0022] The system receives first binary protocol data sent by the first server via a TCP connection. This first binary protocol data is obtained by the first server parsing a service request triggered by a client for a target service, extracting first request data corresponding to the target service from the service request, converting the first request data into second request data in a second programming language used by the second server based on a type mapping relationship, and then serializing the second request data using a custom binary protocol. The first request data is data in the first programming language used by the first server. The custom binary protocol is used to define the data transmission specifications between the first server and the second server.

[0023] Using the custom binary protocol, the first binary protocol data is deserialized to obtain the second request data;

[0024] Based on the second request data, the request method corresponding to the target service is invoked to obtain the first response data corresponding to the second programming language;

[0025] Using the custom binary protocol, the first response data is serialized to obtain second binary protocol data, and the second binary protocol data is forwarded to the first server so that the first server can deserialize the second binary protocol data to obtain the first response data, convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0026] In a seventh aspect, embodiments of this application provide a cross-language service invocation device, located at the second server in a distributed system. The distributed system includes a first server and a second server, wherein the first server and the second server use different programming languages. The device includes:

[0027] The receiving module is configured to receive first binary protocol data sent by the first server via a TCP connection. The first binary protocol data is obtained by the first server parsing a service request triggered by a client for a target service, extracting first request data corresponding to the target service from the service request, converting the first request data into second request data in a second programming language used by the second server based on a type mapping relationship, and serializing the second request data using a custom binary protocol. The first request data is data in a first programming language used by the first server. The custom binary protocol is used to define the data transmission specifications between the first server and the second server.

[0028] The processing module is used to deserialize the first binary protocol data using the custom binary protocol to obtain the second request data;

[0029] The calling module is used to call the request method corresponding to the target service based on the second request data to obtain the first response data corresponding to the second programming language;

[0030] The forwarding module is used to serialize the first response data using the custom binary protocol to obtain second binary protocol data, and forward the second binary protocol data to the first server so that the first server can deserialize the second binary protocol data to obtain the first response data, convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0031] Eighthly, embodiments of this application provide an electronic device, including: a memory, a processor, and a communication interface; wherein, the memory stores a computer program, and when the computer program is executed by the processor, the processor can at least implement the cross-language service call data processing method as described in the fifth aspect.

[0032] In a ninth aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor of an electronic device, enables the processor to at least implement the cross-language service invocation method as described in the fifth aspect.

[0033] In a tenth aspect, embodiments of this application provide a computer program product, including: a computer program or instructions that, when executed by a processor of an electronic device, enable the processor to at least implement the cross-language service invocation method as described in the fifth aspect.

[0034] In a microservice architecture, a service product can contain multiple service modules depending on its functionality. These service modules run independently on separate servers, and each server may be programmed in a different language. Different languages ​​differ in data type definitions, memory management, and calling conventions. Therefore, when a client initiates a service call, it often faces the problem of the requested data not being correctly recognized and processed due to these differences in server-side languages.

[0035] The cross-language service invocation scheme in this application embodiment provides services to the client through a distributed service system comprising multiple servers using different programming languages. To achieve the cross-language service invocation scheme, after receiving the client's service request, the source server can pre-convert the request data into a parameter language, and then use a custom binary protocol to serialize and encapsulate the converted request data to generate binary protocol data for transmission to the target server. The target server uses the same custom binary protocol to decapsulate and deserialize the data to obtain the request data programmed in the language used by the target server. In this way, the target service can be directly invoked based on the deserialized request data to achieve cross-language service invocation.

[0036] Specifically, after receiving a service request triggered by the client for the target service, the first server first parses the service request to extract the first request data corresponding to the target service. This first request data is data in the first programming language used by the first server. Next, based on the type mapping relationship corresponding to the first request data, the first request data is converted into second request data in the second programming language used by the second server. Then, a custom binary protocol is used to serialize the second request data, resulting in first binary protocol data. This custom binary protocol defines the data transmission standard between the first and second servers. Subsequently, the first binary protocol data is forwarded to the second server via a TCP connection, allowing the second server to use the custom binary protocol to deserialize the first binary protocol data, obtaining the second request data. Based on the second request data, the second server calls the target service, generating first response data in the second programming language, and forwards the serialized second binary protocol data to the first server. Finally, the first server deserializes the second binary protocol data to obtain the first response data, converts it into second response data in the first programming language, and forwards the second response data to the client.

[0037] In the above scheme, the first server performs parameter language conversion on the first request data by combining type mapping relationships. This accurately converts data from different language environments into a data format that the second server can directly recognize, solving the cross-language type compatibility problem and eliminating data understanding barriers caused by language characteristics. Then, the parameter-converted second request data is serialized according to a custom binary protocol, generating binary protocol data which is then transmitted to the second server via a TCP connection. Because the custom binary protocol specifies unified data format standards and communication rules, it ensures that the data transmitted to the second server, which uses different programming languages, can accurately parse the binary protocol data and obtain the restored second request data, guaranteeing the accuracy and consistency of data during network transmission. Thus, the second server can directly call the corresponding target service based on the second request data, achieving high-performance, low-latency, and high-reliability cross-language service calls, ensuring that the client can successfully obtain the required target service. Furthermore, using a custom binary protocol as the application layer protocol and serializing the second request data according to its specified format results in smaller binary protocol data that can more compactly store information, reducing data transmission volume and ensuring correct and efficient data transmission over the network. Attached Figure Description

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

[0039] Figure 1 This application provides an schematic diagram of a cross-language service invocation system as an embodiment of the present application.

[0040] Figure 2 A flowchart illustrating a cross-language service invocation method provided in this application embodiment;

[0041] Figure 3 A schematic diagram of a custom binary protocol provided for an embodiment of this application;

[0042] Figure 4 A flowchart illustrating how a custom binary protocol is used to serialize the second request data to obtain first binary protocol data, as provided in this application embodiment;

[0043] Figure 5 A flowchart illustrating yet another cross-language service invocation method provided in this application embodiment;

[0044] Figure 6 A flowchart illustrating the selection of a target service node to be invoked, provided in an embodiment of this application;

[0045] Figure 7 This is an application diagram illustrating a cross-language service invocation method provided in an embodiment of this application;

[0046] Figure 8 A schematic diagram of a cross-language service invocation device provided in an embodiment of this application;

[0047] Figure 9 To and Figure 8 A schematic diagram of the electronic device corresponding to the cross-language service invocation device provided in the embodiment shown;

[0048] Figure 10 A schematic diagram of a cross-language service invocation device provided in an embodiment of this application;

[0049] Figure 11 To and Figure 10 The illustrated embodiment provides a schematic diagram of the electronic device corresponding to the cross-language service invocation device. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0051] It should be noted that, in the cases involving user information in the embodiments of this application, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse. In addition, the various models involved in this application (including but not limited to language models or large models) comply with relevant laws and standards.

[0052] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0053] With the widespread adoption of distributed service system architectures, cross-language calls between services developed in different programming languages ​​have become a core requirement for enterprise applications. For example, calls between Node.js front-end services and Java back-end services.

[0054] Currently, cross-language service call solutions mainly rely on the HTTP / REST protocol or HTTP-based RPC frameworks (such as gRPC using HTTP / 2). However, these solutions use HTTP as the application layer protocol, and the HTTP protocol itself contains a large amount of text-formatted header information and redundant fields, requiring additional format parsing overhead during serialization and deserialization. For high-frequency, low-data-volume service call scenarios (such as real-time data interaction between microservices), the redundant headers and parsing time of the HTTP protocol significantly increase network transmission latency and reduce call throughput. Furthermore, text serialization formats such as JSON lack strong type constraints, requiring developers to manually handle type conversions between languages, and dynamic parsing of field types during deserialization leads to increased CPU utilization. Additionally, the error rate for parsing complex nested structures is relatively high, easily causing runtime errors.

[0055] To address the performance overhead, efficiency issues, and accuracy problems associated with cross-language service calls, this application provides a solution. The basic idea is to adopt an architecture that deeply integrates a custom binary protocol (application layer) with a TCP protocol (transport layer). Before calling the target service, language type conversion and protocol-level optimization corresponding to the pre-compiled request data enable high-performance, low-latency, and high-reliability cross-language service calls. Specifically, before calling the target service, the source server can pre-convert the request data into a specific language. Then, using the custom binary protocol as the transport application layer protocol, the converted request data is serialized according to the protocol's format to generate binary protocol data, which is transmitted to the target server via a TCP connection. The target server uses the same custom binary protocol to deserialize the binary protocol data to obtain the request data programmed in the target server's language. This allows direct invocation of the target service based on the deserialized request data, achieving low-energy and high-reliability cross-language service calls.

[0056] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0057] The cross-language service invocation method provided in this application embodiment can be executed by an electronic device, which can be a terminal device such as a PC, laptop, or smartphone, or a server. The server can be a physical server containing an independent host, a virtual server, a cloud server, or a server cluster.

[0058] Figure 1 This application provides an schematic diagram of a cross-language service invocation system, as illustrated in the embodiments of this application. Figure 1 As shown, the system includes a client and a distributed service system that provides services to the client.

[0059] The client can be various terminal devices or applications that require service access. Its distributed service system includes multiple servers using different programming languages, such as... Figure 1 The diagram illustrates the first server, the second server, ..., the Nth server, etc.

[0060] In practice, when a client wants to access a target service, it can construct a service request using protocols such as HTTP / HTTPS or RPC. This request includes the target service identifier, request method, request parameters, and request headers, and is sent over the network to a designated port in the distributed service system—specifically, the port corresponding to the first server. When the first server receives the client's service request for the target service, it parses the request to extract the first request data corresponding to the target service.

[0061] The first request data is data in the first programming language used by the first server. That is, the client and the first server use the same programming language. Furthermore, when parsing the service request, the service name corresponding to the target service can be extracted from the request. Based on this service name, a second server can be determined to provide the target service. This second server uses a second programming language.

[0062] Since the second server providing the target service uses a different programming language than the first server, in order to avoid the second server being unable to directly recognize the first request data when calling the service, the first server can first perform parameter language type conversion on the first request data before forwarding it to the second server, and then forward the converted request data to the corresponding second server.

[0063] In this process, when the first server performs parameter language type conversion, it can first determine the first data type corresponding to the first request data, and then, based on the type mapping relationship corresponding to the first data type, convert the first request data into second request data in the second programming language used by the second server. The type mapping relationship describes the mapping relationship between the first data type in the first programming language and its corresponding second data type in the second programming language.

[0064] In practical applications, the mapping relationship between the data types in the first programming language and their corresponding data types in the second programming language can be pre-stored. In this way, the first server can quickly and accurately perform parameter language type conversion processing on the first request data based on the pre-stored mapping relationship.

[0065] Upon receiving the second request data after parameter language type conversion, the first server uses a custom binary protocol to serialize the second request data, obtaining first binary protocol data in binary format. The custom binary protocol defines the data transmission specifications between the first and second servers.

[0066] In this embodiment of the application, in order to ensure that two servers using different programming languages ​​can accurately interact and parse data, and avoid problems such as data format incompatibility and field parsing errors caused by language differences, and to transmit data more efficiently, a custom binary protocol suitable for data transmission between cross-language servers is designed in this embodiment of the application.

[0067] The custom binary protocol, by predefining the target serialization rules for data serialization and the data structure (including protocol header and message body) for data transmission between servers, enables servers in different programming language environments to encapsulate and decapsulate data based on a unified standard. This design avoids the redundant overhead of text protocols (such as JSON and XML) and solves the compatibility problems caused by differences in type systems in cross-language communication, thereby significantly improving data transmission efficiency while ensuring the accuracy of interaction.

[0068] Furthermore, the header of the custom binary protocol only contains necessary control fields (such as message length, version number, and checksum), excluding redundant descriptive information. Field lengths are strictly defined by a fixed number of bytes, avoiding the overhead and ambiguity of delimiter parsing found in text protocols. This minimalist design results in a very small header size, and combined with the compact encoding of the binary data body, significantly reduces the overall data transmission volume, network bandwidth consumption, and parsing time on both servers. In short, the custom binary protocol designed in this application is compact and efficient.

[0069] In this way, the second request data is serialized according to the target serialization rules agreed in the custom binary protocol to obtain binary data. Then, according to the data format predetermined in the custom binary protocol, the binary data and metadata such as the target serialization rules are encapsulated to generate the first binary protocol data. This not only ensures the structural consistency and parsing reliability of the data during transmission, but also supports seamless communication across platforms and languages.

[0070] Next, the first server forwards the first binary protocol data to the second server via a TCP connection. Both the first and second servers can use TCP as their transport layer protocol. TCP, as a connection-oriented and reliable transport layer protocol, possesses features such as ordered data transmission, retransmission mechanisms, and flow control. In this embodiment, choosing TCP as the transmission carrier ensures that the first binary protocol data is not lost or duplicated during forwarding and arrives at the second server in order, providing a fundamental reliability guarantee for cross-service data interaction.

[0071] Furthermore, custom binary protocols are inherently compact and efficient, making them a natural fit for TCP's byte-stream transmission method. Unlike text protocols (such as JSON), binary data does not require character encoding conversion and can be transmitted directly in byte form over a TCP connection, reducing additional encoding / decoding overhead and further improving data transmission efficiency between servers.

[0072] After receiving the first binary protocol data sent by the first server via a TCP connection, the second server uses a custom binary protocol to deserialize the first binary protocol data to obtain the second request data. That is, the second server uses the same custom binary protocol specification as the first server, and according to the provisions of the custom binary protocol, parses and deserializes the first binary protocol data to obtain the second request data that the second server can directly recognize.

[0073] Next, the second server invokes the target service based on the second request data, generates first response data corresponding to the second programming language, and forwards the serialized second binary protocol data of the first response data to the first server. Specifically, the first response data can be serialized and encapsulated according to a custom binary protocol to obtain the second binary protocol data.

[0074] In practical applications, the processing capacity of a single server is limited and may not be able to handle high concurrency requests. Furthermore, the failure of a single server can render the entire service unavailable. Therefore, to address the limitations of a single server in terms of performance, reliability, scalability, and availability, this embodiment configures multiple servers for each server in the distributed service system, allowing multiple servers to process requests in parallel and shorten response time.

[0075] Specifically, in one optional embodiment, each server can be configured with multiple servers, and each server can provide the client with the same service functions as its respective server. In practical applications, to better distinguish and manage the servers among multiple servers, each server in each server can be numbered, so that each server has its own identification information. For example, for Figure 1 The second server shown in the diagram includes N servers, with server 1 numbered 1, server 2 numbered 2, and server N numbered N.

[0076] In one optional embodiment, upon receiving the second request data, a target server i can be determined from the N servers corresponding to the second server using a preset load balancing strategy. The second request data is then sent to target server i. Target server i invokes a target service based on the second request data to generate first response data corresponding to the second programming language. The first response data is then serialized and encapsulated according to a custom binary protocol to obtain second binary protocol data. This second binary protocol data, serialized from the first response data, is then forwarded to the first server.

[0077] After receiving the second binary protocol data sent by the second server, the first server can parse, deseal, and deserialize the received second binary protocol data according to a custom binary protocol to obtain the first response data.

[0078] Since the client can only directly recognize data in the first programming language, after the first server deserializes the first response data, it converts the first response data into second response data corresponding to the first programming language based on the type mapping relationship of the data type of the first response data. Finally, the second response data is forwarded to the client so that the client can successfully access the target service.

[0079] As described above, when making a service call, the first server first performs parameter language conversion on the parameters in the first request data to obtain the second request data corresponding to the second programming language used by the second server. Then, it serializes the language-type converted second request data according to the format in the custom binary protocol. In this way, after receiving the binary protocol data, the second server can quickly complete the deserialization according to the parsing rules of the custom binary protocol and directly process the restored second request data based on its own second programming language to call the corresponding target service.

[0080] In other words, because the parameter language conversion is completed in advance, the second server does not need to handle cross-language type adaptation issues after receiving binary protocol data, significantly reducing the risk of parsing errors caused by type incompatibility. On the other hand, the serialization and deserialization process based on a custom binary protocol reduces redundant data transmission compared to text protocols, and the parsing logic is simpler and more efficient, significantly improving data processing speed. At the same time, the unified protocol specification ensures the consistency of data transmission between the two servers, maintaining stable communication quality even when facing complex service data, ultimately achieving efficient, accurate, and reliable data interaction between servers using different programming languages.

[0081] The above embodiments describe the main functions of each component in the cross-language service invocation system. The cross-language service invocation process will be described in detail below with reference to the following embodiments.

[0082] Figure 2 A flowchart illustrating a cross-language service invocation method provided in this application embodiment is available. This method can be... Figure 1 The first server in the distributed service system shown executes the following: Figure 2 As shown, it may include the following steps:

[0083] 201. Receive the service request triggered by the client for the target service, parse the service request, and extract the first request data corresponding to the target service from the service request.

[0084] 202. Based on the type mapping relationship corresponding to the first request data, the first request data is converted into second request data in the second programming language used by the second server, and the second request data is serialized using a custom binary protocol to obtain the first binary protocol data.

[0085] 203. The first binary protocol data is forwarded to the second server via a TCP connection, so that the second server uses a custom binary protocol to deserialize the first binary protocol data to obtain the second request data. Based on the second request data, the target service is called to generate the first response data corresponding to the second programming language, and the second binary protocol data after serialization of the first response data is forwarded to the first server.

[0086] 204. Deserialize the second binary protocol data to obtain the first response data.

[0087] 205. Convert the first response data into the second response data corresponding to the first programming language, and forward the second response data to the client.

[0088] When the first server receives a service request from the client targeting the target service, it parses the request to extract the first request data corresponding to the target service. The service request includes information such as request headers, request body, request URL, protocol version, and request timestamp. The request header typically contains metadata such as client type, data format, and authentication information. The request body carries the core data, including request parameters and structured data corresponding to the request method.

[0089] Upon receiving a service request, it can be parsed according to the protocol version within the request to extract the service name and the first request data corresponding to the target service. The first request data refers to the key data directly used by the target service to execute its specific service functions; specifically, it may include the request parameters and request method corresponding to the target service.

[0090] Next, based on the type mapping relationship corresponding to the first request data, the first request data is converted into second request data in the second programming language used by the second server. The type mapping relationship describes the mapping relationship between data types in the first programming language and their corresponding data types in the second programming language. This type mapping relationship is the foundation for cross-language data exchange, ensuring semantic consistency and structural integrity when data is transmitted between servers corresponding to different service modules.

[0091] In practice, a type conversion mapping table corresponding to the first programming language and the second programming language can be created in advance. Furthermore, the corresponding data types in the second programming language for each data type in the first programming language are determined, their corresponding type mapping relationships are created, and these type mapping relationships are stored in the type conversion mapping table. Additionally, type conversion mapping tables can be created for other programming languages ​​to store the data type conversion mapping relationships between them. This allows the first server to convert the received first request data into request data in any programming language used by the server providing the service to be invoked, thus directly calling the service provided by the server using any programming language.

[0092] By creating type conversion mapping tables between multiple programming languages, seamless conversion between various programming languages ​​can be supported on different servers, thus solving the compatibility problem of cross-language types and enabling different servers to call and use services provided by servers in various different programming languages.

[0093] Therefore, when performing parameter language type conversion on the first request data, we can first determine the first data type corresponding to the first request data, then retrieve the type conversion mapping relationship corresponding to the first data type from the type conversion mapping table corresponding to the first programming language and the second programming language, and perform parameter language type conversion on the first request data based on the second data type corresponding to the first data type in the type conversion mapping relationship to obtain the second request data.

[0094] In inter-service data interaction scenarios, different programming languages ​​represent data structures differently. Serializing data before transmission ensures secure and efficient data flow. In distributed service architectures, data transmission between services relies on serialization protocols to convert in-memory objects into a transmittable format. Existing serialization protocols (such as JSON and Protobuf) struggle to balance transmission efficiency and data format compatibility. For example, while JSON serialization offers high readability, the serialized data is large, making it unsuitable for high-concurrency scenarios. Protobuf, despite its high compression rate, requires strict adherence to version compatibility rules for field changes, making it less suitable for frequently iterating service systems. Furthermore, none of these general protocols are optimized for specific inter-service interaction scenarios (such as the request forwarding scenario between the first and second servers in this application), leading to redundant fields and time-consuming parsing in the serialization of second request data containing complex nested structures, thus impacting service response efficiency.

[0095] To address the aforementioned issues, this application proposes a novel serialization protocol (hereinafter referred to as a custom binary protocol) for data transmission between cross-language services. This protocol is custom-designed to address the structural characteristics of the second request data (such as including request parameters, metadata, and other multi-level information). It enables efficient data compression and rapid parsing, flexibly adapts to dynamic changes in data fields, and is compatible with the cross-language interaction scenarios between the first and second servers.

[0096] The custom binary protocol defines the data transmission specifications between the first and second servers, enabling servers in different programming language environments to encapsulate and decapsulate data based on a unified standard. This custom protocol clarifies how data is transmitted between the two servers by pre-defining processing rules and specifications. The processing rules include target serialization rules for data serialization, compression algorithms for data compression, verification methods for data validation, and encapsulation rules. The specifications can include data format, the meaning of each field in the transmitted data, and interaction rules for data transmission.

[0097] Specifically, in this embodiment, a custom binary protocol specifies that data between two servers is encoded in binary form during network transmission. Compared to text protocols, it is smaller in size and faster to parse, making it suitable for high-performance scenarios. Furthermore, it defines the specific meaning of each binary segment, as well as the corresponding verification method, target serialization rules, and encapsulation format during data transmission, to address data format and cross-language conversion issues for cross-language servers.

[0098] After obtaining the second request data, it can be serialized according to the target serialization rules specified in the custom binary protocol to convert the second request data into binary data in a transmittable format. Then, according to the encapsulation format specified in the custom binary protocol, the converted binary data and other metadata are encapsulated to generate the first binary protocol data. This not only ensures that two servers using different programming languages ​​can accurately interact and parse data, avoiding problems such as data format incompatibility and field parsing errors caused by language differences, but also enables more efficient data transmission.

[0099] Next, the first binary protocol data is forwarded to the second server via a TCP connection. Because the first binary protocol data is compact and efficient, it can be transmitted directly in binary byte form via the TCP connection when forwarding it to the second server. This avoids intermediate conversion, reduces additional encoding / decoding overhead, and further improves the data transmission efficiency between servers.

[0100] In this embodiment, the reliability of TCP and the efficiency of the custom binary protocol complement each other. TCP ensures secure data delivery, while the custom binary protocol ensures efficient data transmission. The combination of the two enables cross-service data interaction to achieve a balance between stability, efficiency, and compatibility (adapting to servers with different programming languages), ultimately supporting precise and efficient service collaboration between services in a distributed architecture.

[0101] In this way, the first binary protocol data can be efficiently and reliably forwarded to the second server via a TCP connection. The second server then uses a custom binary protocol to decapsulate the first binary protocol data, extracting the message body by stripping metadata such as the protocol header. Following the target serialization rules agreed upon in the custom binary protocol, the message body is deserialized to obtain the second request data. Based on the second request data, the target service is invoked to generate the first response data corresponding to the second programming language. Finally, the second binary protocol data, serialized from the first response data, is forwarded to the first server.

[0102] Then, according to the data format agreed in the custom binary protocol, the second binary protocol data is decapsulated to extract the corresponding message body from the second binary protocol data, and the service data encapsulated in the message body is deserialized according to the target serialization rules agreed in the custom binary protocol to obtain the first response data.

[0103] Finally, based on the type conversion mapping relationship corresponding to the data type of the first response data, the first response data corresponding to the second programming language is converted into the second response data corresponding to the first programming language, and the second response data is forwarded to the client so that the client can successfully access the target service.

[0104] In summary, in this embodiment, the first server, by combining type mapping relationships, performs parameter language conversion processing on the first request data. This accurately converts data from different language environments into a data format that the second server can directly recognize, solving the cross-language type compatibility problem and eliminating data understanding barriers caused by language characteristics. Then, the parameter-converted second request data is serialized according to a custom binary protocol, generating binary protocol data which is then transmitted to the second server via a TCP connection. Since the custom binary protocol specifies a unified data format standard, it ensures that data transmitted to the second server, which uses different programming languages, can accurately parse the binary protocol data and obtain the restored second request data, guaranteeing the accuracy and consistency of data during network transmission. Thus, the second server can directly call the corresponding target service based on the second request data, achieving high-performance, low-latency, and high-reliability cross-language service calls, ensuring that the client can successfully obtain the required target service. Furthermore, using a custom binary protocol as the application layer protocol and serializing the second request data according to its specified format results in smaller, more compact binary protocol data, reducing data transmission volume and ensuring correct and efficient data transmission over the network.

[0105] The following is an exemplary description of the specific implementation process of parameter language conversion processing for the first request data in the above embodiments. Specifically, before converting the first request data into second request data based on the type mapping relationship corresponding to the first request data, the method further includes a process of automatically generating a service interface definition file in the first programming language.

[0106] Specifically, the process involves obtaining the service code corresponding to the target service interface. The target service interface is the interface used to provide the target service, and the service code is the code in the second programming language. Metadata corresponding to the target service interface is extracted from the service code. Using a pre-defined type mapping relationship, and based on the metadata, the target service interface of the first programming language type is converted into interface elements matching the second programming language type. Based on the syntax specifications of the first programming language, the converted interface elements are structurally integrated to generate a service interface definition file in the first programming language.

[0107] One possible implementation for converting a target service interface of a first programming language type into an interface element matching a second programming language type based on metadata and utilizing a preset type mapping relationship is as follows: Parse the metadata corresponding to the target service interface to obtain the first type information, first field information, and first method information corresponding to the target service interface. Based on the preset type mapping relationship, perform type conversion processing on the first type information, first field information, and first method information corresponding to the target service interface to obtain the second type information, second field information, and second method information corresponding to the target service interface. The second type information, second field information, and second method information corresponding to each service interface are information of the first encoding language. The second type information is determined as the interface name, the second field information is converted into the interface's attribute name and corresponding attribute type, and the second method information is converted into the interface's method name, parameter list, and return value type.

[0108] One possible implementation for generating a service interface definition file in the first programming language by structurally integrating the converted interface elements based on the syntax specification of the first programming language is as follows: Following the interface declaration format of the second programming language, using the interface name as the interface identifier, the attribute names and attribute types are sequentially defined as member attributes of the interface, and the method names, parameter lists, and return value types are defined as member methods of the interface, thus generating a service interface definition file conforming to the specification of the first programming language. This service interface definition file serves as the authoritative interface specification between the service provider (second server) and the service consumer (first server), clearly defining method signatures, parameter types, return value structures, and exception definitions, eliminating ambiguities in the parsing of the same service interface across different programming languages.

[0109] In other words, before the first server calls the target service corresponding to the second server, it can automatically generate a service interface definition file that conforms to the specifications of the first programming language. This not only eliminates the cost of manual maintenance and avoids manually writing service interface definition files for each language, thus improving development efficiency, but also verifies the parameter types in the first request data based on the service interface definition file to ensure cross-language compatibility and reduce runtime risks.

[0110] Next, the request parameters in the first request data are verified using the service interface definition file that conforms to the first programming language specification. After the verification is successful, the first request data is converted into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data.

[0111] Specifically, the first request data includes the request method corresponding to the target service and the second request parameters required when calling the request method. In an optional embodiment, the second request parameters are verified to conform to the type requirements set for the second request parameters in the service interface definition file. If the second request parameters are successfully verified, in response to confirming successful verification, the first data type corresponding to the second request parameters is identified, and the second data type corresponding to the first data type is found from the type conversion mapping table. Based on the second data type, the second request parameters are converted into first request parameters using the second programming language used by the second server.

[0112] One possible implementation for verifying whether a second request parameter conforms to the type requirements set for the second request parameter in the service interface definition file may include: in response to determining that the data type corresponding to the second request parameter is a basic data type, verifying whether the second request parameter conforms to the type mapping requirements defined in the service interface definition file; or, in response to determining that the data type corresponding to the second request parameter is a composite data type, verifying whether the field composition, nesting level, and required field settings of the second request parameter are consistent with the interface structure definition in the service interface definition file. Here, a composite data type refers to a structured data type composed of multiple data fields.

[0113] In other words, when validating the parameter type of the second request parameter, the validation includes checking whether it conforms to type specifications, structural constraints, and validation rules. Different validation rules can be applied according to the data type. For example, for basic data types, it can be checked whether the basic data type conforms to the type mapping standard defined by the target service interface. For example, for string data, it can be checked whether it is truly a string; for data of different types, it can be checked whether it is a valid number. For composite data types, it can be checked whether the field composition, nesting level, and required field settings of complex objects are consistent with the structural definition of the target service interface. For collection-type data, it can be checked whether the element type matching degree and capacity limit of the collection-type parameters meet the interface constraints. For parameters containing service function semantics, it can be checked whether the parameters conform to preset format, preset range, and other validation conditions.

[0114] By combining the service interface definition file of the first programming language, we can verify whether the parameter type corresponding to the second request parameter in the first request data conforms to the definition constraints. This ensures the accuracy of parameter language type conversion processing, guarantees cross-language compatibility, and reduces runtime risks.

[0115] In another optional embodiment, type constraints can be generated based on the service interface definition file, and the validity of the parameters can be verified based on the type constraints before the first request data is processed by parameter language conversion.

[0116] After the type validation of the first request data passes, the first data type corresponding to the second request parameter is identified, and the second data type corresponding to the first data type is found from the type conversion mapping table. Based on the second data type, the second request parameter is converted into the first request parameter of the second programming language used by the second server. This can accurately convert the parameter language type corresponding to the second request parameter in the first request data to ensure that the corresponding target service can be successfully called.

[0117] In practical applications, a single request parameter may correspond to multiple data elements. For example, when a client requests access to a user service, the second request parameter may include information such as the user identifier (id), username, and request timestamp. That is, when the second request parameter in the first request data includes multiple data elements, the parameter language type conversion process can be performed separately for each data element in the second request parameter to convert each data element into its corresponding data element in the second programming language.

[0118] Furthermore, in distributed service systems, serialization protocols act as a conversion bridge during data exchange between services, and their reliability directly impacts the stability of the distributed service system. However, traditional serialization schemes (such as JSON) generally employ recursive traversal of the data object graph for serialization. While this design performs well with simple data structures, it exposes fatal flaws when dealing with complex object relationships (nested objects). For example, when bidirectional references (such as parent-child nodes referencing each other) or circular references exist between data objects (A references B, B references C, and C references A), recursive serialization can fall into an infinite loop. Taking JSON as an example, its specification does not define an object reference mechanism; the serializer will continuously expand the reference chain until a stack overflow is triggered, leading to the risk of stack overflow, which in turn can cause the distributed service system to crash or fall into an infinite loop.

[0119] To avoid stack overflow or data loss due to circular references during serialization of data elements in the second request parameters, in an optional embodiment, when serializing each data element in the second request parameters, explicit references can be used to track each data object to achieve a complete mapping of the object graph. Circular reference detection is performed on each data element. When a data element is detected as a serialized object, it is determined to be a nested object. Before serializing the data element, circular reference processing can be performed on it first. This avoids runtime crashes and improves the robustness of service calls.

[0120] Furthermore, parameterized language type conversion may disrupt the reference structure corresponding to the original data elements. For example, if object A references object B, and object B references object A, the type conversion process will recursively process the reference chain by default. This can lead to stack overflow or infinite loops during the conversion process. Therefore, in this embodiment, the circular reference detection in the data element processing flow can be designed as a dual protection mechanism: performing circular reference detection before parameterized language type conversion and performing it again after parameterized language type conversion.

[0121] Performing two circular reference checks is to ensure the stability and security of the distributed service system at different stages and with different granularities. The first check is performed when building or updating the object graph, i.e., before the parameter language type conversion of the second request parameter, to prevent circular references from forming during the construction process. The second check is performed before the serialization operation to ensure that even if a circular reference is accidentally introduced at runtime, it will be detected in time. Circular reference handling methods include breaking references, using weak references, topological sorting, and serialization substitution. Whether two checks are needed depends on the complexity and reliability requirements of the distributed service system. In practical applications, a single circular reference handling operation can be performed before or after the parameter language type conversion.

[0122] The following details the detection of circular references for each data element and the handling of circular references when detected. Since the detection and handling of circular references are largely the same for each data element, we will only use the first data element as an example to illustrate its specific implementation. Here, the first data element is any one of the multiple data elements.

[0123] Specifically, for the first data element, before performing type conversion on it, it's first checked whether the first data element has already undergone type conversion to determine if a circular reference exists. In practice, the data identifier corresponding to the first data element is retrieved from the allocation table. The allocation table records data elements that have undergone type conversion. In actual applications, after each data element has undergone type conversion, a unique data identifier can be assigned to each data element and stored in the allocation table. Thus, when performing circular reference detection on the first data element, the existence of a circular reference can be determined by checking if a corresponding data identifier is stored in the allocation table. If a corresponding data identifier is found, it indicates that a type conversion has already been performed on the first data element, confirming the existence of a circular reference, and the circular reference can then be addressed.

[0124] Specifically, in response to determining that a data identifier corresponding to the first data element is found in the allocation table, a circular reference is processed for the first data element. A unique identifier is assigned to the first data element and a circular reference flag is added. The position of the circular reference node in the data structure is replaced with a special flag containing the unique identifier, and the reference path corresponding to the first data element is recorded. Based on the second data type, the first data element is converted into a second data element in the second programming language.

[0125] Next, it checks whether the second data element has a circular reference flag. If a circular reference flag is detected, the circular reference is processed first, and then the second data element is serialized. This way, the original data remains unchanged, and the reference relationship is only changed during the serialization stage.

[0126] The configuration allows you to select a corresponding circular reference handling strategy. These strategies include reference replacement, lazy loading, and truncation protection. Reference replacement replaces the circular reference with a lightweight placeholder (e.g., {"$ref":"obj_1"}). Lazy loading generates a corresponding proxy object, delaying the parsing of the actual data. Truncation protection returns an explicit truncation flag, such as {"truncated":true}, when the depth limit is exceeded.

[0127] Furthermore, in practical applications, after performing parameter language type conversion on each data element in the first request data, in order to ensure the reliability of the conversion result so that the second server can parse the correct request data, in another optional embodiment, after obtaining the second request data, the second request data is verified. If the verification is successful, it is then checked whether each data element in the second request data has a circular reference marker. If a circular reference marker is detected, the circular reference is processed first, and then serialization processing is performed on each data element in the second request data. This allows the original data to remain unchanged while the reference relationship is converted only during the serialization stage.

[0128] The second request data includes the first request parameters. The specific process for verifying the second request data can be as follows: First, perform data integrity verification on the second request data to check for missing fields, complete required fields, and whether the object structure corresponding to the first request parameters matches the interface definition of the second programming language. Second, perform data type correctness verification on the first request parameters to check whether the field types of each field in the first request parameters match the type specifications of the second programming language, whether the data format conforms to preset standards, and whether the values ​​are within a reasonable range. Third, perform processing rule verification on the first request parameters to check whether they conform to preset processing logic, whether they satisfy field constraints, and whether the relationships between associated objects are legal. When the data integrity verification, type correctness verification, and processing rule verification all pass, the first request parameters are deemed successfully verified.

[0129] Next, after confirming that the first request parameter verification is successful, in response to this confirmation, a custom binary protocol is used to serialize the request method in the first request parameter and the second request data to obtain the first binary protocol data. This allows for verification of the converted request data, ensuring the correctness of the parameter language type conversion, enabling the client to successfully access the target service provided by the second server. The above embodiment describes the process of serializing and encapsulating the second request data after parameter language conversion according to the designed custom binary protocol to generate the first binary protocol data. However, traditional serialization processing typically requires multiple memory copies (e.g., from object memory to the JVM heap memory buffer, and then to the kernel buffer), and each serialization or data transfer dynamically allocates a buffer, increasing the operating system's memory management overhead.

[0130] In one alternative embodiment, the serialization process is optimized to avoid the memory copy overhead and frequent memory allocation in the traditional serialization process by adopting a zero-copy serialization method. It can directly reuse the pre-allocated buffer that can be directly used by network I / O, and directly serialize the second request data in the memory buffer to generate binary data.

[0131] In practice, the target buffer pre-allocated for the service request is obtained from the buffer pool, the second request data is written into the target buffer, and the second request data is serialized using a custom binary protocol in the target buffer to obtain the first binary protocol data.

[0132] Among these methods, memory-mapped files can be used to transform file I / O operations into memory operations, allowing the data serialization process to be completed directly in the mapped target buffer, avoiding the multiple copies of "object → heap memory → kernel buffer" in traditional serialization.

[0133] Furthermore, before detailing the serialization process according to the custom binary protocol in the above embodiments, let's first introduce the protocol format corresponding to the custom binary protocol designed in this application. For example... Figure 3 The protocol format shown illustrates that in a custom binary protocol, a complete binary protocol data set typically consists of two parts: a protocol header and a message body. The protocol header describes the metadata of the data packet and serves as a guide for the receiving end (such as a second server) to parse the binary protocol data. The message body carries the actual service data and is the core content of the data packet.

[0134] For example, such as Figure 3 The protocol header shown includes a version number field, a total length field, a sequence number field, a service number field, a message type field, a compression algorithm field, a serialization rule field, and a platform type field. The total length field occupies 4 bytes, while all other fields occupy 1 byte each, meaning the protocol header consists of 14 bytes. This concise header avoids redundant information. Specifically, the version number field stores the identifier corresponding to the protocol version. The total length field stores the size of the data packet corresponding to the generated binary protocol data. The sequence number field stores the request ID corresponding to the client's service request. The service number field stores the service number corresponding to the target service to be accessed. The message type field stores whether the binary protocol data is a request or response data. The compression algorithm field stores the compression algorithm used to compress the binary protocol data. The serialization rule field stores the serialization rule used to perform serialization processing. The platform type field stores the platform information corresponding to the sending end.

[0135] Among them, such as Figure 3The message body shown includes a header delimiter, message body fields, and a footer delimiter. Both the header and footer delimiters occupy 5 bytes. The message body fields are variable, allowing for dynamic addition of data. The message body fields include metadata fields, security verification fields (for storing metadata and security verification information), actual request parameters, and return values. Furthermore, they can be formatted as follows... Figure 3 The encapsulation format shown encapsulates the protocol header first and the message body last to generate binary protocol data.

[0136] As described above, the protocol header fields in the binary protocol data are concise and of fixed length, allowing the receiving end to quickly parse out the required metadata and locate the corresponding message body structure without complex logic. Furthermore, the message body fields can be dynamically added without affecting the overall structure or usability. The following section details the specific implementation process of serializing and encapsulating the second request data to generate the first binary protocol data, based on the designed custom binary protocol.

[0137] Figure 4 This application provides a flowchart illustrating how a custom binary protocol is used to serialize the second request data to obtain first binary protocol data. (See flowchart for example.) Figure 4 As shown, the method includes the following steps:

[0138] 401. Encode the second request data into user data in binary format according to the target serialization rules agreed in the custom binary protocol.

[0139] 402. Based on the data size corresponding to the user data, select the corresponding target compression algorithm from the preset algorithm list.

[0140] 403. Compress the user data according to the target compression algorithm to obtain the compressed request data.

[0141] 404. According to the data format corresponding to the binary protocol data specified in the custom binary protocol, encapsulate the compressed user data, target serialization rule identifier, and target compression algorithm identifier to generate the first binary protocol data.

[0142] When generating the first binary protocol data to be transmitted, the second request data can be encoded into binary format user data according to the target serialization rules agreed upon in the custom binary protocol. The second request data includes the request method corresponding to the target service and the first request parameters required to call that request method. During encoding, only the first request parameters and the method name corresponding to the request method in the second request data can be encoded to obtain the binary format user data.

[0143] In practical applications, user data may contain a large amount of data, resulting in a significant data volume that impacts data transmission efficiency between servers. Therefore, binary-formatted user data can be compressed. During compression, a target compression algorithm can be selected from a pre-defined algorithm list based on the size of the user data. The user data is then compressed according to the target algorithm to obtain the compressed request data.

[0144] This means selecting the optimal compression strategy based on the size of the user data. For example, small data can be compressed without compression, medium data can be compressed quickly, and large data can be compressed with a high compression ratio. This not only reduces the size of binary data and the amount of data transmitted, but also improves transmission efficiency.

[0145] Next, according to the data format corresponding to the binary protocol data specified in the custom binary protocol, the compressed user data, target serialization rule identifier, and target compression algorithm identifier are encapsulated to generate the first binary protocol data.

[0146] When encapsulating this data, the process begins by retrieving the data corresponding to each field in the protocol format, according to the data format specified in the custom binary protocol. Specifically, the target service interface corresponding to the request method is determined based on the request method of the target service. Then, a pre-defined service number mapping table is queried based on the target service interface to determine the service number corresponding to the service request. This pre-defined service number mapping table stores the mapping relationship between the unique identifier of each service interface (such as interface name, URI path, etc.) and its corresponding numerical number. Using this pre-defined service number mapping table, the interface request can be quickly converted into an internal service number. Next, the message type corresponding to the service request is determined based on the first request parameters. Metadata is extracted from the first request parameters to obtain metadata including parameter type, parameter length, and field descriptions. A pre-defined hash algorithm is used to encrypt the first request parameters and the request method, generating security verification data. Finally, according to the target serialization rules, the metadata and security verification data are sequentially converted into binary format metadata and binary format security verification data.

[0147] After obtaining the data corresponding to each field in the protocol format, the data is encapsulated according to the encapsulation format specified in the protocol. Specifically, following the order of protocol header first and message body last, the service number corresponding to the determined service request, message type, target compression algorithm identifier, and serialization rule identifier are written into the protocol header area of ​​the custom binary protocol, and the binary format metadata, binary format security verification data, and compressed user data are written into the message body area of ​​the custom binary protocol to generate the first binary protocol data.

[0148] Additionally, the version number field, total length field, serial number field, and platform type field can be obtained simultaneously, and this data can be filled into the corresponding field positions in the protocol header area. In summary, this embodiment of the application serializes the second request data according to the target serialization rules agreed upon in the custom binary protocol to obtain binary format user data. This converts structured data into compact binary format data, reducing data volume and improving transmission efficiency. Furthermore, the user data is further compressed by dynamically selecting a compression algorithm based on the data size, which further reduces the corresponding data volume. This allows for protocol encapsulation of the compressed user data with the target serialization rule identifier and compression algorithm identifier, resulting in less redundant information in the generated first binary protocol data. This reduces data transmission volume, thereby improving data transmission efficiency and protocol parsing accuracy.

[0149] The following section provides a detailed explanation of the communication connection between the first server and the second server.

[0150] In this embodiment, the first server can forward the first binary protocol data to the second server via a TCP connection. Before forwarding the first binary protocol data to the second server, a previously established TCP connection can be reused. Since each new connection requires a three-way handshake, and each connection needs independent allocation of send / receive buffers and kernel data structures, this can easily trigger system resource bottlenecks in high-concurrency scenarios. Therefore, in this embodiment, previously established TCP connections can be reused to avoid handshake delays, reduce transmission latency, and minimize connection overhead.

[0151] Specifically, the system searches the connection mapping table for the TCP connection corresponding to the target service to detect whether a TCP connection has been established between the first server and the service node providing the target service in the second server. In response to determining that a TCP connection has been established, the system reuses the established TCP connection between the first server and the service node. The first binary protocol data is then forwarded to the service node by reusing the established TCP connection.

[0152] The above embodiments describe the specific implementation process of cross-language service calls corresponding to the first server. The specific implementation process of cross-language service calls corresponding to the second server will be described in detail below.

[0153] Figure 5 A flowchart illustrating another cross-language service invocation method provided in this application embodiment, the method can be... Figure 1 The second server in the distributed service system shown executes the following: Figure 5 As shown, it may include the following steps:

[0154] 501. Receive the first binary protocol data sent by the first server through the TCP connection.

[0155] 502. Using a custom binary protocol, deserialize the first binary protocol data to obtain the second request data.

[0156] 503. Based on the second request data, call the request method corresponding to the target service to obtain the first response data corresponding to the second programming language.

[0157] 504. Using a custom binary protocol, serialize the first response data to obtain second binary protocol data, and forward the second binary protocol data to the first server so that the first server can deserialize the second binary protocol data to obtain the first response data, convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0158] The second server receives the first binary protocol data sent by the first server via a TCP connection. This first binary protocol data is obtained by the first server parsing the service request triggered by the client for the target service, extracting the first request data corresponding to the target service from the service request, converting the first request data into second request data in a second programming language used by the second server based on the type mapping relationship, and then serializing the second request data using a custom binary protocol. The first request data is data in the first programming language used by the first server. The custom binary protocol is used to define the data transmission specifications between the first and second servers.

[0159] The specific implementation process for generating the first binary protocol data is described above and will not be repeated here.

[0160] When the second server receives the first binary protocol data sent by the first server through a TCP connection, the second server adopts the same custom binary protocol specification as the first server, and parses and deserializes the first binary protocol data according to the provisions in the custom binary protocol to obtain the second request data that the second server can directly recognize.

[0161] One possible implementation for parsing and deserializing the first binary protocol data is as follows: Parse the protocol header area of ​​the first binary protocol data according to a custom binary protocol, extracting the identifier corresponding to the target compression algorithm, the identifier corresponding to the target serialization rule, the total length information, and the security verification data; verify whether the total length of the first binary protocol data is consistent with the total length information recorded in the protocol header, and verify data integrity through the security verification data; extract the message body area from the first binary protocol data; decompress the user data field in the message body area according to the decompression algorithm corresponding to the target compression algorithm identifier to obtain binary format user data; deserialize the metadata field and security verification data field in the message body area and the binary format user data sequentially according to the deserialization rule corresponding to the target serialization rule identifier to obtain the corresponding metadata, security verification data, and user data; combine the metadata, security verification data, and user data into the second request data.

[0162] Since the second request data is already obtained after parameter language type conversion, the second server can directly identify the second request data. Thus, after deserialization, it can directly call the request method corresponding to the target service based on the second request data to obtain the first response data corresponding to the second programming language.

[0163] Finally, a custom binary protocol is used to serialize the first response data to obtain second binary protocol data, which is then forwarded to the first server. The first server then deserializes the second binary protocol data to obtain the first response data, converts the first response data into second response data corresponding to the first programming language, and forwards the second response data to the client.

[0164] In summary, in this embodiment, the first server performs parameter language conversion on the first request data, accurately converting data from different language environments into a data format that the second server can directly recognize. This solves the cross-language compatibility problem and eliminates data comprehension barriers caused by language characteristics. Then, the second request data, after parameter conversion, is serialized according to a custom binary protocol. This generates binary protocol data, which is then transmitted to the second server via a TCP connection. This ensures that the second server can accurately parse the binary protocol data according to the custom binary protocol to obtain the restored second request data, guaranteeing the accuracy and consistency of data during network transmission. Thus, the second server can directly call the corresponding target service based on the second request data, achieving high-performance, low-latency, and highly reliable cross-language service calls, ensuring that the client can successfully obtain the required target service. Furthermore, using a custom binary protocol as the application layer protocol and serializing the second request data according to the format specified by this protocol results in smaller binary protocol data that can more compactly store information, reducing data transmission volume and ensuring correct and efficient data transmission over the network.

[0165] In practical applications, the processing capacity of a single server is limited and may not be able to handle high concurrency requests. Furthermore, the failure of a single server will render the entire service unavailable. Therefore, to address the limitations of a single server in terms of performance, reliability, scalability, and availability, in this embodiment of the application, each server in the distributed service system can be configured with multiple service nodes, with services provided by multiple service nodes. When a target service is invoked, the target service node can be selected from the multiple service nodes providing the target service, and then the target service node will provide the target service to the client.

[0166] Specifically, firstly, based on the request method in the second request data, the target service to be invoked by the first server is determined. Based on the service name corresponding to the target service, the target service node to be invoked is selected from multiple service nodes that provide the target service. The first request parameters and request method in the second request data are encapsulated into a request object, and the request object is sent to the target service node, so that the target service node invokes the request method based on the first request parameters in the request object to obtain the first response data.

[0167] In a distributed service architecture, multiple service nodes deployed for the same service may have hardware differences. Service nodes may experience momentary performance degradation due to peak processing times or resource contention among neighboring service nodes. In such cases, a static load balancing strategy can be used to schedule these service nodes.

[0168] Traditional service scheduling schemes typically employ static load balancing strategies (such as round-robin or random). However, static scheduling cannot detect the real-time load of each service node, and newly started service nodes may experience sudden increases in response latency due to cache warming, making them susceptible to being misjudged as high-load nodes by static scheduling strategies, thus affecting service calls. To address these issues, this application proposes a dynamic service scheduling method based on the real-time weights corresponding to each service node.

[0169] Figure 6 This is a flowchart illustrating how to select a target service node to be invoked, as provided in an embodiment of this application. Figure 6 As shown, the method may include the following steps:

[0170] 601. Obtain the service table from the service registry and find multiple service nodes corresponding to the service name of the target service from the service table.

[0171] 602. Check the health status and service status of multiple service nodes to select multiple candidate service nodes from the multiple service nodes.

[0172] 603. Determine the real-time service weights of multiple candidate service nodes at the current moment.

[0173] 604. Select the target service node with the highest real-time service weight from multiple candidate service nodes.

[0174] In practice, each service node can pre-register its services with the service registry. Registration information includes, but is not limited to, node IP address, port number, service version number, runtime language, and real-time health status. The service registry stores metadata for all registered services in a service table. Thus, when a service node providing a target service needs to be invoked, the service table can be retrieved from the service registry, and the service node corresponding to the target service's name can be found within the table.

[0175] Once multiple service nodes providing the target service are identified, their health and service status are checked to filter out candidate service nodes. Health status determines whether a service node has the capability to process requests normally. Specifically, health status includes: network connectivity, storage availability, CPU utilization, memory usage, thread blocking rate, and process liveness. Service status determines whether a service node should participate in traffic allocation.

[0176] Next, the real-time service weights of multiple candidate service nodes are determined at the current moment. These weights are updated periodically according to a preset cycle. The real-time service weight characterizes the processing capacity of a service node; the stronger the processing capacity, the higher the real-time service weight. In other words, a higher real-time service weight indicates a stronger ability to process requests, and the node will be assigned more tasks.

[0177] The real-time service weight of a candidate service node can be calculated by combining its original service weight and current load capacity. The original service weight characterizes the basic processing capability of the service node. The original service weight can be determined by considering the service node's hardware performance, network bandwidth, and hardware configuration level. Hardware performance can include the number of CPU cores, memory size, and disk speed.

[0178] Since the process for determining the real-time service weight for each candidate service node is roughly the same, this explanation will focus on the target candidate service node as an example. The target candidate service node is any one of multiple candidate service nodes.

[0179] In one optional embodiment, the specific implementation process for determining the current service weights corresponding to multiple candidate service nodes may include: obtaining the original service weights corresponding to the target candidate service nodes, as well as the number of requests currently being processed and the current running status of the target candidate service nodes; adjusting the original service weights based on the number of requests currently being processed and the current running status to determine the effective service weights corresponding to the target candidate service nodes at the current moment; and determining the real-time service weights corresponding to the target candidate service nodes at the current moment based on the effective service weights corresponding to the current moment and the real-time service weights corresponding to the previous moment.

[0180] The current running status indicates whether a service node can operate normally. The effective service weight indicates the actual processing capacity of the service node in the current running status. The effective service weight can be adjusted based on the service node's status. For example, if the CPU utilization of a service node is too high, its effective service weight is reduced. If a service node has insufficient memory, its effective service weight is significantly reduced. If the response time of a service node is too long, its effective service weight is reduced. The adjustment can be preset with corresponding magnitude values, and the effective service weight of each service node is dynamically adjusted based on these values.

[0181] Each load balancing selection affects the effective service weight, which in turn affects the real-time service weight. The real-time service weight of the selected service node will decrease, while the real-time service weight of the unselected node will increase.

[0182] Specifically, based on the ratio of the effective service weight of the target candidate service node at the current moment to its original service weight, an adjustment range is determined for weight adjustment of the target candidate service node. In response to determining that the target candidate service node is selected as the target service node at the current moment, the real-time service weight of the target candidate service node at the current moment is reduced based on the adjustment range, resulting in an updated real-time service weight. Alternatively, in response to determining that the target candidate service node is not selected as the target service node at the current moment, the real-time service weight of the target candidate service node at the current moment is increased based on the adjustment range, resulting in an updated real-time service weight.

[0183] Finally, the target service node with the highest real-time service weight is selected from multiple candidate service nodes to provide the target service to the client.

[0184] For example, suppose the second server is configured with 3 service nodes to provide the target service, and the effective service weight of service node A at the current time is 5, the effective weight of service node B at the current time is 3, and the effective weight of service node C at the current time is 2.

[0185] First round of selection: Calculate the real-time service weight of each service node at the current moment.

[0186] The current real-time service weight of service node A is: 0 + 5 = 5

[0187] The current real-time service weight of service node B is: 0 + 3 = 3

[0188] The current real-time service weight of service node C is: 0 + 2 = 2

[0189] In the first round, service node A can be selected as the target service node. After service node A is selected, its current real-time service weight is adjusted: 5-10=-5.

[0190] Second round of selection: Calculate the real-time service weight of each service node at the current moment.

[0191] The current real-time service weight of service node A is: -5 + 5 = 0

[0192] The current real-time service weight of service node B is: 3 + 3 = 6

[0193] The current real-time service weight of service node C is: 2 + 2 = 4

[0194] In the second round, service node B can be selected. Once service node B is selected, the current real-time service weight of service node A is adjusted: 6-10=-4.

[0195] The third round of selection: Calculate the real-time service weight of each service node at the current moment.

[0196] The current real-time service weight of service node A is: 0 + 5 = 5

[0197] The current real-time service weight of service node B is: -4 + 3 = -1

[0198] The current real-time service weight of service node C is: 4 + 2 = 6

[0199] In the third round, service node C can be selected. Once service node C is selected, its current real-time service weight is adjusted: 6-10=-4.

[0200] When adjusting the real-time service weights of each service node, weights can be increased or decreased proportionally. The number of times a service node is selected is allocated according to the proportion of its effective service weights. This prevents the same service node from being selected continuously to provide the target service. Furthermore, when the current state of a service node changes, its effective service weights are adjusted, which in turn affects the real-time service weights and thus the selection of service nodes. This design ensures that service nodes can recover quickly from failures while also responding quickly to changes in performance.

[0201] When a service node performs well, its real-time service weight is gradually increased. This can be done gradually. For example, after service node A recovers from a failure and has been running stably for a preset period, its real-time service weight can be gradually increased. Alternatively, when a new server D joins the service node cluster corresponding to the second server, the new service node D starts with a low weight, and its real-time service weight is gradually increased during the warm-up period.

[0202] When a service node performs poorly, its weight is reduced. Furthermore, automatic removal of faulty nodes is supported, employing circuit breaker protection or service degradation measures. For example, if a heartbeat detection times out, the real-time service weight of the faulty node is reset to zero. Rapid degradation can be used; if service node B's response times out three times consecutively, its real-time service weight can be rapidly reduced. Alternatively, if service node B's error rate surges, its real-time service weight can also be rapidly reduced.

[0203] In summary, the embodiments of this application check the health status and service status of multiple service nodes to filter out multiple candidate service nodes, and then select the target service node with the highest real-time service weight from the multiple candidate service nodes. In this way, the service nodes can be dynamically called to provide the target service based on the real-time service weight of each service node in high-concurrency scenarios, thereby achieving load-balanced scheduling of multiple service nodes.

[0204] To facilitate understanding of the cross-language service invocation implementation process provided in this application, the following is in conjunction with the appendix. Figure 7 As shown, the implementation process is illustrated in a specific application scenario. In practical implementation, in a distributed service system architecture, the Node.js front-end service calls the Java back-end service to work together to provide the target service to the client.

[0205] To enable cross-language service calls between Node.js frontend services and Java backend services, the SCF-NODE framework can be added to the Node.js frontend, such as... Figure 7 As shown, the SCF-NODE framework includes a network module, a serialization module, and a type mapping module. This allows the Node.js frontend to directly convert TypeScript request data into Java request data, and then uses a custom binary protocol to serialize the converted request data, obtaining binary protocol data. This binary protocol data is then forwarded to the Java backend via a TCP connection. The Java backend includes a Java SCF service module, a serialization module, and a network module. The Java SCF service module can perform unified scheduling management, load balancing, and health monitoring of multiple service nodes corresponding to the Java backend.

[0206] When a client sends a service request to the Node.js frontend for a target service, the Node.js frontend determines the target service to be invoked on the corresponding Java backend based on the service request. When invoking the target service on the Java backend, the Node.js frontend parses the service request sent by the client to extract the first request method corresponding to the target service and the first request parameters required to invoke that method. After type checking and validation of the TypeScript programming language request parameters before conversion, the frontend checks for circular references in the first request parameters. If a circular reference exists, it first handles the circular reference and then, based on a preset type mapping relationship, converts the TypeScript programming language first request parameter into a Java programming language second request parameter.

[0207] Before converting the first request parameter into the second request parameter, the service interface definition file corresponding to the custom-generated TypeScript programming language can be used to perform type checking on each data element in the first request parameter to ensure that the first request parameter can be accurately converted into the second request parameter based on the preset type mapping relationship of each data type.

[0208] Specifically, before making a service call, the Node.js frontend can use a pre-defined type mapping relationship to convert the target service interface of the Java backend into an interface element that matches the TypeScript programming language type based on the metadata corresponding to the target service interface of the Java backend. According to the syntax specification of the TypeScript programming language, the converted interface element is structurally integrated to generate the service interface definition file corresponding to the TypeScript programming language.

[0209] After the first request parameter passes validation, it is checked whether a circular reference exists. If a circular reference exists, the circular reference is first processed by assigning a unique identifier to the first request parameter and adding a circular reference marker. The position of the circular reference node in the data structure is replaced with a special marker containing the unique identifier. Then, based on the type mapping relationship corresponding to the data type of the first request parameter, the first request parameter of type TypeScript is converted into a second request parameter of type Java.

[0210] The second request parameter is validated for data integrity, data type correctness, and processing rules. If all three validations pass, the second request parameter is considered successfully validated.

[0211] Then, after the second request parameter is successfully verified, a custom binary protocol is used to serialize the second request parameter and the request method to obtain the first binary protocol data. The custom binary protocol is used to define the data transfer standard between the Node.js frontend and the Java backend.

[0212] Specifically, the process involves: obtaining a custom binary protocol; querying a preset service number mapping table based on the target service interface corresponding to the request method to determine the service number corresponding to the service request; determining the message type corresponding to the service request based on the second request parameters; selecting the corresponding target compression algorithm and target serialization rule from a preset algorithm list based on the data size and data type of the second request parameters; extracting metadata from the second request parameters to obtain metadata including parameter type, parameter length, and field description; encrypting the second request parameters and request method using a preset hash algorithm to generate security verification data; converting the second request parameters and the request method into binary format user data according to the target serialization rule; compressing the binary format user data according to the target compression algorithm to obtain compressed user data; and sequentially writing the determined service number, message type, target compression algorithm, and target serialization rule corresponding to the service request into the protocol header area of ​​the custom binary protocol, and writing the extracted metadata, generated security verification data, and compressed user data into the message body area of ​​the custom binary protocol to generate first binary protocol data, following the order of protocol header first and message body last.

[0213] Next, the Node.js frontend forwards the first binary protocol data to the Java backend via a TCP connection. Upon receiving the call request from the Node.js frontend, the Java backend uses a custom binary protocol to deserialize the first binary protocol data, obtaining the second request parameters and the request method. The Java backend can determine the target service node to be called based on the real-time service weight of each service node at the current moment.

[0214] Specifically, the health and service status of multiple service nodes are checked to filter out multiple candidate service nodes; the real-time service weight of the multiple candidate service nodes at the current moment is determined; and the target service node with the highest real-time service weight is selected from the multiple candidate service nodes. The second request data is sent to the target service node, so that the target service node calls the request method based on the second request parameters, generates the first response data corresponding to the Java programming language, and forwards the second binary protocol data serialized from the first response data to the Node.js frontend.

[0215] The determination of the real-time service weights for multiple candidate service nodes at the current moment involves: adjusting the original service weights based on the number of requests currently being processed and the current running status to determine the effective service weight of the target candidate service node at the current moment; and determining the real-time service weight of the target candidate service node at the current moment based on the effective service weight at the current moment and the real-time service weight at the previous moment. The original service weights characterize the basic processing capabilities of the service nodes. Furthermore, after each service call is completed, the real-time service weights of each service node are adjusted according to the ratio of the effective service weight at the current moment to the original service weight to update the real-time service weights of each service node.

[0216] By using a custom binary protocol and parameter language conversion, cross-language service calls can be made, which solves the cross-language call compatibility problem and enables accurate and efficient cross-language service calls.

[0217] The following describes in detail one or more embodiments of the cross-language service invocation apparatus of this application. Those skilled in the art will understand that these apparatuses can all be configured using commercially available hardware components through the steps taught in this solution.

[0218] Figure 8 A schematic diagram of a cross-language service invocation device provided in an embodiment of this application is shown below. Figure 8 As shown, this location is at the first server end of the distributed service system. The device includes: a parsing module 11, a first conversion module 12, a forwarding module 13, a processing module 14, and a second conversion module 15.

[0219] The parsing module 11 is used to receive a service request triggered by the client for the target service, parse the service request, and extract the first request data corresponding to the target service from the service request; the first request data is data in the first programming language used by the first server.

[0220] The first conversion module 12 is used to convert the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first data type of the first request data, and to serialize the second request data using a custom binary protocol to obtain first binary protocol data; the custom binary protocol is used to define the data transmission standard between the first server and the second server.

[0221] The forwarding module 13 is used to forward the first binary protocol data to the second server via a TCP connection, so that the second server uses the custom binary protocol to deserialize the first binary protocol data to obtain the second request data, calls the target service based on the second request data, generates the first response data corresponding to the second programming language, and forwards the second binary protocol data after serialization of the first response data to the first server.

[0222] Processing module 14 is used to deserialize the second binary protocol data to obtain the first response data.

[0223] The second conversion module 15 is used to convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0224] Optionally, the first conversion module 12 is specifically used to: obtain a target buffer pre-allocated for the service request from the buffer pool; write the second request data into the target buffer; and serialize the second request data in the target buffer using a custom binary protocol to obtain first binary protocol data.

[0225] Optionally, the first conversion module 12 is specifically configured to: encode the second request data into binary format user data according to the target serialization rules agreed in the custom binary protocol; select a corresponding target compression algorithm from a preset algorithm list based on the data size corresponding to the user data; compress the binary format user data according to the target compression algorithm to obtain compressed request data; and encapsulate the compressed user data, the target serialization rule identifier, and the target compression algorithm identifier according to the data format corresponding to the binary protocol data specified in the custom binary protocol to generate first binary protocol data.

[0226] Optionally, the data format corresponding to the binary protocol data includes a protocol header and a message body. The protocol header includes a service number field, a message type field, a compression algorithm field, and a serialization rule field. The message body includes a metadata field, a security verification data field, and a user data field. The user data field includes a request parameter field and a response return value field. The second request data includes the request method corresponding to the target service and the first request parameters required when calling the request method. Specifically, the first conversion module 12 is used to: query a preset service number mapping table according to the target service interface corresponding to the request method to determine the service number corresponding to the service request; determine the message type corresponding to the service request according to the first request parameters; and perform metadata processing on the first request parameters. Extract metadata including parameter type, parameter length, and field description; perform encrypted calculations on the first request parameters and request method using a preset hash algorithm to generate security verification data; according to the target serialization rule, sequentially convert the metadata and security verification data into binary format metadata and binary format security verification data; following the order of protocol header first and message body last, sequentially write the determined service number corresponding to the service request, message type, target compression algorithm identifier, and serialization rule identifier into the protocol header area of ​​the custom binary protocol, and write the binary format metadata, the binary format security verification data, and the compressed user data into the message body area of ​​the custom binary protocol to generate first binary protocol data.

[0227] Optionally, before converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data, the first conversion module 12 is further configured to: obtain the service code corresponding to the target service interface, wherein the target service interface is an interface used to provide the target service, and the service code is code in the second programming language; extract the metadata corresponding to the target service interface from the service code; convert the target service interface of the first programming language type into an interface element matching the second programming language type based on the metadata using a preset type mapping relationship; and perform structured integration of the converted interface element based on the syntax specification of the first programming language to generate a service interface definition file of the first programming language.

[0228] Optionally, the first conversion module 12 is further configured to: parse the metadata corresponding to the target service interface to obtain the first type of information, the first field information, and the first method information corresponding to the target service interface; perform type conversion processing on the first type of information, the first field information, and the first method information corresponding to the target service interface based on a preset type mapping relationship to obtain the second type of information, the second field information, and the second method information corresponding to the target service interface; the second type of information, the second field information, and the second method information corresponding to each service interface are information of the first coding language; determine the second type of information as the interface name, convert the second field information into the attribute name and corresponding attribute type of the interface, and convert the second method information into the method name, parameter list, and return value type of the interface. According to the interface declaration format of the second programming language, using the interface name as the interface identifier, the attribute name and attribute type are sequentially determined as member attributes of the interface, and the method name, parameter list, and return value type are determined as member methods of the interface, to generate a service interface definition file conforming to the first programming language specification.

[0229] Optionally, the first request data includes the request method corresponding to the target service and the second request parameters required when calling the request method; the first conversion module 12 is specifically used to: verify whether the second request parameters meet the type requirements set for the second request parameters in the service interface definition file; in response to determining that the second request parameters have been successfully verified, identify the first data type corresponding to the second request parameters; search for the second data type corresponding to the first data type in the type conversion mapping table; and based on the second data type, convert the second request parameters into the first request parameters of the second programming language used by the second server.

[0230] Optionally, the first conversion module 12 is specifically used to: in response to determining that the data type corresponding to the second request parameter is a basic data type, verify whether the second request parameter conforms to the type mapping requirements defined in the service interface definition file; or, in response to determining that the data type corresponding to the second request parameter is a composite data type, verify whether the field composition, nesting level, and required field settings of the second request parameter are consistent with the interface structure definition in the service interface definition file; the composite data type refers to a structured data type composed of multiple data fields.

[0231] Optionally, the second request parameter includes multiple data elements; the first conversion module 12 is specifically used for: for the first data element, in response to determining that a data identifier corresponding to the first data element is found in the allocation table, performing circular reference processing on the first data element, assigning a unique identifier to the first data element and adding a circular reference marker, and replacing the position of the circular reference node in the data structure with a special marker containing the unique identifier; the first data element is any one of the multiple data elements; recording the reference path corresponding to the first data element; and converting the first data element into a second data element of the second programming language based on the second data type; wherein, the allocation table is used to record data elements that have undergone type conversion processing.

[0232] Optionally, after converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data, the first conversion module 12 is further configured to: perform data integrity verification on the second request data to detect whether any fields in the second request data are missing, whether required fields are complete, and whether the object structure corresponding to the first request parameter in the second request data is consistent with the interface definition of the second programming language; perform data type correctness verification on the first request parameter to detect whether the field type corresponding to each field in the first request parameter matches the type specification of the second programming language, whether the data format conforms to the preset standard, and whether the value is within a reasonable range; perform processing rule verification on the first request parameter to detect whether the first request parameter conforms to the preset processing logic, whether it satisfies the constraints between fields, and whether the relationship between associated objects is legal; when the data integrity verification, the type correctness verification, and the processing rule verification all pass, it is determined that the first request parameter verification is successful; in response to determining that the first request parameter verification is successful, a custom binary protocol is used to serialize the first request parameter and the request method in the second request data to obtain first binary protocol data.

[0233] Optionally, before forwarding the first binary protocol data to the second server via a TCP connection, the forwarding module 13 is further configured to: search for a TCP connection corresponding to the target service in a connection mapping table to detect whether a TCP connection has been established between the first server and the service node providing the target service in the second server; in response to determining that a TCP connection has been established, reuse the TCP connection established between the first server and the service node; and forward the first binary protocol data to the service node via the TCP connection.

[0234] Figure 8The device shown can execute the steps performed by the first server in the foregoing embodiments. For detailed execution process and technical effects, please refer to the relevant description of the first server in the foregoing embodiments, which will not be repeated here.

[0235] In one possible design, the above Figure 8 The structure of the cross-language service invocation device shown can be implemented as an electronic device. For example... Figure 9 As shown, the electronic device may include: a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code, which, when executed by the processor 21, enables the processor 21 to at least implement the cross-language service invocation method executed by the first server provided in the foregoing embodiments.

[0236] In addition, embodiments of the present invention provide a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor is able to at least implement the cross-language service invocation method executed by the first server provided in the foregoing embodiments.

[0237] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0238] Figure 10 This is a schematic diagram of the structure of a cross-language service invocation device provided in an embodiment of the present invention, as shown below. Figure 10 As shown, the device is applied to the second server and includes: a receiving module 31, a processing module 32, a calling module 33, and a forwarding module 34.

[0239] The receiving module 31 is configured to receive first binary protocol data sent by the first server via a TCP connection; wherein, the first binary protocol data is obtained by the first server parsing the service request triggered by the client for the target service, extracting the first request data corresponding to the target service from the service request, converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data, and serializing the second request data using a custom binary protocol; the first request data is data in the first programming language used by the first server; the custom binary protocol is used to define the data transmission standard between the first server and the second server.

[0240] Processing module 32 is used to deserialize the first binary protocol data using the custom binary protocol to obtain the second request data.

[0241] The calling module 33 is used to call the request method corresponding to the target service based on the second request data to obtain the first response data corresponding to the second programming language.

[0242] The forwarding module 34 is used to serialize the first response data using the custom binary protocol to obtain second binary protocol data, and forward the second binary protocol data to the first server so that the first server can deserialize the second binary protocol data to obtain the first response data, convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

[0243] Optionally, the invocation module 33 is specifically configured to: determine the target service to be invoked by the first server based on the request method in the second request data; select the target service node to be invoked from multiple service nodes that provide the target service based on the service name corresponding to the target service; encapsulate the first request parameter and the request method in the second request data into a request object, and send the request object to the target service node, so that the target service node invokes the request method based on the first request parameter in the request object to obtain the first response data.

[0244] Optionally, the calling module 33 is specifically used to: obtain a service table from the service registry and search for multiple service nodes corresponding to the service name in the service table; check the health status and service status of the multiple service nodes to filter out multiple candidate service nodes from the multiple service nodes; determine the real-time service weight corresponding to the multiple candidate service nodes at the current moment; and select the target service node with the highest real-time service weight from the multiple candidate service nodes.

[0245] Optionally, the calling module 33 is specifically configured to: for a target candidate service node, obtain the original service weight corresponding to the target candidate service node, as well as the number of requests currently being processed and the current running status corresponding to the target candidate service node; the target candidate service node is any one of the plurality of candidate service nodes; the original service weight is used to characterize the basic processing capability of the service node; based on the number of requests currently being processed and the current running status, adjust the original service weight to determine the effective service weight corresponding to the target candidate service node at the current moment; based on the effective service weight corresponding to the current moment and the real-time service weight corresponding to the previous moment, determine the real-time service weight corresponding to the target candidate service node at the current moment.

[0246] Optionally, the calling module 33 is further configured to: determine an adjustment range for weight adjustment of the target candidate service node based on the ratio of the effective service weight corresponding to the target candidate service node at the current time to the original service weight corresponding to the target candidate service node; in response to determining that the target candidate service node is selected as the target service node at the current time, reduce the real-time service weight corresponding to the target candidate service node at the current time based on the adjustment range to obtain an updated real-time service weight; or, in response to determining that the target candidate service node is not selected as the target service node at the current time, increase the real-time service weight corresponding to the target candidate service node at the current time based on the adjustment range to obtain an updated real-time service weight.

[0247] Optionally, the processing module 32 is specifically configured to: parse the protocol header area of ​​the first binary protocol data according to the custom binary protocol, extract the identifier corresponding to the target compression algorithm, the identifier corresponding to the target serialization rule, the total length information, and the security verification data; verify whether the total length of the first binary protocol data is consistent with the total length information recorded in the protocol header, and verify the data integrity through the security verification data; extract the message body area from the first binary protocol data; decompress the user data field in the message body area according to the decompression algorithm corresponding to the target compression algorithm identifier to obtain binary format user data; deserialize the metadata field and the security verification data field in the message body area and the binary format user data sequentially according to the deserialization rule corresponding to the target serialization rule identifier to obtain the corresponding metadata, security verification data, and user data; and combine the metadata, security verification data, and user data into the second request data.

[0248] Figure 10 The device shown can execute the steps performed by the second server in the foregoing embodiments. For detailed execution process and technical effects, please refer to the relevant description of the second server in the foregoing embodiments, which will not be repeated here.

[0249] In one possible design, the above Figure 10 The structure of the cross-language service invocation device shown can be implemented as an electronic device. For example... Figure 11 As shown, the electronic device may include: a processor 21, a memory 22, and a communication interface 23. The memory 22 stores executable code, which, when executed by the processor 21, enables the processor 21 to at least implement the cross-language service invocation method executed by the second server as provided in the foregoing embodiments.

[0250] In addition, this application provides a non-transitory machine-readable storage medium storing executable code. When the executable code is executed by a processor of an electronic device, the processor can at least implement the cross-language service invocation method executed by the first server provided in the foregoing embodiments.

[0251] Accordingly, this application also provides a computer program product, which includes a computer program or instructions that, when executed by a processor, cause the processor to implement the steps in the above method embodiments. It should be understood that each step or combination of steps in the above method flow can be implemented by the computer program or instructions. Furthermore, these computer programs or instructions can be applied to the processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device, enabling the processor of the general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to function as an apparatus for implementing the corresponding functions in the above method embodiments.

[0252] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0253] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. This application can take the form of a computer program product implemented 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.

[0254] Finally, it should be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0255] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cross-language service invocation method, characterized in that, A first server is applied in a distributed service system, the distributed service system including the first server and the second server, wherein the first server and the second server use different programming languages, the method comprising: The server receives a service request triggered by a client for a target service, parses the service request, and extracts first request data corresponding to the target service from the service request; the first request data is data in a first programming language used by the first server. Based on the type mapping relationship corresponding to the first request data, the first request data is converted into second request data in the second programming language used by the second server, and a custom binary protocol is used to serialize the second request data to obtain first binary protocol data; the custom binary protocol is used to define the data transmission standard between the first server and the second server; The first binary protocol data is forwarded to the second server via a TCP connection, so that the second server uses the custom binary protocol to deserialize the first binary protocol data to obtain the second request data. Based on the second request data, the target service is called to generate the first response data corresponding to the second programming language, and the second binary protocol data after serialization of the first response data is forwarded to the first server. The second binary protocol data is deserialized to obtain the first response data; The first response data is converted into second response data corresponding to the first programming language, and the second response data is forwarded to the client.

2. The method according to claim 1, characterized in that, The step of using a custom binary protocol to serialize the second request data to obtain first binary protocol data includes: Retrieve the target buffer pre-allocated for the service request from the buffer pool; Write the second request data into the target buffer; In the target buffer, the second request data is serialized using a custom binary protocol to obtain the first binary protocol data.

3. The method according to any one of claims 1-2, characterized in that, The step of serializing the second request data using a custom binary protocol to obtain first binary protocol data includes: The second request data is encoded into user data in binary format according to the target serialization rules agreed in the custom binary protocol; Based on the data size corresponding to the user data, select the corresponding target compression algorithm from the preset algorithm list; The binary format user data is compressed according to the target compression algorithm to obtain compressed request data. According to the data format corresponding to the binary protocol data specified in the custom binary protocol, the compressed user data, the target serialization rule identifier, and the target compression algorithm identifier are encapsulated to generate the first binary protocol data.

4. The method according to claim 3, characterized in that, The data format corresponding to the binary protocol data includes a protocol header and a message body. The protocol header includes a service number field, a message type field, a compression algorithm field, and a serialization rule field. The message body includes a metadata field, a security verification data field, and a user data field. The user data field includes a request parameter field and a response return value field. The second request data includes the request method corresponding to the target service and the first request parameters required when calling the request method. The step of encapsulating the compressed user data, the serialization rule identifier, and the target compression algorithm identifier according to the data format corresponding to the binary protocol data specified in the custom binary protocol to generate the first binary protocol data includes: The service number corresponding to the service request is determined by querying a preset service number mapping table based on the target service interface corresponding to the request method. Based on the first request parameters, determine the message type corresponding to the service request; Metadata is extracted from the first request parameters to obtain metadata including parameter type, parameter length, and field description; The first request parameters and request method are encrypted and calculated using a preset hash algorithm to generate security verification data. According to the target serialization rules, the metadata and the security verification data are sequentially converted into binary format metadata and binary format security verification data; Following the order of protocol header first and message body last, the service number corresponding to the determined service request, message type, target compression algorithm identifier, and serialization rule identifier are sequentially written into the protocol header area of ​​the custom binary protocol. The metadata in binary format, the security verification data in binary format, and the compressed user data are written into the message body area of ​​the custom binary protocol to generate the first binary protocol data.

5. The method according to claim 1, characterized in that, Before converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data, the method further includes: Obtain the service code corresponding to the target service interface, wherein the target service interface is an interface used to provide the target service, and the service code is the code of the second programming language; Extract the metadata corresponding to the target service interface from the service code; Using a preset type mapping relationship, based on the metadata, the target service interface of the first programming language type is converted into an interface element that matches the second programming language type; Based on the syntax of the first programming language, the converted interface elements are structurally integrated to generate a service interface definition file in the first programming language.

6. The method according to claim 5, characterized in that, The step of using preset type mapping rules and based on the metadata to convert the target service interface of the first programming language type into an interface element that matches the second programming language type includes: Parse the metadata corresponding to the target service interface to obtain the first type of information, the first field information, and the first method information corresponding to the target service interface; Based on a preset type mapping relationship, the first type information, first field information, and first method information corresponding to the target service interface are subjected to type conversion processing to obtain the second type information, second field information, and second method information corresponding to the target service interface; the second type information, second field information, and second method information corresponding to the target service interface are information in the first encoding language; The second type of information is determined as the interface name, the second field information is converted into the attribute name and corresponding attribute type of the interface, and the second method information is converted into the method name, parameter list and return value type of the interface; The step of structurally integrating the converted interface elements based on the syntax specifications of the second programming language to generate the first programming language service interface definition file includes: According to the interface declaration format of the second programming language, the interface name is used as the interface identifier, and the attribute name and attribute type are determined as the member attributes of the interface in sequence. The method name, parameter list and return value type are determined as the member methods of the interface to generate a service interface definition file that conforms to the specification of the first programming language.

7. The method according to claim 6, characterized in that, The first request data includes the request method corresponding to the target service and the second request parameters required when calling the request method; Wherein, the step of converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data includes: Verify whether the second request parameter conforms to the type requirements set for the second request parameter in the service interface definition file; In response to the determination that the second request parameter has been successfully verified, the first data type corresponding to the second request parameter is identified; From the type conversion mapping table, find the second data type that corresponds to the first data type; Based on the second data type, the second request parameter is converted into a first request parameter using the second programming language used by the second server.

8. The method according to claim 7, characterized in that, The step of verifying whether the second request parameter conforms to the type requirements set for the second request parameter in the service interface definition file includes: In response to determining that the data type corresponding to the second request parameter is the basic data type, verify whether the second request parameter conforms to the type mapping requirements defined in the service interface definition file; or... In response to determining that the data type corresponding to the second request parameter is a composite data type, the system verifies whether the field composition, nesting level, and required field settings of the second request parameter are consistent with the interface structure definition in the service interface definition file; the composite data type refers to a structured data type composed of multiple data fields.

9. The method according to claim 7, characterized in that, The second request parameter includes multiple data elements; The step of converting the second request parameters into first request parameters using the second programming language used by the second server, based on the second data type, includes: For the first data element, in response to determining that a data identifier corresponding to the first data element is found in the allocation table, the first data element is subjected to circular reference processing. A unique identifier is assigned to the first data element and a circular reference flag is added. The position of the circular reference node in the data structure is replaced with a special flag containing the unique identifier. The first data element is any one of the plurality of data elements. Record the reference path corresponding to the first data element; Based on the second data type, the first data element is converted into a second data element in the second programming language; The allocation table is used to record data elements that have undergone type conversion processing.

10. The method according to claim 1, characterized in that, After converting the first request data into second request data in the second programming language used by the second server based on the type mapping relationship corresponding to the first request data, the method further includes: The second request data is subjected to data integrity verification to detect whether any fields in the second request data are missing, whether the required fields are complete, and whether the object structure corresponding to the first request parameter in the second request data is consistent with the interface definition of the second programming language. The data type correctness of the first request parameter is verified to check whether the field type of each field in the first request parameter matches the type specification of the second programming language, whether the data format conforms to the preset standard, and whether the value is within a reasonable range. The first request parameter is processed according to the rules to check whether the first request parameter conforms to the preset processing logic, whether it meets the constraints between fields, and whether the relationship between the associated objects is legal. When the data integrity verification, the type correctness verification, and the processing rule verification all pass, it is determined that the first request parameter verification is successful. The step of using a custom binary protocol to serialize the second request data to obtain first binary protocol data includes: In response to the successful verification of the first request parameter, a custom binary protocol is used to serialize the request method in the first request parameter and the second request data to obtain the first binary protocol data.

11. The method according to claim 1, characterized in that, Before forwarding the first binary protocol data to the second server via a TCP connection, the method further includes: The TCP connection corresponding to the target service is searched in the connection mapping table to detect whether a TCP connection has been established between the first server and the service node providing the target service in the second server. In response to determining that a TCP connection has been established, the TCP connection already established between the first server and the service node is reused; The step of forwarding the first binary protocol data to the second server via a TCP connection includes: The first binary protocol data is forwarded to the service node via the TCP connection.

12. A method for cross-language service invocation, characterized in that, A second server is applied in a distributed service system, the distributed service system including a first server and a second server, wherein the first server and the second server use different programming languages, the method comprising: The system receives first binary protocol data sent by the first server via a TCP connection. This first binary protocol data is obtained by the first server parsing a service request triggered by a client for a target service, extracting first request data corresponding to the target service from the service request, converting the first request data into second request data in a second programming language used by the second server based on a type mapping relationship, and then serializing the second request data using a custom binary protocol. The first request data is data in a first programming language used by the first server. The custom binary protocol is used to define the data transmission specifications between the first server and the second server. Using the custom binary protocol, the first binary protocol data is deserialized to obtain the second request data; Based on the second request data, the request method corresponding to the target service is invoked to obtain the first response data corresponding to the second programming language; Using the custom binary protocol, the first response data is serialized to obtain second binary protocol data, and the second binary protocol data is forwarded to the first server so that the first server can deserialize the second binary protocol data to obtain the first response data, convert the first response data into second response data corresponding to the first programming language, and forward the second response data to the client.

13. The method according to claim 12, characterized in that, The step of invoking the request method corresponding to the target service based on the second request data to obtain the first response data corresponding to the second programming language includes: Based on the request method in the second request data, the target service to be invoked by the first server is determined. Based on the service name corresponding to the target service, the target service node to be invoked is selected from multiple service nodes that provide the target service; The first request parameter and the request method in the second request data are encapsulated into a request object, and the request object is sent to the target service node so that the target service node calls the request method based on the first request parameter in the request object to obtain the first response data.

14. The method according to claim 13, characterized in that, The step of selecting the target service node to be invoked from multiple service nodes providing the target service based on the service name corresponding to the target service includes: Retrieve the service table from the service registry, and search for multiple service nodes corresponding to the service name from the service table; Check the health status and service status of the multiple service nodes to filter out multiple candidate service nodes from the multiple service nodes; Determine the real-time service weights corresponding to the multiple candidate service nodes at the current moment; The target service node with the highest real-time service weight is selected from the plurality of candidate service nodes.

15. The method according to claim 14, characterized in that, Determining the current service weights corresponding to the plurality of candidate service nodes includes: For a target candidate service node, obtain the original service weight corresponding to the target candidate service node, as well as the number of requests currently being processed and the current running status of the target candidate service node; the target candidate service node is any one of the plurality of candidate service nodes; the original service weight is used to characterize the basic processing capability of the service node; Based on the number of requests currently being processed and the current running status, the original service weight is adjusted to determine the effective service weight corresponding to the target candidate service node at the current moment; Based on the effective service weight corresponding to the current time and the real-time service weight corresponding to the previous time, the real-time service weight corresponding to the target candidate service node at the current time is determined.

16. The method according to claim 15, characterized in that, The method further includes: The adjustment range for adjusting the weight of the target candidate service node is determined based on the ratio of the effective service weight of the target candidate service node at the current time to the original service weight of the target candidate service node. In response to determining that the target candidate service node is selected as the target service node at the current moment, the real-time service weight corresponding to the target candidate service node at the current moment is reduced based on the adjustment range to obtain the updated real-time service weight; or... In response to determining that the target candidate service node is not selected as the target service node at the current time, the real-time service weight corresponding to the target candidate service node at the current time is increased based on the adjustment range to obtain the updated real-time service weight.

17. The method according to claim 12, characterized in that, The step of using the custom binary protocol to deserialize the first binary protocol data to obtain the second request data includes: According to the custom binary protocol, the protocol header area of ​​the first binary protocol data is parsed to extract the identifier corresponding to the target compression algorithm, the identifier corresponding to the target serialization rule, the total length information, and the security verification data. Verify whether the total length of the first binary protocol data is consistent with the total length information recorded in the protocol header, and verify the data integrity through security verification data; Extract the message body region from the first binary protocol data; According to the decompression algorithm corresponding to the target compression algorithm identifier, the user data field in the message body area is decompressed to obtain user data in binary format; According to the deserialization rule corresponding to the target serialization rule identifier, the metadata field and security verification data field in the message body area and the user data in binary format are deserialized sequentially to obtain the corresponding metadata, security verification data and user data; The metadata, security verification data, and user data are combined into the second request data.

18. An electronic device, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the cross-language service invocation method as described in any one of claims 1 to 11 or 12 to 17.

Images