Dubbo containerized deployment method, system, equipment, media and product

Abstract

The present application discloses a Dubbo containerized deployment method, system, device, medium and product, which relates to the field of server deployment technology. The method includes: initiating a service discovery request instruction to a registration center; receiving a provider instance list returned by the registration center based on the service discovery request instruction, selecting a microservice provider instance information in the provider instance list as the target provider instance information; and sending a call instance request to the microservice provider instance corresponding to the target provider instance information. The present application fixes the microservice consumers and microservice providers with upstream and downstream call relationships in the same container area as the registration center. The microservice consumers can only request the microservice providers in the same container area through the registration center, thereby avoiding the phenomenon of failure of upstream and downstream microservice calls of the container application due to the regionalization of the container application network address and the non-fixed network address.

Description

Technical Field

[0001] The present application relates to the field of server deployment technology, and in particular to Dubbo containerized deployment methods, devices, media, and program products. Background Art

[0002] In recent years, with the advancement of computer hardware and software technologies and the increasing scale of software, various microservice technology frameworks have emerged. Among them, the Dubbo framework has emerged as one of the industry's leading microservice frameworks, favored by Java developers due to its open source, high performance, transparent RPC (Remote Procedure Call) architecture, and rich service governance solutions. However, the Dubbo framework has some flaws in containerized deployment. For example, remote calls between services are based on IP addresses (network addresses), which cannot cope with the situation where only domain names are exposed in containerized deployments. This can lead to regionalized and unstable network addresses in container applications, resulting in failures in upstream and downstream microservice calls. Summary of the Invention

[0003] The main purpose of this application is to provide a Dubbo containerized deployment method, device, storage medium and computer program product, aiming to solve the technical problem of failure of upstream and downstream microservice calls of container applications due to the regionalization of container application network addresses and the non-fixed network addresses.

[0004] To achieve the above objectives, this application proposes a Dubbo containerized deployment method, which is applied to any microservice consumer in a container microservice consumer cluster. The container microservice consumer cluster is deployed in a container area. The container area also includes a registration center and a container microservice provider cluster. The container microservice provider cluster includes multiple microservice providers, and at least one microservice provider instance is deployed in the microservice provider. The method includes:

[0005] Initiate a service discovery request instruction to the registration center, wherein the registration center stores the microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, build a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer, and send the provider instance list to the microservice consumer;

[0006] Receive the provider instance list returned by the registration center based on the service discovery request instruction, and select a microservice provider instance information in the provider instance list as the target provider instance information;

[0007] A call instance request is sent to the microservice provider instance corresponding to the target provider instance information, wherein the microservice provider instance corresponding to the target provider instance information processes the task corresponding to the call instance request.

[0008] In addition, to achieve the above objectives, this application also proposes a Dubbo containerized deployment method, which is applied to any microservice provider in a container microservice provider cluster. At least one microservice provider instance is deployed in the microservice provider. The container microservice provider cluster is deployed in a container area. The container area also includes a registration center and a container microservice consumer cluster. The container microservice consumer cluster includes multiple microservice consumers. The method includes:

[0009] A registration instance request instruction is initiated to the registration center, wherein the registration center stores the microservice provider instance information of at least one microservice provider instance in the microservice provider according to the registration instance request instruction. After receiving the service discovery request sent by the microservice consumer, the registration center builds a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer. The provider instance list is sent to the microservice consumer. The microservice consumer selects a microservice provider instance information in the provider instance list as the target provider instance information, and sends a call instance request to the microservice provider instance corresponding to the target provider instance information.

[0010] If there is a microservice provider instance that receives the instance call request in at least one microservice provider instance, the task corresponding to the instance call request is processed according to the microservice provider instance that receives the instance call request.

[0011] In one embodiment, after the step of initiating a registration instance request to a registration center, the method further includes:

[0012] If an update instruction is received, the microservice provider instance corresponding to the update instruction in each microservice provider instance is updated according to the update instruction to obtain a grayscale instance;

[0013] Send the grayscale instance information corresponding to the grayscale instance to the registration center, where the registration center updates the stored microservice provider instance information based on the grayscale instance information;

[0014] Sending a first query instruction to the registration center according to a preset time interval for querying the grayscale instance weight, wherein the first query instruction represents the grayscale instance weight included in the grayscale instance information being queried;

[0015] Receiving the grayscale instance weight returned by the registration center based on the first query instruction;

[0016] Determine whether the grayscale instance weight is greater than or equal to the preset release weight;

[0017] If the grayscale instance weight is greater than or equal to the preset release weight, the grayscale instance release is determined to be complete.

[0018] In one embodiment, after the step of determining whether the grayscale instance weight is greater than or equal to the preset release weight, the method further includes:

[0019] If the grayscale instance weight is less than the preset release weight, the grayscale instance weight in the registration center is increased according to the preset weight increase coefficient, and the step of initiating a query instruction for the grayscale instance weight to the registration center according to the preset time interval for querying the grayscale instance weight is continued.

[0020] In one embodiment, after the step of initiating a registration request to a registration center, the method further includes:

[0021] If an exit instruction is received, a second query instruction is sent to the registration center according to a preset time interval for querying the weight of the instance to be exited, wherein the second query instruction represents the weight of the instance to be exited contained in the instance information to be exited corresponding to the instance to be exited, and the instance to be exited is the microservice provider instance corresponding to the exit instruction;

[0022] receiving the weight of the instance to be deregistered returned by the registration center based on the second query instruction;

[0023] Determine whether the weight of the instance to be exited is less than or equal to the preset exit weight;

[0024] If the weight of the instance to be exited is less than or equal to the preset exit weight, the registration center is notified to disable the instance to be exited.

[0025] In one embodiment, after the step of determining whether the weight of the instance to be exited is less than or equal to the preset exit weight, the following steps are performed:

[0026] If the weight of the instance to be exited is greater than the preset exit weight, the weight of the instance to be exited in the registration center is reduced according to the preset de-weighting coefficient, and the step of initiating a query instruction to query the weight of the instance to be exited to the registration center according to the preset time interval for querying the weight of the instance to be exited is continued.

