A dual protocol microservice bridging system, method, and dual protocol microservice apparatus

Abstract

The present disclosure relates to the technical field of software architecture, and discloses a dual-protocol microservice bridging system, method and dual-protocol microservice device. The system comprises: a plurality of microservice modules, which integrate dual-protocol communication capabilities of a first communication protocol and a second communication protocol through the same service code; a dual-protocol engine module, which comprises a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; a service registry center, which respectively stores protocol registration information of each microservice module under the first communication protocol and the second communication protocol through a namespace grouping isolation mechanism; and a protocol routing module, which enables microservice modules adopting different communication protocols to directly interact. By marking the first annotation and the second annotation in the same code, two sets of independent codes do not need to be developed, and the processing of the first communication protocol and the second communication protocol can be natively supported, unnecessary redundant work is avoided, the development amount is significantly reduced, and the development efficiency is directly improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software architecture, and particularly relates to a dual-protocol micro-service bridging system and method and a dual-protocol micro-service device. BACKGROUND

[0002] A micro-service architecture divides a software system into independently deployed micro-services according to business functions, and uses interfaces to realize data transmission between services, and has the advantages of low coupling, good fault isolation, easy maintenance, and strong scalability. The interaction and communication mode between micro-services plays a key role in the stability, response speed, and running efficiency of the system.

[0003] However, in the related art, some micro-service architectures use a single HyperText Transfer Protocol (HTTP) protocol for communication. When a new service is developed using a new protocol, the old service needs to be redeveloped or an intercommunication is realized through a protocol conversion module, which often has the problems of long development cycle and high cost. Therefore, how to enable a micro-service architecture to have dual-protocol processing capability based on the same service code, thereby improving development efficiency and reducing development cost, has become a problem to be solved. SUMMARY

[0004] Therefore, the present application provides a dual-protocol micro-service bridging system and method and a dual-protocol micro-service device to solve the problem of how to enable a micro-service architecture to have dual-protocol processing capability based on the same service code, thereby improving development efficiency and reducing development cost.

[0005] In one aspect, the present disclosure provides a dual-protocol micro-service bridging system, which includes: a plurality of micro-service modules, which integrate dual-protocol communication capabilities of a first communication protocol and a second communication protocol through the same service code, and a service interface position of the service code is labeled with first protocol annotations and second protocol annotations at the same time; a dual-protocol engine module, which includes a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; a service registry center, which stores protocol registration information of each micro-service module under the first communication protocol and the second communication protocol respectively through a namespace grouping isolation mechanism; and a protocol routing module, which is configured to automatically select a protocol channel matched with a protocol type of a micro-service module as a caller based on the protocol registration information, so that micro-service modules using different communication protocols directly interact.

[0006] The other aspect of the present disclosure further provides a dual-protocol microservice bridging method, which comprises the following steps: simultaneously marking a first protocol annotation and a second protocol annotation at a service interface position of a microservice module, enabling a same service code with dual-protocol communication capability of a first communication protocol and a second communication protocol through a dynamic proxy; binding a corresponding first protocol engine for the first communication protocol and configuring a thread optimization strategy for a high-concurrency scenario, and binding a corresponding second protocol engine for the second communication protocol and configuring a thread optimization strategy of a fixed thread model through a dual-protocol engine module; registering protocol registration information of the microservice module under the first communication protocol and the second communication protocol respectively through a namespace grouping isolation mechanism of a service registry center; matching a target microservice module based on the protocol registration information of the service registry center in response to a request of a microservice module as a calling party, automatically selecting a protocol channel matched with a protocol type of the calling party, and enabling microservice modules adopting different communication protocols to directly interact.

[0007] The other aspect of the present disclosure further provides a dual-protocol microservice device, which comprises the following parts: a service interface module, simultaneously marking a first protocol annotation based on a Spring Cloud framework and a second protocol annotation based on a Dubbo framework, and generating a service interface of a first communication protocol and a second communication protocol through a dynamic proxy; an engine configuration module, binding a first protocol engine and a second protocol engine, configuring the number of IO threads of the first protocol engine to be equal to the number of processor cores, and configuring the number of working threads to be N times of the number of processor cores, and initializing a fixed number of threads in a thread pool of the second protocol engine at service startup; a registration isolation module, storing registration information of the microservice under the first communication protocol in a first Group and storing registration information of the microservice under the second communication protocol in a second Group through a namespace grouping isolation mechanism of a service registry center.

[0008] The other aspect of the present disclosure further provides an electronic device, which comprises a memory for storing a computer program and a processor for executing the computer program to realize the dual-protocol microservice bridging method.

[0009] The other aspect of the present disclosure further provides a computer readable storage medium, which stores computer instructions for making a computer realize the dual-protocol microservice bridging method.

[0010] The other aspect of the present disclosure further provides a computer program product, which comprises computer instructions for making a computer execute the dual-protocol microservice bridging method.

[0011] Through the dual-protocol microservice bridging system, method, and dual-protocol microservice device of the above embodiments of this disclosure, multiple microservice modules can natively support the processing of the first and second communication protocols by simultaneously annotating the first protocol annotation and the second protocol annotation at the interface position of the same service code, without having to develop two separate sets of code for the two protocols. This avoids unnecessary redundant work, significantly reduces development workload, and directly improves development efficiency.

[0012] Furthermore, the native dual-protocol support of the dual-protocol microservice module, combined with the automatic adaptation of the protocol routing module, enables new services (dual-protocol) and old services (single-protocol) to interact directly without the need for additional development of conversion modules or modification of old services, significantly reducing the development cost of system expansion. Attached Figure Description

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

