Dual-protocol micro-service bridging system and method and dual-protocol micro-service device

Abstract

The invention relates to the technical field of software architecture, and discloses a dual-protocol micro-service bridging system and method and a dual-protocol micro-service device, and the system comprises a plurality of micro-service modules which integrate the dual-protocol communication capabilities of a first communication protocol and a second communication protocol through the same service code; the dual-protocol engine module comprises a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; the service registration center is used for respectively storing protocol registration information of each micro-service module under the first communication protocol and the second communication protocol through a namespace grouping isolation mechanism; and the protocol routing module enables the micro-service modules adopting different communication protocols to directly interact. By marking the first annotation and the second annotation on the same code, the processing of the first communication protocol and the second communication protocol can be originally supported without developing two sets of independent codes, so that unnecessary redundant work is avoided, the development amount is remarkably reduced, and the development efficiency is directly improved.

Description

Technical Field

[0001] The present invention relates to the technical field of software architecture, and in particular to a dual-protocol microservice bridging system, method, and dual-protocol microservice device. Background Art

[0002] By breaking down software systems into independently deployed microservices based on business functions and using interfaces to transfer data between services, the microservices architecture offers advantages such as low coupling, good fault isolation, easy maintenance, and strong scalability. The interaction and communication between microservices plays a key role in influencing system stability, responsiveness, and operational efficiency.

[0003] However, some related technologies use a single Hypertext Transfer Protocol (HTTP) for communication. When developing new services using a new protocol, existing services must be redeveloped or interoperable through protocol conversion modules, often leading to long development cycles and high costs. Therefore, how to enable microservice architectures to handle dual protocols within the same service code, thereby improving development efficiency and reducing costs, has become a pressing issue. Summary of the Invention

[0004] In view of this, the present invention provides a dual-protocol microservice bridging system, method and dual-protocol microservice device to solve the problem of how to enable the microservice architecture to have dual-protocol processing capabilities based on the same service code, thereby improving development efficiency and reducing development costs.

[0005] On the one hand, the present disclosure provides a dual-protocol microservice bridging system, which includes: multiple microservice modules, which integrate the dual-protocol communication capabilities of a first communication protocol and a second communication protocol through the same service code, and the service interface position of the service code is annotated with the first protocol annotation and the second protocol annotation at the same time; 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 registration center, which stores the protocol registration information of each microservice 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 that matches the protocol type of the microservice module as the caller based on the protocol registration information, so that microservice modules using different communication protocols can interact directly.

[0006] On the other hand, the present disclosure also provides a dual-protocol microservice bridging method, which includes: simultaneously marking the first protocol annotation and the second protocol annotation at the service interface position of the microservice module, and enabling the same service code to have dual-protocol communication capabilities of the first communication protocol and the second communication protocol through dynamic proxy; through the dual-protocol engine module, binding the corresponding first protocol engine to the first communication protocol and configuring a thread optimization strategy for high concurrency scenarios, and binding the corresponding second protocol engine to the second communication protocol and configuring a thread optimization strategy for a fixed thread model; through the namespace grouping isolation mechanism of the service registration center, registering the protocol registration information of the microservice module under the first communication protocol and the second communication protocol respectively; in response to the request of the microservice module as the caller, matching the target microservice module based on the protocol registration information of the service registration center, and automatically selecting the protocol channel that matches the protocol type of the caller, so that microservice modules using different communication protocols can interact directly.

[0007] On the other hand, the present disclosure also provides a dual-protocol microservice device, including: a service interface module, which simultaneously annotates the first protocol annotation based on the Spring Cloud framework and the second protocol annotation based on the Dubbo framework, and generates service interfaces of the first communication protocol and the second communication protocol through dynamic proxy; an engine configuration module, which binds the first protocol engine and the second protocol engine, the number of IO threads of the first protocol engine is configured to be equal to the number of processor cores, the number of working 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; a registration isolation module, which 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 group isolation mechanism of the service registration center.

[0008] On the other hand, the present disclosure further provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the above-mentioned dual-protocol microservice bridging method when executing the computer program.

[0009] On the other hand, the present disclosure further provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to implement the above-mentioned dual-protocol microservice bridging method.

[0010] On the other hand, the present disclosure further provides a computer program product, including computer instructions, which are used to enable a computer to execute the above-mentioned dual-protocol microservice bridging method.

