Soft bus service registration and discovery method and system in hybrid cloud environment

Abstract

The invention provides a soft bus service registration and discovery method and system in a hybrid cloud environment, and the method comprises the steps: a first micro-service instance deployed on a working node in a container arrangement cluster carries out the service registration, publishing the service metadata to a service agent running on the working node by using a first subscription / publishing model; the service agent establishes an address conversion rule for issuing the service registration to the outside, and forms new service metadata based on the address conversion rule; and the service agent publishes the new service metadata to other working nodes in the cluster or external network equipment by using a second subscription / publishing model. According to the application, a decentralized, automatic and lightweight solution is provided, and micro-service automatic discovery and communication of a cross-container arrangement cluster and a bare computer environment are realized.

Description

Technical Field

[0001] This application relates to the field of cloud computing and distributed system technology, and in particular to a method and system for registering and discovering soft bus services in a hybrid cloud environment. Background Technology

[0002] With the development of cloud-native technologies, enterprise IT architectures are undergoing a migration from traditional physical servers to Kubernetes container orchestration platforms. During this process, hybrid deployment architectures (coexistence of Kubernetes clusters and physical bare metal) have become the norm. These architectures typically face the core challenge of achieving seamless service discovery and communication between heterogeneous environments.

[0003] Traditional solutions such as centralized registry centers, service meshes, and native Kubernetes solutions all have significant drawbacks, as follows: Centralized registry centers (such as Nacos and Eureka) have single-point performance bottlenecks and failure risks. When deployed across network domains, network interconnection configuration is complex and requires additional components such as Ingress, LoadBalancer or VPN, resulting in a cumbersome architecture and high latency. Service meshes (such as Istio+Envoy) have high resource overhead, require the injection of agents into each Pod, and require the deployment of complex agents on bare metal when governing bare metal services, as well as a unified management control plane, resulting in high overall complexity. Native Kubernetes solutions (such as NodePort and HostNetwork) require manual pre-definition and configuration, resulting in rigid port management, a lack of dynamism, and security vulnerabilities in the HostNetwork mode.

[0004] In summary, existing technologies cannot effectively solve the service discovery problem between Kubernetes and bare metal heterogeneous environments while ensuring decentralization and low overhead. Summary of the Invention

[0005] In view of this, this application proposes a method, system, device, and storage medium for software bus service registration and discovery in a hybrid cloud environment. By providing a decentralized, automated, and lightweight solution, it realizes automated microservice discovery and communication across container orchestration clusters and bare-metal environments.

[0006] Firstly, this application provides a method for software bus service registration and discovery in a hybrid cloud environment, including: When the first microservice instance deployed on a worker node within the container orchestration cluster registers its service metadata to the service broker running on the worker node using the first subscription / publish model; The service proxy establishes address translation rules for publishing the service registration externally, and generates new service metadata based on these address translation rules; The service broker uses a second subscription / publish model to publish the new service metadata to other worker nodes within the cluster or external network devices.

[0007] As described above, this application deploys a first microservice instance and a service proxy on worker nodes within a container orchestration cluster. When the first microservice instance registers for a service, it automatically publishes its own service metadata to the service proxy. Then, the service proxy establishes address translation rules for publishing the service registration externally, and based on these address translation rules, it forms new service metadata. Subsequently, the new service metadata is published to other worker nodes within the cluster or external network devices, enabling microservice instances on other worker nodes within the cluster or external network devices to directly subscribe and discover services. This achieves service discovery in a hybrid cloud environment, facilitating interaction and communication between different microservice instances.

[0008] Optionally, the first subscription / publish model includes a first data distribution service topic; the second subscription / publish model includes a second data distribution service topic. The first data distribution service topic serves as a logical data topic used for service registration within the container orchestration cluster, and is used to carry and distribute the registration metadata of microservice instances; The second data distribution service topic serves as a logical data topic for service registration by other working nodes within the cluster or external network devices. It is used to carry and distribute the new service metadata, which contains routable service access addresses.