[0014] Figure 1 This is an exemplary schematic diagram of the architecture of a dual-protocol microservice bridging system according to an embodiment of this disclosure;

[0015] Figure 2 This is a flowchart illustrating a dual-protocol microservice bridging method provided in an embodiment of this disclosure;

[0016] Figure 3 This is an exemplary schematic diagram of another dual-protocol microservice bridging system architecture according to an embodiment of this disclosure;

[0017] Figure 4 This is a schematic diagram illustrating a specific application of the architecture of a dual-protocol microservice bridging system according to an embodiment of this disclosure;

[0018] Figure 5 This is an exemplary schematic diagram of the architecture of a dual-protocol microservice device according to an embodiment of this disclosure;

[0019] Figure 6 This is a schematic diagram of another dual-protocol microservice bridging system provided in this embodiment. Detailed Implementation

[0020] Microservice architecture is a software system architecture that breaks down a software system into multiple independently deployed and running microservices, based on business functions. These microservices communicate and transmit data through interfaces, remaining independent of each other. Therefore, microservice architecture offers advantages such as low system coupling, excellent fault isolation, ease of updates and maintenance, and strong scalability. In a microservice architecture, the interaction and communication methods between different microservices have a significant impact on the stability, response speed, and operational efficiency of the entire microservice architecture system.

[0021] Because of the versatility of the HTTP protocol, some microservice architectures are developed using HTTP communication. Clients communicate with the entire service system, as well as with the microservices within the service system, using HTTP to generate language-specific data structures and interfaces through the Feign interface. However, using a single HTTP protocol for interaction between the system and microservices requires a three-way handshake and a four-way handshake. The access process follows a request-response model, where the request transmission must include a request header, request line, and request body. Because the request header and request line have a fixed format and are quite large, regardless of the size of the request body, both must be included, resulting in significant memory consumption during request transmission. The response model suffers from the same problem; regardless of the size of the response body, both request headers and request body must be included. This leads to slow system performance and potential system crashes when there are many users accessing the system.

[0022] Furthermore, using a single HTTP protocol for communication limits the further development and expansion of the entire software system. For example, if existing microservices in a system use HTTP, while newly introduced microservices use a different communication protocol, the problem of converting communication protocols between different services needs to be overcome. There are generally two solutions: one is to redevelop all microservices in the entire system based on the new communication protocol; the other is to develop a protocol conversion module or layer to convert between the new and old communication protocols, enabling calls between the new and old services. Solution one has problems such as long development cycles and high costs, while solution two requires protocol conversion on every access, resulting in slow access speeds and potential system crashes.

[0023] In conclusion, the relevant technologies often suffer from the following problems:

[0024] 1. Using the single HTTP protocol for communication requires multiple accesses to achieve communication and data transmission between services, resulting in slow access speeds and a tendency for system crashes.

[0025] 2. When newly introduced microservices are developed using a different communication protocol, it is necessary to overcome the problem of converting communication protocols between different services, which leads to long development cycles and high development costs.

[0026] To address the aforementioned issues, various embodiments of this disclosure provide a dual-protocol microservice bridging system. The system includes: multiple microservice modules that integrate dual-protocol communication capabilities using a first and second communication protocol through a single service code, with the service interface of the service code simultaneously annotated with both the first and second protocol annotations; a dual-protocol engine module, including a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; a service registry center that, through a namespace grouping and isolation mechanism, stores protocol registration information for each microservice module under the first and second communication protocols respectively; and a protocol routing module configured to automatically select a protocol channel matching the protocol type of the calling microservice module based on the protocol registration information, enabling direct interaction between microservice modules using different communication protocols.

[0027] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] Please refer to Figure 1 , Figure 1 This is an exemplary schematic diagram of the architecture of a dual-protocol microservice bridging system according to an embodiment of this disclosure. Figure 1 As shown, the dual-protocol microservice bridging system 100 includes: multiple microservice modules 101, a dual-protocol engine module 102, a service registry center 103, and a protocol routing module 104, wherein:

[0029] Multiple microservice modules 101 integrate dual-protocol communication capabilities of the first and second communication protocols through the same service code, and the service interface of the service code is marked with both the first protocol annotation and the second protocol annotation.

[0030] In this embodiment, microservice module 101 refers to an independent microservice instance in a microservice architecture that undertakes specific business functions. Here, each microservice module 101 has dual-protocol communication capabilities.

[0031] The same service code can mean that the business logic code of each microservice module 101 only needs to be written once. Dual protocol support can be achieved through annotations and dynamic proxies, without the need to develop separate code for the first and second communication protocols.

[0032] Furthermore, the first communication protocol can be the HTTP protocol, and the second communication protocol can be the Triple protocol.

[0033] Here, the Triple protocol is a communication protocol released by Dubbo3 for the cloud-native era; Dubbo is a high-performance distributed service framework that supports multiple communication protocols for remote procedure calls.

[0034] Furthermore, the annotations placed at the service interface location within the same service code refer to protocol identifiers, which declare the communication protocols supported by the service interface.

[0035] Here, by annotating the service interface, the bytecode enhancement technology of the corresponding framework can be triggered, and the framework will automatically generate a proxy class for the corresponding communication protocol based on the annotation.

[0036] For example, for the @RestController annotation associated with the Spring Cloud framework, the Spring Cloud framework generates HTTP protocol proxy logic through byte enhancement technology, enabling the interface to directly respond to HTTP requests. The proxy logic can specifically include: request parsing (such as parsing HTTP request headers and parameters), business method invocation, and HTTP response encapsulation.

[0037] Understandably, the proxy logic corresponding to the two annotations is generated based on the same set of service code, eliminating the need to write separate business implementations for the two protocols. Therefore, after annotating with the first and second protocol annotations, the same service interface can be called via both the HTTP protocol and the Triple protocol.

