Data processing method, device and electronic equipment of service mesh platform

Abstract

The application provides a data processing method and device of a service grid platform and an electronic device. The service grid platform is connected with a registration center through a first controller to obtain specified service data. Based on a target service selected by a user and included in the service grid platform, service configuration data corresponding to the target service is generated and issued to k8s and stored. The first controller listens to changes in the service configuration data in k8s through a k8s API-Server, obtains a registration center service model of the target service based on the service configuration data stored in k8s, and converts the service grid platform service model into a proxy service model and issues it to all proxies. The method automatically interfaces with the registration center, so that the service information and instance information of the registration center can be synchronously displayed on the service grid platform, realizing real-time synchronization between the grid platform and the service grid platform without manual intervention.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a data processing method, apparatus, and electronic device for a service mesh platform. Background Technology

[0002] All configuration strategies in a service mesh platform are service-oriented. The primary data imported during service mesh platform operation is service information, including service name, service address, and service tags. Existing service mesh platforms only offer good support for Kubernetes services. They obtain service names, instance information, and service versions by querying the Kubernetes API server in the container environment. However, in financial industry practice, the use of Kubernetes' built-in service mechanism is relatively limited; traditional registry mechanisms are typically used for service registration and discovery. Service mesh platforms only provide an interface implementation mechanism and do not offer a specific solution for connecting to a registry center.

[0003] In existing technologies, for registry center scenarios, information can only be queried manually from the registry center, and then service information (ServiceEntry, WorkloadEntry) is created on the service mesh platform. The service mesh platform then watches this information and transforms and distributes it to the agent.

[0004] However, in reality, a registry often contains hundreds or even thousands of microservices. Manually querying and creating this service information is extremely time-consuming, labor-intensive, and error-prone. Furthermore, this method only works when the microservice instances are fixed. Once a microservice is deployed in a container environment, due to the dynamic scheduling and IP address allocation mechanisms for microservices, the instance IPs of microservices can easily drift, making it impractical to manually monitor and modify the configuration information on the service mesh platform. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a data processing method, apparatus and electronic device for a service mesh platform, which realizes real-time synchronization between the registration center and the service mesh platform without the need for manual intervention.

[0006] This application provides a data processing method for a service mesh platform, which is applied to the service mesh platform. The data processing method includes the following steps: The first controller, pre-configured in the service mesh platform, connects to the registration center based on the pre-configured login information of the registration center and obtains all service data of the registration center; Based on the target service selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service is generated, and the service configuration data of the target service is sent to Kubernetes and stored. The first controller listens for changes in service configuration data in Kubernetes through the Kubernetes API-Server, obtains the service model of the target service's registry center based on the service configuration data stored in Kubernetes, and converts the service model of the target service's registry center into a service mesh platform service model based on pre-configured code transformation logic. The service mesh platform converts the service mesh platform service model of the target service into a proxy service model, and distributes the proxy service model of the target service to all proxies.

[0007] In some embodiments, the data processing method of the service mesh platform further includes: In response to connecting to the service mesh platform, a pre-configured service mesh platform management program is executed, displaying a first management interface and a second management interface; The first management interface is used to configure the login information of the registration center; The second management interface is used to query all service data of the registration center, determine the target service that needs to be included in the service mesh platform, and modify the status of the target service to access the network.

[0008] In some embodiments, in the data processing method of the service mesh platform, a pre-configured first controller in the service mesh platform connects to the registry center according to pre-configured login information of the registry center, and obtains all service data of the registry center, including: The login information of the pre-configured registry center is stored in etcd storage as a custom resource; The first controller, which is pre-configured in the service mesh platform, listens to the configuration in the etcd storage through the k8s API-server. When it receives login information from the registry center, it connects to the corresponding registry center based on the login information and queries all service data in the registry center.

[0009] In some embodiments, the data processing method of the service mesh platform, the step of generating service configuration data corresponding to the target service selected by the user from all service data for inclusion in the service mesh platform, and distributing and storing the service configuration data of the target service to Kubernetes, includes: Based on the target services selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service data is generated. The service configuration data is distributed to Kubernetes as a custom resource and stored in etcd storage.

