Service grid system generation method, device, and service grid system

Abstract

The present disclosure provides a method, device, service grid system, computer system and computer-readable storage medium for generating a service grid system. The generating method includes: deploying sidecar containers in multiple running carriers respectively; obtaining service discovery data related to business programs in the running carriers; synchronizing the service discovery data related to business programs in the running carriers to the sidecar containers; and generating a service grid system according to the multiple sidecar containers with synchronized service discovery data.

Description

Technical Field

[0001] The present disclosure relates to the field of microservice technology, and more specifically, to a method and device for generating a service grid system, a service grid system, a computer system, and a computer-readable storage medium. Background Art

[0002] With the further development of microservice architecture and the rise of cloud-native concepts, the shortcomings of traditional microservice architecture are increasingly questioned and challenged. In order to solve some of the problems faced by traditional microservice architecture, service mesh technology came into being.

[0003] In the process of implementing the concepts disclosed herein, the inventors discovered that there are at least the following problems in the current service mesh technology: the current service mesh system has poor environmental adaptability and usually needs to be built on a specific operating environment or operating system, which makes it difficult for many users to enjoy the benefits brought by the service mesh technology. Summary of the invention

[0004] In view of this, the present disclosure provides a method and apparatus for generating a service grid system, a service grid system, a computer system, and a computer-readable storage medium.

[0005] One aspect of the present disclosure provides a method for generating a service mesh system, including: deploying sidecar containers in multiple running carriers respectively; obtaining service discovery data related to business programs in the running carriers; synchronizing the service discovery data related to the business programs in the running carriers to the sidecar containers; and generating the service mesh system based on the multiple sidecar containers with synchronized service discovery data.

[0006] According to an embodiment of the present disclosure, obtaining service discovery data related to the business program in the running carrier includes: obtaining registration data from different cluster registration centers; obtaining configuration data from different cluster configuration centers; and using the registration data and the configuration data as the service discovery data.

[0007] According to an embodiment of the present disclosure, the deploying of sidecar containers in multiple running carriers respectively includes: compiling a container image file according to a set program; obtaining target resource file information according to the container image file, wherein the target resource file information has configuration information related to the container image file; and deploying the sidecar container for the running carrier according to the target resource file information.

[0008] According to an embodiment of the present disclosure, obtaining target resource file information according to the container image file includes: obtaining initial resource file information; capturing the initial resource file information through a callback program; and modifying relevant configuration information of the initial resource file information according to the container image file to obtain the target resource file information.

[0009] According to an embodiment of the present disclosure, the generation method of the above-mentioned service grid system also includes: obtaining a calling logic business program; redirecting the calling logic business program to a first sidecar container, wherein the calling logic business program and the first sidecar container belong to the same first running carrier; determining a second sidecar container according to the service discovery data in the first sidecar container; determining a service logic business program according to the service discovery data in the second sidecar container, wherein the second sidecar container and the service logic business program belong to the same second running carrier; and realizing data communication between the calling logic business program in the first running carrier and the service logic business program in the second running carrier according to the first sidecar container and the second sidecar container.

[0010] According to an embodiment of the present disclosure, redirecting the calling logic business program to the first sidecar container includes: obtaining address information of the export traffic of the calling logic business program; and redirecting the address information of the export traffic of the calling logic business program to the address of the first sidecar container according to the network address translation protocol.

[0011] According to an embodiment of the present disclosure, determining the service logic business program based on the service discovery data in the second sidecar container includes: obtaining the address information of the ingress traffic of the second running carrier; and redirecting the address information of the ingress traffic of the second running carrier to the address of the service logic business program according to the network address translation protocol.

[0012] Another aspect of the present disclosure provides a service mesh system, including: a deployment subsystem for respectively deploying sidecar containers in multiple running carriers; a service mesh subsystem for obtaining service discovery data related to business programs in the running carriers; and a data plane subsystem for synchronizing the service discovery data related to the business programs in the running carriers to the sidecar containers, and generating the service mesh system based on multiple sidecar containers with synchronized service discovery data.

[0013] Another aspect of the present disclosure provides a device for generating a service grid system, including: a deployment module for respectively deploying sidecar containers in multiple running carriers; an acquisition module for acquiring service discovery data related to business programs in the running carriers; a synchronization module for synchronizing the service discovery data related to the business programs in the running carriers to the sidecar containers; and a generation module for generating the service grid system according to multiple sidecar containers with synchronized service discovery data.

[0014] Another aspect of the present disclosure provides a computer system, including: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described above.

[0015] Another aspect of the present disclosure provides a computer-readable storage medium storing computer-executable instructions, which are used to implement the above method when executed.

[0016] Another aspect of the present disclosure provides a computer program, which includes computer executable instructions, and the instructions are used to implement the method described above when executed.

[0017] According to the embodiments of the present disclosure, by respectively deploying sidecar containers in multiple operating carriers, obtaining service discovery data related to the business programs in the operating carriers, synchronizing the service discovery data related to the business programs in the operating carriers to the sidecar containers, and generating a service grid system based on multiple sidecar containers with synchronized service discovery data, since the deployment of sidecar containers and the acquisition and synchronization of service discovery data do not need to rely on a specific operating environment or operating system, the technical problem of the low environmental adaptability of the current service grid system is at least partially overcome, thereby obtaining a service grid system that can run in various operating environments or operating systems, and will not be unable to implement the service grid technology due to environmental restrictions, and can further enjoy the technical effects of the dividends brought by the service grid technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The above and other objects, features and advantages of the present disclosure will become more apparent through the following description of the embodiments of the present disclosure with reference to the accompanying drawings, in which:

[0019] Figure 1 An exemplary system architecture to which a method for generating a service grid system according to an embodiment of the present disclosure can be applied is schematically shown;

[0020] Figure 2 A flow chart schematically shows a method for generating a service grid system according to an embodiment of the present disclosure;

[0021] Figure 3 A flowchart of obtaining service discovery data related to a business program in a running carrier according to an embodiment of the present disclosure is schematically shown;

[0022] Figure 4 A flowchart of respectively deploying sidecar containers in multiple running carriers according to an embodiment of the present disclosure is schematically shown;

[0023] Figure 5 A flowchart of obtaining target resource file information according to a container image file according to an embodiment of the present disclosure is schematically shown;

[0024] Figure 6 Schematically shows a flow chart of data communication in a service grid system according to an embodiment of the present disclosure;

[0025] Figure 7 The architecture diagram of the service grid system according to the embodiment of the present disclosure is schematically shown;

[0026] Figure 8 A timing diagram of data communication in a service grid system relying on K8S according to an embodiment of the present disclosure is schematically shown;

[0027] Fig. 9 A timing diagram of data communication in a non-K8S service grid system according to an embodiment of the present disclosure is schematically shown;