[0038] The dual-protocol engine module 102 includes a first protocol engine corresponding to a first communication protocol and a second protocol engine corresponding to a second communication protocol.

[0039] In this embodiment, the dual-protocol engine module 102 is the underlying processing component that supports the microservice module 101 to implement dual-protocol communication. Its core function is to connect to the request processing flow of two different communication protocols respectively, so as to ensure that the same service can efficiently respond to calls of different protocols.

[0040] For example, when microservice module 101 receives a request using the HTTP protocol, the first protocol engine is used to parse the request format, schedule business logic, and generate a response corresponding to the protocol; when microservice module 101 receives a request using the Triple protocol, the second protocol engine is used to parse binary data, process call logic, and generate a protocol-adapted response.

[0041] The first protocol engine is a low-level processing engine adapted to the HTTP protocol, and the second protocol engine is a low-level processing engine adapted to the Triple protocol.

[0042] Furthermore, the dual-protocol engine module 102 enables the microservice module 101 to natively handle requests for both protocols without additional protocol conversion steps through the collaborative work of the two engines, thus solving the limitation that a single engine can only support one protocol.

[0043] Furthermore, in the annotations of the service code, the first protocol annotation is used to trigger the initialization and binding of the first protocol engine and to inform the first protocol engine that it needs to handle HTTP protocol requests; the second protocol annotation is used to trigger the initialization and binding of the second protocol engine and to inform the second protocol engine that it needs to handle Triple protocol requests.

[0044] Furthermore, the annotation only declares the protocol types supported by the service through tags; the actual protocol processing capability is implemented by the dual protocol engine module 102.

[0045] Specifically, in the dual-protocol engine module 102, the first protocol engine, based on the declaration of the first protocol annotation, is specifically used to execute the HTTP protocol request processing flow; in the dual-protocol engine module 102, the second protocol engine, based on the declaration of the second protocol annotation, is specifically used to execute the Triple protocol request processing flow.

[0046] Service registry 103 uses a namespace grouping and isolation mechanism to store the protocol registration information of each microservice module under the first communication protocol and the second communication protocol respectively.

[0047] In this embodiment, the configuration files of multiple microservice modules 101 simultaneously configure service registration information for both the HTTP protocol and the Triple protocol.

[0048] Here, service registration information refers to the registration parameter configuration of microservice module 101 locally. It can be used to inform microservice module 101 how to connect to service registry 103, or which protocol to use for registration. For example, service registration information may include, but is not limited to: the address of service registry, protocol representation, protocol engine parameters, etc.

[0049] Furthermore, after startup, microservice module 101 generates a registration request to be sent to service registry 103 by reading service registration information from its local configuration file. Service registry 103 stores the protocol registration information of microservice module 101 based on the registration request.

[0050] Furthermore, the protocol registration information stored in the service registry 103 may include the service address, port, or instance status of the microservice module 101 under the HTTP protocol, or the service address, port, or instance status of the microservice module 101 under the Triple protocol.

[0051] The protocol routing module 104 is configured to automatically select a protocol channel that matches the protocol type of the microservice module that is the caller, based on the protocol registration information, so that microservice modules using different communication protocols can interact directly.

[0052] In this embodiment, when the microservice module acting as the caller only supports the HTTP protocol, the protocol routing module 104 automatically matches the HTTP protocol channel of the target dual-protocol service.

[0053] When the caller is a dual-protocol service and uses the HTTP protocol, the protocol routing module 104 automatically matches the HTTP protocol channel of the target service.

[0054] When the caller is a dual-protocol service and uses the HTTP protocol, the protocol routing module 104 automatically matches the Triple protocol channel of the target service.

[0055] Specifically, microservice modules that only support the HTTP protocol are called old service modules, and microservice modules that support both the HTTP and Triple protocols are called new service modules. When an old service module acts as a caller, the protocol routing module 104 can match the HTTP protocol channel of the target service for the caller. In this case, the first communication protocol channel can come from the HTTP protocol channels of other old or new service modules.

[0056] When a new service module acts as the caller, if the caller uses an HTTP protocol channel, the protocol routing module 104 can match the HTTP protocol channel of the target service for the caller. At this time, the HTTP protocol channel can come from the HTTP protocol channel of the old service module or the new service module.

[0057] If the caller uses the Triple protocol channel, the protocol routing module 104 can match the Triple protocol channel of the target service for the caller. In this case, the Triple protocol channel comes from the Triple protocol channel of the new service module.

[0058] Furthermore, when a microservice module acting as the caller initiates a cross-service call, the protocol routing module 104 receives the call request and obtains whether the caller's protocol type is HTTP or Triple. Based on the target service identifier in the call request, it queries the target service's protocol registration information from the service registry 103. Based on the caller's protocol type, it filters out the matching protocol channel from the queried registration information. Through the matching protocol channel, the caller can directly interact with the target service without any protocol conversion steps.

[0059] Through the dual-protocol microservice bridging system, method, and apparatus of the above embodiments of this disclosure, multiple microservice modules can natively support HTTP and Triple protocols by simultaneously annotating the first protocol and the second protocol at the interface location of the same service code. This eliminates the need to develop two separate sets of code for the two protocols, avoiding unnecessary redundancy, significantly reducing development workload, and directly improving development efficiency. Through the native dual-protocol support of the dual-protocol microservice module, combined with the automatic adaptation of the protocol routing module, new services (dual-protocol) and old services (single-protocol) can interact directly without the need for additional conversion modules or modifications to old services, greatly reducing the development cost of system expansion. The service registry 103 stores dual-protocol information in isolation, and the protocol routing module 104 strictly matches protocol types to avoid call failures caused by protocol incompatibility, ensuring highly reliable communication.