[0011] Through the dual-protocol microservice bridging system, method and dual-protocol microservice device of the above-mentioned embodiments of the present disclosure, multiple microservice modules can natively support the processing of the first communication protocol and the second communication protocol by simultaneously marking the first protocol annotation and the second protocol annotation at the interface position of the same service code, without the need to develop two independent sets of code for the two protocols, thereby avoiding unnecessary redundant work, significantly reducing the development workload, and directly improving development efficiency.

[0012] In addition, through the native dual-protocol support of the dual-protocol microservice module and the automatic adaptation of the protocol routing module, new services (dual-protocol) and old services (single-protocol) can interact directly without the need to develop additional conversion modules or transform old services, greatly reducing the development cost of system expansion. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the following briefly introduces the drawings required for use in the specific embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0014] Figure 1 is an exemplary schematic diagram of the architecture of a dual-protocol microservice bridging system according to an embodiment of the present disclosure; Figure 2 This is a flow chart of a dual-protocol microservice bridging method provided by an embodiment of the present disclosure; Figure 3 is an exemplary schematic diagram of the architecture of another dual-protocol microservice bridging system according to an embodiment of the present disclosure; Figure 4 This is a specific application diagram of the architecture of a dual-protocol microservice bridging system according to an embodiment of the present disclosure; Figure 5 is an exemplary schematic diagram of the architecture of a dual-protocol microservice device according to an embodiment of the present disclosure; Figure 6 This is a structural diagram of another dual-protocol microservice bridging system provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0015] A microservices architecture is a software system architecture that breaks down a software system into multiple independently deployed and run microservices, based on business functions. Microservices communicate and transmit data through interfaces, maintaining independence from each other. This architecture offers advantages such as low system coupling, excellent fault isolation, ease of updating and maintenance, and strong scalability. The interaction and communication between microservices in a microservices architecture significantly impacts the stability, responsiveness, and operational efficiency of the entire microservices architecture.

[0016] Due to the high versatility of the HTTP protocol, some microservice architectures in related technologies are developed using the HTTP communication protocol. The HTTP protocol is used between the client and the entire service system, as well as between the microservices within the service system. Data structures and interfaces for specific languages ​​are generated through the Feign interface. When a single HTTP protocol is used for interaction between the system and microservices, three handshakes and four handshakes are required. The access process adopts a request-response model, and the request transmission must include a request header + request line + request body. Because the request header + request line format is fixed and the volume is large, no matter how small the request body data is, the request header and request body must be carried. This will result in a larger content being occupied when transmitting the request. The response model has the same problem. No matter how small the memory of the response body is, the request header and request body must be carried. As a result, when there are a large number of accessing users, the entire system runs slowly, and there is also the problem of downtime.

[0017] Furthermore, using a single HTTP protocol for communication will also limit the further development and expansion of the entire software system. For example, if the microservices of an existing system use the HTTP protocol for communication, and a newly introduced microservice business is developed using another communication protocol, it is necessary to overcome the problem of converting the communication protocols between different services. There are generally two solutions to this problem. One is to redevelop all microservices of the entire system based on the new communication protocol; the other is to convert the new communication protocol to the old communication protocol by developing a protocol conversion module or protocol conversion layer to enable calls between the new and old services. Solution 1 has problems such as long development cycles and high costs. Solution 2 requires protocol conversion for each access, resulting in slow access speeds and prone to downtime.

[0018] After summarizing, it is concluded that related technologies often have the following problems: 1. Using HTTP as a single protocol for communication requires multiple visits to achieve communication and data transmission between services, resulting in slow access speeds and prone to system crashes.

[0019] 2. When a newly introduced microservice business is developed using another communication protocol, it is necessary to overcome the problem of converting communication protocols between different services, resulting in a long development cycle and high development costs.

[0020] To solve the above problems, various embodiments of the present disclosure provide a dual-protocol microservice bridging system, which includes: multiple microservice modules, which integrate the dual-protocol communication capabilities of the first communication protocol and the second communication protocol through the same service code, and the service interface position of the service code is annotated with the first protocol annotation and the second protocol annotation at the same time; 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 registration center, which stores the protocol registration information of each microservice module under the first communication protocol and the second communication protocol respectively through a namespace grouping isolation mechanism; a protocol routing module, which is configured to automatically select a protocol channel that matches the protocol type of the microservice module as the caller based on the protocol registration information, so that microservice modules using different communication protocols can interact directly.

[0021] To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present disclosure.

[0022] 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 the present 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 registration center 103 and a protocol routing module 104, wherein: Multiple microservice modules 101 integrate dual-protocol communication capabilities of the first communication protocol and the second communication protocol through the same service code, and the service interface position of the service code is marked with both the first protocol annotation and the second protocol annotation.