[0027] In addition, to achieve the above objectives, this application also proposes a Dubbo containerized deployment system, which includes a registration center deployed in the container area, a container microservice provider cluster and a container microservice consumer cluster. The container microservice consumer cluster includes multiple microservice consumers, and at least one microservice provider instance is deployed in the microservice provider in the container microservice consumer cluster.

[0028] Microservice provider, used to initiate registration instance request instructions to the registration center;

[0029] Microservice consumers, used to initiate service discovery request instructions to the registration center;

[0030] The registration center is used to store microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, it builds a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer, and sends the provider instance list to the microservice consumer;

[0031] The microservice consumer receives the provider instance list returned by the registration center based on the service discovery request instruction, selects a microservice provider instance information in the provider instance list as the target provider instance information; and sends a call instance request to the microservice provider instance corresponding to the target provider instance information;

[0032] The microservice provider is configured to process a task corresponding to the instance call request if there is a microservice provider instance that receives the instance call request in at least one microservice provider instance.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a Dubbo containerized deployment device, which includes: a memory, a processor, and a computer program stored in the memory and runnable on the processor, and the computer program is configured to implement the steps of the Dubbo containerized deployment method as described above.

[0034] In addition, to achieve the above-mentioned purpose, the present application also proposes a medium, which is a computer-readable storage medium. A computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the Dubbo containerized deployment method as described above are implemented.

[0035] In addition, to achieve the above-mentioned purpose, the present application also provides a product, which is a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps of the Dubbo containerized deployment method as described above.

[0036] One or more technical solutions proposed in this application have at least the following technical effects:

[0037] This application proposes deploying a container microservice consumer cluster, a container microservice provider cluster, and a registration center in a container area, and the container microservice consumer cluster includes multiple microservice consumers, the container microservice provider cluster includes multiple microservice providers, and at least one microservice provider instance is deployed in the microservice provider, thereby enabling the microservice provider deployed with at least one microservice provider instance to be in the same container area as the microservice consumer, thereby avoiding the phenomenon that when the microservice consumer calls the microservice provider instance in the microservice provider due to the regionalization of the container application network address and the non-fixed network address, the container application upstream and downstream microservice calls fail.

[0038] The registration center also stores and manages microservice provider instance information in real time based on the microservice provider's registration instance request. Therefore, after a microservice consumer initiates a service discovery request instruction to the registration center, the registration center will build a provider instance list based on the stored information of at least one microservice provider instance from all microservice providers in the same container area as the microservice consumer, and send it to the microservice consumer. This ensures that when the microservice consumer initiates a call, it can accurately obtain a list of available microservice provider instances in the same container area as itself. The microservice consumer then intelligently selects a target provider instance from the provider instance list. This process can make intelligent decisions based on factors such as service status and load, thereby optimizing resource utilization and improving overall system performance. Finally, a call instance request is sent to the selected target provider instance, which processes the task in real time. This step ensures the efficient execution of the service call. In general, this application achieves precise matching of service discovery and calling processes, and can effectively avoid the occurrence of call failures caused by the regionalization and non-fixedness of container application network addresses even in complex and changeable network environments. It further enhances the accuracy, stability and availability of the system, reduces the risk of call failures, and provides a strong guarantee for the stable operation of the microservice architecture. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0041] Figure 1 This is a flowchart of the first embodiment of the Dubbo containerized deployment method of this application;

[0042] Figure 2 This is a schematic diagram of the scenario for the Dubbo containerized deployment method for this application;

[0043] Figure 3 This is a process diagram of the first embodiment of the Dubbo containerized deployment method of this application;

[0044] Figure 4 This is a flowchart of the third embodiment of the Dubbo containerized deployment method of this application;

[0045] Figure 5 This is a schematic diagram of the third embodiment of the Dubbo containerized deployment method of this application;

[0046] Figure 6 This is a flowchart of the fourth embodiment of the Dubbo containerized deployment method of this application;

[0047] Figure 7 This is a schematic diagram of the fourth embodiment of the Dubbo containerized deployment method of this application;

[0048] Figure 8 A schematic diagram of the device structure of the hardware operating environment involved in the Dubbo containerized deployment method in an embodiment of the present application;

[0049] The purpose, features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0050] It should be understood that the specific embodiments described herein are merely used to explain the technical solutions of the present application and are not intended to limit the present application.

[0051] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0052] The Dubbo framework currently has some defects in the containerized deployment process. For example, service governance relies on the customized dubbo management end to interact with the registration center. Service governance such as permission adjustment, disabling, and isolation all require manual operations, and there is a lack of solutions for grayscale releases. In terms of lossless service releases, the dubbo framework also does not provide a solution, resulting in traffic loss when the service version is released.

[0053] This application also provides suitable solutions for grayscale releases and lossless releases of application traffic, supporting containerized deployments for automatic grayscale and lossless transitions to new versions. By applying scheduled scheduling and combining it with the Dubbo service governance and authorization method, the Dubbo service's automated grayscale release is achieved. The entire release process is fully automated, independent of the Dubbo management side. The container's graceful exit capability allows for automatic disconnection from the Dubbo service registration center, thus achieving lossless exit of service traffic.

[0054] The present application provides a Dubbo containerized deployment method, which realizes the grayscale release and lossless exit of microservice instances by gradually increasing or decreasing weights through scheduled tasks, ensuring the smooth transition of services and high availability of the system, enhancing the stability and reliability of the system, and reducing the risks brought by version updates and instance exits. At the same time, the automated weight adjustment process improves operation and maintenance efficiency and reduces the possibility of human error. And because the microservice provider deployed with at least one microservice provider instance is in the same container area as the microservice consumer, it can avoid the phenomenon that the microservice consumer fails to call the upstream and downstream microservices of the container application due to the regionalization of the container application network address and the non-fixed network address when calling the microservice provider instance in the microservice provider due to the fact that the microservice provider and the microservice consumer are not in the same container area.

[0055] Furthermore, the present application embodiment provides a Dubbo container deployment method, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the Dubbo containerized deployment method of this application.

[0056] It should be noted that the execution entity of this embodiment can be a computing service device with data processing, network communication, and program execution capabilities, such as a server, intelligent system, tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions. The following uses a microservice consumer as an example to illustrate this embodiment.

