Protocol conversion method, device, electronic device and computer-readable storage medium

Abstract

This disclosure provides a protocol conversion method, apparatus, electronic device, and computer-readable storage medium, relating to the field of computer and internet technology. The protocol conversion method includes: a first sidecar component of a first service receiving first traffic through a first protocol; the first sidecar component separating the business application logic of the first service from the protocol conversion logic; the first sidecar component decoding the first traffic under the first protocol to obtain second traffic; and the first sidecar component forwarding the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service can process the second traffic. Embodiments of this disclosure can flexibly convert first traffic under the first protocol into second traffic under the native protocol of the first service.

Description

Technical Field

[0001] The present disclosure relates to the field of computer and Internet technology, and in particular to a protocol conversion method, device, electronic device and computer-readable storage medium. Background Art

[0002] Traditional protocol conversion solutions mainly include: gateway-based protocol conversion and SDK (software development kit)-enhanced protocol conversion.

[0003] Among them, gateway-based protocol conversion has the following disadvantages: the gateway is prone to single point failure, resulting in inaccessibility of all internal services; in addition, the gateway protocol expansion cost is high, requiring specialized personnel to carry out protocol expansion development work, and the upgrade process will also affect all internal services.

[0004] Among them, the protocol conversion based on SDK enhancement has the following disadvantages: the development of SDK is closely bound to its corresponding application itself; in addition, SDK enhanced protocol conversion is difficult to upgrade and replace, and the maintenance cost is high; and SDK supports protocol conversion by exposing more ports (that is, one protocol conversion mode requires customization of one port), and the user experience is poor.

[0005] Therefore, the protocol conversion in the related technology has problems such as inflexible conversion, high conversion cost, difficulty in protocol conversion and upgrading, and poor user experience. Summary of the invention

[0006] The purpose of the present disclosure is to provide a protocol conversion method, device, electronic device and computer-readable storage medium, which can deploy protocol conversion separately on each application service, and the protocol conversion is easy to upgrade and update, and is convenient for maintenance.

[0007] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by the practice of the present disclosure.

[0008] The disclosed embodiment provides a protocol conversion method, including: a first sidecar component of a first service receives first traffic through a first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic; the first sidecar component decodes the first traffic under the first protocol to obtain second traffic; the first sidecar component forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0009] In some embodiments, a first sidecar component of a first service receives a first traffic through a first protocol, including: the first sidecar component of the first service receives the first traffic through a first connection, and the first connection is established based on the first protocol; wherein the first sidecar component decodes the first traffic under the first protocol to obtain a second traffic, including: a message processor of the first sidecar component decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic; wherein the first sidecar component forwards the second traffic to a business application interface of the first service through a native protocol of the service interface of the first service, including: the message processor forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0010] In some embodiments, the first connection is a connection between the first sidecar component and a gateway or a load balancing component; wherein, before the first sidecar component of the first service receives the first traffic through the first connection, the method further includes: the first sidecar component of the first service receives a request message for establishing a connection from a gateway or a load balancing component; the first sidecar component negotiates with the gateway or the load balancing component based on the request message; during the negotiation process, it is determined to establish the first connection between the first sidecar component and the gateway or the load balancing component through the first protocol.

[0011] In some embodiments, the first connection is a connection between the first sidecar component and the second sidecar component of the second service; wherein, before the first sidecar component of the first service receives the first traffic through the first connection, the method further includes: the second sidecar component of the second service intercepts a connection request message sent by the second service to the first service, and the connection request message carries the first protocol; the second sidecar component sends the connection request message to the first sidecar component of the first service for protocol inference, and negotiates whether the first protocol in the connection request message can establish a connection; if it is determined through negotiation that the first protocol in the connection request message is supported, the first connection is established between the first sidecar component and the second sidecar component through the first protocol in the connection request.

[0012] In some embodiments, the method also includes: the business application component of the first service generates response traffic in response to the second traffic; the business application component of the first service encodes the response traffic through the native protocol of the service interface, and sends the encoded response traffic to the first sidecar component; the first sidecar component decodes the response traffic under the native protocol, and encodes the response traffic using the first protocol; the first sidecar component forwards the encoded response traffic to the second service or client through the first protocol.

[0013] In some embodiments, the first traffic is the call traffic of the second service calling the first service; wherein, before the first sidecar component of the first service receives the first traffic through the first protocol, the method also includes: the second service determines to initiate a service call to the first service through the first traffic; the second sidecar component of the second service determines to turn on the protocol conversion function according to the first traffic; the second sidecar component forwards the first traffic to the protocol conversion interface of the first sidecar component of the first service through the protocol conversion interface of the second sidecar component, so that the first sidecar component performs protocol conversion on the first traffic.

[0014] In some embodiments, the first traffic is the call traffic of the client calling the first service; wherein, before the first sidecar component of the first service receives the first traffic through the first protocol, the method also includes: the client sends the first traffic to the gateway or load balancing component corresponding to the first service through a third protocol; the gateway or load balancing component corresponding to the first service receives the first traffic through the third protocol; the gateway or load balancing component forwards the first traffic to the first sidecar component of the first service through the first protocol.

[0015] The embodiment of the present disclosure provides a protocol conversion device, including: a first traffic receiving module, a protocol conversion module and a traffic forwarding module.

[0016] Among them, the first traffic receiving module is used for the first sidecar component of the first service to receive the first traffic through the first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic; the protocol conversion module can be used for the first sidecar component to decode the first traffic under the first protocol to obtain the second traffic; the traffic forwarding module can be used for the first sidecar component to forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0017] An embodiment of the present disclosure provides an electronic device, which includes: a memory and a processor; the memory is used to store program instructions; the processor calls the program instructions stored in the memory to implement any of the above-mentioned protocol conversion methods.