[0023] In this embodiment, the microservice module 101 refers to an independent microservice instance in the microservice architecture for undertaking specific business functions. Here, each microservice module 101 has dual-protocol communication capabilities.

[0024] The same service code may mean that only one set of business logic code needs to be written for each microservice module 101, and dual-protocol support can be achieved through annotations and dynamic proxies, without the need to develop code separately for the first communication protocol and the second communication protocol.

[0025] Furthermore, the first communication protocol may be the HTTP protocol, and the second communication protocol may be the Triple protocol.

[0026] Here, 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.

[0027] Furthermore, the annotation marked at the service interface position of the same service code refers to the protocol identification tag, which is used to declare the communication protocol supported by the service interface.

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

[0029] For example, for the @RestController annotation associated with the Spring Cloud framework, the Spring Cloud framework uses byte enhancement technology to generate HTTP protocol proxy logic, 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, HTTP response encapsulation, etc.

[0030] It is understandable that 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 the first and second protocol annotations, the same service interface can be called via both HTTP and Triple protocols.

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

[0032] 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 can be to connect to the request processing processes of the two communication protocols respectively to ensure that the same service can efficiently respond to calls from different protocols.

[0033] For example, when the microservice module 101 receives a request for the HTTP protocol, the first protocol engine is used to parse the request format, schedule business logic, generate a response for the corresponding protocol, etc.; when the microservice module 101 receives a request for the Triple protocol, the second protocol engine is responsible for parsing binary data, processing call logic, generating a response adapted to the protocol, etc.

[0034] Among them, the first protocol engine is an underlying processing engine adapted to the HTTP protocol, and the second protocol engine is an underlying processing engine adapted to the Triple protocol.

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

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

[0037] Furthermore, the annotation only declares the protocol types supported by the service through marking, and the actual protocol processing capability is implemented by the dual-protocol engine module 102.

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

[0039] The service registration center 103 stores the protocol registration information of each microservice module under the first communication protocol and the second communication protocol respectively through the namespace grouping isolation mechanism.

[0040] In this embodiment, the configuration files of the multiple microservice modules 101 are configured with service registration information of both HTTP protocol and Triple protocol.

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

[0042] Furthermore, after startup, the microservice module 101 reads the service registration information in the local configuration file to generate a registration request to be sent to the service registration center 103. The service registration center 103 stores the protocol registration information of the microservice module 101 based on the registration request.

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

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

[0045] In this embodiment, when the microservice module 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.

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

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

[0048] Specifically, a microservice module that only supports the HTTP protocol is referred to as an old service module, and a microservice module that supports both the HTTP protocol and the Triple protocol is referred to as a new service module. When an old service module is the caller, the protocol routing module 104 can match the caller with an HTTP protocol channel of the target service. In this case, the first communication protocol channel can come from the HTTP protocol channel of another old service module or the new service module.

[0049] When the new service module is the caller, if the caller uses the HTTP protocol channel, the protocol routing module 104 can match the HTTP protocol channel of the target service for the caller. The HTTP protocol channel at this time can come from the HTTP protocol channel of the old service module or the new service module.

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

[0051] Furthermore, when the microservice module as the caller initiates a cross-service call, the protocol routing module 104 receives the call request and obtains the caller's protocol type as HTTP protocol or Triple protocol; according to the target service identifier in the call request, the protocol registration information of the target service is queried from the service registration center 103; based on the caller's protocol type, a matching protocol channel is filtered out from the queried registration information; through the matching protocol channel, the caller interacts directly with the target service without any protocol conversion steps.

[0052] Through the dual-protocol microservice bridging system, method, and dual-protocol microservice device of the above-mentioned embodiments of the present disclosure, multiple microservice modules can natively support the processing of HTTP protocol and Triple protocol by simultaneously marking the first protocol annotation and the second protocol annotation at the interface position of the same service code, without the need to develop two independent sets of code for the two protocols, thereby avoiding unnecessary redundant work, significantly reducing the 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, the new service (dual protocol) and the old service (single protocol) can interact directly without the need for additional development of conversion modules or transformation of old services, greatly reducing the development cost of system expansion. The service registration center 103 stores the dual-protocol information in isolation, and the protocol routing module 104 strictly matches the protocol type to avoid call failures caused by protocol incompatibility and ensure highly reliable communication.