[0009] As described above, the two-layer data distribution architecture, consisting of the first data distribution service topic and the second data distribution service topic, serves as a subscription / publishing model. This architecture constructs a path for carrying and distributing internal metadata and external routable addresses, providing a reliable logical isolation channel between internal and external network domains for service discovery in a hybrid cloud environment.

[0010] Optionally, the step of publishing its service metadata to the service broker running on the worker node using the first subscription / publish model specifically includes: The first microservice instance publishes its service metadata to the first data distribution service topic during service registration; The service agent subscribes to the first data distribution service topic and obtains the service metadata; The service broker uses a second subscription / publish model to publish the new service metadata to other worker nodes within the cluster or external network devices, specifically including: The service agent publishes the new service metadata to the second data distribution service topic; A second microservice instance deployed on other worker nodes within the cluster or on an external network device subscribes to the second data distribution service topic to obtain the new service metadata.

[0011] Based on the topic subscription communication relationship, service instances only need to publish to the data distribution service topic, and the service broker listens by subscribing. This achieves complete decoupling between business logic (microservices) and infrastructure logic (service broker), ensuring that the service broker can reliably capture all registration events. After generating new service metadata, the service broker publishes the new service metadata to the second data distribution service topic. Second microservice instances deployed on other worker nodes in the cluster or on external network devices can obtain the new service metadata by subscribing to the second data distribution service topic, thereby realizing bidirectional data interaction of microservices in a hybrid cloud environment.

[0012] Optionally, the service proxy establishes address translation rules for publishing the service registration externally, and generates new service metadata based on these address translation rules, specifically including: The service proxy allocates an unused external access port on the worker node to the first microservice instance. The service proxy configures network address translation rules on its working node to forward traffic destined for that working node and with the target port being the external access port to the container network address of the first microservice instance. The service proxy translates the network address in the service metadata into the network address of the worker node to form new service metadata.

[0013] As described above, by allocating external access ports through service proxies, configuring network address translation rules, and translating network addresses in service metadata, the internal hiding and external accessibility of microservice addresses within the cluster are achieved. This avoids directly exposing the container network address of the first microservice instance, reduces the risk of container network attacks, and improves service access security. Furthermore, by establishing a mapping relationship between external traffic and microservices inside the container through network address translation rules, the problem of container cluster internal addresses not being directly accessible from the external network is solved, breaking down the address barriers for service access in hybrid cloud environments.

[0014] Optionally, after the service broker publishes the new service metadata to other worker nodes within the cluster or external network devices using the second subscription / publish model, it further includes: Other worker nodes within the cluster or external network devices initiate HTTP requests based on the routable access address in the new service metadata, wherein the routable access address includes the network address of the worker node and the external access port; The service proxy forwards the HTTP request to the container network address of the first microservice instance based on the network address translation rules, and after the first microservice instance processes the HTTP request, it returns the response data to other worker nodes in the cluster or external network devices along the original path.

[0015] As described above, after other worker nodes within the cluster or external network devices obtain the routable access address from the new service metadata through the second data distribution service topic, they rely on network address translation rules to complete the bidirectional forwarding of HTTP requests and responses, ensuring the integrity and reliability of service communication in the hybrid cloud environment. Requests and responses are returned along the original path without the need to build additional forwarding links, improving the efficiency of cross-environment service interaction and reducing link latency. The entire process is relayed through a service proxy, achieving isolation between external requests and microservices within the cluster, ensuring service interoperability, further improving the security of microservice instances, and enabling bidirectional data interaction of microservices in the hybrid cloud environment.

[0016] Optionally, the service proxy includes an internal proxy unit and an external proxy unit; The internal proxy unit runs on the network plane of the container orchestration cluster, and is used to subscribe to the first data distribution service topic and communicate with the external proxy unit. The external proxy unit operates in host network mode, sharing the network namespace with the host machine, and is used to perform operations such as allocating external access ports, configuring network address translation rules, and publishing data to the second data distribution service topic.

[0017] As described above, by clearly dividing the service proxy into internal proxy units and external proxy units, the internal proxy unit runs on the container network plane and focuses on subscribing to internal data distribution topics and communicating within the cluster; while the external proxy unit runs in host network mode, directly manipulating the host network stack and is responsible for performing key operations such as port allocation, network address translation rule configuration, and external data publishing.