[0057] The Dubbo containerized deployment method in this embodiment is applied to any microservice consumer in the container microservice consumer cluster. The container microservice consumer cluster is deployed in the container area. The container area also includes a registration center and a container microservice provider cluster. The container microservice provider cluster includes multiple microservice providers, and at least one microservice provider instance is deployed in the microservice provider.

[0058] It should be noted that Dubbo is a high-performance, lightweight, open-source Java RPC (Remote Procedure Call) framework for building distributed service applications. Containerized deployment refers to packaging an application, its dependencies, and configuration files into a standalone executable package and deploying it on a containerized platform. A microservice consumer is a service or application responsible for invoking other services (microservice providers). A microservice consumer cluster is a collection of multiple microservice consumers deployed on different servers or different virtual nodes of the same server. A container zone is a logical or physical concept used to describe the environment or zone in which a group of containerized services are deployed and run, corresponding to one or more physical or virtual server clusters. A registry is a centralized service responsible for storing and managing microservice instance information, enabling service discovery and invocation. A microservice provider is a service responsible for providing services to other services (microservice consumers). A microservice provider cluster is a collection of multiple microservice providers deployed on different servers or different virtual nodes of the same server. Correspondingly, a microservice provider instance is a specific instance of a microservice provider in a containerized deployment, namely, a microservice provider process running in a container. A microservice provider can deploy multiple instances to achieve high availability and load balancing. It is worth noting that a service can be both a microservice provider and a microservice consumer.

[0059] For example, refer to Figure 2 , Figure 2This is a scenario diagram of the Dubbo containerized deployment method of this application. The figure includes a container DNS resolution system and two container deployment areas (hereinafter referred to as container areas): container deployment area 1 (hereinafter referred to as container area 1) and container deployment area 2 (hereinafter referred to as container area 2). Taking container area 1 as an example, a container microservice consumer cluster, a container zookeeper registration center cluster and a container microservice provider cluster are deployed in container area 1, wherein the container microservice consumer cluster contains at least one microservice consumer, such as the microservice consumer C in the figure, the container microservice provider cluster contains at least one microservice provider, such as the microservice provider P in the figure, and the container zookeeper registration center cluster contains at least one registration center, such as the registration center R in the figure. The microservice provider instance in the microservice provider P registers itself with the registration center R when it starts, so that the microservice consumer C can query the instance information from the registration center when needed to realize the remote call of the instance service. The microservice consumer C in the container area 1 can only call the microservice provider instance in the microservice provider in the container area 1, thereby avoiding the problem of failure of upstream and downstream microservice calls. The composition and principles of container deployment zone 2 are similar to those of container zone 1 and are not detailed here. When users access services using domain names, the container DNS resolution system deployed in the environment resolves the domain names into network addresses, allowing access to services in the container. This approach solves the problem of only exposing the domain name in containerized deployments.

[0060] Reference Figure 1 The Dubbo containerized deployment method in this embodiment includes steps S10 to S30:

[0061] Step S10: Initiate a service discovery request instruction to the registration center, wherein the registration center stores the microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, build a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer, and send the provider instance list to the microservice consumer;

[0062] Reference Figure 3 , Figure 3This is a process diagram of the first embodiment of the Dubbo containerized deployment method of this application. When the container environment is deployed, the microservice provider sends a registration instance request instruction to the registration center (such as Eureka, Consul, Zookeeper, etc.). The instruction contains detailed information of the microservice provider, such as service name, version number, instance address (network address and port), metadata, etc. The registration center will receive this information and store it in an internal data structure for subsequent service discovery and load balancing. After successful registration, the registration center will send a successful registration message to the microservice provider; at the same time, the microservice consumer will also register itself with the registration center. After successful registration, the registration center will send a successful registration message to the microservice consumer. When a user requests a service using a domain name, the container DNS resolution process (container domain name resolution system) is first triggered. DNS resolves the user's requested domain name into a corresponding network address and makes a service request. The microservice consumer, receiving the service request, then initiates a service discovery request to the registry. Upon receiving the service discovery request, the registry searches its internal storage for all microservice provider instance information. This information, submitted by the microservice provider via the register instance request upon startup, contains key information such as the provider's service type, network address, port number, and container zone. The registry then uses this information to perform refined filtering and matching. It selects from its stored microservice provider instances those that match the service type and container zone specified in the microservice consumer's request, constructs a list of provider instances, and returns it to the microservice consumer. If all provider instances of a particular service type are unavailable (e.g., due to system upgrades or maintenance), the registry returns an error message to the microservice consumer and may offer alternative solutions or retry suggestions. In distributed deployment scenarios, if consumers need to access service providers in different container zones, the registry can also provide cross-zone service discovery.

[0063] Step S20: receiving the provider instance list returned by the registration center based on the service discovery request instruction, and selecting a microservice provider instance information in the provider instance list as the target provider instance information;

[0064] It should be noted that there are many ways for a microservice consumer to select a microservice provider instance information from the provider instance list as the target provider instance information, such as polling, random selection or load balancing algorithm, which can be freely set according to actual conditions.

[0065] After receiving the provider instance list from the registry, the microservice consumer first parses it. This list contains detailed information about multiple microservice provider instances, such as network addresses, port numbers, health status, weights, and priorities. Based on business needs and configuration policies, the microservice consumer filters and sorts the provider instance list. Filtering can be based on factors such as location (for example, the microservice consumer selects the nearest instance to call based on its own location and the location of the provider instance) and service version (for example, the microservice consumer selects a microservice provider instance of the same version based on its own version information to ensure compatibility with its own version). Sorting can be based on metrics such as weights and response time. Based on the filtering and sorting results, the microservice consumer selects one or more target provider instances (in scenarios where high service availability is required, the consumer can automatically switch to other available instances if the preferred provider instance becomes unavailable). Before initiating the call, the microservice consumer can perform additional validation, such as checking the health status of the provider instance and performing security authentication. The microservice consumer also prepares the parameters and context information required for the call. Using the selected target provider instance information, the microservice consumer initiates a service call request to the provider over the network. After receiving the provider instance list returned by the registration center, it can be cached. The next time the same service is needed, the target provider instance information can be directly selected from the cache to reduce the number of requests.