[0028] Fig.10 A schematic diagram showing the principle of traffic hijacking at the calling end in the data plane subsystem according to an embodiment of the present disclosure is shown;

[0029] Fig.11 The schematic diagram shows the principle diagram of server traffic hijacking in the data plane subsystem according to an embodiment of the present disclosure;

[0030] Fig.12 The schematic diagram of service registration / discovery across K8S clusters in the Istio subsystem according to an embodiment of the present disclosure is shown;

[0031] Fig.13 Schematically shows an Isti according to an embodiment of the present disclosure. o Schematic diagram of the service configuration function across K8S clusters in the subsystem;

[0032] Fig.14 A block diagram schematically shows a device for generating a service grid system according to an embodiment of the present disclosure; and

[0033] Fig.15 A block diagram of a computer system suitable for implementing the method for generating a service grid system described above according to an embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0034] Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present disclosure. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present disclosure. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of the concepts of the present disclosure.

[0035] The terms used herein are only for describing specific embodiments and are not intended to limit the present disclosure. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0036] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification, and should not be interpreted in an idealized or overly rigid manner.

[0037] In the case of using expressions such as "at least one of A, B, and C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.). In the case of using expressions such as "at least one of A, B, or C, etc.", it should generally be interpreted in accordance with the meaning of the expression generally understood by those skilled in the art (for example, "a system having at least one of A, B, or C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0038] In view of the tight coupling between RPC SDK (library program for completing remote procedure calls, which needs to be compiled with business code and run in one process) and business code in traditional microservice architecture, which restricts their independent development, RPC SDK bugs (failures) or the addition of new features requires business cooperation for online upgrades; poor observability, difficult and costly problem location, many interdependent microservices form a complex call chain, and problem location is complicated and requires cross-business and cross-departmental collaboration for troubleshooting; lack of traffic management and grayscale management, and does not support features such as "traffic splitting and migration", "error and timeout injection", "canary release"; and poor security, a service mesh technology was born. The Istio system (the de facto standard for current service mesh technology) is now the most popular service mesh system in the industry, and is the leader and integrator of many current service mesh technologies.

[0039] However, in the process of realizing the concept of the present disclosure, the inventor found that the realization of service grid technology requires the Istio system to be completely built on the K8S (Kubernetes, a container cluster scheduling management system, a recognized standard for container cluster management platforms) system, and the two are closely related. Specifically, including: the core object "service" in Istio needs to reuse the Service CRD of K8S; the service registration mechanism needs to utilize the internal mechanism of K8S; various rules and policies within Istio need to be described based on the CRD mechanism of K8S, and its storage needs to use the etcd database of K8S; Istio's data plane needs to run in the pod of K8S with the business container in the form of SideCar, and the data plane container needs to be transparently injected into the business Pod through the Hook mechanism of K8S; Istio's own deployment and cluster management also need to make full use of the mechanism of K8S, such as using Service (service), Deployment (deployment) and other K8S CRDs. However, in production practice, many users use K8S, but its version is too low and does not meet some requirements of Istio, which makes it impossible to use the Istio system to implement service mesh. There are even many users who do not use K8S at all, so they cannot use Istio. However, due to the strong coupling relationship between the Istio system and K8S, these users need to either migrate the system to K8S from scratch or upgrade K8S to enjoy the benefits of the Istio system when they need to build a service mesh system. However, due to the extreme importance and huge complexity of K8S as an infrastructure, whether it is migration from scratch or upgrading K8S, it means huge costs and risks for production systems, and serious accidents will occur if you are not careful.

[0040] Among them, CRD is the abbreviation of Custom Resource Definition, which is an extension mechanism of K8S for the resource objects it manages. Through this mechanism, users can define many resource objects that K8S does not have natively, thereby expanding the functions of K8S. etcd database is a k / v storage, and K8S uses it as the storage of CRD objects. SideCar, commonly known as "sidecar", is a container deployment mode in the container cluster management platform (such as K8S), which refers to starting a container in the Pod where the business is located to complete certain non-business-related functions (such as logging, monitoring, etc.). Simply put, it is a way to deploy non-business-related containers in a 1:1 ratio. Pod is the smallest unit of K8S container scheduling. A Pod can have multiple containers, and these containers share a set of environments (such as TCP / IP network stack and other resources). Container is a lightweight virtualization technology. A physical machine can be virtualized into many containers to improve resource utilization. The Hook mechanism is a plug-in mode injection mode, which directly relies on the HOOK mechanism to expand business functions within the system.

[0041] In the process of implementing the concept of the present disclosure, the inventors also found that due to the strong dependence of Istio on K8S, it is easily affected by the limitations of K8S itself. For example, K8S's Service CRD naturally only supports a single cluster, so it does not support services across K8S clusters (although the K8S community has a solution, it is still immature in the experimental stage and cannot be applied to the production environment). The reason for this problem is: currently each K8S cluster has its own exclusive etcd database, so the same-name services defined in different K8S clusters are located in different etcd databases. Since the two etcd databases have no connection, the business container in a K8S cluster can only perceive the services in this cluster, but not the services in other K8S clusters.

[0042] The embodiments of the present disclosure provide a method, device, service grid system, computer system and computer-readable storage medium for generating a service grid system. The generating method includes respectively deploying sidecar containers in multiple running carriers; obtaining service discovery data related to business programs in the running carriers; synchronizing the service discovery data related to business programs in the running carriers to the sidecar containers; and generating a service grid system according to the multiple sidecar containers with synchronized service discovery data.

[0043] Figure 1 The exemplary system architecture 100 to which the method for generating a service grid system according to an embodiment of the present disclosure can be applied is schematically shown. It should be noted that: Figure 1What is shown is merely an example of a system architecture to which the embodiments of the present disclosure can be applied, in order to help those skilled in the art understand the technical content of the present disclosure, but it does not mean that the embodiments of the present disclosure cannot be used in other devices, systems, environments or scenarios.

[0044] like Figure 1 As shown, the system architecture 100 according to this embodiment may include terminal devices 101, 102, 103, a network 104 and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired and / or wireless communication links, etc.

[0045] The terminal devices 101, 102, 103 can interact with the server 105 through the network 104 to receive or send control instructions, etc. Various operating environments can be provided on the terminal devices 101, 102, 103, for example, systems such as Linux and Unix can be installed, or Pod, Docker, etc. can be set, wherein Pod and Docker are both open source application container engines.

[0046] The terminal devices 101 , 102 , and 103 may be various electronic devices having display screens and supporting different system configurations, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0047] The server 105 may be a server that provides various services, such as a background management server that provides configuration information, control instructions or service discovery data to the terminal devices 101, 102, 103. The background management server may analyze and process the received request instructions, and feed back the processing results (such as instruction information generated according to the configuration information, etc.) to the terminal device.