[0018] Optionally, the method further includes: A third microservice instance deployed on the external network device publishes its service metadata to the second data distribution service topic upon startup; The service agent subscribes to the second data distribution service topic and obtains the service metadata published by the third microservice instance; The service broker forwards the service metadata of the third microservice instance to the first data distribution service topic for discovery by the first microservice instance within the container orchestration cluster.

[0019] As described above, in a hybrid cloud or multi-cloud architecture, the container orchestration cluster may be deployed in a private cloud environment, while external network devices are located in a public cloud or at the edge. Through this mechanism, the service metadata of a third microservice instance deployed on an external network device can be discovered by the first microservice instance within the container orchestration cluster, enabling service interoperability across cloud environments.

[0020] Optionally, the configuration of network address translation rules specifically includes: Configure a target network address translation rule by calling the operating system kernel's iptables or eBPF mechanism.

[0021] As described above, the service proxy can configure network address translation rules by calling the operating system kernel's iptables or eBPF mechanisms. iptables, as a mature and stable network filtering and NAT tool in the Linux kernel, ensures broad compatibility and reliability of the solution. Through carefully designed rule chains, it can achieve accurate source / destination address translation and maintain low latency when the number of rules is controllable, making it suitable for scenarios with moderate performance requirements but needing rapid deployment. eBPF, as a next-generation kernel programmable technology, allows the direct execution of custom packet processing logic in kernel mode, avoiding the data copying overhead of traditional user space and kernel space. When configuring target network address translation rules, eBPF can achieve microsecond-level rule matching and traffic forwarding, significantly reducing network latency and improving throughput in high-concurrency scenarios.

[0022] Optionally, the service proxy allocates external access ports, specifically including: Randomly select a port number from the preset port range that is not occupied by other services on this node as the external access port.

[0023] As described above, random port allocation is a dynamic port allocation method that can allocate and release port resources in a timely manner according to the actual needs of microservice instances. When the service proxy randomly selects a port, it checks in real time whether the port is already occupied by other services on the local node. This dynamic detection mechanism can promptly detect port conflicts and reselect other available ports, ensuring that the allocated external access port is unique and usable.

[0024] Secondly, this application provides a soft bus service registration and discovery system in a hybrid cloud environment, the system including a first microservice instance and service proxy deployed on worker nodes within a container orchestration cluster; When the first microservice instance registers its service, it uses the first subscription / publish model to publish its service metadata to the service broker. The service proxy establishes address translation rules for publishing the service registration externally, and generates new service metadata based on these address translation rules; The service broker uses a second subscription / publish model to publish the new service metadata to other worker nodes within the cluster or external network devices.

[0025] Thirdly, this application provides a computing device, the computing device comprising: processor; Memory, used to store one or more programs; When the processor executes one or more programs, it enables the processor to implement the above-described method for registering and discovering soft bus services in a hybrid cloud environment.

[0026] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a computer, implements the above-described method for registering and discovering soft bus services in a hybrid cloud environment.

[0027] These and other aspects of this application will become more apparent in the description of the following embodiments(s). Attached Figure Description

[0028] Figure 1 A flowchart illustrating the first method for registering and discovering soft bus services in a hybrid cloud environment provided in this application embodiment; Figure 2 A flowchart illustrating the second method for registering and discovering soft bus services in a hybrid cloud environment provided in this application embodiment; Figure 3 This application provides a schematic diagram illustrating the interaction between a container orchestration cluster and an external physical bare metal. Figure 4 A service call flowchart for a method of registering and discovering soft bus services in a hybrid cloud environment, provided in an embodiment of this application; Figure 5 This is a structural diagram of a computing device provided in an embodiment of this application.

[0029] It should be understood that the dimensions and shapes of the block diagrams in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of this application. The relative positions and inclusion relationships between the block diagrams presented in the structural diagrams are only schematic representations of the structural relationships between the block diagrams, and are not intended to limit the physical connection methods of the embodiments of this application. Detailed Implementation