[0066] Step S30: Send an instance call request to the microservice provider instance corresponding to the target provider instance information, wherein the microservice provider instance corresponding to the target provider instance information processes the task corresponding to the instance call request.

[0067] It should be noted that, referring to Figure 3 The microservice consumer sends a call instance request to the microservice provider, which contains call parameters and identifiers. After receiving the call request from the microservice consumer, the target provider instance in the microservice provider processes the tasks in the request, such as executing business logic or data processing.

[0068] Based on the business logic and interface specifications, the microservice consumer constructs a call instance request, which includes necessary information such as the method name, parameters, authentication information, and request headers. The microservice consumer uses protocols such as HTTP (Hypertext Transfer Protocol) and network transport layer technologies such as TCP / IP (Transmission Control Protocol / Internet Protocol) to send the call request to the network address and port of the target provider instance. After receiving the request, the target provider instance's network service component (such as a web server or message queue) performs preliminary parsing and validation before beginning the task. Upon completion, the microservice provider prepares the result as a response message (containing the task execution result, status code, response headers, and other information) and returns it to the microservice consumer over the network. Upon receiving the response, the microservice consumer parses and validates it, and based on the response content, determines subsequent actions (such as processing business logic or returning it to the front-end). Based on business needs, requests can be compressed, encrypted, or batched to reduce network transmission overhead and improve efficiency.

[0069] In this embodiment, by deploying the container microservice consumer cluster, the container microservice provider cluster and the registration center in the container area, and the container microservice consumer cluster includes multiple microservice consumers, the container microservice provider cluster includes multiple microservice providers, and at least one microservice provider instance is deployed in the microservice provider, it is possible to implement a microservice provider deployed with at least one microservice provider instance and the microservice consumer in the same container area, thereby avoiding the phenomenon that when the microservice consumer calls the microservice provider instance in the microservice provider due to the regionalization of the container application network address and the non-fixed network address, the container application upstream and downstream microservice calls fail.

[0070] The registration center also stores and manages microservice provider instance information in real time based on the microservice provider's registration instance request. Therefore, after a microservice consumer initiates a service discovery request instruction to the registration center, the registration center will build a provider instance list based on the stored information of at least one microservice provider instance from all microservice providers in the same container area as the microservice consumer, and send it to the microservice consumer. This ensures that when the microservice consumer initiates a call, it can accurately obtain a list of available microservice provider instances in the same container area as itself. The microservice consumer then intelligently selects a target provider instance from the provider instance list. This process can make intelligent decisions based on factors such as service status and load, thereby optimizing resource utilization and improving overall system performance. Finally, a call instance request is sent to the selected target provider instance, which processes the task in real time. This step ensures the efficient execution of the service call. In general, this application achieves precise matching of service discovery and calling processes, and can effectively avoid the occurrence of call failures caused by the regionalization and non-fixedness of container application network addresses even in complex and changeable network environments. It further enhances the accuracy, stability and availability of the system, reduces the risk of call failures, and provides a strong guarantee for the stable operation of the microservice architecture.

[0071] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned first embodiment can be referred to the above introduction and will not be repeated later.

[0072] It should be noted that the execution subject terminal of this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a server, intelligent system, tablet computer, personal computer, mobile phone, etc., or an electronic device capable of implementing the above functions. The following uses a microservice provider as an example to illustrate this embodiment.

[0073] In this embodiment, the Dubbo containerized deployment method is applied to any microservice provider in a container microservice provider cluster. At least one microservice provider instance is deployed in the microservice provider. The container microservice provider cluster is deployed in a container area. The container area also includes a registration center and a container microservice consumer cluster. The container microservice consumer cluster includes multiple microservice consumers, including steps A10 to A20:

[0074] Step A10: Initiate a registration instance request instruction to the registration center, wherein the registration center stores the microservice provider instance information of at least one microservice provider instance in the microservice provider according to the registration instance request instruction. After receiving the service discovery request sent by the microservice consumer, the registration center constructs a provider instance list based on at least one microservice provider instance information of all stored microservice providers in the same container area as the microservice consumer, and sends the provider instance list to the microservice consumer. The microservice consumer selects a microservice provider instance information in the provider instance list as the target provider instance information, and sends a call instance request to the microservice provider instance corresponding to the target provider instance information.

[0075] It's important to note that the instance registration request is a command sent by the microservice provider to the registry to register its own instance's service instance information, such as the address, port, and service. After a microservice provider instance is successfully registered, the registry can periodically send health check requests to the service provider instance to verify its availability. If an instance fails, the registry can remove it from the list and no longer return it during service discovery, preventing microservice consumers from connecting to faulty microservice provider instances.

[0076] Step A20: If there is a microservice provider instance that receives the instance call request in at least one microservice provider instance, the task corresponding to the instance call request is processed according to the microservice provider instance that receives the instance call request.

[0077] It should be noted that for time-consuming tasks, asynchronous calls can be considered. This involves placing the call request in a message queue, which the service provider then processes and returns the result asynchronously. Furthermore, fault-tolerance strategies such as retries, timeouts, and circuit breakers can be implemented on the microservice provider side to address issues such as network failures and service unavailability.

[0078] For example, assume there are three microservice provider instances A, B, and C, which are deployed in container area 1 respectively, and the registration center records their instance information. When microservice consumer D is located in container area 1 and needs to call a service, it sends a service discovery request to the registration center. The registration center compares the address of the service discovery request, filters out the three instances A, B, and C in the same container area as D (i.e., container area 1) from the stored information, builds a provider instance list [A, B, C], and sends it to D. D selects B as the target provider instance through the load balancing strategy and sends a call instance request to B, requesting it to process a certain task. After receiving the request, B, as the target provider instance, begins processing the task.

[0079] This embodiment provides a Dubbo containerized deployment method to ensure that microservice providers only respond to call requests from microservice consumers within the same container, thereby avoiding the problem of cross-container call failures. Under this strategy, microservice providers register their instance information with a registry, enabling the registry to track and manage the status of all available instances in real time. When a microservice consumer initiates a service discovery request, the registry returns a list of healthy provider instances within the same container region. The consumer then selects the optimal target provider instance from this list based on factors such as service health and load balancing. Once selected, the consumer directly sends a call request to that instance, and the provider immediately responds and processes the task, ensuring efficient and smooth service calls. In summary, this embodiment not only achieves precise integration of service discovery and call processes, but also significantly improves the system's adaptability to changing network environments. It effectively resolves call challenges caused by dynamic changes in container network addresses, reduces the probability of service call failures, and establishes a solid defense for the robust operation of the microservice architecture.