[0048] It should be noted that the method for generating the service grid system provided in the embodiment of the present disclosure can generally be executed by the server 105. Accordingly, the service grid system provided in the embodiment of the present disclosure can generally be set in the server 105. The method for generating the service grid system provided in the embodiment of the present disclosure can also be executed by a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Accordingly, the service grid system provided in the embodiment of the present disclosure can also be set in a server or server cluster that is different from the server 105 and can communicate with the terminal devices 101, 102, 103 and / or the server 105. Alternatively, the method for generating the service grid system provided in the embodiment of the present disclosure can also be executed by the terminal devices 101, 102 or 103, or can also be executed by other terminal devices different from the terminal devices 101, 102 or 103. Accordingly, the service grid system provided in the embodiment of the present disclosure can also be set in the terminal devices 101, 102 or 103, or can be set in other terminal devices different from the terminal devices 101, 102 or 103.

[0049] For example, the sidecar container, business program, service discovery data and / or control instructions based thereon may be originally stored in any one of the terminal devices 101, 102 or 103 (for example, the terminal device 101, but not limited thereto), or stored in an external storage device and may be imported into the terminal device 101. Then, the terminal device 101 may locally execute the method for generating the service grid system provided in the embodiment of the present disclosure, or send the sidecar container, business program, service discovery data and / or control instructions based thereon to other terminal devices, servers, or server clusters, and the other terminal devices, servers, or server clusters that receive the sidecar container, business program, service discovery data and / or control instructions based thereon may execute the method for generating the service grid system provided in the embodiment of the present disclosure.

[0050] It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0051] Figure 2 The flowchart of the method for generating a service grid system according to an embodiment of the present disclosure is schematically shown.

[0052] like Figure 2 As shown, the method includes operations S201 to S204.

[0053] In operation S201 , sidecar containers are deployed in multiple running carriers respectively.

[0054] According to an embodiment of the present disclosure, an operation carrier is used to provide an operation environment for an application program. The operation carrier may be, for example, a physical machine, a VM (Virtual Machine) virtual machine, or a Pod on a K8S system, and the multiple operation carriers may be on the same physical machine, virtual machine, or K8S system, for example, different Pods in the same K8S system, for managing different business programs. A container may be, for example, a container built by Docker software on a physical machine or VM virtual machine, or a container built in a Pod. A sidecar container is a container for running data plane programs. The data plane program may be, for example, SideCar, Proxy, or Enovy, wherein SideCar, Proxy, and Enovy are all programs that implement forwarding proxy work, and the data plane program running in the sidecar container is used as an intermediate agent to implement data communication between specific business programs.

[0055] According to the embodiments of the present disclosure, business programs and data plane programs run in different containers, and the various programs in different containers are independent of each other and do not interfere with each other. Therefore, to achieve normal communication between services in the service grid system, the first thing is to inject a sidecar container into each party's business program to implement the proxy service. Among them, each party of the business program can be, for example, the caller, the callee, the client, or the service party, and each party's business program can include multiple businesses to implement the same or different tasks.

[0056] It should be noted that there can be one or more sidecar containers. Generally, there is only one sidecar container. In some cases, for example, when a complete business requires several aspects to be completed together, multiple sidecar containers may be generated as needed. Each sidecar container corresponds to a different aspect of the data plane program. Multiple sidecar containers work together to complete the application or access of the business.

[0057] It should also be noted that each party's business program and the sidecar container injected into the corresponding business program are located on the same running carrier. Business programs of different parties are located on different running carriers, and the sidecar containers corresponding to business programs of different parties are located on the running carrier corresponding to the business program.

[0058] In operation S202, service discovery data related to the business program in the running carrier is obtained.

[0059] According to an embodiment of the present disclosure, service discovery data may include, for example, a service instance and a target address and a target port related to the service instance, so as to determine the traffic flow direction of the related service and realize targeted service communication.

[0060] According to the embodiments of the present disclosure, the service discovery data may change at different times, for example, the related service instances may increase or decrease, or the underlying machine related to providing a certain service may have abnormalities such as power failure, network disconnection, memory overflow or insufficient disk capacity, resulting in the unavailability of the service instance, etc. Therefore, it is necessary to obtain the latest service discovery data related to the business program in real time to ensure the feasibility and integrity of the completion of the business.

[0061] It should be noted that the above service discovery data can be directly obtained from the existing system data by establishing a connection relationship with the existing network system, or can also be obtained in a customized manner.

[0062] In operation S203 , service discovery data related to the business program in the running carrier is synchronized to the sidecar container.

[0063] According to an embodiment of the present disclosure, the service discovery data with dynamic changes obtained through the above operations is synchronized to the sidecar container in real time, and the data plane program is updated in real time according to the changes, thereby ensuring the reliability of business communication between different operating carriers.

[0064] In operation S204 , a service mesh system is generated according to the multiple sidecar containers that synchronize the service discovery data.

[0065] According to an embodiment of the present disclosure, by setting independent running containers for business programs and data plane programs respectively in different running carriers, and implementing the configuration of a complete sidecar container based on the acquired service discovery data and the data plane program, business communication between different running carriers (for example, may include business interactions such as service discovery and load balancing) can be achieved through the sidecar container, and all these programs together constitute a complete service grid system.

[0066] According to the embodiments of the present disclosure, by respectively deploying sidecar containers in multiple operating carriers, obtaining service discovery data related to the business programs in the operating carriers, synchronizing the service discovery data related to the business programs in the operating carriers to the sidecar containers, and generating a service grid system based on multiple sidecar containers with synchronized service discovery data, since the deployment of sidecar containers and the acquisition and synchronization of service discovery data do not need to rely on a specific operating environment or operating system, the technical problem of the low environmental adaptability of the current service grid system is at least partially overcome, thereby obtaining a service grid system that can run in various operating environments or operating systems, and will not be unable to implement the service grid technology due to environmental restrictions, and can further enjoy the technical effects of the dividends brought by the service grid technology.

[0067] According to an embodiment of the present disclosure, the service mesh system may be, for example, an Istio system partially built on a K8S system, or may be an Istio system built on a non-K8S system. The sidecar container may be deployed by, for example, directly configuring the Istio data plane program in the system environment provided by K8S, or may be deployed by designing a specific running program. The service discovery data may be obtained directly based on the original existing K8S cluster, or may be obtained by establishing a connection relationship with other system clusters. The process of synchronizing the service discovery data to the sidecar container may be directly implemented based on the environment provided by the K8S system, or may be implemented through other synchronization methods.

[0068] Through the above-mentioned embodiments of the present disclosure, it is possible to partially or completely break away from the K8S system environment and generate a complete service mesh system, which changes the strong dependency relationship between the Istio system and K8S and turns the relationship between the two into a weak dependency or even an independent relationship, thereby greatly changing and promoting the implementation of Istio, making its implementation easier and with very low risks, and further enjoying the benefits brought by Istio.

[0069] Reference below Figure 3 to Figure 6 , combined with specific embodiments Figure 2 The method shown is further explained.