[0030] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0032] The solutions provided in this application will now be described in detail with reference to the accompanying drawings and embodiments.

[0033] This application proposes a method and system for registering and discovering soft bus services in a hybrid cloud environment. By providing a decentralized, automated, and lightweight solution, it enables automated discovery and communication of microservices across container orchestration clusters and bare-metal environments.

[0034] like Figure 1 As shown, this application provides a method for registering and discovering soft bus services in a hybrid cloud environment. It is applicable to hybrid cloud environments containing at least one container orchestration cluster (such as a Kubernetes cluster) and at least one external network device (such as a physical bare-metal server or virtual machine). By combining the publish-subscribe mechanism of a two-layer Data Distribution Service (DDS) with a dynamic Network Address Translation (NAT) mapping mechanism, it solves the core challenge of service communication between the Kubernetes cluster and the bare-metal environment. (Refer to...) Figure 1 As shown, the method includes: S110: When the first microservice instance deployed on a worker node within the container orchestration cluster registers its service metadata to the service broker running on the worker node using the first subscription / publish model; S120: The service proxy establishes an address translation rule for publishing the service registration externally, and forms new service metadata based on the address translation rule; S130: The service broker uses the second subscription / publish model to publish the new service metadata to other worker nodes in the cluster or external network devices.

[0035] The first subscription / publish model includes a first data distribution service topic, which serves as a logical data topic for service registration within the container orchestration cluster, and is used to carry and distribute the registration metadata of microservice instances. The second subscription / publish model includes a second data distribution service topic, which serves as a logical data topic for service registration by services running on other worker nodes within the cluster or on external network devices, and is used to carry and distribute the new service metadata, which carries a routable service access address.

[0036] This application embodiment deploys a first microservice instance and a service proxy on worker nodes within a container orchestration cluster. When the first microservice instance registers for a service, it automatically publishes its own service metadata to the service proxy. Then, the service proxy establishes address translation rules for publishing the service registration externally, and forms new service metadata based on these address translation rules. Subsequently, the new service metadata is published to other worker nodes within the cluster or external network devices, enabling microservice instances on other worker nodes within the cluster or external network devices to directly subscribe and discover services. This achieves service discovery in a hybrid cloud environment, facilitating interaction and communication between different microservice instances.

[0037] The following reference Figures 2-4 This application provides a more detailed description of a method for registering and discovering soft bus services in a hybrid cloud environment, as illustrated in the embodiments of this application. Figure 2 As shown, the method for registering and discovering soft bus services in this hybrid cloud environment includes: S210: The first microservice instance deployed on the worker node within the container orchestration cluster publishes its service metadata to the first data distribution service topic upon startup.

[0038] Combination Figure 3 As shown, the container orchestration cluster is specifically a Kubernetes Pod with at least two worker nodes, namely Node 1 and Node 2, both of which can communicate with external physical bare metal. Each node has a service broker deployed in the form of a DaemonSet.

[0039] Once the first microservice instance deployed on node 1 of this Kubernetes Pod starts, its service metadata, such as service name, Pod IP, and service port, is published to the specified internal service-registry DDS Topic (e.g., service-registry-internal).

[0040] S220: A service broker deployed on the worker nodes of the container orchestration cluster subscribes to the first data distribution service topic and listens for service metadata published by the first microservice instance.

[0041] In this step, the service broker is deployed as a DaemonSet on nodes one and two of the Kubernetes cluster. It continuously subscribes to the aforementioned internal service-registry DDS Topic to listen for new service registration events.

[0042] S230: The service proxy allocates an external access port that is not occupied on the worker node where the first microservice instance is located.

[0043] When the service agent on node 1 detects a new service registration event (e.g., {name: 'svc-a', ip: '10.244.1.2', port: 8080}), it first parses the Pod IP in the service registration event and determines whether the Pod is running on its current worker node. If the determination is no, the service registration event is ignored and no action is taken. If the determination is yes, an unused port number (e.g., 31001) from a preset port range (e.g., 30000–32767) is assigned to the service as its external access port.