[0080] Based on the second embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the second embodiment can be referred to above and will not be described in detail later. Figure 4 and Figure 5 , Figure 4 This is a flow chart of the third embodiment of the Dubbo containerized deployment method of this application. Figure 5 This is a schematic diagram of the third embodiment of the Dubbo containerized deployment method of this application. Step A10, the method of initiating a registration instance request to the registration center also includes steps B10 to B60:

[0081] Step B10: If an update instruction is received, the microservice provider instance corresponding to the update instruction in each microservice provider instance is updated according to the update instruction to obtain a grayscale instance;

[0082] It's important to note that an update instruction is a command used to update a microservice provider instance, typically including the specific content and version information of the update. A grayscale instance is a microservice provider instance that has been updated but not yet fully rolled out, used to test new features or updates within a limited scope.

[0083] A system administrator or automated deployment tool detects a new software version or configuration change and triggers the sending of an update instruction. This instruction typically contains the name of the microservice to be updated, its version number, and an overview of the update details. After receiving the update instruction, the registry or a dedicated configuration management service parses the instruction and determines which microservice provider instances need to be updated. The specific contents of the update instruction are deployed as a grayscale instance, and the new software version or configuration is run on the grayscale instance.

[0084] Step B20: Send the grayscale instance information corresponding to the grayscale instance to the registration center, where the registration center updates the stored microservice provider instance information based on the grayscale instance information;

[0085] It should be noted that the grayscale instance information includes a data set of detailed information such as the status, version, and weight of the grayscale instance.

[0086] After the grayscale instance is deployed, it registers its own instance information with the registration center, including the network address, port, version, weight, etc. In this embodiment, the initial weight of the grayscale instance is set to 1, which is the lowest weight preset by the registration center. The registration center will distribute the request traffic according to the set weight. The specific distribution method includes weighted polling, weighted random algorithms, etc., which can be freely set according to the actual situation. In this embodiment, the weighted polling algorithm is used as an example to illustrate that by setting the weight, the traffic distribution ratio of different service instances can be adjusted. Instances with high weights will receive more traffic. For example, if there is a service instance with a weight of 10 and a total weight of 100, it will handle 10% of the traffic.

[0087] Step B30: sending a first query instruction to the registration center according to a preset time interval for querying the grayscale instance weight, wherein the first query instruction represents the grayscale instance weight contained in the grayscale instance information being queried;

[0088] It's important to note that the interval for querying grayscale instance weights is configurable. This refers to the time interval used to periodically query grayscale instance weights. For grayscale instances with a small user base, the first interval can be shortened to enable faster version updates. For grayscale instances with a large user base or with high service stability requirements, the first interval can be lengthened to ensure a smooth transition to new versions.

[0089] Step B40: receiving the grayscale instance weight returned by the registration center based on the first query instruction;

[0090] It should be noted that when the registration center is unavailable or returns incorrect weight information, the grayscale instance can resend the first query instruction to the registration center.

[0091] Step B50, determining whether the grayscale instance weight is greater than or equal to the preset release weight;

[0092] It should be noted that the preset release weight is a weight threshold used to determine whether the grayscale instance is ready for full promotion. It can be freely set according to actual conditions and can be the highest weight preset by the registration center. In this embodiment, the preset release weight is set to 100. If the weight of the grayscale instance is greater than or equal to the preset release weight, then it can be considered that the instance has reached the predetermined level of promotion and can be considered for inclusion in a wider user group for testing. In a feasible embodiment, multiple preset release weights can be set to divide the grayscale release process into multiple stages. Clear goals and evaluation criteria are set for each stage to ensure that the stability and reliability of the grayscale version are gradually improved.

[0093] In a feasible implementation, step B50 may include step B501:

[0094] Step B501: If the grayscale instance weight is less than the preset publishing weight, the grayscale instance weight in the registry is increased according to the preset weighting coefficient, and the step of initiating a grayscale instance weight query instruction to the registry at the preset grayscale instance weight query time interval is continued;

[0095] It should be noted that if the grayscale instance weight is less than the preset release weight, it indicates that the grayscale instance has not yet received all traffic and is not ready for full rollout. In this case, the grayscale instance increases its weight based on the preset weighting factor. The value obtained by multiplying the preset weighting factor by its own weight can be used as the new grayscale instance weight. The registration center is notified to update the recorded grayscale instance weight to the new grayscale instance weight. Other ways to increase weight include percentage increases and exponential increases. In this embodiment, a preset fixed value is used. The fixed value is based on the sequence a [1, 2, 4, 8, 16, 32, 64, 100] obtained when the preset weighting factor is 2. This sequence is transformed based on the total request traffic and the number of instances to obtain the sequence b [1, 3, 6, 12, 25, 50, 100]. This sequence includes 25 and 50, two important weight change nodes. When the weight is 25, the grayscale instance receives one-quarter of the total request traffic. When the weight is 50, the grayscale instance receives one-quarter of the total request traffic.

[0096] For example, assuming that the time interval for querying the grayscale instance weight is five minutes and the preset release weight is 100, refer to Figure 5When the instance to be updated receives the update instruction, it begins the release operation and deploys the grayscale instance. The grayscale instance also queries the registry for its grayscale instance weight every five minutes and determines whether the grayscale instance weight has reached 100. For example, if the grayscale instance weight returned by the registry in a query is 50, which is clearly not 100, the grayscale instance will initiate a request to the registry to double the weight, that is, to change the grayscale instance weight to 100. Five minutes later, the grayscale instance continues to query the registry and receives a grayscale instance weight of 100, reaching the preset release weight, and the grayscale release is complete.

[0097] In this embodiment, by using such a weight-increasing method, the traffic receiving ratio of the grayscale instance can be steadily increased, the risk of new version release can be reduced, and the stability of the system can be significantly improved.