[0053] In a possible implementation of the above embodiment, continue to refer to Figure 1 ,in: The arrow from microservice module 101 to dual-protocol engine module 102 indicates that microservice module 101 exposes its service interface through dual-protocol engine module 102 and relies on dual-protocol engine 102 to process requests. The arrow from microservice module 101 to service registry 103 indicates that upon startup, microservice module 101 registers its service information with service registry 103.

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

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

[0056] In a possible implementation of the above embodiment, multiple microservice modules 101 mark the service interface position of the service code with the first protocol annotation based on the Spring Cloud framework, and generate the service interface of the first communication protocol through dynamic proxy; Multiple microservice modules 101 mark the service interface position of the service code with the second protocol annotation based on the Dubbo framework, and generate the service interface of the second communication protocol through dynamic proxy.

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

[0058] Correspondingly, multiple microservice modules 101 mark the service interface position of the service code with @Restcontroller based on the Spring Cloud framework, and generate the service interface of the HTTP protocol through dynamic proxy; Multiple microservice modules 101 mark the service interface position of the service code with @DubboService based on the Dubbo framework, and generate the service interface of the Triple protocol through dynamic proxy.

[0059] Here, the first protocol annotation @Restcontroller is a marker at the Java bytecode level, which is used to inform the Spring Cloud framework that "this interface needs to generate an HTTP protocol service interface". It automatically implements HTTP request parsing, routing, and response generation through dynamic proxy, supporting HTTP protocol communication.

[0060] The second protocol annotation @Dubbo Service is also a marker at the Java bytecode level, which is used to inform the Dubbo framework that "this interface needs to generate a service interface for the Dubbo protocol (such as the Triple protocol)". It automatically implements the decoding of remote procedure call (RPC) requests, interface mapping, and binary response generation through dynamic proxies, enabling the interface to support high-performance RPC communication in the Dubbo ecosystem.

[0061] Furthermore, dynamic proxy refers to the technology of dynamically generating proxy classes based on annotations when the framework starts the service.

[0062] The microservice module 101 generates a service interface of the HTTP protocol and a service interface of the Triple protocol through dynamic proxy.

[0063] Here, the HTTP service interface is generated by a dynamic proxy triggered by the @RestController annotation, adapted to the Spring Cloud framework, and supports HTTP request interactions. Similarly, the Triple service interface is 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).

[0064] 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 after processing is completed, the HTTP response is returned through the Spring Cloud engine; 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.

[0065] Here, we can ensure that the service interfaces of the dual protocols reuse the same set of business logic, avoid code redundancy, and prevent logical conflicts between proxy classes.

[0066] Through the dual-protocol microservice bridging system, method and dual-protocol microservice device of the above-mentioned embodiment of the present disclosure, the @RestController annotation and @DubboService annotation marked on the same service interface are combined with dynamic proxy technology to automatically generate service interfaces of the HTTP protocol and the Triple protocol, so that a set of business logic can support the interaction of the two protocols at the same time. There is no need to develop independent interfaces or business codes for the two protocols, which greatly improves development efficiency and reduces development costs. The dual-protocol interface design enables the new service module to interact with the old service that only supports HTTP through the HTTP interface, and to communicate efficiently with other new services through the Triple interface. A smooth system transition can be achieved without modifying the old service, thereby ensuring seamless compatibility between the old and new systems and reducing system expansion costs.

[0067] In a possible implementation of the above embodiment, the first protocol engine is a lightweight Web container optimized based on IO threads, and the thread model of the first protocol engine satisfies: The number of IO threads is equal to the current number of CPU cores, and the number of worker threads is equal to the 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 meets the following requirements: A fixed number of threads is initialized when the service starts; the fixed number is the upper limit of the thread pool.

[0068] 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 refined configuration of IO threads and worker threads, and adapt to the HTTP protocol interaction of the Spring Cloud framework.

[0069] Here, the IO thread is responsible for 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 equal the current number of CPU cores can reduce thread context switching overhead and maximize CPU resource utilization.

[0070] Worker threads are responsible for 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 IO threads.

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

[0072] Furthermore, the first protocol engine may be an Undertow engine, a Ttomcat engine, a Jjetty engine or a Ggrizzly engine.

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

[0074] Here, a fixed number of threads is 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".

[0075] Here, the thread model is marked as “fixed”, which indicates 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.

[0076] Furthermore, the second protocol engine may be a Netty engine, a MINA engine, a Vert.x engine, or a QuickServer engine.