[0010] In some embodiments, in the data processing method of the service mesh platform, the first controller listens for changes in service configuration data in Kubernetes via the Kubernetes API-Server, obtains the registry service model of the target service based on the service configuration data stored in Kubernetes, and converts the registry service model of the target service into a service mesh platform service model based on pre-configured code transformation logic, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server to obtain the registry service model of the target service that needs to be included in the service mesh platform; The first controller converts the registry service model of the target service into a service mesh platform service model based on pre-configured code conversion logic. The service mesh platform service model includes ServiceEntry and WorkloadEntry. ServiceEntry and WorkloadEntry are custom resources provided by the second server and stored in etcd storage.

[0011] In some embodiments, in the data processing method of the service mesh platform, the first controller listens to the service configuration data in etcd storage through a k8s API-Server to obtain the registry service model of the target service to be included in the service mesh platform, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server. When it detects that the status of the service configuration resource has changed to access the service mesh platform, the first controller establishes a subscription mechanism with the registry center. Based on the subscription mechanism, the registry service model of the target service in the registry center is obtained in real time.

[0012] In some embodiments, the data processing method of the service mesh platform includes converting the service mesh platform service model of the target service into a proxy service model, comprising: The service mesh platform listens to the k8s API-server to obtain the service mesh platform service model of the target service. Convert the obtained ServiceEntry and WorkloadEntry into the Istio service model ServiceInstance; The service mesh platform converts the ServiceInstance model into a proxy service model, which includes EDS and CDS.

[0013] In some embodiments, the data processing method of the service mesh platform, wherein the proxy service model of the target service is distributed to all proxies, includes: The service mesh platform distributes the agent service models EDS and CDS to all agents via the xds protocol.

[0014] In some embodiments, a data processing apparatus for a service mesh platform is also provided, applied to the service mesh platform, the data processing apparatus comprising: The acquisition module is used to enable the first controller, which is pre-configured in the service mesh platform, to connect to the registration center based on the pre-configured login information of the registration center and acquire all service data of the registration center; The distribution module is used to generate service configuration data corresponding to the target service selected by the user from all service data to be included in the service mesh platform, and distribute the service configuration data of the target service to k8s and store it. The first conversion module is used to obtain the registry service model of the target service based on the service configuration data obtained by the first controller, and convert the registry service model of the target service into a service mesh platform service model based on the pre-configured code conversion logic. The second conversion module is used to enable the service mesh platform to convert the service mesh platform service model of the target service into a proxy service model, and to distribute the proxy service model of the target service to all proxies.

[0015] In some embodiments, an electronic device is also provided, the electronic device including: a processor, a memory and a bus, the memory storing machine-readable instructions executable by the processor, the processor communicating with the memory via the bus when the electronic device is running, and the steps of the data processing method of the service mesh platform being executed by the processor when the machine-readable instructions are executed.

[0016] This application provides a data processing method, apparatus, electronic device, and medium for a service mesh platform. A pre-configured first controller in the service mesh platform connects to the registration center based on pre-configured login information and obtains all service data from the registration center. Based on a target service selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service is generated and distributed to and stored in Kubernetes. The first controller uses Kubernetes... The API-Server listens for changes in service configuration data in Kubernetes, retrieves the service model of the target service's registry based on the service configuration data stored in Kubernetes, and converts the target service's registry service model into a service mesh platform service model based on pre-configured code transformation logic. The service mesh platform then converts the target service's service mesh platform service model into a proxy service model and distributes the target service's proxy service model to all proxies. This method automatically connects to the registry, enabling the service information and instance information of the registry to be synchronously displayed on the service mesh platform. This achieves real-time synchronization between the mesh platform and the service mesh platform without manual intervention. Even if the information in the registry changes, it can be promptly synchronized to the service mesh platform. Users can select which applications to add to the service mesh on the service mesh platform, view the access status of all services, manage the import process, and observe the import progress and deviations. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of a natively supported Kubernetes service watch-based architecture is shown. Figure 2 The diagram illustrates an architecture diagram of interfacing with a registry center in the prior art. Figure 3 A flowchart of the data processing method of the service mesh platform described in an embodiment of this application is shown; Figure 4 A flowchart illustrating the process of interfacing with the registration center as described in an embodiment of this application is shown; Figure 5 This paper illustrates the architecture diagram of the service mesh platform interfacing with the registry center as described in an embodiment of this application. Figure 6A schematic diagram of the data processing apparatus of the service mesh platform according to an embodiment of this application is shown; Figure 7 A schematic diagram of the structure of the electronic device described in an embodiment of this application is shown. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0020] All configuration strategies in a service mesh platform are service-oriented. The primary data imported during service mesh platform operation is service information, including service name, service address, and service tags. Existing service mesh platforms only offer good support for Kubernetes services. They obtain service names, instance information, and service versions by querying the Kubernetes API server in the container environment. However, in financial industry practice, the use of Kubernetes' built-in service mechanism is relatively limited; traditional registry mechanisms are typically used for service registration and discovery. Service mesh platforms only provide an interface implementation mechanism and do not offer a specific solution for connecting to a registry center.