[0098] Step B60: If the grayscale instance weight is greater than or equal to the preset release weight, it is determined that the grayscale instance release is completed.

[0099] It should be noted that if the purpose of the grayscale release is to completely replace the old version of the service instance, then after confirming that the new version of the grayscale instance is running stably and reaches the preset release weight, the microservice provider instance corresponding to the update instruction in step B10 can be safely destroyed.

[0100] In this example, a method for gradually increasing the weight of grayscale instances through scheduled tasks enables grayscale releases of microservice instances. This ensures a smooth transition to new versions and high system availability, enhances system stability and reliability, and reduces the risks associated with version updates. Furthermore, the automated weight adjustment process improves operational efficiency and reduces the likelihood of human error.

[0101] Based on the second embodiment of the present application, in the fourth embodiment of the present application, the same or similar contents as those in the above embodiment can be referred to the above introduction, and will not be repeated in detail. Figure 6 and Figure 7 , Figure 6 This is a flowchart of the fourth embodiment of the Dubbo containerized deployment method of this application. Figure 7 This is a schematic diagram of the fourth embodiment of the Dubbo containerized deployment method of this application. Step A10, the method of initiating a registration instance request to the registration center also includes steps C10 to C40:

[0102] Step C10: If a logout instruction is received, a second query instruction is sent to the registration center according to a preset time interval for querying the weight of the instance to be logged out, wherein the second query instruction represents querying the weight of the instance to be logged out contained in the instance information corresponding to the instance to be logged out, and the instance to be logged out is the microservice provider instance corresponding to the logout instruction;

[0103] It should be noted that the exit instruction is a signal indicating that a microservice provider instance needs to be removed from the service.

[0104] Upon receiving the exit command, the instance invokes the graceful exit method and sends a second query command to a registry (such as Eureka, Consul, Zookeeper, etc.) at a preset interval (e.g., every 5 seconds) to query the weight of the instance currently being exited. The preset interval for querying the weight of the instance being exited is configurable. If the weight of the instance being exited is high, indicating that it is currently processing many or important requests, the query interval can be extended until the weight drops below a certain threshold. If the weight is low or there are no requests being processed, the query interval can be shortened to expedite the exit process.

[0105] Step C20: receiving the weight of the instance to be deregistered returned by the registration center based on the second query instruction;

[0106] It should be noted that in this embodiment, the weight of the instance to be decommissioned refers to the proportion of request traffic allocated to the instance among all instances providing the same service. This weight reflects the importance and activity of the instance to be decommissioned in the total service traffic and is a key indicator of its contribution to the service.

[0107] Step C30, determining whether the weight of the instance to be exited is less than or equal to the preset exit weight;

[0108] It should be noted that the preset exit weight is a set weight threshold used to determine whether the instance to be exited can be disabled without affecting the overall stability of the environment. In this embodiment, the preset release weight can be set to 1. If the weight of the instance to be exited is less than or equal to the preset exit weight, the instance is considered to have a low current load and can be safely exited.

[0109] In a feasible implementation, step C30 may include step C301:

[0110] Step C301: If the weight of the instance to be exited is greater than the preset exit weight, the weight of the instance to be exited in the registration center is reduced according to the preset weight reduction coefficient, and the step of initiating a query instruction to query the weight of the instance to be exited to the registration center according to the preset time interval for querying the weight of the instance to be exited is continued.

[0111] It should be noted that if the weight of the instance to be decommissioned is greater than the preset publishing weight, it indicates that the instance to be decommissioned can still receive traffic and is not yet ready to be disabled. The instance to be decommissioned then reduces its weight according to the preset decommissioning factor. The value obtained by multiplying the preset decommissioning factor by its own weight can be used as the new grayscale instance weight. The registration center is then notified to update the recorded grayscale instance weight to the new grayscale instance weight. In this embodiment, the method of decommissioning the grayscale instance weight according to the preset fixed value is consistent with the method of obtaining data in step B501, so it will not be repeated here.

[0112] For example, during the second query, if the weight of the instance to be exited is 50, which is greater than the preset exit weight of 1, the instance to be exited will send a request to the registry to change its weight to 25. Assuming the second interval is five minutes, after five minutes, the instance to be exited will continue to send a query to the registry for its weight, entering the next cycle.

[0113] In this embodiment, such a weight reduction method can be used to control risks during the exit process, ensure that the service maintains high availability during the exit process, avoid service interruption, and achieve a lossless exit effect.

[0114] Step C40: If the weight of the instance to be exited is less than or equal to the preset exit weight, the registration center is notified to disable the instance to be exited.

[0115] It should be noted that disabling is to remove the instance to be decommissioned from the service so that it no longer receives new traffic.

[0116] For example, assuming that the time interval for querying the weight of the instance to be exited is five minutes, and the preset exit weight is 1, refer to Figure 7When the instance to be exited receives the exit command, it begins a graceful exit. Every five minutes, the instance to be exited queries the registry for its weight and determines whether it is 1. If, in a particular query, the instance receives a weight of 2, it will initiate a request to the registry to reduce its weight exponentially, changing its weight to 1. Five minutes later, the instance to be exited queries the registry again and receives a grayscale weight of 1, reaching the preset exit weight. The instance to be exited then immediately initiates a series of pre-exit preparations. These preparations include, but are not limited to: first, stopping new requests by closing or redirecting relevant ports to avoid introducing new workload during the exit process; second, efficiently managing and processing all received but outstanding requests, ensuring that each request is properly processed, either through completion or transfer to another healthy instance through a retry mechanism; and finally, the instance to be exited cleans up local resources, such as freeing up memory and closing database connections, to reduce resource usage and potential resource leaks. After all necessary preparations have been completed and all requests have been properly processed, the instance to be exited will gracefully shut down its processes or containers. At this point, it will also proactively send a disable request to the registry, informing the registry that the instance will soon be or has become unavailable, and requesting the registry to remove the instance's information from the service list to ensure that other services or clients do not continue to send new requests to it. After receiving the disable request, the registry will update its service registry and may trigger some additional cleanup or notification operations to ensure the overall consistency and availability of the system. Finally, once the registry confirms that the instance has been disabled and removed from the service list, the instance to be exited can safely destroy its processes or containers, releasing all occupied resources, thus completing the entire graceful exit process. This series of steps is designed to minimize the impact on running services and clients and ensure the stability and reliability of the system.