[0077] It is understandable that, through the above initialization configuration of the first protocol engine and the second protocol engine, the thread pool ramping phenomenon can be avoided, that is, resource competition caused by the dynamic creation of threads by the thread pool during high traffic can be avoided.

[0078] Through the dual-protocol microservice bridging system, method and dual-protocol microservice device of the above-mentioned embodiments of the present disclosure, the first protocol engine completely decouples IO operations from business logic processing by separating IO threads from worker threads, ensuring that business processing does not block the IO process, maximizing the use of CPU resources, and improving the processing efficiency of the HTTP protocol. The second protocol engine adopts a fixed thread model to avoid resource competition for dynamic creation / destruction of threads, reduce performance fluctuations caused by thread pool expansion under high traffic, and adapt 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, reuses code, avoids protocol processing conflicts, and reduces the complexity of multi-protocol maintenance.

[0079] In a possible implementation of the above embodiment, the namespace grouping isolation mechanism of the service registry is implemented through the Group of the Nacos registry, where: The service registration center stores the protocol registration information of the microservice module 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; The service registration center 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.

[0080] In this embodiment, a first group and a second group are set in the Nacos registration center.

[0081] Here, the Group of the Nacos registration center is a logical isolation unit, and the protocol registration information stored in different Groups is completely independent.

[0082] For example, when registering and configuring the first group corresponding to the HTTP protocol, the registration configuration method can be: spring: cloud: nacos: discovery: server-addr: localhost:8848.

[0083] Among them, "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 of the Spring Cloud ecosystem, which is used to configure cloud-native features related to microservices; "nacos" is used to specify the use of Nacos as the service registration center and configuration center; discovery is used to specifically refer to the configuration of the "service discovery" function; "server-addr: localhost:8848" is the core configuration item, which is used to specify the address and port of the Nacos service registration center.

[0084] Furthermore, when the microservice module 101 starts, it reads the above configuration and performs the following operations: The microservice connects to the local Nacos service registration center according to "server-addr" and automatically registers its own service information in Nacos. Subsequently, Nacos obtains the registration information of other microservice modules 101 in real time to realize cross-service calls.

[0085] In addition, the 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.

[0086] When registering and configuring the second group corresponding to the Triple protocol, the registration configuration method can be: dubbo: protocol: name: tri port: -1 threadpool: fixed threads: 2000 registry: address: nacos: / / localhost:8848 group: dubbo config-center: address: nacos: / / localhost:8848 metadata-report: address: nacos: / / localhost:8848.

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

[0088] Specifically, "name: tri" is used to specify the Triple protocol; "port: -1" means that an unoccupied port is automatically and randomly assigned at startup. When registering with Nacos, the actually assigned port will be recorded for the caller to obtain through service discovery; "threadpool: fixed" is used to specify the thread pool type as "fixed"; "threads: 2000" is used to configure the number of threads in the fixed thread pool to 2000.

[0089] Furthermore, "dubbo.registry" is used to specify which service registry the Dubbo service is registered with. "address: nacos: / / localhost:8848" specifies that the service registry is Nacos, and the address shares the same Nacos node with SpringCloud to ensure that dual-protocol services are registered with the same registry. "group: dubbo" specifies that the service is grouped as dubbo in Nacos, which is used to logically isolate the Dubbo service (Triple protocol) from the SpringCloud service (HTTP protocol) within Nacos. "config-center. address: nacos: / / localhost:8848" specifies that Nacos is the configuration center of Dubbo, which is used to store the dynamic configuration of the Dubbo service. When the service starts, the latest configuration will be pulled from Nacos, and it can be dynamically updated without restarting the service. "metadata-report:address: nacos: / / localhost:8848" specifies that Nacos is the metadata reporting address, which is used to store the metadata of the Dubbo service. When other services call Triple protocol services, they first obtain metadata from Nacos to ensure that the parameter parsing and interface mapping of the RPC call are accurate.

[0090] It is understandable that Nacos' namespace grouping isolation mechanism completely separates the registration information of SpringCloud (HTTP) and Dubbo (Triple) through independent logical spaces. This not only ensures that the protocol routing module can accurately match the channel, but also supports the independent operation and maintenance and performance optimization of dual-protocol services. It is the underlying data isolation guarantee for achieving dual-protocol communication in the same service code.

[0091] Through the dual-protocol microservice bridging system, method, and dual-protocol microservice device of the above-mentioned embodiments of the present 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 based on the protocol type of the caller, avoiding erroneous calls due to information mixing and preventing information interaction conflicts under high concurrency.