[0018] The embodiment of the present disclosure provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the protocol conversion method as described in any one of the above items is implemented.

[0019] The embodiment of the present disclosure provides a computer program product or a computer program, which includes a computer instruction stored in a computer-readable storage medium. A processor of a computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device performs the above-mentioned protocol conversion method.

[0020] The protocol conversion method, device, electronic device, and computer-readable storage medium provided in the embodiments of the present disclosure perform protocol conversion on the first traffic through a first sidecar component separated from the business application logic of the first service, which, on the one hand, avoids the single point failure caused by centralized protocol conversion; on the other hand, by separating the protocol conversion logic from the business application logic, the protocol conversion can be isolated from the application logic, avoiding the impact of the addition and update of the protocol conversion on the application logic, and also making the addition and update of the protocol conversion unaffected by the application, thereby improving the flexibility of adding and updating the protocol conversion and facilitating later maintenance.

[0021] It is to be understood that the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification are used to explain the principles of the present disclosure. Obviously, the accompanying drawings described below are only some embodiments of the present disclosure, and for ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without creative work.

[0023] Figure 1 It is a schematic diagram of a north-south traffic protocol conversion architecture shown according to the relevant technology.

[0024] Figure 2 It is a schematic diagram of an east-west traffic protocol conversion architecture shown according to the relevant technology.

[0025] Figure 3 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0026] Figure 4 It is a schematic diagram of a protocol conversion architecture shown in an embodiment of the fundamental application.

[0027] Figure 5 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0028] Figure 6 The figure is a flowchart of a first connection establishment method according to an exemplary embodiment.

[0029] Figure 7 The figure is a flow chart of a method for establishing a connection according to an exemplary embodiment.

[0030] Figure 8 The present invention is a flowchart of a service response method according to an exemplary embodiment.

[0031] Fig. 9 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0032] Fig.10 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0033] Fig.11 It is a schematic structural diagram of a sidecar assembly according to an exemplary embodiment.

[0034] Fig.12 The present invention is a block diagram of a protocol conversion device according to an exemplary embodiment.

[0035] Fig.13 A schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0036] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The same reference numerals in the figures represent the same or similar parts, and thus their repeated description will be omitted.

[0037] The features, structures or characteristics described in the present disclosure may be combined in one or more embodiments in any suitable manner. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced while omitting one or more of the specific details, or other methods, components, devices, steps, etc. may be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the present disclosure.

[0038] The accompanying drawings are only schematic diagrams of the present disclosure, and the same reference numerals in the drawings represent the same or similar parts, so their repeated description will be omitted. Some block diagrams shown in the accompanying drawings do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0039] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and steps, nor must they be executed in the order described. For example, some steps can be decomposed, and some steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0040] In the description of the present application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this article is only a kind of association relationship describing the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" means one or more, and "plurality" means two or more. The words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not limit them to be different; the terms "comprising", "including" and "having" are used to express the meaning of open inclusion and mean that in addition to the listed elements / components / etc., there may be other elements / components / etc.

[0041] In order to more clearly understand the above-mentioned objects, features and advantages of the present invention, the present invention is further described in detail below in conjunction with the accompanying drawings and specific implementation methods. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0042] Protocol conversion refers to the process of converting the standard or protocol of one device into a protocol suitable for another device, in order to achieve interoperability between different protocols. Protocols usually appear in the form of software. For example, a router converts the data format, data rate, etc. in one network into a protocol suitable for another network. For example, in the RPC (Remote Procedure Call Protocol) field network, there are many protocols, which come from different RPC frameworks, and they need to be converted to be compatible with each other.

[0043] In this application, the point where the protocol conversion occurs can be the upstream service or the Provider end (data provider) or the downstream service or the Consumer end (data caller). The conventional protocol conversion function will be integrated in the gateway to implement external requests through the http protocol to the internal private rpc (remote call service) protocol service (generally speaking, different applications have different RPC protocols), which is common in north-south traffic (traffic from client to server). However, with the popularization of cloud-native architecture, the diversity of system implementation methods is becoming normalized, and programming languages, RPC and even communication protocols are no longer limited to a certain type. This has given rise to a strong demand for east-west traffic protocol conversion.

[0044] In the traditional protocol conversion scheme, there are two main schemes: one is the protocol conversion based on the gateway mode, and the other is the protocol conversion based on SDK (Software Development Kit) enhancement. The following will focus on these two types of protocol conversion methods and explain their respective advantages and disadvantages.

[0045] Gateway mode protocol conversion, such as Figure 1 As shown, the deployment of API gateway is the main method, the protocol conversion capability is implemented in the gateway application, and internal service calls are made through the agreed service description and method calling method. Figure 1 The spring cloud in it is a microservice framework, Dubbo is a service framework, and the application container is the APP container (App container).

[0046] This protocol conversion method is common in scenarios where external traffic calls internal services. The gateway acts as a unified outlet for the internal interface and provides it to external users for service interface calls. Usually, the gateway provides a unified domain name and maps requests to different backend protocols based on different front-end requests (such as Figure 1 The protocol corresponding to service A shown in Figure 1 The protocol corresponding to service B is shown in Figure 1The protocol corresponding to the service N shown in the figure, where N is a certificate greater than or equal to 1). Common requests include Web (World Wide Web, Global Wide Area Network) sites, mobile apps, edge computing, etc. As the only exit for internal services, the gateway can provide good security protection and unified management for internal services. This protocol conversion method has the following advantages: high resource utilization, unified management of interface resources, and is a relatively common protocol conversion method. However, it also has its disadvantages, such as single point failures that may be caused by centralized deployment, operation and maintenance developers are exclusive R&D personnel responsible for the gateway, business personnel and service personnel may not be the same group of people, and business R&D personnel who want to customize or modify the gateway for their own service interface will fail to modify due to insufficient capabilities, or need to seek help from operation and maintenance personnel, resulting in flexible and costly protocol conversion through the gateway.