[0117] In this embodiment, by gradually reducing the weight of the instance to be exited through a scheduled task, a lossless exit of the microservice instance is achieved, ensuring a smooth service transition and a consistent user experience. This enhances the controllability and flexibility of the system and reduces the risk of service interruption caused by service exit. Furthermore, the automated weight adjustment process improves operational efficiency and reduces the possibility of human error.

[0118] It should be noted that, under the condition that the technology is feasible and the logic is clear, the above embodiments can be combined in pairs or in multiple combinations.

[0119] It should be noted that the above examples are only used to understand this application and do not constitute a limitation on the Dubbo containerized deployment method of this application. More simple transformations based on this technical concept are all within the scope of protection of this application.

[0120] This application also provides a Dubbo containerized deployment system, which includes a registration center deployed in a container area, a container microservice provider cluster, and a container microservice consumer cluster. The container microservice consumer cluster includes multiple microservice consumers, and at least one microservice provider instance is deployed in the microservice provider in the container microservice consumer cluster:

[0121] Microservice provider, used to initiate registration instance request instructions to the registration center;

[0122] Microservice consumers, used to initiate service discovery request instructions to the registration center;

[0123] The registration center is used to store microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, it builds a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer, and sends the provider instance list to the microservice consumer;

[0124] The microservice consumer receives the provider instance list returned by the registration center based on the service discovery request instruction, selects a microservice provider instance information in the provider instance list as the target provider instance information; and sends a call instance request to the microservice provider instance corresponding to the target provider instance information;

[0125] The microservice provider is configured to process a task corresponding to the instance call request if there is a microservice provider instance that receives the instance call request in at least one microservice provider instance.

[0126] The Dubbo containerized deployment system provided in this application, which utilizes the Dubbo containerized deployment method described in the aforementioned embodiments, can resolve the technical issue of failures in upstream and downstream microservice calls to container applications due to regionalized and non-fixed network addresses. Compared to the prior art, the beneficial effects of the Dubbo containerized deployment system provided in this application are the same as those of the Dubbo containerized deployment method described in the aforementioned embodiments. Other technical features of the Dubbo containerized deployment system are the same as those disclosed in the aforementioned embodiments and are not further elaborated upon here.

[0127] The present application provides a Dubbo containerized deployment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the Dubbo containerized deployment method in the above-mentioned embodiment one.

[0128] Reference below Figure 8 , which shows a schematic diagram of the structure of a Dubbo containerized deployment device suitable for implementing an embodiment of the present application. The Dubbo containerized deployment device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions: tablet computers), PMPs (Portable Media Players: portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., as well as fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The Dubbo containerized deployment device shown is only an example and should not limit the functions and scope of use of the embodiments of this application.

[0129] like Figure 8As shown, the Dubbo containerized deployment device may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the Dubbo containerized deployment device are also stored in RAM1004. The processing device 1001, ROM1002 and RAM1004 are connected to each other via a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the Dubbo containerized deployment device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a Dubbo containerized deployment device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have instead.

[0130] In particular, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0131] The Dubbo containerized deployment device provided in this application, using the Dubbo containerized deployment method described in the above-mentioned embodiments, can resolve the technical issue of failures in upstream and downstream microservice calls to container applications due to regionalized and non-fixed network addresses. Compared to the prior art, the beneficial effects of the Dubbo containerized deployment device provided in this application are the same as those of the Dubbo containerized deployment method described in the above-mentioned embodiments. Other technical features of the Dubbo containerized deployment device are the same as those disclosed in the above-mentioned embodiments and are not further elaborated here.

[0132] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0133] The above are only specific embodiments of the present application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

[0134] The present application provides a medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, and the computer-readable program instructions are used to execute the Dubbo containerized deployment method in the above embodiment.

[0135] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0136] The above-mentioned computer-readable storage medium can be included in the Dubbo containerized deployment device; or it can exist independently without being assembled into the Dubbo containerized deployment device.

[0137] The above-mentioned computer-readable storage medium carries one or more programs, and the above-mentioned one or more programs can be executed by the Dubbo containerized deployment device.

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

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

[0140] The modules described in the embodiments of the present application may be implemented in software or hardware, wherein the name of a module does not necessarily limit the unit itself.

[0141] The computer-readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the aforementioned Dubbo containerized deployment method, which can solve the technical problems of Dubbo containerized deployment. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the Dubbo containerized deployment method provided in the aforementioned embodiment, and are not further elaborated here.

[0142] The present application also provides a product, which is a computer program product, including a computer program, which implements the steps of the Dubbo containerized deployment method as described above when the computer program is executed by a processor.

[0143] The computer program product provided in this application can resolve the technical problem of container application upstream and downstream microservice call failures caused by the regionalization and non-fixed network addresses of container applications. Compared with the existing technology, the beneficial effects of the computer program product provided in this application are the same as those of the Dubbo containerized deployment method provided in the above embodiment, and will not be repeated here.

[0144] The above are only some embodiments of the present application and are not intended to limit the patent scope of the present application. All equivalent structural transformations made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect application in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A Dubbo container deployment method, characterized in that: Applied to any microservice consumer in a container microservice consumer cluster, the container microservice consumer cluster is deployed in a container area, the container area also includes a registration center and a container microservice provider cluster, the container microservice provider cluster includes multiple microservice providers, and at least one microservice provider instance is deployed in the microservice provider, the method includes: Initiate a service discovery request instruction to the registration center, wherein the registration center stores the microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, build a provider instance list based on at least one microservice provider instance information of all microservice providers in the same container area as the microservice consumer, and send the provider instance list to the microservice consumer; wherein, the microservice provider initiates a registration instance request instruction to the registration center, and if an update instruction is received, the microservice provider corresponding to the update instruction in each of the microservice provider instances is updated according to the update instruction. The grayscale instance is updated to obtain a grayscale instance; the grayscale instance information corresponding to the grayscale instance is sent to the registration center, wherein the registration center updates the stored microservice provider instance information according to the grayscale instance information; a first query instruction is sent to the registration center according to a preset time interval for querying the grayscale instance weight, wherein the first query instruction represents a query for the grayscale instance weight contained in the grayscale instance information; the grayscale instance weight returned by the registration center based on the first query instruction is received; whether the grayscale instance weight is greater than or equal to the preset release weight; if the grayscale instance weight is greater than or equal to the preset release weight, it is determined that the grayscale instance release is completed; Receive a provider instance list returned by the registration center based on the service discovery request instruction, and select a microservice provider instance information from the provider instance list as the target provider instance information; Send a call instance request to the microservice provider instance corresponding to the target provider instance information, wherein the microservice provider instance corresponding to the target provider instance information processes the task corresponding to the call instance request.