[0021] Please refer to Figure 1 , Figure 1 The diagram illustrates a natively supported architecture based on Kubernetes service watch. The service mesh platform automatically monitors service and endpoint resources on the Kubernetes platform according to the configuration, then converts the configuration into an internal resource model ServiceInstance, which is then converted into proxy data models EDS and RDS, and finally distributed to all proxies via the xds protocol.

[0022] Please refer to Figure 2 , Figure 2 This diagram illustrates the architecture for interfacing with the registry center in the prior art; such as... Figure 2As shown, in existing technologies, for registry center scenarios, information can only be queried manually from the registry center, and then service information (ServiceEntry, WorkloadEntry) is created on the service mesh platform. The service mesh platform watches this information and transforms and distributes it to the proxy. Here, the service information generated by the service mesh platform includes ServiceEntry and WorkloadEntry, etc. ServiceEntry is used to define access rules for external services or non-Kubernetes native services, while WorkloadEntry is used to describe detailed information about workloads (such as services on virtual machines or physical machines). The proxy, as an independent network component, takes over all inter-service communication, separates network functions (such as traffic routing and fault handling) from business logic, and routes requests to the correct target service instance based on the service information issued by the service mesh platform. In this way, service communication logic and business logic are decoupled, providing a unified, transparent, and scalable network function layer.

[0023] However, in reality, a registry often contains hundreds or even thousands of microservices. Manually querying and creating this service information is extremely time-consuming, labor-intensive, and error-prone. Furthermore, this method only works when the microservice instances are fixed. Once a microservice is deployed in a container environment, due to the dynamic scheduling and IP address allocation mechanisms for microservices, the instance IPs of microservices can easily drift, making it impractical to manually monitor and modify the configuration information on the service mesh platform.

[0024] Specifically, container orchestration systems like Kubernetes dynamically adjust the deployment location of Pods (container groups, where an instance of a microservice typically runs within a Pod) based on resource usage (CPU, memory), node health, affinity / anti-affinity rules, etc. Each Pod is assigned a unique IP address upon startup. Furthermore, in a Kubernetes network, each Pod is assigned a unique cluster-wide IP address by a CNI (Container Network Interface) plugin (such as Calico, Flannel, etc.) upon startup, and the IP address is reclaimed after Pod destruction. When a new Pod is created, it requests and obtains a completely new IP address; therefore, the IP addresses of microservice instances deployed in container environments can drift at any time.

[0025] Based on this, the existing architecture for connecting to the registry center leads to the following three types of problems: service information is stored in the registry center, making it impossible to efficiently and stably import registry center information into the service mesh platform; there is a lack of management mechanisms, making it impossible for maintenance personnel to manage the import process and observe the import progress and deviations; and changes to the registry center information cannot be synchronized to the service mesh platform in a timely manner.