[0060] In one possible implementation of the above embodiments, refer to... Figure 1 ,in:

[0061] The arrow pointing from microservice module 101 to dual-protocol engine module 102 indicates that microservice module 101 exposes service interfaces through dual-protocol engine module 102 and relies on dual-protocol engine 102 to process requests. The arrow pointing from microservice module 101 to service registry 103 indicates that when microservice module 101 starts, it registers its own service information with service registry 103.

[0062] The arrow pointing from the dual-protocol engine module 102 to the protocol routing module 104 indicates that when the dual-protocol engine 102 processes a request, it passes protocol type information (such as HTTP or Triple) to the protocol routing module 104 to assist it in making routing decisions.

[0063] The arrow pointing from the service registry 103 to the protocol routing module 104 indicates that the protocol routing module 104 obtains the list of available services and protocol information from the service registry 103 for dynamic routing. The arrow pointing from the protocol routing module 104 to the microservice module 101 indicates that the protocol routing module 104 routes the request to the corresponding protocol interface of the target microservice based on the protocol type of the request.

[0064] In one possible implementation of the above embodiments, multiple microservice modules 101 annotate the service interface location of the service code with a first protocol annotation based on the Spring Cloud framework, and generate a service interface of the first communication protocol through dynamic proxy;

[0065] Multiple microservice modules 101 annotate the service interface location of the service code with a second protocol annotation based on the Dubbo framework, and generate the service interface of the second communication protocol through dynamic proxy.

[0066] In this embodiment, the first protocol annotation is @Restcontroller based on the Spring Cloud framework, and the second protocol annotation is @DubboService based on the Dubbo framework.

[0067] Correspondingly, multiple microservice modules 101 annotate the service interface location of the service code with @Restcontroller based on the Spring Cloud framework, and generate HTTP protocol service interfaces through dynamic proxies;

[0068] Multiple microservice modules 101 annotate the service interface location in the service code with @DubboService based on the Dubbo framework, and generate service interfaces of the Triple protocol through dynamic proxy.

[0069] Here, the first protocol annotation @Restcontroller is a marker at the Java bytecode level, used to tell the Spring Cloud framework "this interface needs to generate an HTTP protocol service interface", which automatically implements the parsing, routing and response generation of HTTP requests through dynamic proxy, and supports HTTP protocol communication.

[0070] The second protocol annotation, @Dubbo Service, is also a Java bytecode level marker used to inform the Dubbo framework that "this interface needs to generate a service interface of the Dubbo protocol (such as the Triple protocol)". Through dynamic proxy, it automatically implements the decoding of Remote Procedure Call (RPC) requests, interface mapping, and binary response generation, enabling the interface to support high-performance RPC communication in the Dubbo ecosystem.

[0071] Furthermore, dynamic proxy refers to the technology by which a framework dynamically generates proxy classes based on annotations when the service starts.

[0072] Microservice module 101 generates HTTP protocol service interfaces and Triple protocol service interfaces through dynamic proxy.

[0073] Here, the HTTP protocol service interface is an interface generated by a dynamic proxy triggered by the @RestController annotation, adapted to the Spring Cloud framework, and supports HTTP protocol request interactions. Similarly, the Triple protocol service interface is an interface generated by a dynamic proxy triggered by the @DubboService annotation, adapted to the Dubbo framework, and supports RPC interactions for Dubbo protocols (such as the Triple protocol).

[0074] For example, when an HTTP request arrives, the HTTP proxy class calls the implementation class of the service interface (i.e., the business logic instance), and returns an HTTP response through the Spring Cloud engine after processing; when an RPC request of the Triple protocol arrives, the Triple proxy class calls the implementation class of the same service interface and returns a binary response through the Dubbo engine.

[0075] This ensures that the service interfaces of both protocols reuse the same set of business logic, avoiding code redundancy and preventing logical conflicts between proxy classes.

[0076] The dual-protocol microservice bridging system, method, and apparatus of the above embodiments of this disclosure automatically generate HTTP and Triple protocol service interfaces by using the @RestController and @DubboService annotations on the same service interface, combined with dynamic proxy technology. This allows a single set of business logic to support interaction between the two protocols simultaneously. There is no need to develop separate interfaces or business code for the two protocols, significantly improving development efficiency and reducing development costs. The dual-protocol interface design enables new service modules to interact with legacy services that only support HTTP via the HTTP interface, and to communicate efficiently with other new services via the Triple interface. This allows for a smooth system transition without modifying legacy services, ensuring seamless compatibility between the old and new systems and reducing system expansion costs.

[0077] In one possible implementation of the above embodiments, the first protocol engine is a lightweight web container optimized for IO threads, and the thread model of the first protocol engine satisfies:

[0078] The number of I / O threads is equal to the current number of CPU cores, and the number of worker threads is equal to a preset multiple of the current number of CPU cores;

[0079] The second protocol engine is an asynchronous communication framework based on a fixed-thread model. The thread pool of the second protocol engine satisfies the following:

[0080] When the service starts, a fixed number of threads are initialized; the fixed number is the upper limit of the thread pool.

[0081] In this embodiment, the first protocol engine is the underlying processing engine that supports the HTTP protocol. It is a lightweight web container that can achieve performance optimization through fine-grained configuration of IO threads and worker threads, and is adapted to the HTTP protocol interaction of the Spring Cloud framework.

[0082] Here, the IO thread is used to handle network IO operations (such as receiving HTTP requests and sending HTTP responses) and does not participate in business logic processing. Setting the number of IO threads to be equal to the current number of CPU cores can reduce thread context switching overhead and maximize the utilization of CPU resources.