[0092] Further references Figure 2 , Figure 2 This is a flow chart of a dual-protocol microservice bridging method provided by an embodiment of the present disclosure, which is applied to the above Figure 1 In the dual-protocol microservice bridging system 100 shown, the process of the method may include the following steps: In step S201, the first protocol annotation and the second protocol annotation are simultaneously marked at the service interface position of the microservice module, and the same service code is enabled to have dual-protocol communication capabilities of the first communication protocol and the second communication protocol through dynamic proxy.

[0093] Step S202: Through the dual-protocol engine module, a first protocol engine is bound to the first communication protocol and a thread optimization strategy for high concurrency scenarios is configured; and a second protocol engine is bound to the second communication protocol and a thread optimization strategy for a fixed thread model is configured.

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

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

[0096] The dual-protocol microservice bridging system, method, and dual-protocol microservice device of the above-mentioned embodiments of the present disclosure enable the same service code to have dual-protocol communication capabilities for a first communication protocol and a second communication protocol. Furthermore, the protocol registration information of the microservice module under the first communication protocol and the second communication protocol are registered separately through the namespace grouping isolation mechanism of the service registration center. This solves the problems of limited access between new-protocol microservices and old-protocol microservices, as well as slow access speed and low access efficiency based on independently developed protocol conversion modules. With minimal development effort, rapid development of dual-protocol microservices, microservice architectures, and dual-protocol service systems is achieved, greatly improving development efficiency while reducing development costs.

[0097] In a possible implementation of the above embodiment, a first communication protocol is bound to a corresponding first protocol engine and a thread optimization strategy for high concurrency scenarios is configured through a dual-protocol engine module, and a second communication protocol is bound to a corresponding second protocol engine and a thread optimization strategy for a fixed thread model is configured, including: Through the dual-protocol engine module, a lightweight container based on IO thread optimization is used as the first protocol engine, the first communication protocol is bound to the corresponding first protocol engine, the number of IO threads of the first protocol engine is configured to the current number of CPU cores, and the number of working threads of the first protocol engine is configured to the current preset multiple of the number of CPU cores; wherein the first protocol engine is an Undertow engine, a Ttomcat engine, a Jjetty engine, or a Ggrizzly engine; Through the dual-protocol engine module, the asynchronous communication framework of the fixed thread model is used as the second protocol engine, the corresponding second protocol engine is bound to the second communication protocol, and the threads are initialized 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.

[0098] Through the dual-protocol microservice bridging system, method and dual-protocol microservice device of the above-mentioned embodiments of the present invention, through the refined design of the thread model, while ensuring the high-performance operation of the dual-protocol, resource waste and protocol conflicts are avoided, providing stable and reliable underlying support for complex microservice architectures.

[0099] In a specific embodiment, please refer to Figure 3 , Figure 3 This is an exemplary schematic diagram of the architecture of another dual-protocol microservice bridging system according to an embodiment of the present disclosure. Figure 3 As shown, the dual-protocol microservice bridging system 300 includes: multiple microservice modules 301, a communication framework 302, a service registration center 303, a configuration center 304, a monitoring module 305 and a current limiting and degradation module 306, wherein: The microservice module 301 is the microservice module 101 included in the dual-protocol microservice bridging system 100 .

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

[0101] 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 server that provides the specific service according to the load balancing algorithm, thereby solving the problem of network waiting and long request response time caused by different server loads in service access.

[0102] Furthermore, the load balancing algorithm uses the load balancing algorithm provided by the Spring Cloud protocol and the Dubbo protocol. Specifically, the load balancing algorithm includes but is not limited to: polling algorithm, weighted polling algorithm, minimum connection number algorithm, and hash algorithm.

[0103] The configuration center 304 is used to store system-level and service-level configuration information, and can adopt Nacos, a SaaS product provided by Alibaba Cloud MSE.

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

[0105] The flow limiting and degradation module 306 is used to limit the number of requests per unit time in high-concurrency scenarios of dual protocols. It can adopt the 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.

[0106] In a possible implementation of the above embodiment, continue to refer to Figure 3 ,in: 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.

[0107] The arrow from the microservice module 301 to the service registration center 303 indicates that when the microservice is started, its own service information is registered with the service registration center 303; the service registration center 303 registers the HTTP and Triple protocol information to different namespaces respectively.

[0108] The arrow from the service registration center 303 to the communication framework 302 indicates that the load balancing module 3021 regularly obtains the latest service list from the service registration center 303 and dynamically selects the target service instance based on algorithms such as polling and weighted polling.