[0026] Based on this, this application provides a data processing method, apparatus, electronic device, and medium for a service mesh platform. A pre-configured first controller in the service mesh platform connects to the registration center based on pre-configured login information to obtain all service data from the registration center. Based on a target service selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service is generated, and the service configuration data of the target service is sent to and stored in Kubernetes. The first controller uses Kubernetes... The API-Server listens for changes in service configuration data in Kubernetes, retrieves the service model of the target service's registry based on the service configuration data stored in Kubernetes, and converts the target service's registry service model into a service mesh platform service model based on pre-configured code transformation logic. The service mesh platform then converts the target service's service mesh platform service model into a proxy service model and distributes the target service's proxy service model to all proxies. This method automatically connects to the registry, enabling the service information and instance information of the registry to be synchronously displayed on the service mesh platform. This achieves real-time synchronization between the mesh platform and the service mesh platform without manual intervention. Even if the information in the registry changes, it can be promptly synchronized to the service mesh platform. Users can select which applications to add to the service mesh on the service mesh platform, view the access status of all services, manage the import process, and observe the import progress and deviations.

[0027] Please refer to Figure 3 , Figure 3 A flowchart of the data processing method of the service mesh platform described in an embodiment of this application is shown; as follows: Figure 3 As shown, the data processing method for the service mesh platform is applied to the service mesh platform, and the data processing method includes the following steps S301-S304: S301. The first controller, which is pre-configured in the service mesh platform, connects to the registration center according to the login information of the pre-configured registration center and obtains all service data of the registration center; S302. Based on the target service selected by the user from all service data to be included in the service mesh platform, generate service configuration data corresponding to the target service, and send the service configuration data of the target service to k8s and store it. S303. The first controller listens for changes in service configuration data in k8s through the k8s API-Server, obtains the service model of the registry center of the target service based on the service configuration data stored in k8s, and converts the service model of the registry center of the target service into the service mesh platform service model based on the pre-configured code conversion logic. S304. The service mesh platform converts the service mesh platform service model of the target service into a proxy service model, and distributes the proxy service model of the target service to all proxies.

[0028] Please refer to Figure 4 , Figure 4 The flowchart illustrating the interface with the registration center as described in this application embodiment is shown; please refer to it. Figure 5 , Figure 5 The diagram illustrates the architecture of the service mesh platform connecting to the registry center as described in this application embodiment.

[0029] In step S101, the first controller, which is pre-configured in the service mesh platform, connects to the registration center according to the login information of the pre-configured registration center and obtains all service data of the registration center.

[0030] The first controller, namely the controller component gtsm-operator, is a custom controller developed based on the Kubernetes Operator pattern. It automatically executes tasks such as registry center integration and service data synchronization through predefined logic.

[0031] The login information is the information used to enable successful communication between the service mesh platform and the registry center, including access authentication information, registry center cluster address, etc.

[0032] All service data, including data for all services, with each service's data including service name, instance list, instance details, etc.

[0033] like Figure 4 and Figure 5 As shown, the service mesh platform includes a service mesh platform management terminal, as referred to Figure 4 In step 1, the user enters the login information of the registry center to be connected from the service mesh platform's management terminal. This includes access authentication information, the registry center cluster address, etc., ensuring that communication between the service mesh platform and the registry center is successful. The registry center connection information is stored in etcd in CR format. This connection information includes a complete set of parameters for linking to the registry center, including login and authentication information, registry center address information, and other configurations.

[0034] Reference Figure 4 In step 2, the service mesh platform controller component gtsm-operator watches the k8s API-server to obtain the connection information of the registry center; in step 3, the gtsm-operator component connects to the registry center according to the configuration information and queries all service data of the registry center.

[0035] Specifically, the service mesh controller listens to the configuration in etcd storage through the API-server. When it receives configuration information from the registry center, it connects to the corresponding registry center to query the service information in the registry center. The service mesh controller then stores the obtained service information in etcd in the form of CR.

[0036] Based on this, in some embodiments, a pre-configured first controller in the service mesh platform connects to the registry center according to pre-configured login information of the registry center, and obtains all service data of the registry center, including: The login information of the pre-configured registry center is stored in etcd storage as a custom resource; The first controller, which is pre-configured in the service mesh platform, listens to the configuration in the etcd storage through the k8s API-server. When it receives login information from the registry center, it connects to the corresponding registry center based on the login information and queries all service data in the registry center.

[0037] In step 302, based on the target service selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service is generated, and the service configuration data of the target service is sent to Kubernetes and stored.