[0047] A gateway is a product or application that has dedicated R&D personnel. Unlike business R&D personnel, business R&D personnel cannot directly modify other people's systems.

[0048] SDK protocol extension is usually used in scenarios where heterogeneous services or services with different RPC protocols access each other. This type of traffic is usually called east-west traffic. SDK protocol extension enhancement, such as Figure 2 As shown in the figure, when traffic enters the intranet from the outside through the gateway, it will call related services (such as service A). However, if the service cannot provide complete services, it will continue to call other services (such as Figure 2 In the service scheduling process, the protocol conversion can be completed through the SDK corresponding to the service. Figure 2 As shown, when service A calls service B, the protocol conversion can be achieved through the SDK interface corresponding to service B.

[0049] Usually, when RPC SDK is provided to business R&D, it is not allowed to be modified at will (it is developed by special personnel, and the product provided to business R&D personnel is a packaged product, which can only be used by business R&D personnel and cannot be modified). Of course, some RPC SDKs provide good extension methods, such as Dubbo. The advantages are good performance and high resource utilization. However, Dubbo's SDK uses different ports to distinguish the adaptation of different protocols, that is, different protocol requests need to access different ports of the application, which has a poor experience.

[0050] In order to solve the above problems, the present application provides a protocol conversion method, which can be specifically described through the following embodiments.

[0051] Figure 3 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0052] Reference Figure 3 The protocol conversion method provided by the embodiment of the present disclosure may include the following steps.

[0053] Step S302: A first sidecar component of a first service receives first traffic through a first protocol, and the first sidecar component is used to separate a business application logic of the first service from a protocol conversion logic.

[0054] SideCar (sidecar component) can split the functions that originally belong to the application (such as the application that provides the first service) into separate processes. In the microservice system, the microservice functions integrated in the application can be separated into the sidecar component, for example, the protocol conversion function of the application can be separated into the sidecar component.

[0055] SideCar is an independently deployed process that can reduce the coupling between application code and underlying code, and help heterogeneous services quickly access the microservice system through SideCar.

[0056] In this embodiment, the business application itself and the protocol conversion logic itself can be separated by SideCar through the cloud native service grid. The protocol conversion SideCar is injected in equal amounts according to the number of deployed instances of the business application itself (for example, one application can deploy multiple instances, and one instance can deploy one SideCar).

[0057] This embodiment can be implemented by adopting the SideCar mode of the service grid to separate the protocol conversion capability from the gateway or application SDK to the data plane of the SideCar.

[0058] Through the above deployment method, the gateway does not need to be deployed in a centralized manner. It can adopt lightweight implementations such as Ingress or Service in K8s. The domain name can also be freely set according to business needs, and the traffic inlet and outlet can be configured in a diversified manner.

[0059] In some embodiments, the first sidecar component of the first service may receive the first traffic via a first protocol, where the first protocol may be some public service protocols, such as HTTP protocol, HTTP1 protocol, etc., which is not limited in this application.

[0060] like Figure 4 As shown, the first sidecar component of the first service (such as service B) can receive the first traffic from the gateway through the HTTP protocol (that is, the first traffic can be the north-south traffic from the external network), and can also receive the first traffic from other services (such as service A or service N, etc.) through the HTTP protocol (that is, the first traffic can be the east-west traffic from other services). This application does not impose any restrictions on this.

[0061] Step S304: The first sidecar component decodes the first traffic under the first protocol to obtain the second traffic.

[0062] In some embodiments, after receiving the first traffic, the first sidecar component determines the protocol type of the first protocol corresponding to the first traffic, and then decodes the first traffic according to the protocol type corresponding to the first protocol to obtain decoded second traffic.

[0063] Step S306: The first sidecar component forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0064] In some embodiments, the first sidecar component may encode the second traffic using a native protocol of the service interface of the first service, and then forward the second traffic to the application interface of the first service through the native protocol.

[0065] Among them, the native protocol of the first service can be, for example, a private protocol corresponding to the first service. Different services can correspond to different private protocols, and this application does not impose any restrictions on this.

[0066] Generally speaking, the public protocols corresponding to different services may be well-known, such as the HTTP protocol or the HTTP1 protocol, and different services know how to use the public protocols for encoding and decoding; while the private protocols corresponding to different services may be different, and the protocols between different services may need to be converted.

[0067] The above-mentioned native protocol may be a private protocol corresponding to the first service.

[0068] In some embodiments, the first sidecar component is aware of the encoding and decoding method of the native protocol of the service interface of the first service.

[0069] The above-mentioned embodiment lowers the threshold for protocol extension by abstracting the RPC call process and adopting a plug-in mechanism. By upgrading and optimizing the protocol conversion process through the above-mentioned first component, the impact of the application itself can be reduced. In addition, the user experience can be improved by adapting the unified port of the first service to multiple protocols in the first service. And the deployment through the SideCar method can retain the original application protocol port entry, without any impact on the original RPC framework, and the SideCar can be controlled by issuing corresponding control rules from the control plane to achieve dynamic switch protocol extension functions. At the same time, cloud-native methods such as K8s Service, Ingress, etc. can be used to dynamically control the north-south traffic requests of the service.