[0070] Figure 3 The flowchart of acquiring service discovery data related to a business program in a running carrier according to an embodiment of the present disclosure is schematically shown.

[0071] like Figure 3 As shown, the method includes operations S301 to S303.

[0072] In operation S301, registration data from different cluster registration centers is obtained.

[0073] According to the embodiments of the present disclosure, the registration data characterizes the operating status of the underlying devices related to the application service, such as whether it is available for normal operation, whether it is available, etc. If it is unavailable, it will be deleted from the registration data to maintain the normal and stable operation of the entire system. The registration center completes the above maintenance work, and the registration center can be one or multiple across clusters. Different clusters can be clusters of any nature, such as existing server clusters, K8S system clusters or other clusters.

[0074] In operation S302, configuration data from different cluster configuration centers is obtained.

[0075] According to an embodiment of the present disclosure, configuration data represents configuration information related to services and systems. A configuration center completes maintenance work on configuration data, and the configuration center may be one or multiple across clusters.

[0076] In operation S303, the registration data and configuration data are used as service discovery data.

[0077] According to the embodiments of the present disclosure, the registration data and configuration data distributed in different clusters are synchronized to a unified control plane platform by means of plug-ins. The unified control plane platform can be, for example, the Pilot module of the Istio system (the module in the control plane of the Istio system responsible for completing service discovery, traffic management, and intelligent routing). When the Pilot program starts, it runs a configuration file, which includes the addresses of different clusters for completing service discovery. By running the configuration file, the communication between the Pilot and each cluster is realized, and the above synchronization process is completed.

[0078] It should be noted that Pilot itself does not perform service discovery. It only synchronizes the service discovery data in the cluster to its own memory. Each cluster implements the function of a registration center or a configuration center.

[0079] Through the above-mentioned embodiments of the present disclosure, only the Pilot module of the Istio system is used in the process of implementing the service grid system, reducing many dependencies on K8S in native Istio. At the same time, the above-mentioned Pilot module obtained through the embodiments of the present disclosure can be regarded as an ordinary application, which can directly realize data communication with different clusters, effectively solving the problem that native Istio does not support service registration / discovery and service configuration across K8S clusters.

[0080] Figure 4 The flowchart of respectively deploying sidecar containers in multiple running carriers according to an embodiment of the present disclosure is schematically shown.

[0081] like Figure 4 As shown, the method includes operations S401 to S403.

[0082] In operation S401, a container image file is compiled according to a setting program.

[0083] According to an embodiment of the present disclosure, the setting program is the above-mentioned data plane program, which is compiled to obtain a binary image image, that is, a container image file.

[0084] In operation S402, target resource file information is obtained according to the container image file, wherein the target resource file information has configuration information related to the container image file.

[0085] According to an embodiment of the present disclosure, the target resource file information may also include, for example, the target running carrier for the business program, the specifications of the target running carrier (such as CPU, memory, etc.), the image file, the relevant path and other configuration information. The configuration information related to the container image file may include, for example, information related to SideCar, path code, and some additional other attributes.

[0086] In operation S403, a sidecar container is deployed for the running carrier according to the target resource file information.

[0087] According to an embodiment of the present disclosure, a target running carrier is determined according to target resource file information, and then the target running carrier loads the above-mentioned image image to obtain a sidecar container.

[0088] Figure 5 The flowchart of obtaining target resource file information according to a container image file according to an embodiment of the present disclosure is schematically shown.

[0089] like Figure 5 As shown, the method includes operations S501 to S503.

[0090] In operation S501, initial resource file information is acquired.

[0091] According to an embodiment of the present disclosure, the initial resource file information does not include the above-mentioned configuration information related to the container image file.

[0092] In operation S502, the initial resource file information is captured through a callback program.

[0093] According to an embodiment of the present disclosure, the callback program may be, for example, a Hook program developed on K8S.

[0094] In operation S503, the configuration information related to the initial resource file information is modified according to the container image file to obtain the target resource file information.

[0095] According to an embodiment of the present disclosure, when it is necessary to release a business program, the Hook program in the previous operation will be actively called, and the Hook program will modify the relevant configuration information to include the configuration information related to the container image file (that is, the information related to the sidecar container), and finally obtain the target resource file information.

[0096] Through the above-mentioned embodiments of the present disclosure, K8S can automatically start the sidecar container when it actually starts to release the business. During this process, the user can still use the past business release process and does not need to do anything extra to start the sidecar container, thereby achieving the automatic and transparent effect of data plane program injection.

[0097] Figure 6 The flowchart of data communication in the service grid system according to an embodiment of the present disclosure is schematically shown.

[0098] like Figure 6 As shown, the method includes operations S601 to S605.

[0099] In operation S601, a calling logic service program is obtained.

[0100] According to an embodiment of the present disclosure, the calling logic service program may be, for example, a specific application software, which has service-side data that needs to be accessed during normal operation.

[0101] In operation S602, the calling logic service program is redirected to the first sidecar container, wherein the calling logic service program and the first sidecar container belong to the first running carrier.

[0102] According to an embodiment of the present disclosure, the first sidecar container is a proxy service program for the application software, such as SideCar or Proxy. The call traffic or communication data of the logical business program will be intercepted by the SideCar or Proxy during actual communication, and the SideCar or Proxy will replace it to complete the subsequent communication.

[0103] In operation S603 , a second sidecar container is determined according to the service discovery data in the first sidecar container.

[0104] According to an embodiment of the present disclosure, the second sidecar container is the SideCar or Proxy of the service party that needs to be accessed.

[0105] In operation S604, a service logic business program is determined according to the service discovery data in the second sidecar container, wherein the second sidecar container and the service logic business program belong to the same second running carrier.

[0106] According to an embodiment of the present disclosure, the service logic business program is the service provider that the above-mentioned application software ultimately needs to access, and the service provider is also finally determined through SideCar or Proxy.

[0107] In operation S605 , data communication between the calling logic service program in the first running carrier and the service logic service program in the second running carrier is implemented according to the first sidecar container and the second sidecar container.

[0108] According to an embodiment of the present disclosure, the above operation S602 also includes: obtaining address information of the egress traffic that calls the logical business program; and redirecting the address information of the egress traffic that calls the logical business program to the address of the first sidecar container according to the network address translation protocol.

[0109] According to an embodiment of the present disclosure, the above operation S604 also includes: obtaining address information of the ingress traffic of the second running carrier; and redirecting the address information of the ingress traffic of the second running carrier to the address of the service logic business program according to the network address translation protocol.

[0110] Through the above-mentioned embodiments of the present disclosure, the sidecar container can be obtained through the transparently injected data plane program to realize the communication between business services. Before that, it is more coordinated with the above-mentioned specific environment construction methods such as removing K8S dependency and cross-service clusters, so as to obtain a service grid system with high environmental compatibility.