[0038] Service mesh platforms such as Istio are natively designed to watch the Kubernetes API Server to obtain information, distribute the service configuration data of the target service to Kubernetes and store it, and thus listen to the status changes of the service configuration data through the Kubernetes API Server.

[0039] In some embodiments, generating service configuration data corresponding to the target service selected by the user from all service data for inclusion in the service mesh platform, and distributing and storing the service configuration data of the target service to Kubernetes includes: Based on the target services selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service data is generated. The service configuration data is distributed to Kubernetes as a custom resource and stored in etcd storage.

[0040] It should be noted that the data processing method of the service mesh platform further includes: In response to connecting to the service mesh platform, a pre-configured service mesh platform management program is executed, displaying a first management interface and a second management interface; The first management interface is used to configure the login information of the registration center; The second management interface is used to query all service data of the registration center, determine the target service that needs to be included in the service mesh platform, and modify the status of the target service to access the network.

[0041] The first management interface is used for managing information connected to the registration center; the second management interface is used for service management. In other words, the service mesh platform provides two management interfaces: registry center interface management and service management. The registry center interface management is used to configure information such as IP address, port, user, and password in the registry center; the service management is used to query the services in the registry center and control which services need to be injected into the proxy.

[0042] Based on this, the target service refers to the target service selected by the user from all services, such as the service that the user manually selects to be connected to the service mesh.

[0043] The service configuration data of the target services, i.e., the list of target services, indicates that these target services have been selected and informs the service mesh platform so that the service mesh platform can obtain the registry service model of the target services.

[0044] For details, please refer to Figure 4 In step 4, gtsm-operator will store the obtained information in etcd for viewing on the interface; in step 5, users can query all data under the registry through the service mesh platform, and then users can select which services to include in the service mesh on the interface. This configuration will be distributed to Kubernetes in the form of CR and then stored in etcd.

[0045] In step S303, the first controller listens for changes in service configuration data in k8s through the k8s API-Server, obtains the registry service model of the target service based on the service configuration data stored in k8s, and converts the registry service model of the target service into a service mesh platform service model based on the pre-configured code transformation logic.

[0046] The first controller listens for changes in service configuration data in Kubernetes via the Kubernetes API-Server, obtains the service registry model of the target service based on the service configuration data stored in Kubernetes, and converts the service registry model of the target service into a service mesh platform service model based on pre-configured code transformation logic, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server to obtain the registry service model of the target service that needs to be included in the service mesh platform; The first controller converts the registry service model of the target service into a service mesh platform service model based on pre-configured code conversion logic. The service mesh platform service model includes ServiceEntry and WorkloadEntry. ServiceEntry and WorkloadEntry are custom resources provided by the second server and stored in etcd storage.

[0047] The service model of the registry center, that is, the service definition format natively stored in the registry center, includes service name, instance list, etc.

[0048] Different registry centers have significantly different models (e.g., Nacos uses JSON, while ZK uses node paths).

[0049] The service mesh platform service model provides a unified data format required by service meshes (such as Istio). Core resources include: ServiceEntry: defines service access rules (such as DNS name, port protocol); WorkloadEntry: records service instance details (compatible with K8s Endpoints).

[0050] The code conversion logic is used to convert the service model of the registry center into the service mesh platform service model; the adapter code pre-built in gtsm-operator is used to handle field mapping and data cleaning, thereby converting the service model of the registry center into the service mesh platform service model.

[0051] Please refer to Figure 4 In steps 6, 7, and 8, the gtsm-operator watches the k8s API-server to obtain the registry center services that need to be included in the mesh. In step 7, the gtsm-operator converts the service model of the registry center into the service model ServiceEntry and WorkloadEntry of the service mesh platform according to the code logic. In step 8, ServiceEntry and WorkloadEntry are cr provided by istio and will be stored in etcd.

[0052] The first controller of the service mesh platform listens to the configuration in the etcd storage through the API-server. When it receives a service status change, the controller establishes a subscription mechanism with the registry center to obtain the service and instance information of the registry center in real time. The first controller creates the service resources ServiceEntry and WorkloadEntry of the service mesh platform.