[0070] Compared with the SDK protocol conversion mode, this embodiment uses a new technology (cloud native service mesh mode) to separate protocol conversion from application, so as to avoid the impact of protocol conversion module upgrade on application, and is no longer bound to the service implementation language. Through SideCar hot update, the upgrade can have no impact on the application itself, and there is no need to restart the application container. Compared with the multi-port protocol support method, the single port is a protocol inference that adapts to the insulation treatment, which effectively reduces the client connection access threshold and improves the user experience. Compared with the gateway protocol conversion method, in addition to the above-mentioned innovations, the distributed deployment follows the service deployment, avoiding single point failures in multi-service scenarios.

[0071] In summary, the above embodiments can achieve the following technical effects.

[0072] 1. Use the service mesh mode (SideCar) to reduce the intrusiveness of the protocol conversion module to the application and reduce the impact of protocol updates and upgrades on the application.

[0073] 2. Through distributed deployment of protocol conversion modules, the centralized impact and single point failure risk brought by gateway-type protocol conversion can be avoided. It can truly achieve on-demand deployment and effective use of resources.

[0074] 3. Through single-port adaptive protocol message processing, the complexity of users is greatly reduced and the user experience is improved.

[0075] Figure 5 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0076] refer to Figure 5 , the above-mentioned protocol conversion method may include the following steps.

[0077] Step S502: A first sidecar component of a first service receives first traffic through a first connection, where the first connection is established based on a first protocol.

[0078] Among them, the above-mentioned first connection may refer to the connection between the first sidecar component and the gateway, or may refer to the connection between the first sidecar component and the sidecar components of other services, and this application does not impose any restrictions on this.

[0079] In some embodiments, the first connection may be established via a first protocol.

[0080] Step S504: The message processor of the first sidecar component decodes the first traffic through a decoder corresponding to the first protocol to obtain second traffic.

[0081] In some embodiments, the first sidecar component may include a codec corresponding to the first protocol.

[0082] In some embodiments, the message processor of the first sidecar component may decode the first traffic by a decoder corresponding to the first protocol to obtain the second traffic.

[0083] Step S506: The message processor forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0084] In some embodiments, after the message processor decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic, it can also forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0085] In this embodiment, by sending and receiving traffic through the first connection, the protocol of the traffic can be easily determined, which facilitates protocol conversion.

[0086] The following will be Figure 7 Example or Figure 8 The embodiment explains how the above-mentioned first connection is established.

[0087] Figure 6 The figure is a flowchart of a first connection establishment method according to an exemplary embodiment.

[0088] In some embodiments, the first connection is a connection between the first sidecar component and a gateway or a load balancing component.

[0089] refer to Figure 6 , the above-mentioned first connection establishment method may include the following steps.

[0090] Step S602: The first sidecar component of the first service receives a request message for establishing a connection from a gateway or a load balancing component.

[0091] Step S604: The first sidecar component negotiates with the gateway or the load balancing component according to the request message.

[0092] Step S606: During the negotiation process, it is determined that a first connection is established between the first sidecar component and the gateway or the load balancing component through a first protocol.

[0093] Step S608: A first sidecar component of a first service receives first traffic through a first connection, where the first connection is established based on a first protocol.

[0094] Among them, the above-mentioned first connection may refer to the connection between the first sidecar component and the gateway, or may refer to the connection between the first sidecar component and the sidecar components of other services, and this application does not impose any restrictions on this.

[0095] In some embodiments, the first connection may be established via a first protocol.

[0096] In step S610, the message processor of the first sidecar component decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic.

[0097] In some embodiments, the first sidecar component may include a codec corresponding to the first protocol.

[0098] In some embodiments, the message processor of the first sidecar component may decode the first traffic by a decoder corresponding to the first protocol to obtain the second traffic.

[0099] Step S612: The message processor forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0100] In some embodiments, after the message processor decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic, it can also forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0101] In this embodiment, when processing the protocol conversion of north-south traffic, the first component SideCar of the first service can perform protocol negotiation based on the request message for establishing a connection from the gateway or the load balancing component LB. During the negotiation process, it is determined whether the establishment of the link is based on HTTP1, HTTP2, or other public protocols. After the connection is established (TCP connection), the subsequent network request binary message will be encoded and decoded into a specific protocol model by the encoder Encoder or decoder Decoder of the public protocol. Note that this connection is established between the gateway or LB and the port exposed by the SideCar of the service. After the request message is parsed by the SideCar, the message processor in the SideCar will forward the request through the native protocol of the application interface to the port exposed by the application (such as the application of the first service). After the application is processed, the result will be returned to the client through the SideCar.

[0102] Figure 7 The figure is a flow chart of a method for establishing a connection according to an exemplary embodiment.

[0103] In some embodiments, the first connection is a connection between the first sidecar component and a second sidecar component of the second service.

[0104] The second service may be a service different from the first service.

[0105] refer to Figure 7 , the above connection establishment method may include the following steps.

[0106] Step S702: The second sidecar component of the second service intercepts a connection request message sent by the second service to the first service, where the connection request message carries the first protocol.

[0107] In step S704, the second sidecar component sends the connection request message to the first sidecar component of the first service for protocol inference, and negotiates whether the first protocol in the connection request message can establish a connection.

[0108] Step S706: If it is determined through negotiation that the first protocol in the connection request message is supported, a first connection is established between the first sidecar component and the second sidecar component through the first protocol in the connection request.

[0109] Step S708: A first sidecar component of a first service receives first traffic through a first connection, where the first connection is established based on a first protocol.