[0111] Figure 7 The following schematically shows an architecture diagram of a service grid system according to an embodiment of the present disclosure.

[0112] It should be noted that the control plane of the native Istio system includes three main modules: Polit, Mixer and Istio-Auth. Among them, Polit is used to implement service discovery, traffic management, intelligent routing and other functions, Mixer is used to implement telemetry-related functions, and Istio-Auth mainly completes the mTLS secure communication function. Among them, mTLS is a two-way TLS (Secure Transport Layer Protocol) secure communication mechanism. These three modules of the native Istio system are strongly coupled with K8S. The purpose of this disclosure is to reduce Istio's strong dependence on K8S, thereby reducing the risks of migrating and upgrading K8S, and even making Istio independent of K8S, and building a service mesh system that can be used in a more open environment.

[0113] Before the implementation of this disclosure, Mixer was removed from this disclosure because it would cause performance issues. The mTLS secure communication function of Istio-Auth is not particularly needed in the internal network environment of an enterprise, so it was also removed from this disclosure. Removing these two modules can remove many K8S-related dependencies in native Istio. The Polit module is retained as the focus, and it completes the service discovery and service configuration functions. The Polit module communicates with the data plane through the xDS protocol. After the data plane receives relevant information, it can complete the backend service addressing, traffic management, grayscale management and other functional features. The above three modules of native Istio mainly rely on K8S's apiserver (application interface service, specifically the apiserver exposed by K8S, through which other programs interact with K8S) to access the corresponding CRD objects. By modifying native Istio and adding relevant switch parameters to control Polit, Mixer and Istio-Auth to access K8S's apiserver, they can be prevented from interacting directly with K8S (other dependencies on K8S can also be solved in a similar way), thereby achieving the goal of completely removing K8S dependencies.

[0114] like Figure 7 As shown, the service mesh system disclosed in the present invention includes a data subsystem, a data plane subsystem and a service mesh subsystem.

[0115] The deployment subsystem is used to deploy sidecar containers in multiple runtimes.

[0116] According to the embodiments of the present disclosure, the "deployment subsystem" mainly solves the problem of automatic injection of data plane programs (taking Proxy as an example here) (i.e., the deployment problem of the sidecar container). In the service grid technology, the Proxy and the business program are located in one place (such as the same physical machine, VM virtual machine or Pod), but they are two independent processes, but they share the same TCP / IP network stack facilities. From a deployment perspective, the business program has nothing to do with the Proxy, and users should not be aware of the existence of the Proxy, so the problem of automatic Proxy injection must be solved.

[0117] The service grid subsystem is used to obtain service discovery data related to the business programs running in the carrier.

[0118] According to the embodiments of the present disclosure, the "Istio subsystem" (i.e., the service mesh subsystem) plays the role of the "brain" in the service mesh technology and is the control plane of the service mesh technology. The Istio subsystem communicates with the sidecar container injected with Proxy in the data plane through the xDS protocol (the API for interaction between the data plane and the control plane in the service mesh, and the xDS control plane can dynamically complete the configuration and control of the data plane), and dynamically completes the configuration and control of the sidecar container, such as telling the IP / Port (address / port) of the backend service instance of the relevant process in the sidecar container, routing rules, etc.

[0119] The data plane subsystem is used to synchronize the service discovery data related to the business program in the running carrier to the sidecar container, and to generate a service mesh system based on multiple sidecar containers that synchronize the service discovery data.

[0120] According to the embodiments of the present disclosure, the "data plane subsystem" is the place in the service mesh technology where the communication between microservices is specifically completed. The access traffic of the business program (including the calling end and the service end) is redirected to the above-mentioned sidecar container through the traffic hijacking mechanism, and the sidecar container completes tasks including protocol encoding and decoding, service registration / discovery, routing, health detection, load balancing, etc. The business logic and the Proxy in the sidecar container are two independent processes, and the two are completely decoupled. The business logic only needs to concentrate on completing the business itself, and the remaining non-business logic is all completed by the Proxy. The upgrade of the Proxy through the "hot upgrade" technology will not cause the interruption of the business logic. Currently available Proxy includes open source implementations such as Envoy (the data plane of Istio standard), Mosn (the data plane implementation provided by Ant Financial), and they are all compatible with the xDS protocol.

[0121] Through the above embodiments of the present disclosure, the Istio subsystem only retains the Pilot module in the native Istio system for synchronizing service discovery data, and removes the Mixer and Istio-Auth modules. Therefore, the Istio subsystem without K8S dependency can be understood as just an ordinary application and can be treated as an ordinary application. It can be deployed in an environment without K8S or in a low-version K8S environment that does not support Istio.

[0122] According to the embodiments of the present disclosure, there are two solutions to the problem of automatic injection of data plane programs (taking Proxy as an example) in the above-mentioned deployment subsystem level.

[0123] Solution 1: Compile the container image file according to the set program; obtain the initial resource file information; capture the initial resource file information through the callback program; modify the relevant configuration information of the initial resource file information according to the container image file to obtain the target resource file information; and deploy the sidecar container for the running carrier according to the target resource file information. Complete the automatic injection of the Proxy.

[0124] Figure 8 A timing diagram of data communication in a service grid system relying on K8S according to an embodiment of the present disclosure is schematically shown.

[0125] like Figure 8 As shown, operations S801 to S807 are included, wherein operations S801 to S803 complete the automatic injection of the Proxy that depends on K8S.

[0126] In operation S801, when publishing the business program, K8S resource files and configurations are delivered.

[0127] According to an embodiment of the present disclosure, when a deployment platform needs to release an application, some resource files and configurations must first be filled in for further transmission. The resource files and configurations are the initial resource file information in the above-mentioned solution one.

[0128] In operation S802, find relevant information and modify the K8S resource file.

[0129] According to an embodiment of the present disclosure, the deployment platform transmits the originally edited resource file (ie, the initial resource file information) to a callback program (eg, a Hook program), and then the callback program modifies the resource file.

[0130] In operation S803, the modified K8S resource file (including Proxy related information) is returned.

[0131] According to an embodiment of the present disclosure, the modified K8S resource file is the target resource file information in the above-mentioned solution one, and the target resource file information is returned to the deployment platform.

[0132] In operation S804 , the sidecar container into which the Proxy is injected is started.

[0133] In operation S805, work is started and communication is established with the service discovery data provider (IstioPilot) of the service mesh subsystem to receive configuration information.

[0134] In operation S806 , the business logic container is started.

[0135] In operation S807, the work starts and data communication is performed when necessary (by the Proxy).

[0136] According to the embodiment of the present disclosure, in the solution that relies on K8S, by developing the Hook program of K8S and then registering it in K8S, when K8S wants to release the business program, it will actively call the Hook program, and the Hook program will include the Proxy related information by modifying the relevant configuration information, so that when K8S actually starts to release the business, it will automatically start the Proxy (i.e., operation S804). In this process, the user still uses the past business release process and does not need to do anything extra for this, thereby achieving an automatic and transparent effect.