[0053] The first controller listens to the service configuration data in the etcd storage via the k8s API-Server to obtain the registry service model of the target service to be included in the service mesh platform, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server. When it detects that the status of the service configuration resource has changed to access the service mesh platform, the first controller establishes a subscription mechanism with the registry center. Based on the subscription mechanism, the registry service model of the target service in the registry center is obtained in real time.

[0054] In step S304, the service mesh platform converts the service mesh platform service model of the target service into a proxy service model, and distributes the proxy service model of the target service to all proxies.

[0055] The service mesh platform converts the service mesh platform service model of the target service into a proxy service model, including: The service mesh platform listens to the k8s API-server to obtain the service mesh platform service model of the target service. Convert the obtained ServiceEntry and WorkloadEntry into the Istio service model ServiceInstance; The service mesh platform converts the ServiceInstance model into a proxy service model, which includes EDS and CDS.

[0056] The proxy service model is a configuration format that can be directly executed by proxies (such as Envoy) in the service mesh. Its core includes: EDS (Endpoint Discovery Service): instance-level data (IP:port, health status, load weight); CDS (Cluster Discovery Service): service-level routing policies (timeout, retry, circuit breaker threshold).

[0057] The proxy service model for the target service is distributed to all proxies; including: The service mesh platform distributes the agent service models EDS and CDS to all agents via the xds protocol.

[0058] The goal of a service mesh platform is to uniformly manage the service logic of microservices, while the agent is responsible for execution. Therefore, the agent service model EDS and CDS need to be distributed to all agents.

[0059] The proxy service models EDS and CDS are distributed to all proxies. Under the unified management of the service mesh platform, any changes to service instances (scaling up or down, restarting, failures) can be synchronized to all relevant proxies in real time. The unified management of the service mesh platform ensures that all proxies have consistent, global traffic rules, guaranteeing the uniformity of policy implementation.

[0060] The data processing method of the service mesh platform described in this application embodiment realizes full automation from monitoring the registry center, transforming the model, issuing configurations and making the agent effective, solving the problems of "manual querying and creating services being time-consuming, labor-intensive, error-prone, and unable to cope with dynamic changes".

[0061] Please refer to Figure 4 In steps 9, 10, 11, and 12, the mesh platform watches the Kubernetes API server, obtains ServiceEntry and WorkloadEntry, and converts them into the Istio service model ServiceInstance. In step 11, the service mesh platform converts the ServiceInstance model into the proxy data models EDS and CDS. In step 12, the service mesh platform distributes the service models EDS and CDS to all proxies via the XDS protocol.

[0062] Based on the same inventive concept, this application also provides a data processing device for a service mesh platform corresponding to the data processing method of the service mesh platform. Since the principle of the device in this application is similar to the data processing method of the service mesh platform in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0063] Please refer to Figure 6 , Figure 6 This illustration shows a schematic diagram of the structure of a data processing device for a service mesh platform according to an embodiment of this application; the data processing device is applied to the service mesh platform and includes: The acquisition module 601 is used to enable the first controller, which is pre-configured in the service mesh platform, to connect to the registration center according to the login information of the pre-configured registration center and acquire all service data of the registration center; The distribution module 602 is used to generate service configuration data corresponding to the target service based on the target service selected by the user from all service data to be included in the service mesh platform, and to distribute the service configuration data of the target service to k8s and store it. The first conversion module 603 is used to enable the first controller to listen for changes in service configuration data in k8s through the k8s API-Server, obtain the registry service model of the target service based on the service configuration data stored in k8s, and convert the registry service model of the target service into a service mesh platform service model based on the pre-configured code conversion logic. The second conversion module 604 is used to enable the service mesh platform to convert the service mesh platform service model of the target service into a proxy service model, and to distribute the proxy service model of the target service to all proxies.

[0064] In some embodiments, the data processing apparatus of the service mesh platform further includes: The display module is used to respond to the execution of a pre-configured service mesh platform management program when connected to the service mesh platform, and to display the first management interface and the second management interface; The first management interface is used to configure the login information of the registration center; The second management interface is used to query all service data of the registration center, determine the target service that needs to be included in the service mesh platform, and modify the status of the target service to access the network.