[0044] S240: The service proxy configures network address translation rules on its working node to forward traffic destined for the working node and with the target port being the external access port to the container network address of the first microservice instance.

[0045] In this step, the service broker invokes system commands or APIs to add a DNAT rule. For example, using the iptables command: iptables -t nat -A PREROUTING -d <nodeip>The rule `-p tcp --dport 31001 -j DNAT--to-destination 10.244.1.2:8080` forwards all TCP traffic destined for the specified dynamic port 31001 on this node to the corresponding Pod IP and service port.

[0046] S250: The service agent converts the network address in the service metadata to the network address of the worker node, and publishes the converted metadata to the second data distribution service topic.

[0047] In this step, the service agent replaces the IP address in the received internal service metadata with the host IP of the current node (Node IP) and the port with a dynamically assigned port, forming new metadata (such as {name: 'svc-a', ip:'192.168.1.100', port: 31001}), and publishes it to the external service-registry DDS Topic (such as service-registry-external).

[0048] S260: A second microservice instance deployed on other worker nodes within the cluster or on an external network device discovers and obtains the routable access address of the first microservice instance by subscribing to the second data distribution service topic.

[0049] In this step, the second microservice instance running on other worker nodes within the cluster or on an external network device subscribes to an external service-registry DDS Topic, discovers and obtains the routable access address of the first microservice instance, and initiates an HTTP request through this routable access address. This routable access address includes the network address (Node IP) of the worker node and the external access port (port 31001), and directly calls the service within the Kubernetes Pod. The service proxy forwards the HTTP request initiated by the second microservice instance to the container network address of the first microservice instance based on the network address translation rules. After the first microservice instance processes the HTTP request, it returns the response data to the second microservice instance on other worker nodes within the cluster or on the external network device, thereby achieving bidirectional data interaction between microservices in a hybrid cloud environment.

[0050] In some embodiments, a third microservice instance is also deployed on the external network device. Upon startup, the microservice instance publishes its service metadata to the external service-registry DDS Topic. The service broker subscribes to the external service-registry DDS Topic, listens for the service metadata published by the third microservice instance, and forwards the service metadata of the third microservice instance to the internal service-registry Topic. This allows the first microservice instance within the Kubernetes Pod to discover the service and directly call the service within the external network device, thereby achieving service interoperability across cloud environments.

[0051] The following is combined Figure 4 This example illustrates a specific application scenario, demonstrating the detailed workflow of the soft bus service registration and discovery method provided in this application's embodiments within a hybrid cloud environment. (Refer to...) Figure 4 As shown, in this scenario, a user service is deployed within a Kubernetes cluster, while a web application service is deployed on a physical bare metal machine outside the cluster.

[0052] like Figure 4 As shown, the workflow of the soft bus service registration and discovery method in this hybrid cloud environment includes a service registration phase and a service discovery and invocation phase. The specific process is as follows: Service registration phase: The user service instance is started in the Kubernetes cluster with Pod IP 10.244.1.5 and service port 8080; The user service instance publishes its service metadata {"name": "user-service", "ip": "10.244.1.5", "port": 8080} to the first data distribution service topic (such as service-registry-internal); The internal agent of the service agent running on the worker node where the Pod is located (Node IP is 192.168.1.101) listens for this message and notifies the external agent through the local API. The external proxy unit assigns dynamic port 31005 and configures iptables DNAT rules: iptables -t nat-A PREROUTING -d 192.168.1.101 -p tcp --dport 31005 -j DNAT --to-destination10.244.1.5:8080; The external agent unit publishes the converted service information {"name": "user-service", "ip": "192.168.1.101", "port": 31005} to the second data distribution service topic (such as service-registry-external).

[0053] Service discovery and invocation phase: The web service on the physical bare metal subscribes to the second data distribution service topic and obtains the routable address of the user service: 192.168.1.101:31005. The web service directly sends an HTTP request to http: / / 192.168.1.101:31005 / api / user / 1; The request packet arrives at port 31005 of the Kubernetes node 192.168.1.101 and is automatically forwarded to Pod 10.244.1.5:8080 by the default iptablesDNAT rules; After the user service processes the request, the response returns to the web service along the original path, completing a service call across heterogeneous environments.