[0110] Among them, the above-mentioned first connection may refer to the connection between the first sidecar component and the gateway, or may refer to the connection between the first sidecar component and the sidecar components of other services, and this application does not impose any restrictions on this.

[0111] In some embodiments, the first connection may be established via a first protocol.

[0112] In step S710, the message processor of the first sidecar component decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic.

[0113] In some embodiments, the first sidecar component may include a codec corresponding to the first protocol.

[0114] In some embodiments, the message processor of the first sidecar component may decode the first traffic by a decoder corresponding to the first protocol to obtain the second traffic.

[0115] Step S712: The message processor forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0116] In some embodiments, after the message processor decodes the first traffic through a decoder corresponding to the first protocol to obtain the second traffic, it can also forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0117] In this embodiment, when processing the protocol conversion of east-west traffic, the first component SideCar of the first service performs protocol negotiation with the second service based on the connection request message from other services (such as the second service). During the negotiation process, it is determined whether the establishment of the link is based on HTTP1, HTTP2, or other public protocols. After the connection is established (TCP connection), the subsequent network request binary message will be encoded and decoded into a specific protocol model by the encoder Encoder or decoder Decoder of the public protocol. Note that this connection is established between the port exposed by the SideCar of the first service and the interface exposed by the SideCar of the second service. After the request message is parsed by the first sidecar component SideCar of the first service, the message processor will forward the request to the port exposed by the application through the native protocol of the application interface. After the application is processed, the result will be returned to the client through SideCar.

[0118] Figure 8 The present invention is a flowchart of a service response method according to an exemplary embodiment.

[0119] refer to Figure 8 , the above service response method may include the following steps.

[0120] Step S802: The business application component of the first service generates response traffic in response to the second traffic.

[0121] In some embodiments, the service application component of the first service may generate a response traffic in response to the second traffic based on the service demand.

[0122] Step S804: The business application component of the first service encodes the response traffic through the native protocol of the service interface, and sends the encoded response traffic to the first sidecar component.

[0123] In step S806, the first sidecar component decodes the response traffic under the native protocol and encodes the response traffic using the first protocol.

[0124] In step S808, the first sidecar component forwards the encoded response traffic to the second service or client through the first protocol.

[0125] In some embodiments, if the first traffic is north-south traffic, the first sidecar component may forward the encoded response traffic to the client through the first protocol; if the first traffic is east-west traffic, the first sidecar component may forward the encoded response traffic to other services (such as the second service that initiated the first traffic) through the first protocol.

[0126] Fig. 9 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0127] In some embodiments, the first traffic is call traffic in which a client calls a first service.

[0128] refer to Fig. 9 , the above-mentioned protocol conversion method may include the following steps.

[0129] Step S902: The client sends the first traffic to the gateway or load balancing component corresponding to the first service through the third protocol.

[0130] The third protocol may be the same as the first protocol or different from the first protocol, and this application does not impose any limitation on this.

[0131] If the third protocol is different from the first protocol, the gateway or the load balancing component may perform protocol conversion between the third protocol and the first protocol, which is not described in detail in this embodiment.

[0132] Step S904: The gateway or load balancing component corresponding to the first service receives the first traffic through the third protocol.

[0133] Step S906: The gateway or load balancing component forwards the first traffic to the first sidecar component of the first service through the first protocol.

[0134] Step S908: A first sidecar component of the first service receives first traffic through a first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic.

[0135] Step S910: The first sidecar component decodes the first traffic under the first protocol to obtain the second traffic.

[0136] In step S912, the first sidecar component forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0137] Fig.10 The present invention is a flowchart of a protocol conversion method according to an exemplary embodiment.

[0138] In some embodiments, the first traffic is call traffic in which the second service calls the first service.

[0139] Step S1002: The second service determines to initiate a service call to the first service through the first traffic.

[0140] Step S1006: The second sidecar component of the second service determines to enable a protocol conversion function according to the first traffic.

[0141] In some embodiments, the second sidecar component of the second service may determine whether to enable a protocol conversion function for the first traffic based on configuration information sent by the control plane.

[0142] Step S1008: The second sidecar component forwards the first traffic to the protocol conversion interface of the first sidecar component of the first service through the protocol conversion interface of the second sidecar component, so that the first sidecar component performs protocol conversion on the first traffic.

[0143] If the second sidecar component determines according to the configuration information that the protocol conversion function should not be enabled for the first traffic, the second sidecar component will transfer the first traffic to the first service through the general interface; if the second sidecar component determines according to the configuration information that the protocol conversion function should be enabled for the first traffic, the second sidecar component will forward the first traffic to the protocol conversion interface of the first sidecar component of the first service through the protocol conversion interface of the second sidecar.

[0144] When the first sidecar component of the first service receives the first traffic through the protocol conversion interface, it knows that the first traffic needs to be converted into a protocol, and then uses the first sidecar component to convert the first traffic into a protocol.

[0145] Step S1011: A first sidecar component of a first service receives first traffic through a first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic.

[0146] Step S1012: The first sidecar component decodes the first traffic under the first protocol to obtain the second traffic.

[0147] Step S1014: The first sidecar component forwards the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0148] In some embodiments, when SideCar processes the protocol conversion of east-west traffic, the initiator of the request is called the Consumer in the internal application. The recipient of the request is called the Provider. Both the Consumer and Provider will deploy SideCar, also known as the data plane. The programs running in SideCar are the same, but they play different roles in different roles. Fig.11 The specific structure of the sidecar components on the Consumer and Provider sides is shown, but Fig.11 In order to omit duplication, the SideCar on the Consumer side is not described in detail. It is basically the same as the Provider, and the differences will be pointed out later.