[0137] Solution 2: Compile the container image file according to the set program; obtain the target resource file information according to the container image file, wherein the target resource file information has configuration information related to the container image file; and deploy the sidecar container for the running carrier according to the target resource file information. Automatic injection of non-K8S Proxy is completed.

[0138] Fig. 9 A timing diagram of data communication in a non-K8S service grid system according to an embodiment of the present disclosure is schematically shown.

[0139] like Fig. 9 As shown, operations S901 to S907 are included, wherein operations S901 to S903 complete the automatic injection of non-K8S Proxy.

[0140] In operation S901, the service program starts to be released.

[0141] In operation S902, the Proxy related information (package location, etc.) is searched and the corresponding configuration information is generated.

[0142] According to an embodiment of the present disclosure, the corresponding configuration information is the configuration information related to the container image file in the above-mentioned solution 2.

[0143] In operation S903, the program package and configuration file of the Proxy are downloaded to the corresponding execution carrier.

[0144] According to an embodiment of the present disclosure, what is obtained through this operation is the sidecar container with the target resource file information obtained through the above-mentioned solution 2.

[0145] In operation S904, the Proxy program is started on the corresponding execution carrier.

[0146] In operation S905, work is started and communication is established with the service discovery data provider (IstioPilot) of the service mesh subsystem to receive configuration information.

[0147] In operation S906, return.

[0148] In operation S907, continue with the other original steps.

[0149] According to the embodiments of the present disclosure, in the non-K8S solution, the service release process of the existing deployment platform is modified, and a new link is inserted before starting the service program. This link first downloads the binary file and configuration information of the Proxy to the corresponding running carrier (such as a physical machine, virtual machine VM or Pod), and then starts the proxy, and then continues according to the original process. By modifying the service release process of the existing deployment platform, the Proxy injection can also be made transparent to the user.

[0150] It can be seen from the above two solutions that whether it is a K8S platform or a non-K8S platform, automatic transparent injection of Proxy can be achieved. Therefore, through the above implementation scheme of the present disclosure, the sidecar container can be deployed on any running carrier (physical machine, virtual machine VM or Pod) in any environment.

[0151] According to an embodiment of the present disclosure, the above-mentioned data plane subsystem level is targeted.

[0152] Fig.10 The schematic diagram shows the principle of calling end traffic hijacking in the data plane subsystem according to an embodiment of the present disclosure.

[0153] According to the embodiments of the present disclosure, in the data plane subsystem, sending a request to the server without changing the calling end code involves the problem of traffic hijacking. Generally, the network address translation protocol (Iptables technology, a tool for configuring and controlling the behavior of the TCP / IP protocol stack of the operating system kernel, is commonly found in the Linux operating system). Traffic hijacking at the calling end involves hijacking the export traffic of the calling logic. The principle is as follows: Fig.10 shown.

[0154] See also Fig.10 Since the calling logic business program (taking the calling end process as an example) and the first sidecar container (taking the Proxy process as an example) belong to the same TCP / IP network stack, the egress traffic from the calling end to the server can be redirected to the Proxy. This utilizes the NAT (Network Address Translation) mechanism of Iptables. By writing relevant rules for the OUTPUT basic chain of Iptables, the IP address of the destination end during the communication process is changed here to achieve the purpose of redirecting the egress traffic.

[0155] Fig.11 The schematic diagram shows the principle of server-side traffic hijacking in the data plane subsystem according to an embodiment of the present disclosure.

[0156] According to the embodiments of the present disclosure, combined with the above-mentioned traffic hijacking principle for the calling end, without changing the server code, the server receives the request involving the hijacking of the inlet traffic. The principle is as follows: Fig.11 shown.

[0157] See also Fig.11 Since the service logic business program (taking the server process as an example) and the second sidecar container (taking the Proxy process as an example) belong to the same TCP / IP network stack, the ingress traffic of the running carrier where the server is located can be redirected to the Proxy. The NAT mechanism of Iptables is also used. By writing relevant rules for the PREROUTING basic chain of Iptables, the IP address of the communication destination is also changed here to achieve the purpose of redirecting the ingress traffic.

[0158] based on Fig.10 and Fig.11 The traffic hijacking method includes: obtaining the calling logic business program of the calling end instance; redirecting the calling logic business program to the first sidecar container of the calling end instance; determining the second sidecar container of the server instance according to the service discovery data in the first sidecar container of the calling end instance; determining the service logic business program of the server instance according to the service discovery data in the second sidecar container of the server instance; and realizing data communication between the calling end instance and the server instance according to the first sidecar container of the calling end instance and the second sidecar container of the server instance.

[0159] Through the hijacking principle of the egress and ingress traffic in the above embodiments of the present disclosure, it can be seen that the calling end and the service end fully utilize the functions of the sidecar container injected with Proxy to complete various functions of the microservice, but they themselves only do business-related things. Due to the universality of the Iptables mechanism, traffic hijacking can be completed regardless of the running carrier (physical machine, virtual machine VM or Pod) and whether it is a K8S environment.

[0160] According to an embodiment of the present disclosure, the above-mentioned Istio subsystem level is targeted.

[0161] Fig.12 A schematic diagram of service registration / discovery across K8S clusters in the Istio subsystem according to an embodiment of the present disclosure is shown.

[0162] According to the embodiments of the present disclosure, Fig.12As shown in the figure, there is only one centralized "custom registration center" in the whole system. All server instances (regardless of whether they are across K8S clusters or other deployment forms) register their IP / PORT to the custom registration center for unified registration and management. There is also only one module in the whole system that provides service discovery data related to service registration / discovery, such as the Istio Pilot module. All callers communicate with Polit through the xDS protocol to obtain the server IP / PORT information. By implementing a plug-in in Polit, the data synchronization of "service IP / PORT" with the custom registration center in the "list / watch" mode is realized. In this way, the problem of native Istio's support for cross-K8S cluster service registration / discovery is solved. Among them, the list / watch mechanism is a data synchronization methodology. The Watch mechanism means that in addition to loading the data of the registration center into the memory through the list, the plug-in also has a watch mechanism. The watch mechanism notifies the Pilot when the data changes, and then merges the changed data with the original list data to form new data to ensure the accuracy of the data in the Pilot.

[0163] Similar to the fact that native Istio does not support service registration / discovery across K8S clusters, there are similar problems with service configuration information. Istio Pilot provides rules and policy objects such as VirtualService (virtual service) and DestinationRule (custom rule) to control the data plane.

[0164] Fig.13 A schematic diagram of the service configuration function across K8S clusters in the Istio subsystem according to an embodiment of the present disclosure is shown.