[0054] In some embodiments, the workflow of the soft bus service registration and discovery method in the hybrid cloud environment may further include a reverse service registration process to enable services on external network devices to register with the container orchestration cluster, as follows: After the external service starts, its metadata is published to the second data distribution service topic; After the external proxy unit of the service proxy listens to this information, it forwards it to the internal proxy unit through the internal API; The internal agent unit publishes the service information to the first data distribution service topic, enabling all service instances within the cluster to discover the external service.

[0055] In summary, the method for registering and discovering soft bus services in a hybrid cloud environment provided in this application deploys a first microservice instance on a worker node within a container orchestration cluster, a second microservice instance on an external network device, and a service proxy on the worker node of the container orchestration cluster. When the first microservice instance starts, it automatically publishes its service metadata to a first data distribution service topic. Then, the service proxy automatically listens for internal service registration events published on the first data distribution service topic and dynamically executes port allocation and network address translation rule configurations. Subsequently, it publishes the translated routable address to the second data distribution topic, enabling the second microservice instance on the external network device to directly subscribe to discovery. This achieves service discovery and invocation in a hybrid cloud environment, facilitating interaction and communication between microservice instances in different environments. This application embodiment has advantages such as decentralization, automation, transparent communication, lightweight and non-intrusiveness, and supports dynamic scaling and fault migration of service instances. The system has strong adaptability and can be widely applied in hybrid cloud environments.

[0056] Figure 5 This is a structural diagram of a computing device 1000 provided in an embodiment of this application. The computing device 1000 includes: a processor 1010, a memory 1020, a communication interface 1030, and a bus 1040.

[0057] It should be understood that Figure 5 The communication interface 1030 in the computing device 1000 shown can be used to communicate with other devices.

[0058] The processor 1010 can be connected to the memory 1020. The memory 1020 can be used to store the program code and data. Therefore, the memory 1020 can be a storage unit inside the processor 1010, an external storage unit independent of the processor 1010, or a component that includes both the storage unit inside the processor 1010 and the external storage unit independent of the processor 1010.

[0059] Optionally, the computing device 1000 may also include a bus 1040. The memory 1020 and communication interface 1030 can be connected to the processor 1010 via the bus 1040. The bus 1040 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 1040 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0060] It should be understood that in the embodiments of this application, the processor 1010 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 1010 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0061] The memory 1020 may include read-only memory and random access memory, and provides instructions and data to the processor 1010. A portion of the processor 1010 may also include non-volatile random access memory. For example, the processor 1010 may also store device type information.

[0062] When the computing device 1000 is running, the processor 1010 executes the computer execution instructions in the memory 1020 to perform the operation steps of the above method.

[0063] It should be understood that the computing device 1000 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the other operations and / or functions of each module in the computing device 1000 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0064] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0065] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0066] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0067] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0068] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0069] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0070] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0071] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0072] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0073] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0074] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0075] It should be noted that the embodiments described in this application are merely some embodiments, not all embodiments. The components of the embodiments of this application typically described and shown in the accompanying drawings can be arranged and designed in various different configurations. Therefore, the above detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0076] The terms "first, second, third, etc." or similar terms such as module A, module B, module C, etc., used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that a specific order or sequence may be interchanged where permitted so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0077] In the above description, the labels indicating the steps do not necessarily mean that the steps will be executed. They may include intermediate steps or be replaced by other steps. Where permissible, the order of the steps may be interchanged or executed simultaneously.

[0078] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned features, elements, steps, or components, but does not exclude the presence or addition of one or more other features, elements, steps, or components, or groups thereof. Thus, the statement "equipment comprising means A and B" should not be limited to an equipment consisting solely of components A and B.

[0079] The term "an embodiment" or "an embodiment" as used in this specification means that a specific feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0080] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present application has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, all of which fall within the scope of protection of the present invention.< / nodeip>

Claims