[0149] In some embodiments, after the east-west traffic user request enters the service corresponding to the Consumer side from the gateway or the load balancing component LB, if the service corresponding to the Consumer side cannot provide complete services, the service on the Consumer side will initiate RPC calls to other services. When initiating RPC calls to other services, the SideCar on the Consumer side will determine whether to enable the SideCar traffic interception and protocol conversion capabilities based on the configuration information sent by the control plane. If this function is enabled, the traffic sent from the Consumer side to the Provider side will be intercepted and forwarded to the port of the Consumer's SideCar by creating iptables routing rules. First, the connection message processed, the Consumer's SideCar will send the connection message to the Provider's SideCar for protocol inference, and negotiate whether the type of protocol can establish a connection. If the protocol requested for connection is supported, the connection is successful. Otherwise, the connection fails to be established. After the connection is successfully established, the service request message will be sent to the Provider's SideCar via the Consumer's SideCar. At this point, there is no need to infer the protocol, but to perform necessary microservice governance operations.

[0150] like Fig.11 As shown, the microservice governance on the Consumer side includes rule routing, load balancing, circuit breaking and degradation, etc., while the Provider side processes service governance functions such as access authentication and access flow limiting. Because this invention is not related to the above service governance features, it will not be described in detail. The focus of this invention is on the IO processing flow stages such as protocol inference and protocol encoding and decoding, so the focus is detailed here.

[0151] In some embodiments, the protocol conversion function in the first sidecar component may be newly added or updated and optimized. The specific principle can be referred to in the following description.

[0152] like Fig.10As shown in the figure, after the message is sent from the Consumer to the Provider, SideCar will decode it by the codec corresponding to the protocol type selected by the protocol negotiation in the connection creation phase. The most important part of protocol conversion is the extended support for multiple protocols. To achieve multi-protocol support on the same port, the above-mentioned key function - protocol inference is indispensable. The protocol inference function abstracts an interface method, for example, it can be named "ProtocolMatcher". Different protocols can rewrite this method when implementing extensions, and formulate specific protocol identification methods. For example, the conventional practice is to extract a special character in the message and define it as MagicCode. The special character is fixed or regular when the connection request of the protocol is made. According to MagicCode, it can be inferred which type of protocol the link belongs to in the supported protocol list. Similarly, when the protocol is extended, the newly added supported protocol can be added to the SideCar runtime through plug-in extension in the same way. As shown in the figure, in addition to the above-mentioned "ProtocolMatcher", the protocol extension also includes "Encoder", "Decoder" and other interface methods related to protocol encoding and decoding.

[0153] After the protocol inference is completed, the specific protocol "Decoder" decoder translates the binary stream message into specific protocol model data, and then goes through a series of message additional processing functions, such as decryption, decompression, and multiplexing of the subject message data. The message type inferencer then infers which type of message in the protocol the message outputs. The recognition principle is similar to the above-mentioned "ProtocolMatcher", and there is also a fixed identifiable code for message type inference. After identifying the message type, the message data is handed over to a specific type of message processor of the protocol for processing. Similarly, the message type can also be extended. The message type processor is the final protocol message processing logic implementation area, which is used to process different message types under different protocols. For example, the request message will process the message, wait for the result to be generated, and then compress, encrypt, encode, etc. the result data through the above-mentioned series of extension functions to generate a binary stream message, and then send it to the Consumer end through the connection channel. For example, the heartbeat message will parse the various data of the heartbeat initiator to modify the heartbeat model data maintained by itself, and return the heartbeat response to the heartbeat initiator.

[0154] Based on the same inventive concept, the present disclosure also provides a protocol conversion device, such as the following embodiment. Since the principle of solving the problem in the device embodiment is similar to that in the above method embodiment, the implementation of the device embodiment can refer to the implementation of the above method embodiment, and the repeated parts will not be repeated.

[0155] Fig.12is a block diagram of a protocol conversion device according to an exemplary embodiment. Fig.12 The protocol conversion device 1200 provided in the embodiment of the present disclosure may include: a first traffic receiving module 1201, a protocol conversion module 1202, and a traffic forwarding module 1203.

[0156] Among them, the first traffic receiving module 1201 can be used for the first sidecar component of the first service to receive the first traffic through the first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic; the protocol conversion module 1202 can be used for the first sidecar component to decode the first traffic under the first protocol to obtain the second traffic; the traffic forwarding module 1203 can be used for the first sidecar component to forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second traffic.

[0157] It should be noted that the first traffic receiving module 1201, the protocol conversion module 1202, and the traffic forwarding module 1203 correspond to S302 to S306 in the method embodiment, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above method embodiment. It should be noted that the above modules, as part of the device, can be executed in a computer system such as a set of computer executable instructions.

[0158] In some embodiments, the first traffic receiving module 1201 may include: a first connection receiving submodule; the protocol conversion module 1202 may include: a first decoding submodule; and the traffic forwarding module 1203 may include: a traffic forwarding submodule.

[0159] Among them, the first connection receiving submodule can be used for the first sidecar component of the first service to receive the first traffic through the first connection, and the first connection is established based on the first protocol; the first decoding submodule can be used for the message processor of the first sidecar component to decode the first traffic through the decoder corresponding to the first protocol to obtain the second traffic; the traffic forwarding submodule can be used for the message processor to forward the second traffic to the business application interface of the first service through the native protocol of the service interface of the first service.

[0160] In some embodiments, the first connection is a connection between a first sidecar component and a gateway or a load balancing component; wherein the protocol conversion device may include: a first request message receiving module, a first negotiation module, and a first connection establishing module.