[0083] Worker threads are used to handle business logic processing. Setting the number of worker threads to a preset multiple of the current number of CPU cores can ensure that business logic processing does not block I / O threads.

[0084] Here, the preset multiplier can be dynamically adjusted according to the complexity of the business. For example, the preset multiplier can be 200.

[0085] Furthermore, the first protocol engine can be the Undertow engine, the Ttomcat engine, the Jjetty engine, or the Ggrizzly engine.

[0086] The second protocol engine is the underlying processing engine that supports the Triple protocol and belongs to the asynchronous communication framework.

[0087] Here, a fixed number of threads are initialized when the service starts (this number is the upper limit of the thread pool and cannot be dynamically expanded), and the thread model is marked as "fixed".

[0088] Here, the thread model is marked as "fixed", which represents a fixed thread model, that is, a thread management mode in which the number of threads in the second protocol engine is fixed at startup and does not increase or decrease during operation.

[0089] Furthermore, the second protocol engine can be the Netty engine, MINA engine, Vert.x engine, or QuickServer engine.

[0090] Understandably, by configuring the first and second protocol engines as described above, the thread pool ramp-up phenomenon can be avoided, that is, resource contention caused by the dynamic creation of threads in the thread pool during high traffic can be avoided.

[0091] Through the dual-protocol microservice bridging system, method, and apparatus of the above embodiments of this disclosure, the first protocol engine, through the configuration of separating IO threads and worker threads, completely decouples IO operations from business logic processing, ensuring that business processing does not block the IO process, maximizing the utilization of CPU resources, and improving the processing efficiency of the HTTP protocol. The second protocol engine adopts a fixed-thread model, avoiding resource contention caused by dynamic thread creation / destruction, reducing performance fluctuations caused by thread pool expansion under high traffic, and adapting to the high-performance RPC communication requirements of the Triple protocol. For microservice scenarios where HTTP and Triple protocols coexist, the optimized configuration of the two types of engines ensures efficient collaboration of the same business logic during dual-protocol interaction, reusing code and avoiding protocol processing conflicts, reducing the complexity of multi-protocol maintenance.

[0092] In one possible implementation of the above embodiments, the namespace grouping isolation mechanism of the service registry is implemented through the Group of the Nacos registry, wherein:

[0093] The service registry stores the protocol registration information of microservice modules under the first communication protocol through the first group; wherein, the protocol registration information includes at least one of the following: service name, IP address, port number or protocol type;

[0094] The service registry stores the protocol registration information of microservice modules under the second communication protocol through the second group; wherein the first group and the second group are isolated from each other.

[0095] In this embodiment, a first group and a second group are set in the Nacos registry.

[0096] Here, the Group in the Nacos registry is a logically isolated unit, and the protocol registration information stored in different Groups is completely independent.

[0097] For example, when registering the first group corresponding to the HTTP protocol, the registration configuration method can be: spring:

[0098] cloud:

[0099] nacos:

[0100] discovery:

[0101] server-addr: localhost:8848.

[0102] Here, "spring" is the root configuration node of the Spring framework, and all Spring-related configurations are nested under this node; "cloud" is the configuration node for the Spring Cloud ecosystem, used to configure cloud-native features related to microservices; "nacos" is used to specify that Nacos is used as the service registry and configuration center; "discovery" is used to specifically configure the "service discovery" function; "server-addr: localhost:8848" is the core configuration item, used to specify the address and port of the Nacos service registry.

[0103] Furthermore, when microservice module 101 starts, it reads the above configuration and performs the following operations:

[0104] The microservice connects to the local Nacos service registry based on "server-addr"; it automatically registers its own service information with Nacos; and subsequently obtains the registration information of other microservice modules 101 in real time through Nacos to achieve cross-service calls.

[0105] In addition, microservice module 101 is also used to periodically send "heartbeats" to Nacos to maintain the registration status. If Nacos does not receive a heartbeat for a long time, it will mark the service as offline to prevent other services from calling invalid nodes.

[0106] When registering the second group corresponding to the Triple protocol, the registration configuration method can be:

[0107] dubbo:

[0108] protocol:

[0109] name: tri

[0110] port: -1

[0111] threadpool: fixed

[0112] threads: 2000

[0113] registry:

[0114] address: nacos: / / localhost:8848

[0115] group: dubbo

[0116] config-center:

[0117] address: nacos: / / localhost:8848

[0118] metadata-report:

[0119] address: nacos: / / localhost:8848.

[0120] Among them, "dubbo.protocol" is used to define the communication protocol and underlying thread model used by Dubbo services.

[0121] Specifically, "name: tri" specifies the Triple protocol; "port: -1" indicates that an unused port will be automatically and randomly assigned at startup, and the actual assigned port will be recorded when registering with Nacos for callers to obtain through service discovery; "threadpool: fixed" specifies the thread pool type as "fixed"; and "threads: 2000" configures the number of threads in the fixed thread pool to be 2000.

[0122] Furthermore, "dubbo.registry" specifies which service registry center Dubbo services should register with; specifically, "address: nacos: / / localhost:8848" specifies Nacos as the service registry center, sharing the same Nacos node as Spring Cloud to ensure that dual-protocol services are registered with the same registry center; "group: dubbo" specifies that the service is grouped as dubbo in Nacos, used for logical isolation between Dubbo services (Triple protocol) and Spring Cloud services (HTTP protocol) within Nacos; "config-center.address: nacos: / / localhost:8848" specifies Nacos as the configuration center for Dubbo, used to store the dynamic configuration of Dubbo services. The latest configuration is pulled from Nacos when the service starts, and can be dynamically updated without restarting the service; "metadata-report:address: nacos: / / localhost:8848" specifies Nacos as the metadata reporting address, used to store the metadata of Dubbo services. When other services call the Triple protocol service, they first obtain metadata from Nacos to ensure that the parameter parsing and interface mapping of the RPC call are accurate.