1. A method for registering and discovering soft bus services in a hybrid cloud environment, characterized in that, The method comprises: A first microservice instance deployed on a worker node in a container orchestration cluster publishes its service metadata to a service agent running on the worker node using a first subscription / publishing model when registering the service; The service agent establishes an address translation rule for publishing the service registration externally, and forms new service metadata based on the address translation rule; The service agent publishes the new service metadata to other worker nodes in the cluster or external network devices using a second subscription / publishing model.

2. The method of claim 1, wherein, The first subscription / publishing model includes a first data distribution service topic; the second subscription / publishing model includes a second data distribution service topic; The first data distribution service topic is a logical data topic used for service registration by internal services in the container orchestration cluster, and is used to carry and distribute the registration metadata of the microservice instance; The second data distribution service topic is a logical data topic used for service registration by services running on other worker nodes in the cluster or external network devices, and is used to carry and distribute the new service metadata, which contains a routable service access address.

3. The method of claim 2, wherein, The first microservice instance publishes its service metadata to the service agent running on the worker node using the first subscription / publishing model, specifically including: The first microservice instance publishes its service metadata to the first data distribution service topic when registering the service; The service agent subscribes to the first data distribution service topic and obtains the service metadata; The service agent publishes the new service metadata to the second data distribution service topic using the second subscription / publishing model, specifically including: The service agent publishes the new service metadata to the second data distribution service topic; The second microservice instance deployed on other worker nodes in the cluster or external network devices subscribes to the second data distribution service topic and obtains the new service metadata.

4. The method of claim 2, wherein, The service agent establishes an address translation rule for publishing the service registration externally, and forms new service metadata based on the address translation rule, specifically including: The service agent allocates an external access port for the first microservice instance that is not occupied on the worker node where the first microservice instance is located; The service agent configures a network address translation rule on the worker node where the service agent is located, and forwards traffic to the worker node and targeting the external access port to the container network address of the first microservice instance; The service agent translates the network address in the service metadata to the network address of the worker node to form new service metadata.

5. The method of claim 4, wherein, After the service agent publishes the new service metadata to other worker nodes in the cluster or external network devices using the second subscription / publishing model, it further comprises: The other worker nodes in the cluster or external network devices initiate an HTTP request according to the routable access address in the new service metadata, which includes the network address of the worker node and the external access port; The service agent forwards the HTTP request to the container network address of the first microservice instance based on the network address translation rule, and returns the response data to other worker nodes in the cluster or external network devices via the original route after the first microservice instance processes the HTTP request.

6. The method of claim 2, wherein, The service agent comprises an internal agent unit and an external agent unit; The internal agent unit runs in the network plane of the container orchestration cluster, subscribes to the first data distribution service topic, and communicates with the external agent unit; The external agent unit runs in the host network mode, shares the network namespace with the host machine, and performs the operations of allocating an external access port, configuring a network address translation rule, and publishing data to the second data distribution service topic.

7. The method of claim 2, wherein, The method further comprises: A third microservice instance deployed on the external network device publishes its service metadata to the second data distribution service topic when starting; The service agent subscribes to the second data distribution service topic and obtains the service metadata published by the third microservice instance; The service agent forwards the service metadata of the third microservice instance to the first data distribution service topic for the first microservice instance in the container orchestration cluster to discover.

8. A soft bus service registration and discovery system in a hybrid cloud environment, characterized by, The system comprises a first microservice instance and a service agent deployed on a worker node in a container orchestration cluster; The first microservice instance publishes its service metadata to the service agent using a first subscription / publishing model when registering a service; The service agent establishes an address translation rule for publishing the service registration externally, and forms new service metadata based on the address translation rule; The service agent publishes the new service metadata to other worker nodes in the cluster or external network devices using a second subscription / publishing model.

9. A computing device, comprising: comprises: a processor; a memory for storing one or more programs; When the one or more programs are executed by the processor, the processor implements a hybrid cloud environment soft bus service registration and discovery method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by a computer to implement a hybrid cloud environment soft bus service registration and discovery method as claimed in any one of claims 1 to 7.

Images