[0161] Among them, the first request message receiving module can be used for the first sidecar component of the first service to receive a request message for establishing a connection from a gateway or a load balancing component before the first sidecar component of the first service receives the first traffic through the first connection; the first negotiation module can be used for the first sidecar component to negotiate with the gateway or the load balancing component according to the request message; the first connection establishment module can be used to determine, during the negotiation process, to establish a first connection between the first sidecar component and the gateway or the load balancing component through a first protocol.

[0162] In some embodiments, the first connection is a connection between a first sidecar component and a second sidecar component of a second service; wherein the protocol conversion device may include: an interception module, a protocol inference module, and a first connection establishment second module.

[0163] Among them, the interception module can be used for the second sidecar component of the second service to intercept the connection request message sent by the second service to the first service before the first sidecar component of the first service receives the first traffic through the first connection, and the connection request message carries the first protocol; the protocol inference module can be used for the second sidecar component to send the connection request message to the first sidecar component of the first service for protocol inference, and negotiate whether the first protocol in the connection request message can establish a connection; the first connection establishment second module can be used to establish a first connection between the first sidecar component and the second sidecar component through the first protocol in the connection request if it is determined through negotiation that the first protocol in the connection request message is supported.

[0164] In some embodiments, the protocol conversion device may include: a response traffic generation module, a response encoding module, a response decoding module and a response forwarding module.

[0165] Among them, the response traffic generation module can be used by the business application component of the first service to generate response traffic in response to the second traffic; the response encoding module can be used by the business application component of the first service to encode the response traffic through the native protocol of the service interface, and send the encoded response traffic to the first sidecar component; the response decoding module can be used by the first sidecar component to decode the response traffic under the native protocol and encode the response traffic using the first protocol; the response forwarding module can be used by the first sidecar component to forward the encoded response traffic to the second service or client through the first protocol.

[0166] In some embodiments, the protocol conversion device may include: a service call initiating module, a protocol conversion function enabling module and a first traffic forwarding module.

[0167] Among them, the first traffic is the calling traffic of the second service calling the first service; wherein, the service call initiation module can be used for the second service to determine to initiate a service call to the first service through the first traffic before the first sidecar component of the first service receives the first traffic through the first protocol; the protocol conversion function activation module can be used for the second sidecar component of the second service to determine to activate the protocol conversion function according to the first traffic; the first traffic forwarding module can be used for the second sidecar component to forward the first traffic to the protocol conversion interface of the first sidecar component of the first service through the protocol conversion interface of the second sidecar component, so that the first sidecar component can perform protocol conversion on the first traffic.

[0168] In some embodiments, the first traffic is the calling traffic of the client calling the first service; wherein the protocol conversion device may include: a first traffic second sending module, a first traffic second receiving module and a first traffic second forwarding module.

[0169] Among them, the first traffic second sending module can be used for the client to send the first traffic to the gateway or load balancing component corresponding to the first service through the third protocol before the first sidecar component of the first service receives the first traffic through the first protocol; the first traffic second receiving module can be used for the gateway or load balancing component corresponding to the first service to receive the first traffic through the third protocol; the first traffic second forwarding module can be used for the gateway or load balancing component to forward the first traffic to the first sidecar component of the first service through the first protocol.

[0170] Since the functions of the device 1200 have been described in detail in the corresponding method embodiments, the present disclosure will not elaborate on them here.

[0171] The modules (and / or submodules and / or) units involved in the embodiments of the present application may be implemented by software or by hardware. The modules (and / or submodules and / or) units described may also be arranged in a processor. The names of these modules (and / or submodules and / or) units do not, in certain circumstances, constitute limitations on the modules (and / or submodules and / or) units themselves.

[0172] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the above-mentioned module, program segment or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0173] In addition, the above-mentioned figures are only schematic illustrations of the processes included in the method according to the exemplary embodiments of the present disclosure, and are not intended to be limiting. It is easy to understand that the processes shown in the above-mentioned figures do not indicate or limit the time sequence of these processes. In addition, it is also easy to understand that these processes can be performed synchronously or asynchronously, for example, in multiple modules.

[0174] Fig.13 The schematic diagram of the structure of the electronic device suitable for implementing the embodiment of the present disclosure is shown. It should be noted that: Fig.13 The electronic device 1300 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0175] like Fig.13 As shown, the electronic device 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1302 or a program loaded from a storage part 1308 into a random access memory (RAM) 1303. In the RAM 1303, various programs and data required for the operation of the electronic device 1300 are also stored. The CPU 1301, the ROM 1302, and the RAM 1303 are connected to each other via a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0176] The following components are connected to the I / O interface 1305: an input section 1306 including a keyboard, a mouse, etc.; an output section 1307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN card, a modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the I / O interface 1305 as needed. A removable medium 1311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1310 as needed, so that a computer program read therefrom is installed into the storage section 1308 as needed.

[0177] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication part 1309, and / or installed from a removable medium 1311. When the computer program is executed by a central processing unit (CPU) 1301, the above-mentioned functions defined in the system of the present application are executed.

[0178] It should be noted that the computer-readable storage medium shown in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0179] As another aspect, the present application also provides a computer-readable storage medium, which may be included in the device described in the above embodiment; or it may exist independently without being assembled into the device. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed by a device, the device can implement functions including: a first sidecar component of a first service receives a first flow through a first protocol, and the first sidecar component is used to separate the business application logic of the first service from the protocol conversion logic; the first sidecar component decodes the first flow under the first protocol to obtain a second flow; the first sidecar component forwards the second flow to the business application interface of the first service through the native protocol of the service interface of the first service, so that the business application component of the first service processes the second flow.