2. A Dubbo container deployment method, characterized in that: Applied to any microservice provider in a container microservice provider cluster, wherein at least one microservice provider instance is deployed in the microservice provider, the container microservice provider cluster is deployed in a container area, the container area further includes a registration center and a container microservice consumer cluster, the container microservice consumer cluster includes multiple microservice consumers, and the method includes: Initiate a registration instance request instruction to the registration center, wherein the registration center stores the microservice provider instance information of at least one microservice provider instance in the microservice provider according to the registration instance request instruction, and after receiving the service discovery request sent by the microservice consumer, build a provider instance list based on at least one microservice provider instance information of all stored microservice providers in the same container area as the microservice consumer, and send the provider instance list to the microservice consumer. The microservice consumer selects a microservice provider instance information in the provider instance list as the target provider instance information, and sends a call instance request to the microservice provider instance corresponding to the target provider instance information; If there is a microservice provider instance that receives the instance call request in at least one microservice provider instance, processing the task corresponding to the instance call request according to the microservice provider instance that receives the instance call request; After the step of initiating a registration instance request to the registration center, the method further includes: If an update instruction is received, the microservice provider instance corresponding to the update instruction in each of the microservice provider instances is updated according to the update instruction to obtain a grayscale instance; Sending the grayscale instance information corresponding to the grayscale instance to the registration center, wherein the registration center updates the stored microservice provider instance information according to the grayscale instance information; Sending a first query instruction to the registration center according to a preset time interval for querying the grayscale instance weight, wherein the first query instruction represents querying the grayscale instance weight included in the grayscale instance information; Receiving the grayscale instance weight returned by the registration center based on the first query instruction; Determine whether the grayscale instance weight is greater than or equal to a preset release weight; If the grayscale instance weight is greater than or equal to the preset release weight, it is determined that the grayscale instance release is completed.

3. The method according to claim 2, wherein After the step of determining whether the grayscale instance weight is greater than or equal to the preset release weight, the method further includes: If the grayscale instance weight is less than the preset release weight, the grayscale instance weight in the registration center is weighted according to the preset weight increase coefficient, and the step of initiating a query instruction for querying the grayscale instance weight to the registration center according to the preset time interval for querying the grayscale instance weight is continued.

4. The method according to claim 2, wherein After the step of initiating a registration request to the registration center, the method further includes: If an exit instruction is received, a second query instruction is sent to the registration center according to a preset time interval for querying the weight of the instance to be exited, wherein the second query instruction represents a query for the weight of the instance to be exited contained in the instance information to be exited corresponding to the instance to be exited, and the instance to be exited is the microservice provider instance corresponding to the exit instruction; receiving the weight of the instance to be deregistered returned by the registration center based on the second query instruction; Determine whether the weight of the instance to be exited is less than or equal to a preset exit weight; If the weight of the instance to be exited is less than or equal to the preset exit weight, the registration center is notified to disable the instance to be exited.

5. The method according to claim 4, wherein After the step of determining whether the weight of the instance to be exited is less than or equal to the preset exit weight, the following steps are performed: If the weight of the instance to be exited is greater than the preset exit weight, the weight of the instance to be exited in the registration center is reduced according to the preset de-weighting coefficient, and the step of initiating a query instruction to query the weight of the instance to be exited to the registration center according to the preset time interval for querying the weight of the instance to be exited is continued.

6. A Dubbo containerized deployment system, characterized in that: It includes a registration center, a container microservice provider cluster, and a container microservice consumer cluster deployed in the container area. The container microservice consumer cluster includes multiple microservice consumers. At least one microservice provider instance is deployed in the microservice provider in the container microservice provider cluster. The microservice provider is used to initiate a registration instance request instruction to the registration center; wherein, after the step of initiating a registration instance request to the registration center, it also includes: if an update instruction is received, updating the microservice provider instance corresponding to the update instruction in each of the microservice provider instances according to the update instruction to obtain a grayscale instance; sending the grayscale instance information corresponding to the grayscale instance to the registration center, wherein the registration center updates the stored microservice provider instance information according to the grayscale instance information; sending a first query instruction to the registration center according to a preset time interval for querying the grayscale instance weight, wherein the first query instruction represents a query for the grayscale instance weight contained in the grayscale instance information; receiving the grayscale instance weight returned by the registration center based on the first query instruction; judging whether the grayscale instance weight is greater than or equal to the preset release weight; if the grayscale instance weight is greater than or equal to the preset release weight, determining that the grayscale instance release is complete; The microservice consumer is used to initiate a service discovery request instruction to the registration center; The registration center is used to store microservice provider instance information according to the registration instance request instruction sent by the microservice provider, and after receiving the service discovery request instruction, build a provider instance list based on at least one microservice provider instance information of all stored microservice providers in the same container area as the microservice consumer, and send the provider instance list to the microservice consumer; The microservice consumer is configured to receive a provider instance list returned by the registration center based on the service discovery request instruction, select a microservice provider instance information from the provider instance list as the target provider instance information; and send a call instance request to the microservice provider instance corresponding to the target provider instance information; The microservice provider is configured to process a task corresponding to the instance call request if there is a microservice provider instance that receives the instance call request in at least one microservice provider instance.

7. A Dubbo containerized deployment device, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the Dubbo containerized deployment method according to any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the Dubbo containerized deployment method according to any one of claims 1 to 5.

9. A computer program product, characterized in that The computer program product includes a computer program, which, when executed by a processor, implements the steps of the Dubbo containerized deployment method according to any one of claims 1 to 5.

Images