[0065] In some embodiments, in the data processing apparatus of the service mesh platform, the acquisition module, when enabling a pre-configured first controller in the service mesh platform to connect to the registration center based on pre-configured login information of the registration center and acquire all service data of the registration center, is specifically used for: The login information of the pre-configured registry center is stored in etcd storage as a custom resource; The first controller, which is pre-configured in the service mesh platform, listens to the configuration in the etcd storage via the API-server. When it receives login information from the registry center, it connects to the corresponding registry center based on the login information and queries all service data in the registry center.

[0066] In some embodiments, in the data processing apparatus of the service mesh platform, the distribution module, when generating service configuration data corresponding to the target service selected by the user from all service data for inclusion in the service mesh platform, and distributing and storing the service configuration data of the target service to Kubernetes, is specifically used for: Based on the target services selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service data is generated. The service configuration data is distributed to Kubernetes as a custom resource and stored in etcd storage.

[0067] In some embodiments, in the data processing apparatus of the service mesh platform, the first conversion module, when the first controller listens for changes in service configuration data in Kubernetes via the Kubernetes API-Server, obtains the registry service model of the target service based on the service configuration data stored in Kubernetes, and converts the registry service model of the target service into a service mesh platform service model based on pre-configured code conversion logic, is specifically used for: The first controller listens to the service configuration data in etcd storage through the k8s API-Server to obtain the registry service model of the target service that needs to be included in the service mesh platform; The first controller converts the registry service model of the target service into a service mesh platform service model based on pre-configured code conversion logic. The service mesh platform service model includes ServiceEntry and WorkloadEntry. The ServiceEntry and WorkloadEntry are custom resources provided by the second server and stored in etcd storage.

[0068] In some embodiments, in the data processing apparatus of the service mesh platform, the first conversion module, when the first controller listens to the service configuration data in the etcd storage via the API-server and obtains the registry service model of the target service to be included in the service mesh platform, is specifically used for: The first controller listens to the service configuration data in etcd storage through the k8s API-Server. When it detects that the status of the service configuration resource has changed to access the service mesh platform, the first controller establishes a subscription mechanism with the registry center. Based on the subscription mechanism, the registry service model of the target service in the registry center is obtained in real time.

[0069] In some embodiments, in the data processing apparatus of the service mesh platform, the second conversion module, when the service mesh platform converts the service mesh platform service model of the target service into a proxy service model, is specifically used for: The service mesh platform listens to the k8s API-server to obtain the service mesh platform service model of the target service. Convert the obtained ServiceEntry and WorkloadEntry into the Istio service model ServiceInstance; The service mesh platform converts the ServiceInstance model into a proxy service model, which includes EDS and CDS.

[0070] In some embodiments, in the data processing apparatus of the service mesh platform, the second conversion module, when the proxy service model of the target service is distributed to all proxies, is specifically used for: The service mesh platform distributes the agent service models EDS and CDS to all agents via the xds protocol.

[0071] Based on the same inventive concept, this application also provides an electronic device corresponding to the data processing method of the service mesh platform. Since the principle of the electronic device in this application is similar to the data processing method of the service mesh platform in this application, the implementation of the electronic device can refer to the implementation of the method, and the repeated parts will not be described again.

[0072] Please refer to Figure 7 , Figure 7 A schematic diagram of the structure of the electronic device according to an embodiment of this application is shown. The electronic device 700 includes: a processor 702, a memory 701 and a bus. The memory 701 stores machine-readable instructions that can be executed by the processor 702. When the electronic device 700 is running, the processor 702 communicates with the memory 701 through the bus. When the machine-readable instructions are executed by the processor 702, the steps of the data processing method of the service mesh platform are executed.

[0073] Based on the same inventive concept, this application also provides a computer-readable storage medium corresponding to the data processing method of the service mesh platform. Since the principle of the computer-readable storage medium in this application is similar to the data processing method of the service mesh platform in this application, the implementation of the computer-readable storage medium can refer to the implementation of the method, and the repeated parts will not be described again.

[0074] A computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the data processing method of the service mesh platform.

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

[0076] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0077] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

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

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

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