[0109] The arrows from the configuration center 304 to the microservice module 301 , the communication framework 302 , and the current 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 current limiting and degradation module 306 .

[0110] The arrows pointing from the microservice module 301 and the communication framework 302 to the monitoring module 305 indicate that the monitoring module 305 collects business indicators from the microservice module 301 and collects protocol layer indicators from the communication framework 302 .

[0111] The bidirectional arrow between the communication framework 302 and the current limiting and degradation module 306 represents that the communication framework 302 transmits real-time traffic data to the current limiting and degradation module 306. The current limiting and degradation module 306 intercepts the request through the communication framework 302 when the traffic exceeds the threshold according to the rules of the configuration center 304.

[0112] In a specific embodiment, please refer to Figure 4 , Figure 4 This is a specific application diagram of the architecture of a dual-protocol microservice bridging system according to an embodiment of the present disclosure. Figure 4 As shown, it is assumed that the microservice architecture including the above-mentioned dual-protocol microservice bridging system 100 includes newly developed business services A, B and C based on Triple protocol and HTTP protocol communication, as well as the original business services D and E based on single HTTP protocol communication.

[0113] Business services A, B, and C were developed using the same approach. In their code, they all implemented the @Restcontroller annotation, using bytecode enhancement technology to dynamically proxy HTTP, and the @Dubble service bytecode enhancement technology to dynamically proxy the Triple protocol open-source framework to implement dual-protocol communication between HTTP and Triple. The configuration files for business services A through C included both the Spring Cloud service registration file and the Dubbo service registration file, as well as both the Rest protocol engine and the Netty engine.

[0114] When users access the aforementioned microservice architecture, they can directly input Business Service A and Business Service D using the universal HTTP protocol. When Business Service A and Business Service D make internal system service calls, they can directly call them using the Triple protocol and the HTTP protocol, respectively. For example, if a user accesses Business Service A via HTTP, Business Service A can call Business Services B and C using the Triple protocol, and interact with Business Service D and Business Service E using HTTP. When the existing Business Service E needs to call the newly developed dual-protocol Business Service B, it can also communicate directly using HTTP. Microservices within the entire microservice architecture can access each other directly based on their own communication protocols, eliminating the need for a protocol conversion module to perform protocol conversion before making calls.

[0115] It should be noted that: the dual-protocol microservice bridging system provided in the above embodiment only uses the division of the above program modules as an example to illustrate when implementing the corresponding dual-protocol microservice bridging method. In actual 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 embodiment and the corresponding Figure 2 The embodiments of the method shown belong to the same concept, and their specific implementation processes are detailed in the method embodiments, which will not be repeated here.

[0116] In a 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 the present 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: The service interface module 501 simultaneously annotates the first protocol annotation based on the Spring Cloud framework and the second protocol annotation based on the Dubbo framework, and generates the service interface of the first communication protocol and the second communication protocol through dynamic proxy; The engine configuration module 502 binds the first protocol engine and the second protocol engine; The registration isolation module 503 stores the registration information of the microservice under the first communication protocol in the first group and stores the registration information under the second communication protocol in the second group through the namespace group isolation mechanism of the service registration center.

[0117] In a possible implementation of the above embodiment, the number of IO threads of the first protocol engine is configured to be equal to the number of processor cores, the number of working 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.

[0118] The present disclosure also provides an electronic device having the above Figure 1 Or the dual-protocol microservice bridging system shown in any one of 3, and having the above Figure 5 The architecture of the dual-protocol microservice device is shown.

[0119] See also Figure 6 , Figure 6 This is a structural diagram of another dual-protocol microservice bridging system provided by an embodiment of the present disclosure, such as Figure 6As shown, the electronic device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. The various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process instructions executed in the electronic device, including instructions stored in or on the memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 6 A processor 10 is taken as an example.

[0120] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0121] The memory 20 stores instructions that can be executed by at least one processor 10, so as to enable at least one processor 10 to execute the method shown in the above embodiment.

[0122] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an 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, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the electronic device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

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

[0124] The electronic device further includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 may be connected via a bus or other means. Figure 6 The bus connection is taken as an example.

[0125] The input device 30 can receive input digital or character information and generate key signal input related to user settings and function control of the electronic device. Examples include a touch screen, keypad, mouse, trackpad, touchpad, pointer, one or more mouse buttons, trackball, joystick, etc. The output device 40 may include a display device, auxiliary lighting devices (e.g., LEDs), and tactile feedback devices (e.g., vibration motors). Such display devices include, but are not limited to, liquid crystal displays, light emitting diodes, monitors, and plasma displays. In some optional embodiments, the display device may be a touch screen.