[0123] Understandably, Nacos' namespace grouping and isolation mechanism separates the registration information of Spring Cloud (HTTP) and Dubbo (Triple) by making the logical spaces independent. This ensures that the protocol routing module can accurately match the channel and supports the independent operation and maintenance and performance optimization of dual-protocol services. It is the underlying data isolation guarantee for realizing dual-protocol communication of the same service code.

[0124] Through the dual-protocol microservice bridging system, method and dual-protocol microservice device of the above embodiments of this disclosure, the registration information of the two types of protocols is completely isolated in Nacos. When the protocol routing module 104 queries, it can accurately locate the corresponding Group according to the protocol type of the caller, avoiding incorrect calls caused by mixed information, and also preventing information interaction conflicts under high concurrency.

[0125] Further reference Figure 2 , Figure 2 This is a flowchart illustrating a dual-protocol microservice bridging method provided in this embodiment, applied to the above-mentioned... Figure 1 In the dual-protocol microservice bridging system 100 shown, the method may include the following steps:

[0126] Step S201: Simultaneously annotate the service interface of the microservice module with both the first protocol annotation and the second protocol annotation, and enable the same service code to have dual protocol communication capabilities of the first and second communication protocols through dynamic proxy.

[0127] Step S202: Through the dual-protocol engine module, bind the corresponding first protocol engine to the first communication protocol and configure a thread optimization strategy for high-concurrency scenarios, and bind the corresponding second protocol engine to the second communication protocol and configure a thread optimization strategy with a fixed thread model.

[0128] Step S203: Register the protocol registration information of the microservice modules under the first communication protocol and the second communication protocol respectively through the namespace grouping and isolation mechanism of the service registry.

[0129] Step S204: In response to the request from the microservice module acting as the caller, the target microservice module is matched based on the protocol registration information of the service registry, and the protocol channel that matches the protocol type of the caller is automatically selected, so that microservice modules using different communication protocols can interact directly.

[0130] The dual-protocol microservice bridging system, method, and apparatus of the above embodiments of this disclosure enable the same service code to have dual-protocol communication capabilities under both the first and second communication protocols. By utilizing the namespace grouping and isolation mechanism of the service registry, and registering the protocol registration information of microservice modules under the first and second communication protocols respectively, the problems of restricted access between new and old protocol microservices, as well as slow access speed and low efficiency based on separately developed protocol conversion modules, are solved. This allows for rapid development of dual-protocol microservices, microservice architectures, and dual-protocol service systems with minimal development effort, significantly improving development efficiency while reducing development costs.

[0131] In one possible implementation of the above embodiments, a dual-protocol engine module is used to bind a corresponding first protocol engine to the first communication protocol and configure a thread optimization strategy for high-concurrency scenarios, and to bind a corresponding second protocol engine to the second communication protocol and configure a thread optimization strategy with a fixed thread model, including:

[0132] The dual-protocol engine module uses a lightweight container optimized for IO threads as the first protocol engine, binds the first communication protocol to the corresponding first protocol engine, configures the number of IO threads of the first protocol engine to the current number of CPU cores, and configures the number of worker threads of the first protocol engine to the current number of CPU cores by a preset multiple; wherein, the first protocol engine is the Undertow engine, Ttomcat engine, Jjetty engine, or Ggrizzly engine.

[0133] The dual-protocol engine module uses the asynchronous communication framework of the fixed-thread model as the second protocol engine, binds the corresponding second protocol engine to the second communication protocol, and initializes the number of threads to a fixed number when the service starts. The fixed number is the upper limit of the thread pool, and the second protocol engine can be the Netty engine, MINA engine, Vert.x engine, or QuickServer engine.

[0134] The dual-protocol microservice bridging system, method, and apparatus of the above embodiments of this disclosure, through the refined design of the thread model, ensure high-performance operation of dual protocols while avoiding resource waste and protocol conflicts, providing stable and reliable underlying support for complex microservice architectures.

[0135] In one specific embodiment, please refer to Figure 3 , Figure 3 This is an exemplary schematic diagram of another dual-protocol microservice bridging system architecture according to an embodiment of this disclosure. Figure 3 As shown, the dual-protocol microservice bridging system 300 includes: multiple microservice modules 301, a communication framework 302, a service registry 303, a configuration center 304, a monitoring module 305, and a rate limiting and degradation module 306, wherein:

[0136] Microservice module 301 is the microservice module 101 included in the aforementioned dual-protocol microservice bridging system 100.

[0137] Communication framework 302 is used to manage the first protocol engine and the second protocol engine, and to implement the parsing, encapsulation and forwarding of the two protocols.

[0138] In this embodiment, the communication framework 302 includes a load balancing module 3021; ​​wherein, the load balancing module 3021 allocates the address and port number of the specific service provider according to the load balancing algorithm, thereby solving the problem of network waiting and long request response time caused by different server loads.

[0139] Furthermore, the load balancing algorithm adopts the load balancing algorithms built into the Spring Cloud protocol and the Dubbo protocol. Specifically, the load balancing algorithms include, but are not limited to: round-robin algorithm, weighted round-robin algorithm, least connections algorithm, and hash algorithm.

[0140] Configuration Center 304 is used to store system-level and service-level configuration information. It can use Nacos, a SaaS product provided by Alibaba Cloud MSE.