[0165] According to the embodiments of the present disclosure, Fig.13 As shown in the figure, there is only one centralized "custom configuration center" in the entire system, and all configuration information is managed by it. There is also only one module in the entire system that provides service discovery data related to service configuration, such as the Istio Pilot module. All sidecar containers (including the caller or the server, and regardless of whether they are deployed across K8S clusters or in other deployment forms) communicate with Pilot through the xDS protocol to obtain relevant configuration information. By implementing a plug-in in Pilot, data synchronization of "service configuration" with the custom configuration center is achieved in a "list / watch" manner. In this way, the problem of native Istio's support for cross-K8S cluster service configuration is solved.

[0166] Through the above-mentioned embodiments of the present disclosure, the "custom registration center" is implemented through the extension mechanism of Istio to complete the service registration / discovery function across K8S clusters, and the "custom configuration center" is implemented to complete the service configuration function across K8S clusters, which effectively solves the problem that native Istio does not support service registration / discovery and service configuration across K8S clusters.

[0167] Fig.14 A block diagram of a device for generating a service grid system according to an embodiment of the present disclosure is schematically shown.

[0168] like Fig.14 As shown, the service grid system generation device 1400 includes a deployment module 1410, an acquisition module 1420, a synchronization module 1430 and a generation module 1440.

[0169] The deployment module 1410 is used to deploy the sidecar container in multiple running carriers respectively.

[0170] The acquisition module 1420 is used to acquire service discovery data related to the business program in the running carrier.

[0171] The synchronization module 1430 is used to synchronize the service discovery data related to the business program in the running carrier to the sidecar container.

[0172] The generation module 1440 is used to generate the service mesh system according to the multiple sidecar containers that synchronize the service discovery data.

[0173] According to the embodiments of the present disclosure, by respectively deploying sidecar containers in multiple operating carriers, obtaining service discovery data related to the business programs in the operating carriers, synchronizing the service discovery data related to the business programs in the operating carriers to the sidecar containers, and generating a service grid system based on multiple sidecar containers with synchronized service discovery data, since the deployment of sidecar containers and the acquisition and synchronization of service discovery data do not need to rely on a specific operating environment or operating system, the technical problem of the low environmental adaptability of the current service grid system is at least partially overcome, thereby obtaining a service grid system that can run in various operating environments or operating systems, and will not be unable to implement the service grid technology due to environmental restrictions, and can further enjoy the technical effects of the dividends brought by the service grid technology.

[0174] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes a first acquisition submodule, a second acquisition submodule and a definition submodule.

[0175] The first acquisition submodule is used to acquire registration data from different cluster registration centers.

[0176] The second acquisition submodule is used to obtain configuration data from different cluster configuration centers.

[0177] Defines submodules for registering and configuring data as service discovery data.

[0178] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes a compilation submodule, a third acquisition submodule and a deployment submodule.

[0179] The compilation submodule is used to compile the container image file according to the set program.

[0180] The third acquisition submodule is used to acquire target resource file information according to the container image file, wherein the target resource file information has configuration information related to the container image file.

[0181] The deployment submodule is used to deploy the sidecar container for the running carrier according to the target resource file information.

[0182] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes an acquisition unit, a capture unit and a modification unit.

[0183] The acquisition unit is used to obtain initial resource file information.

[0184] The capture unit is used to capture the initial resource file information through the callback program.

[0185] The modification unit is used to modify the relevant configuration information of the initial resource file information according to the container image file to obtain the target resource file information.

[0186] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes an acquisition unit, a redirection unit, a first determination unit, a second determination unit and a communication unit.

[0187] The acquisition unit is used to acquire the calling logic business program.

[0188] The redirection unit is used to redirect the calling logic business program to the first sidecar container, wherein the calling logic business program and the first sidecar container belong to the first running carrier.

[0189] The first determining unit is configured to determine the second sidecar container according to the service discovery data in the first sidecar container.

[0190] The second determining unit is used to determine the service logic business program according to the service discovery data in the second sidecar container, wherein the second sidecar container and the service logic business program belong to the same second running carrier.

[0191] The communication unit is used to implement data communication between the calling logic business program in the first running carrier and the service logic business program in the second running carrier according to the first sidecar container and the second sidecar container.

[0192] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes a first acquisition subunit and a first redirection subunit.

[0193] The first acquisition subunit is used to acquire the address information of the egress traffic of the calling logic service program.

[0194] The first redirection subunit is used to redirect the address information of the egress traffic that calls the logical business program to the address of the first sidecar container according to the network address translation protocol.

[0195] According to an embodiment of the present disclosure, the above-mentioned service grid system generation device also includes a second acquisition subunit and a second redirection subunit.

[0196] The second acquisition subunit is used to acquire the address information of the inlet traffic of the second running carrier.

[0197] The second redirection subunit is used to redirect the address information of the ingress traffic of the second operation carrier to the address of the service logic business program according to the network address translation protocol.

[0198] According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits, or at least part of the functions of any one of them can be implemented in one module. According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits can be split into multiple modules for implementation. According to the embodiments of the present invention, any one or more of the modules, submodules, units, and subunits can be at least partially implemented as hardware circuits, such as field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), systems on chips, systems on substrates, systems on packages, application specific integrated circuits (ASICs), or can be implemented by hardware or firmware in any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in any appropriate combination of any of them. Alternatively, according to the embodiments of the present invention, one or more of the modules, submodules, units, and subunits can be at least partially implemented as computer program modules, and when the computer program modules are run, the corresponding functions can be performed.

[0199] For example, any multiple of the deployment module 1410, the acquisition module 1420, the synchronization module 1430, and the generation module 1440 can be combined into one module / submodule / unit / subunit for implementation, or any one of the modules / submodules / units / subunits can be split into multiple modules / submodules / units / subunits. Alternatively, at least part of the functions of one or more of these modules / submodules / units / subunits can be combined with at least part of the functions of other modules / submodules / units / subunits and implemented in one module / submodule / unit / subunit. According to an embodiment of the present disclosure, at least one of the deployment module 1410, the acquisition module 1420, the synchronization module 1430, and the generation module 1440 may be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or may be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or by any one of the three implementation methods of software, hardware, and firmware, or by an appropriate combination of any of them. Alternatively, at least one of the deployment module 1410, the acquisition module 1420, the synchronization module 1430, and the generation module 1440 may be at least partially implemented as a computer program module, and when the computer program module is executed, the corresponding function may be performed.

[0200] It should be noted that the service grid system part and the service grid system generation device part in the embodiments of the present disclosure correspond to the service grid generation method part in the embodiments of the present disclosure. The description of the service grid system part and the service grid system generation device part specifically refers to the service grid system generation method part, which will not be repeated here.