[0180] According to one aspect of the present application, a computer program product or a computer program is provided, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method provided in various optional implementations of the above-mentioned embodiments.

[0181] Through the description of the above implementation methods, it is easy for those skilled in the art to understand that the example implementation methods described here can be implemented by software, or by combining software with necessary hardware. Therefore, the technical solution of the embodiment of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.), including several instructions for a computing device (which can be a personal computer, a server, a mobile terminal, or a smart device, etc.) to execute the method according to the embodiment of the present disclosure.

[0182] Those skilled in the art will readily appreciate other embodiments of the present disclosure after considering the specification and practicing the disclosure disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common knowledge or customary technical means in the art that are not applied for by the present disclosure. The specification and examples are to be regarded as exemplary only, and the true scope and spirit of the present disclosure are indicated by the claims.

[0183] It should be understood that the present disclosure is not limited to the detailed structures, drawings or implementations shown herein, but rather the present disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A protocol conversion method, characterized in that: include: A first sidecar component in a first service receives first traffic through a first connection, where the first connection is established based on a first protocol, and the first sidecar component is used to separate a business application logic from a protocol conversion logic of the first service; The message processor of the first sidecar component decodes the first traffic through a decoder of the first protocol corresponding to the first connection to obtain second traffic; The message processor encodes the second traffic through a native protocol of a service interface of the first service; Then forwarding the second traffic to the business application interface of the first service through the native protocol, so that the business application component of the first service processes the second traffic; wherein the native protocol of the first service is a private protocol of the first service, and different services correspond to different private protocols; If the first connection is a connection between the first sidecar component and a gateway or a load balancing component, then, before the first sidecar component of the first service receives the first traffic through the first connection, the method further includes: The first sidecar component of the first service receives a request message for establishing a connection from a gateway or a load balancing component; The first sidecar component negotiates with the gateway or the load balancing component according to the request message; During the negotiation process, it is determined to establish the first connection between the first sidecar component and the gateway or the load balancing component through the first protocol.

2. The method according to claim 1, characterized in that: If the first connection is a connection between the first sidecar component and a second sidecar component of a second service; then, before the first sidecar component of the first service receives the first traffic through the first connection, the method further includes: The second sidecar component of the second service intercepts a connection request message sent by the second service to the first service, where the connection request message carries the first protocol; The second sidecar component sends the connection request message to the first sidecar component of the first service for protocol inference, and negotiates whether the first protocol in the connection request message can establish a connection; If it is determined through negotiation that the first protocol in the connection request message is supported, the first connection is established between the first sidecar component and the second sidecar component through the first protocol in the connection request.

3. The method according to claim 1, characterized in that: The method further comprises: The business application component of the first service generates a response flow in response to the second flow; The business application component of the first service encodes the response traffic through the native protocol of the service interface, and sends the encoded response traffic to the first sidecar component; The first sidecar component decodes the response traffic under the native protocol and encodes the response traffic using the first protocol; The first sidecar component forwards the encoded response traffic to the second service or client through the first protocol.

4. The method according to claim 1, characterized in that: The first traffic is the call traffic of the second service calling the first service; wherein, before the first sidecar component of the first service receives the first traffic through the first protocol, the method further includes: The second service determines to initiate a service call to the first service through the first traffic; The second sidecar component of the second service determines to enable a protocol conversion function according to the first traffic; The second sidecar component forwards the first traffic to the protocol conversion interface of the first sidecar component of the first service through the protocol conversion interface of the second sidecar component, so that the first sidecar component performs protocol conversion on the first traffic.

5. The method according to claim 1, characterized in that: The first traffic is the call traffic of the client calling the first service; wherein, before the first sidecar component of the first service receives the first traffic through the first protocol, the method further includes: The client sends the first traffic to a gateway or a load balancing component corresponding to the first service through a third protocol; The gateway or load balancing component corresponding to the first service receives the first traffic through the third protocol; The gateway or load balancing component forwards the first traffic to the first sidecar component of the first service through the first protocol.

6. A protocol conversion device, characterized in that: include: A first traffic receiving module, configured for a first sidecar component in a first service to receive first traffic through a first connection, wherein the first connection is established based on a first protocol, and the first sidecar component is configured to separate a business application logic from a protocol conversion logic of the first service; A protocol conversion module, configured for a message processor of the first sidecar component to decode the first traffic through a decoder of the first protocol corresponding to the first connection to obtain a second traffic; A traffic forwarding module, configured for the message processor to encode the second traffic through a native protocol of a service interface of the first service; Then forwarding the second traffic to the business application interface of the first service through the native protocol, so that the business application component of the first service processes the second traffic; wherein the native protocol of the first service is a private protocol of the first service, and different services correspond to different private protocols; If the first connection is a connection between the first sidecar component and a gateway or a load balancing component, the device further includes: A first request message receiving module, configured to receive, through the first sidecar component of the first service, a request message for establishing a connection from a gateway or a load balancing component before the first sidecar component of the first service receives the first traffic through the first connection; A first negotiation module, configured to negotiate with the gateway or the load balancing component according to the request message through the first sidecar component; The first connection establishing module is used to determine, during the negotiation process, to establish the first connection between the first sidecar component and the gateway or the load balancing component through the first protocol.

7. An electronic device, characterized in that: include: Memory and processor; The memory is used to store program instructions; the processor calls the program instructions stored in the memory to implement the protocol conversion method as described in any one of claims 1-5.

8. A computer-readable storage medium having program instructions stored thereon, wherein the program instructions, when executed by a processor, implement the protocol conversion method according to any one of claims 1 to 5.

Images