[0141] The monitoring module 305 is used to monitor key indicators of dual-protocol communication in real time, and can adopt the cloud-native application real-time monitoring service (ARMS) product.

[0142] The rate limiting and degradation module 306 is used to limit the number of requests per unit time in high-concurrency scenarios with dual protocols. It can adopt cloud-native microservices engine (MSE) service governance center, Alibaba Cloud's MSE service governance center, Huawei Cloud's Cloud Service Engine (CSE) service governance center, Tencent Cloud's Service Governance Center (SGC), Volcano Engine's MSE service governance center, etc.

[0143] In one possible implementation of the above embodiments, refer to... Figure 3 ,in:

[0144] The bidirectional arrow between the microservice module 301 and the communication framework 302 indicates that the service module 301 exposes a dual-protocol interface through the communication framework 302 and relies on the protocol engine of the communication framework 302 to handle request parsing and response encapsulation; the communication framework 302 distributes requests to the microservice module 301 through the load balancing module 3021.

[0145] The arrow pointing from microservice module 301 to service registry 303 indicates that when a microservice starts, it registers its own service information with service registry 303; service registry 303 then registers HTTP and Triple protocol information to different namespaces.

[0146] The arrow pointing from the service registry 303 to the communication framework 302 indicates that the load balancing module 3021 periodically obtains the latest service list from the service registry 303 and dynamically selects target service instances based on algorithms such as round-robin and weighted round-robin.

[0147] The arrows pointing from the configuration center 304 to the microservice module 301, the communication framework 302, and the rate limiting and degradation module 306 indicate that the configuration center 304 pushes business configurations to the microservice module 301, pushes protocol engine parameters to the communication framework 302, and pushes rules to the rate limiting and degradation module 306.

[0148] The arrow pointing from the microservice module 301 and the communication framework 302 to the monitoring module 305 indicates that the monitoring module 305 collects business metrics from the microservice module 301 and protocol layer metrics from the communication framework 302.

[0149] The bidirectional arrow between the communication framework 302 and the rate limiting and degradation module 306 indicates that the communication framework 302 transmits real-time traffic data to the rate limiting and degradation module 306. According to the rules of the configuration center 304, when the traffic exceeds the threshold, the rate limiting and degradation module 306 intercepts the request through the communication framework 302.

[0150] In one specific embodiment, please refer to Figure 4 , Figure 4 This is a schematic diagram illustrating a specific application of the architecture of a dual-protocol microservice bridging system according to an embodiment of this disclosure. For example... Figure 4 As shown, the microservice architecture of the dual-protocol microservice bridging system 100 includes newly developed business services A, B, and C that communicate based on the Triple protocol and the HTTP protocol, as well as the original business services D and E that communicate based on the single HTTP protocol.

[0151] The development methods for business services A, B, and C are identical. All three utilize the `@Restcontroller` annotation in their code to dynamically proxy the HTTP protocol, and the `@Dubble service` bytecode enhancement technology to dynamically proxy the Triple protocol using the open-source framework, enabling dual-protocol communication using both HTTP and Triple protocols. The configuration files for business services A through C contain both Spring Cloud and Dubbo service registration files, and also configure the REST protocol engine and the Netty engine.

[0152] When users access the microservice architecture described above, they can directly input business services A and D using the common HTTP protocol. Business services A and D can then make internal service calls using the Triple protocol and HTTP, respectively. For example, if a user accesses business service A via HTTP, service A can interact with services B and C using the Triple protocol, and with services D and E using HTTP. Similarly, when the existing service E needs to call the newly developed dual-protocol service B, communication can be achieved directly via HTTP. Microservices within the entire microservice architecture can directly access each other based on their own communication protocols, without requiring a protocol conversion module to perform protocol conversion before making calls.

[0153] It should be noted that the dual-protocol microservice bridging system provided in the above embodiments is only illustrated by the division of the above program modules when implementing the corresponding dual-protocol microservice bridging method. In practical applications, the above processing can be assigned to different program modules as needed, that is, the internal structure of the above system can be divided into different program modules to complete all or part of the processing described above. In addition, the system provided in the above embodiments and the corresponding Figure 2 The embodiments of the methods shown belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0154] In one specific embodiment, please refer to Figure 5 , Figure 5 This is an exemplary schematic diagram of the architecture of a dual-protocol microservice device according to an embodiment of this disclosure. Figure 5 As shown, the dual-protocol microservice device 500 includes: a service interface module 501, an engine configuration module 502, and a registration isolation module 503, wherein:

[0155] Service interface module 501 is annotated with the first protocol annotation based on the Spring Cloud framework and the second protocol annotation based on the Dubbo framework, and the service interface of the first communication protocol and the second communication protocol is generated through dynamic proxy.

[0156] Engine configuration module 502 binds the first protocol engine and the second protocol engine;

[0157] The registration isolation module 503 stores the registration information of the microservice under the first communication protocol in the first group and the registration information under the second communication protocol in the second group through the namespace grouping isolation mechanism of the service registry.

[0158] In one possible implementation of the above embodiments, the number of IO threads of the first protocol engine is configured to be equal to the number of processor cores, the number of worker threads is configured to be N times the number of processor cores, and the thread pool of the second protocol engine initializes a fixed number of threads when the service starts.

[0159] This disclosure also provides an electronic device having the above-described features. Figure 1 Or any of the dual-protocol microservice bridging systems shown in option 3, and systems with the above-mentioned features. Figure 5 The architecture of the dual-protocol microservice device is shown.

[0160] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of another dual-protocol microservice bridging system provided in this disclosure embodiment, as shown below. Figure 6 As shown, the electronic device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise as required. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 6 Take a processor 10 as an example.