[0081] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data processing method for a service grid platform, characterized in that, Applied to a service mesh platform, the data processing method includes the following steps: The pre-configured login information of the registry center is stored in the etcd storage as a custom resource; The first controller, which is pre-configured in the service mesh platform, listens to the configuration stored in etcd through the k8s API-server. When it receives login information from the registry center, it connects to the corresponding registry center based on the login information and queries all service data in the registry center. Based on the target services selected by the user from all service data to be included in the service mesh platform, service configuration data corresponding to the target service data is generated. The service configuration data is distributed to Kubernetes as a custom resource and stored in etcd storage; The first controller listens for changes in service configuration data in Kubernetes through the Kubernetes API-Server, obtains the service model of the target service's registry center based on the service configuration data stored in Kubernetes, and converts the service model of the target service's registry center into a service mesh platform service model based on pre-configured code transformation logic. The service mesh platform converts the service mesh platform service model of the target service into a proxy service model, and distributes the proxy service model of the target service to all proxies.

2. The data processing method for a service mesh platform according to claim 1, characterized in that, The method further includes: In response to connecting to the service mesh platform, a pre-configured service mesh platform management program is executed, displaying a first management interface and a second management interface; The first management interface is used to configure the login information of the registration center; The second management interface is used to query all service data of the registration center, determine the target service that needs to be included in the service mesh platform, and modify the status of the target service to access the network.

3. The data processing method for a service mesh platform according to claim 1, characterized in that, The first controller listens for changes in service configuration data in Kubernetes via the Kubernetes API-Server, obtains the service registry model of the target service based on the service configuration data stored in Kubernetes, and converts the service registry model of the target service into a service mesh platform service model based on pre-configured code transformation logic, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server to obtain the registry service model of the target service that needs to be included in the service mesh platform; The first controller converts the registry service model of the target service into a service mesh platform service model based on pre-configured code conversion logic. The service mesh platform service model includes ServiceEntry and WorkloadEntry. The ServiceEntry and WorkloadEntry are custom resources provided by the second server and stored in etcd storage.

4. The data processing method for a service mesh platform according to claim 3, characterized in that, The first controller listens to the service configuration data in the etcd storage via the k8s API-Server to obtain the registry service model of the target service to be included in the service mesh platform, including: The first controller listens to the service configuration data in etcd storage through the k8s API-Server. When it detects that the status of the service configuration resource has changed to access the service mesh platform, the first controller establishes a subscription mechanism with the registry center. Based on the subscription mechanism, the registry service model of the target service in the registry center is obtained in real time.

5. The data processing method for a service mesh platform according to claim 4, characterized in that, The service mesh platform converts the service mesh platform service model of the target service into a proxy service model, including: The service mesh platform listens to the k8s API-server to obtain the service mesh platform service model of the target service. Convert the obtained ServiceEntry and WorkloadEntry into the Istio service model ServiceInstance; The service mesh platform converts the ServiceInstance model into a proxy service model, which includes EDS and CDS.

6. The data processing method for a service mesh platform according to claim 5, characterized in that, The proxy service model for the target service is distributed to all proxies; including: The service mesh platform distributes the agent service models EDS and CDS to all agents via the xds protocol.

7. A data processing device for a service grid platform, characterized in that, The data processing device, applied to a service mesh platform, includes: The acquisition module is used to save the login information of the pre-configured registry center in the etcd storage as a custom resource; the first controller in the service mesh platform is pre-configured and listens to the configuration in the etcd storage through the k8s API-server. When it receives the login information of the registry center, it connects to the corresponding registry center based on the login information and queries all service data in the registry center. The distribution module is used to generate service configuration data corresponding to the target service data based on the target service selected by the user from all service data to be included in the service mesh platform. The service configuration data is distributed to Kubernetes as a custom resource and stored in etcd storage; The first conversion module is used to enable the first controller to listen for changes in service configuration data in k8s through the k8s API-Server, obtain the registry service model of the target service based on the service configuration data stored in k8s, and convert the registry service model of the target service into a service mesh platform service model based on the pre-configured code conversion logic. The second conversion module is used to enable the service mesh platform to convert the service mesh platform service model of the target service into a proxy service model, and to distribute the proxy service model of the target service to all proxies.

8. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the data processing method of the service mesh platform as described in any one of claims 1 to 6.

Images