[0126] The electronic device also includes a communication interface for the electronic device to communicate with other devices or a communication network.

[0127] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0128] A portion of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes but is not limited to a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium that can be accessed by the computer.

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

Claims

1. A dual-protocol microservice bridging system, characterized in that: The system comprises: Multiple microservice modules integrate dual-protocol communication capabilities of the first communication protocol and the second communication protocol through the same service code, and the service interface position of the service code is annotated with both the first protocol annotation and the second protocol annotation; a dual-protocol engine module, comprising a first protocol engine corresponding to the first communication protocol and a second protocol engine corresponding to the second communication protocol; The service registration center stores the protocol registration information of each microservice module under the first communication protocol and the second communication protocol respectively through a namespace grouping isolation mechanism; The protocol routing module is configured to automatically select a protocol channel that matches the protocol type of the microservice module 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, wherein: The multiple microservice modules mark the service interface position of the service code with the 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 mark the second protocol annotation based on the Dubbo framework at the service interface position of the service code, and generate the service interface of the second communication protocol through dynamic proxy.

3. The system according to any one of claims 1 or 2, characterized in that The first protocol engine is a lightweight Web container based on IO thread optimization. The thread model of the first protocol engine satisfies: The number of IO threads is equal to the current number of CPU cores, and the number of worker threads is equal to the 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: A fixed number of threads is initialized when the service starts; 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 an Undertow engine, a Tomcat engine, a Jetty engine, or a Grizzly engine, and the second protocol engine is a Netty engine, a MINA engine, a Vert.x engine, or a QuickServer engine.

5. The system according to claim 4, characterized in that The namespace grouping isolation mechanism of the service registration center is implemented through the Group of the Nacos registration center, where: The service registration center stores the protocol registration information of the microservice module 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; The service registration center 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 to 5, characterized in that: The method comprises: Mark the service interface of the microservice module with both the first and second protocol annotations, and use dynamic proxy to enable the same service code to have dual-protocol communication capabilities of the first and second communication protocols; Through the dual-protocol engine module, the first communication protocol is bound to the corresponding first protocol engine and a thread optimization strategy for high concurrency scenarios is configured, and the second communication protocol is bound to the corresponding second protocol engine and a thread optimization strategy for a fixed thread model is configured; Register the protocol registration information of the microservice module under the first communication protocol and the second communication protocol respectively through the namespace grouping isolation mechanism of the service registration center; In response to the request of the microservice module as the caller, the target microservice module is matched based on the protocol registration information of the service registration center, and a protocol channel that matches the protocol type of the caller is automatically selected, so that microservice modules using different communication protocols can interact directly.

7. The method according to claim 6, characterized in that The dual-protocol engine module is used to bind the first communication protocol to the corresponding first protocol engine and configure a thread optimization strategy for high concurrency scenarios, and the second communication protocol is bound to the corresponding second protocol engine and configure a thread optimization strategy for a fixed thread model, including: Through the dual-protocol engine module, a lightweight container based on IO thread optimization is used as the first protocol engine, the first communication protocol is bound to the corresponding first protocol engine, the number of IO threads of the first protocol engine is configured to the current number of CPU cores, and the number of working threads of the first protocol engine is configured to the current preset multiple of the number of CPU cores; wherein the first protocol engine is an Undertow engine, a Tomcat engine, a Jetty engine, or a Grizzly engine; Through the dual-protocol engine module, the asynchronous communication framework of the fixed thread model is used as the second protocol engine, the corresponding second protocol engine is bound to the second communication protocol, and the threads are initialized to a fixed number when the service starts; wherein, the fixed number is the upper limit value of the thread pool, and the second protocol engine is a Netty engine, a MINA engine, a Vert.x engine or a QuickServer engine.

8. A dual-protocol microservice device, characterized in that: The device comprises: The service interface module 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; An engine configuration module, binding the first protocol engine and the second protocol engine; The registration isolation module 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 group isolation mechanism of the service registration center.

9. The device according to claim 8, characterized in that The number of IO threads of the first protocol engine is configured to be equal to the number of processor cores, the number of working 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 is started.

10. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the dual-protocol microservice bridging method according to 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 when the computer program is executed by a processor, the steps of the dual-protocol microservice bridging method according to any one of claims 6 or 7 are implemented.

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

Images