[0161] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0162] The memory 20 stores instructions executable by at least one processor 10 to cause at least one processor 10 to perform the method shown in the above embodiments.

[0163] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0164] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0165] The electronic device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0166] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., LEDs), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touch screen.

[0167] The electronic device also includes a communication interface for communicating with other devices or communication networks.

[0168] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded over a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium may be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0169] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0170] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A dual-protocol microservice bridging system, characterized in that, The system includes: Multiple microservice modules integrate dual-protocol communication capabilities of a first communication protocol and a second communication protocol through the same service code, and the service interface of the service code is marked with both the first protocol annotation and the second protocol annotation; The dual-protocol engine module includes a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; The service registry, through a namespace grouping and isolation mechanism, stores the protocol registration information of each microservice module under the first communication protocol and the second communication protocol respectively; The protocol routing module is configured to automatically select a protocol channel that matches the protocol type of the microservice module acting as the caller, based on the protocol registration information, so that microservice modules using different communication protocols can interact directly.

2. The system according to claim 1, characterized in that, The multiple microservice modules annotate the service interface location of the service code with a first protocol annotation based on the Spring Cloud framework, and generate the service interface of the first communication protocol through dynamic proxy. The multiple microservice modules annotate the service interface locations of the service code with a second protocol annotation based on the Dubbo framework, and generate the service interface of the second communication protocol through dynamic proxy.

3. The system according to claim 1 or 2, characterized in that, The first protocol engine is a lightweight web container optimized for IO threads, and its thread model satisfies: The number of I / O threads is equal to the current number of CPU cores, and the number of worker threads is equal to a preset multiple of the current number of CPU cores; The second protocol engine is an asynchronous communication framework with a fixed-thread model. The thread pool of the second protocol engine satisfies the following: When the service starts, a fixed number of threads are initialized; wherein, the fixed number is the upper limit of the thread pool.

4. The system according to claim 3, characterized in that, The first protocol engine is the Undertow engine, Tomcat engine, Jetty engine, or Grizzly engine, and the second protocol engine is the Netty engine, MINA engine, Vert.x engine, or QuickServer engine.

5. The system according to claim 4, characterized in that, The namespace grouping isolation mechanism of the service registry is implemented through the Group of the Nacos registry, where: The service registry stores the protocol registration information of the microservice module under the first communication protocol through a first group; wherein the protocol registration information includes at least one of the following: service name, IP address, port number or protocol type; The service registry stores the protocol registration information of the microservice module under the second communication protocol through the second group; wherein the first group and the second group are isolated from each other.

6. A dual-protocol microservice bridging method, applied to the dual-protocol microservice bridging system according to any one of claims 1-5, characterized in that, The method includes: The service interface of the microservice module is marked with both the first protocol annotation and the second protocol annotation. Dynamic proxy enables the same service code to have dual protocol communication capabilities of the first and second communication protocols. The dual-protocol engine module binds the first communication protocol to the corresponding first protocol engine and configures a thread optimization strategy for high-concurrency scenarios, and binds the second communication protocol to the corresponding second protocol engine and configures a thread optimization strategy with a fixed thread model. The service registry uses a namespace grouping and isolation mechanism to register the protocol registration information of microservice modules under the first communication protocol and the second communication protocol, respectively. In response to a request from a microservice module acting as a caller, the system matches the target microservice module based on the protocol registration information in the service registry and automatically selects a protocol channel that matches the protocol type of the caller, enabling microservice modules using different communication protocols to interact directly.

7. The method according to claim 6, characterized in that, The method of binding a corresponding first protocol engine to the first communication protocol and configuring a thread optimization strategy for high-concurrency scenarios, and binding a corresponding second protocol engine to the second communication protocol and configuring a thread optimization strategy with a fixed thread model, through the dual-protocol engine module, includes: The dual-protocol engine module uses a lightweight container optimized for IO threads as the first protocol engine, binds the first protocol engine to the first communication protocol, configures the number of IO threads of the first protocol engine to the current number of CPU cores, and configures the number of worker threads of the first protocol engine to a preset multiple of the current number of CPU cores; wherein, the first protocol engine is an Undertow engine, Tomcat engine, Jetty engine, or Grizzly engine. The dual-protocol engine module uses the asynchronous communication framework of the fixed-thread model as the second protocol engine, binds the corresponding second protocol engine to the second communication protocol, and initializes the number of threads to a fixed number when the service starts; wherein, the fixed number is the upper limit of the thread pool, and the second protocol engine is the Netty engine, MINA engine, Vert.x engine or QuickServer engine.

8. A dual-protocol microservice device, characterized in that, The device includes: The service interface module is used to integrate dual-protocol communication capabilities of the first communication protocol and the second communication protocol through the same service code. The service interface position of the same service code is simultaneously marked with the first protocol annotation based on the Spring Cloud framework and the second protocol annotation based on the Dubbo framework, and the service interfaces of the first communication protocol and the second communication protocol are generated through dynamic proxy. The engine configuration module is used to bind the first protocol engine and the second protocol engine; The registration isolation module is used to store the registration information of the microservice under the first communication protocol in the first group and the registration information under the second communication protocol in the second group through the namespace grouping isolation mechanism of the service registry.

9. The dual-protocol microservice according to claim 8, characterized in that, The number of IO threads in the first protocol engine is configured to be equal to the number of processor cores, and the number of worker threads is configured to be N times the number of processor cores. The thread pool of the second protocol engine initializes a fixed number of threads when the service starts.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the dual-protocol microservice bridging method as described in any one of claims 6 or 7 when executing the computer program.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the dual-protocol microservice bridging method as described in any one of claims 6 or 7.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the dual-protocol microservice bridging method as described in any one of claims 6 or 7.

Images