[0201] Fig.15 A block diagram of a computer system suitable for implementing the method for generating a service grid system described above according to an embodiment of the present disclosure is schematically shown. Fig.15 The computer system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0202] like Fig.15As shown, the computer system 1500 according to the embodiment of the present disclosure includes a processor 1501, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1502 or the program loaded from the storage part 1508 to the random access memory (RAM) 1503. The processor 1501 may include, for example, a general-purpose microprocessor (such as a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (for example, an application-specific integrated circuit (ASIC)), etc. The processor 1501 may also include an onboard memory for caching purposes. The processor 1501 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present disclosure.

[0203] In RAM 1503, various programs and data required for the operation of system 1500 are stored. Processor 1501, ROM 1502 and RAM 1503 are connected to each other through bus 1504. Processor 1501 performs various operations of the method flow according to the embodiment of the present disclosure by executing the program in ROM 1502 and / or RAM 1503. It should be noted that the program can also be stored in one or more memories other than ROM 1502 and RAM 1503. Processor 1501 can also perform various operations of the method flow according to the embodiment of the present disclosure by executing the program stored in the one or more memories.

[0204] According to an embodiment of the present disclosure, the system 1500 may further include an input / output (I / O) interface 1505, which is also connected to the bus 1504. The system 1500 may further include one or more of the following components connected to the I / O interface 1505: an input section 1506 including a keyboard, a mouse, etc.; an output section 1507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1508 including a hard disk, etc.; and a communication section 1509 including a network interface card such as a LAN card, a modem, etc. The communication section 1509 performs communication processing via a network such as the Internet. A drive 1510 is also connected to the I / O interface 1505 as needed. A removable medium 1511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 1510 as needed, so that a computer program read therefrom is installed into the storage section 1508 as needed.

[0205] According to an embodiment of the present disclosure, the method flow according to an embodiment of the present disclosure can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable storage medium, and the computer program contains a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 1509, and / or installed from the removable medium 1511. When the computer program is executed by the processor 1501, the above-mentioned functions defined in the system of the embodiment of the present disclosure are executed. According to an embodiment of the present disclosure, the system, equipment, device, module, unit, etc. described above can be implemented by a computer program module.

[0206] The present disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present disclosure is implemented.

[0207] According to an embodiment of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium. For example, it may include, but is not limited to: 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), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, apparatus, or device.

[0208] For example, according to an embodiment of the present disclosure, the computer-readable storage medium may include the ROM 1502 and / or the RAM 1503 described above and / or one or more memories other than the ROM 1502 and the RAM 1503 .

[0209] The flowcharts 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 disclosure. In this regard, each box in the flowchart or block diagram may represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box may also occur in an order different from 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 or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions. It can be understood by those skilled in the art that the features recorded in the various embodiments and / or claims of the present disclosure can be combined and / or combined in a variety of ways, even if such a combination or combination is not explicitly recorded in the present disclosure. In particular, without departing from the spirit and teaching of the present disclosure, the features described in the various embodiments and / or claims of the present disclosure may be combined and / or combined in a variety of ways. All of these combinations and / or combinations fall within the scope of the present disclosure.

[0210] The embodiments of the present disclosure are described above. However, these embodiments are only for illustrative purposes and are not intended to limit the scope of the present disclosure. Although the embodiments are described above separately, this does not mean that the measures in the various embodiments cannot be used in combination to advantage. The scope of the present disclosure is defined by the attached claims and their equivalents. Without departing from the scope of the present disclosure, those skilled in the art may make a variety of substitutions and modifications, which should all fall within the scope of the present disclosure.

Claims

1. A method for generating a service grid system, comprising: Deploy sidecar containers in multiple runtimes; Acquiring service discovery data related to the business program in the running carrier, including: acquiring registration data from different cluster registration centers, the registration data representing the running status of the underlying device related to the application service; acquiring configuration data from different cluster configuration centers, the configuration data representing the configuration information related to the service and the system; and using the registration data and the configuration data as the service discovery data; Synchronizing the service discovery data related to the business program in the running carrier to the sidecar container, including: the registration data and configuration data distributed in different clusters are synchronized to a unified control plane platform by means of plug-ins, and when the program of the control plane platform is started, a configuration file is run, the configuration file includes the addresses of different clusters for completing service discovery, and the communication between the control plane platform and each cluster is realized by running the configuration file, thereby completing the synchronization process; and The service mesh system is generated according to the multiple sidecar containers that synchronize the service discovery data.

2. The method according to claim 1, wherein: The deploying of sidecar containers in multiple running carriers respectively includes: Compile the container image file according to the set program; According to the container image file, acquiring target resource file information, wherein the target resource file information has configuration information related to the container image file; and The sidecar container is deployed for the running carrier according to the target resource file information.

3. The method according to claim 2, wherein: According to the container image file, obtaining target resource file information includes: Get the initial resource file information; Capturing the initial resource file information through a callback program; and According to the container image file, the relevant configuration information of the initial resource file information is modified to obtain the target resource file information.

4. The method according to claim 1, further comprising: Get the calling logic business program; Redirecting the calling logic service program to a first sidecar container, wherein the calling logic service program and the first sidecar container belong to the same first running carrier; Determine a second sidecar container according to the service discovery data in the first sidecar container; Determining a service logic business program according to the service discovery data in the second sidecar container, wherein the second sidecar container and the service logic business program belong to the same second running carrier; and Data communication between the calling logic business program in the first running carrier and the service logic business program in the second running carrier is implemented according to the first sidecar container and the second sidecar container.

5. The method according to claim 4, wherein: Redirecting the calling logic business program to the first sidecar container includes: Obtaining address information of the egress traffic of the calling logic service program; and According to the network address translation protocol, the address information of the egress traffic for calling the logical business program is redirected to the address of the first sidecar container.

6. The method according to claim 4, wherein: Determining the service logic business program according to the service discovery data in the second sidecar container includes: Acquiring address information of the inlet traffic of the second operation carrier; and According to the network address translation protocol, the address information of the ingress traffic of the second operation carrier is redirected to the address of the service logic business program.

7. A service grid system, comprising: The deployment subsystem is used to deploy sidecar containers in multiple runtimes. A service grid subsystem, used to obtain service discovery data related to the business program in the running carrier, including: obtaining registration data from different cluster registration centers, the registration data representing the running status of the underlying device related to the application service; obtaining configuration data from different cluster configuration centers, the configuration data representing the configuration information related to the service and the system; and using the registration data and the configuration data as the service discovery data; and The data plane subsystem is used to synchronize the service discovery data related to the business program in the running carrier to the sidecar container, including: the registration data and configuration data distributed in different clusters synchronize their own data information to a unified control plane platform through plug-ins, and when the program of the control plane platform is started, a configuration file is run, and the configuration file includes the addresses of different clusters for completing service discovery. By running the configuration file, the control plane platform communicates with each cluster to complete the synchronization process; and the service grid system is generated according to multiple sidecar containers that synchronize the service discovery data.

8. A computer system comprising: one or more processors; a memory for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, enables the processor to implement the method according to any one of claims 1 to 6.

Images