Cross-cluster data communication method and system, electronic equipment and storage medium

Abstract

The invention provides a cross-cluster data communication method and system, electronic equipment and a storage medium, and relates to the technical field of communication. The method comprises the following steps: intercepting a service calling request sent by a first service; obtaining a dynamic routing strategy issued by the service grid, and determining a forwarding path of the service calling request according to the dynamic routing strategy and the service calling request; according to the forwarding path of the service calling request, the service calling request is transmitted to the target service so as to call the business parameters in the target service, that is, the service calling request is directly intercepted and processed by the proxy component, and the service calling request is quickly analyzed and forwarded, so that the request is directly transmitted among different clusters, and the service calling efficiency is improved. In other words, multiple times of protocol conversion and gateway forwarding are not needed, the problems of network transmission delay and resource consumption caused by multiple times of protocol conversion and gateway forwarding in the prior art are solved, and cross-cluster efficient, safe and flexible service access of the financial cloud island is effectively achieved.

Description

Technical Field

[0001] The present invention relates to the field of communication technologies, and in particular, to a cross-cluster data communication method, system, electronic device, and storage medium. Background Art

[0002] The Financial Island Cloud is a dedicated platform based on cloud computing technology, aiming to provide a secure, stable, and efficient operating environment for the financial industry. By deploying the data and services of financial institutions in an independent and controlled island cluster environment, it effectively isolates potential external security threats while meeting the strict requirements of the financial industry for data security, privacy protection, and compliance.

[0003] In the related art, service calls between different island clusters are realized by forwarding traffic through a unified gateway. Specifically, in the network access link, each service within Island Cluster A makes call interactions through the Dubbo protocol; when Island Cluster A needs to call a service in Island Cluster B, it first passes through the dubbo proxy of Island Cluster A to convert the call request based on the Dubbo protocol into a call request based on the HTTP protocol, and then transmits it through the unified gateway to the dubbo proxy of Island Cluster B, and then converts the call request of the HTTP protocol into a call request of the Dubbo protocol to perform a service call on the target service in Island Cluster B.

[0004] However, when using the above unified gateway to forward traffic, when facing cross-cluster access, multiple protocol conversions and gateway forwards need to be performed, resulting in problems such as cumbersome processing links and high resource consumption. Summary of the Invention

[0005] The purpose of the present invention is to provide a cross-cluster data communication method, system, electronic device, and storage medium for the deficiencies in the above-mentioned prior art, so as to solve problems such as network transmission delay and resource consumption when using a unified gateway to forward service call requests, realize cross-cluster communication of the native Dubbo protocol, and achieve the effect of efficient, secure, and flexible call of services between cross-clusters.

[0006] To achieve the above purpose, the technical solutions adopted in the embodiments of the present application are as follows:

[0007] In a first aspect, an embodiment of the present application provides a cross-cluster data communication method, which is applied to a proxy component deployed in the service mesh of a first cluster, where the first cluster is a cloud cluster or an island cluster, and the method includes:

[0008] Intercept the service call request sent by the first service. The first service is any service deployed within the service mesh. The service call request is used to indicate the invocation of the target service deployed in the second cluster. The service call request includes the identifier of the target service and the business parameters of the requested resources. The second cluster is a cloud cluster or an island cluster.

[0009] Obtain the dynamic routing policy issued by the service mesh, and determine the forwarding path of the service call request according to the dynamic routing policy and the service call request.

[0010] According to the forwarding path of the service call request, transmit the service call request through the communication network connecting the first cluster and the second cluster to the target service, so as to invoke the business parameters in the target service.

[0011] Optionally, the dynamic routing policy is dynamically updated by the service mesh. The dynamic routing policy includes: a whitelist list of adjustable services after dynamic update, multiple alternative node paths, and the target addresses corresponding to at least one adjustable service. The whitelist list of adjustable services includes the identifiers of at least one adjustable service.

[0012] Optionally, the step of determining the forwarding path of the service call request according to the dynamic routing policy and the service call request includes:

[0013] Determine whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list.

[0014] If it has the permission, determine the destination address corresponding to the target service according to the identifier of the target service and the target addresses corresponding to at least one adjustable service.

[0015] Determine the forwarding path of the service call request according to the destination address corresponding to the target service and the multiple alternative node paths.

[0016] Optionally, the step of determining whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list includes:

[0017] Compare the identifier of the target service with the identifiers of each adjustable service in the whitelist list. If the identifier of the target service is the same as the identifier of the first adjustable service, determine that the first service has the permission to call the target service.

[0018] Optionally, the step of determining whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list includes:

[0019] If the identifier of the target service is different from the identifiers of all adjustable services in the whitelist list, it is determined that the first service does not have the permission to call the target service.

[0020] Optionally, the determining the forwarding path of the service call request according to the destination address corresponding to the target service and the multiple alternative node paths includes:

[0021] Adopt a polling strategy to select at least one target node path from the multiple alternative node paths from the current address corresponding to the first service to the destination address corresponding to the target service;

[0022] Determine the forwarding path of the call request according to each of the target node paths.

[0023] Optionally, the transmitting the service call request to the target service via the communication network connecting the first cluster and the second cluster includes:

[0024] Adopt a preset request compression algorithm to compress the service call request to generate a compressed service call request, and transmit the compressed service call request to the target service via the communication network connecting the first cluster and the second cluster.

[0025] In a second aspect, an embodiment of the present application further provides a cross-cluster data communication system, the system includes: at least one first cluster and at least one second cluster, the first cluster is a cloud cluster or an island cluster, and the second cluster is a cloud cluster or an island cluster;

[0026] At least one service mesh is included in the first cluster, and proxy components are respectively deployed in each service mesh, and the proxy components are used to execute the steps of the cross-cluster data communication method provided in the first aspect.

[0027] In a third aspect, an embodiment of the present application further provides an electronic device, the electronic device includes: a processor, a storage medium and a bus, the storage medium stores machine-readable instructions executable by the processor, when the electronic device runs, the processor communicates with the storage medium through the bus, and the processor executes the machine-readable instructions to execute the steps of the cross-cluster data communication method provided in the first aspect.

[0028] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is run by a processor, it executes the steps of the cross-cluster data communication method provided in the first aspect.

[0029] The beneficial effects of the present application are:

[0030] The present application provides a cross-cluster data communication method, system, electronic device and storage medium. The method includes: intercepting a service call request sent by a first service, where the first service is any service deployed in a service mesh, and the service call request is used to indicate calling a target service deployed in a second cluster. The service call request includes: an identifier of the target service and business parameters of the requested resource. The second cluster is a cloud cluster or an island cluster; obtaining a dynamic routing policy issued by the service mesh, and determining a forwarding path of the service call request according to the dynamic routing policy and the service call request; according to the forwarding path of the service call request, transmitting the service call request through a communication network connecting the first cluster and the second cluster to the target service to call the business parameters in the target service. This solution utilizes the fact that the proxy component MOSN has built-in support for the Dubbo protocol. The proxy component MOSN directly intercepts and processes service call requests of the Dubbo protocol, and quickly parses and forwards service call requests of the Dubbo protocol, realizing the direct transmission of Dubbo protocol requests between different clusters, that is, without multiple protocol conversions (i.e., the conversion process of Dubbo protocol → HTTP protocol → Dubbo protocol) and gateway forwarding, eliminating the HTTP conversion layer, and solving the problems of network transmission delay and resource consumption caused by multiple protocol conversions and gateway forwarding in the prior art, effectively realizing efficient, secure and flexible service access across clusters in a financial cloud island, and significantly reducing network transmission delay and resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following will briefly introduce the drawings required to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present invention, and therefore should not be regarded as limiting the scope. For those of ordinary skill in the art, without creative efforts, other related drawings can also be obtained based on these drawings.

[0032] Figure 1 It is a schematic diagram of the architecture of a cross-cluster communication system provided in the prior art;

[0033] Figure 2 It is a schematic diagram of network intercommunication between clusters in the cross-cluster system provided by the present application;

[0034] Figure 3 It is a schematic diagram of the architecture of the cross-cluster system provided by the present application;

[0035] Figure 4 It is a schematic flowchart of a cross-cluster data communication method provided by the present application;

[0036] Figure 5 It is a schematic flowchart of another cross-cluster data communication method provided by the present application;

[0037] Figure 6 It is a schematic flow diagram of another cross-cluster data communication method provided for this application;

[0038] Figure 7 It is a schematic structural diagram of an electronic device provided for an embodiment of this application. Detailed implementation manners

[0039] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention.

[0040] First, the prior art related to this application will be introduced.

[0041] As Figure 1 shown, it is a cross-cluster communication solution provided in the prior art. Specifically as follows:

[0042] Currently, traffic is forwarded through a unified gateway. For example, in a cross-cluster communication system, there are Cluster A and Cluster B. It can be understood that each cluster can be regarded as a node. And in each cluster, a distributed coordination service Zookeeper and an intermediate proxy dubbo proxy are deployed; the distributed coordination service Zookeeper is responsible for coordinating services between the two clusters, and the intermediate proxy dubbo proxy is a component that plays a role of forwarding, converting or mediating between the client and the server.

[0043] In the above cluster communication architecture, there are mainly two communication scenarios, namely intra-cluster call and cross-cluster call. Specifically, in an intra-cluster call, Service 1 and Service 2 in Cluster A directly interact through the Dubbo private protocol and transmit data in the form of "dubbobody", which is efficient and convenient; while in a cross-cluster call, between Cluster A and Cluster B, due to the difference in the network environment, a dedicated line connection is adopted. At this time, the message body of the Dubbo protocol is encapsulated in the HTTP protocol to construct an HTTP tunnel to transmit data. After reaching the target cluster, the Dubbo message body is taken out for processing. Since the HTTP protocol can be recognized and forwarded by intermediate devices and gateways, this communication method can successfully achieve cross-cluster communication.

[0044] Therefore, in cross-cluster communication, the entire network access link needs to be uniformly forwarded through the intermediate gateway. Although this solution solves the problem that different clusters cannot communicate through the gateway whitelist and takes into account data security at the same time, it cannot meet future business requirements and mainly has the following problems:

[0045] 1. High communication cost: Cross-cluster access requires multiple protocol conversions and gateway forwarding. The processing process is cumbersome, consuming a large amount of resources and resulting in high costs.

[0046] 2. Difficult to meet performance requirements: The unified gateway is prone to becoming a bottleneck and cannot meet the growing bandwidth requirements under high concurrency. The transmission path is long and there are many processes, resulting in obvious delays and difficulty in adapting to real-time services.

[0047] 3. Security risks: Dependence on the gateway whitelist makes management difficult and prone to omissions as the scale expands. The policy is single and lacks flexibility, and there is also a risk of being cracked, threatening data security.

[0048] Based on the above problems, the embodiments of this application propose a new cloud-native service mesh architecture solution, which is a service mesh ISTIO for a Kubernetes-based financial cloud cluster (or island cluster), and an architecture with a proxy component MOSN deployed in the service mesh ISTIO. The proxy component MOSN is used to forward service call requests to achieve cross-network calls for financial cloud islands.

[0049] Reference Figure 2 As shown, it is a schematic diagram of network interconnection between clusters in the cross-cluster system provided by this application. In the cross-cluster communication system provided by this application, multiple independent Kubernetes clusters are constructed, such as a cloud cluster, island cluster A, and island cluster B, and each cluster runs in a different cloud region or data center.

[0050] Exemplarily, the cloud cluster is located in the cloud and provides core financial services, such as payment processing; island cluster A is located in a certain data center and is responsible for user authentication; island cluster B is located in another data center and is responsible for data analysis and report generation.

[0051] The cloud cluster, island cluster A, and island cluster B are respectively deployed in different physical or virtual network environments and need to perform service calls with each other to complete complex business processes. For example: The payment service in the cloud cluster needs to call the authentication service of island cluster A; the authentication service of island cluster A may further call the data analysis service of island cluster B.

[0052] In the cross-cluster, connections are established between clusters through Submariner, Calico GlobalNetworkPolicy, or self-built VPC Peering (also known as virtual private cloud peering) to ensure network connectivity between clusters. Among them, VPCPeering is a way to achieve private network communication between different VPCs, enabling the cloud cluster and each island cluster to be logically in the same network.

[0053] Among them, a connection is also established between the island cluster A and the island cluster B through VPC Peering, enabling network communication between the two island clusters.

[0054] Reference Figure 3 , which is a schematic diagram of the architecture of the cross-cluster system provided by this application. A distributed coordination service Zookeeper, at least one service mesh ISTIO are deployed inside the cloud cluster and each island cluster, and a proxy component MOSN and multiple services are registered in each at least one service mesh ISTIO.

[0055] Among them, in a multi-cluster environment, a distributed registry such as Consul, Etcd or Zookeeper can be used, or a native service discovery mechanism of Kubernetes such as ServiceEntry (in the service mesh ISTIO) can be used to make services visible between different clusters.

[0056] Among them, the distributed coordination service Zookeeper is mainly used for service discovery, configuration management, etc. Among them, the distributed coordination service Zookeeper can also be Nacos;

[0057] The service mesh ISTIO is used to provide traffic management, policy implementation, etc.;

[0058] The proxy component MOSN acts as a network proxy and is used to handle data transmission related to the Dubbo protocol. Among them, the proxy component MOSN is deployed as a sidecar proxy for the Dubbo service on each node of each cluster, replacing the default Envoy of Istio, and the proxy component MOSN supports the Dubbo protocol, can effectively handle the communication between Dubbo services, and also supports the subsequent tri protocol.

[0059] At the same time, by using the XDS integration ability of the proxy component MOSN, it is docked with the control plane of the service mesh ISTIO to achieve cross-cluster service discovery. The configuration of the proxy component MOSN can also be dynamically adjusted through the XDS interface to achieve fine-grained traffic control and protocol conversion, ensuring efficient communication between Dubbo services.

[0060] Between the cloud cluster and each island cluster, through the ServiceEntry configured in the service mesh ISTIO, the services of the remote cluster are exposed to the local cluster to achieve cross-cluster service invocation; and, by using the VirtualService configured in the service mesh ISTIO to define detailed routing rules to control how traffic is forwarded between clusters; by using the DestinationRule configured in the service mesh ISTIO to define load balancing policies, fault recovery policies, etc. to manage cross-cluster service access.

[0061] When the services in the cloud cluster need to access the services in the island cluster A, the service call requests are transmitted between the proxy components MOSN in the Dubbo protocol, and at the same time, the rule control of the service mesh ISTIO is used to ensure the accuracy and security of the communication.

[0062] It should be noted that the structural compositions in the cloud cluster and the island cluster seem similar, but in actual applications, they may have differences in specific configuration parameters, service loads, etc. according to different business requirements and network environments.

[0063] Optionally, this solution provides a cloud-native service mesh architecture with multi-protocol integration, proposes an innovative architecture, combines Kubernetes, the service mesh ISTIO, and the proxy component MOSN, and realizes the deep integration of the Dubbo protocol and the cloud-native environment. In particular, as a sidecar proxy, the proxy component MOSN not only supports the Dubbo protocol but also has the ability to extend to modern microservice communication protocols such as the tri protocol, solving the technical problem of efficient and seamless communication between multi-protocol services.

[0064] Optionally, this solution provides a cross-cluster service discovery and automatic configuration mechanism. By using the XDS integration ability of MOSN and combining the service mesh ISTIO and Dubbo Registry, it realizes the automatic discovery and registration of services across Kubernetes clusters; and through dynamic configuration of ServiceEntry, it can achieve transparent invocation of remote services without manual intervention, improving the service governance efficiency and flexibility in a multi-cluster environment.

[0065] Optionally, this application also constructs an intelligent operation and maintenance and monitoring system, that is, integrates tools such as Prometheus, Grafana, and Jaeger to construct a comprehensive monitoring and logging system, which not only realizes end-to-end tracing and performance monitoring but also greatly improves the ability to quickly locate problems and automatically recover through intelligent alarm and self-healing mechanisms, ensuring the high availability and operation and maintenance efficiency of the system.

[0066] The implementation principle and the corresponding beneficial effects of the cross-cluster data communication method steps provided by this application will be described below through multiple specific embodiments.

[0067] In one embodiment, refer to Figure 4As shown in the figure, a flowchart of a cross-cluster data communication method is provided. Optionally, the execution subject of this method can be an agent component MOSN deployed in the service mesh of a cloud cluster or an island cluster, and the cloud cluster or island cluster runs on terminal devices with data processing functions such as personal computers, laptops, smartphones, and tablets. It should be understood that in other embodiments, the order of some steps of the cross-cluster data communication method can be exchanged according to actual needs, or some of the steps can also be omitted or deleted. As Figure 4 shown, the method includes:

[0068] S401. Intercept the service call request sent by the first service.

[0069] Among them, the first service is any service deployed in the service mesh. The service call request is used to indicate the invocation of the target service deployed in the second cluster. The service call request includes: the identifier of the target service and the business parameters of the requested resource. The second cluster is a cloud cluster or an island cluster.

[0070] Exemplarily, the first service can be an order service deployed in island cluster A, and the target service can be a warehouse service deployed in island cluster B. When the order service in island cluster A needs to call the warehouse service to query whether there is enough inventory of the target commodity, at this time, the order service in island cluster A generates a service call request in the Dubbo protocol. After sending the service call request, the agent component MOSN deployed in the service mesh of island cluster A intercepts the service call request.

[0071] S402. Obtain the dynamic routing policy issued by the service mesh, and determine the forwarding path of the service call request according to the dynamic routing policy and the service call request.

[0072] Among them, the dynamic routing policy is that the service mesh dynamically selects the best path or target node based on real-time security policies and access times to complete communication. The dynamic routing policy is used to indicate the invocation permission and routing information for forwarding the service call request from the first service to the target service.

[0073] S403. According to the forwarding path of the service call request, transmit the service call request through the communication network connecting the first cluster and the second cluster to the target service to invoke the business parameters in the target service.

[0074] In an implementable manner, to solve the problems existing in the existing solution when using a unified gateway to implement service call request forwarding, it is proposed that the proxy component MOSN be used as a sidecar proxy, which can support the forwarding of the Dubbo protocol. The proxy component MOSN determines the forwarding path of the service call request according to the dynamic routing policy issued by the service mesh and the service call request; and according to the forwarding path, directly forwards the service call request to the target service in the second cluster via VPC Peering to call the service parameters in the target service. Therefore, this solution takes advantage of the built-in support for the Dubbo protocol in the proxy component MOSN. The proxy component MOSN directly intercepts and processes the service call requests of the Dubbo protocol, and quickly parses and forwards the service call requests of the Dubbo protocol, realizing the direct transmission of the Dubbo protocol requests between different clusters, that is, without multiple protocol conversions (i.e., the conversion process of Dubbo protocol → HTTP protocol → Dubbo protocol) and gateway forwarding, eliminating the HTTP conversion layer, solving the problems of network transmission delay and resource consumption caused by multiple protocol conversions and gateway forwarding in the prior art, effectively realizing efficient, secure and flexible service access across clusters in the financial cloud island, and significantly reducing network transmission delay and resource consumption.

[0075] In summary, the embodiment of the present application provides a cross-cluster data communication method, which includes: intercepting a service call request sent by a first service, where the first service is any service deployed in the service mesh, and the service call request is used to indicate calling a target service deployed in a second cluster. The service call request includes: the identifier of the target service and the service parameters of the requested resource. The second cluster is a cloud cluster or an island cluster; obtaining the dynamic routing policy issued by the service mesh, and determining the forwarding path of the service call request according to the dynamic routing policy and the service call request; according to the forwarding path of the service call request, transmitting the service call request to the target service via the communication network connecting the first cluster and the second cluster to call the service parameters in the target service. This solution takes advantage of the built-in support for the Dubbo protocol in the proxy component MOSN. The proxy component MOSN directly intercepts and processes the service call requests of the Dubbo protocol, and quickly parses and forwards the service call requests of the Dubbo protocol, realizing the direct transmission of the Dubbo protocol requests between different clusters, that is, without multiple protocol conversions (i.e., the conversion process of Dubbo protocol → HTTP protocol → Dubbo protocol) and gateway forwarding, eliminating the HTTP conversion layer, solving the problems of network transmission delay and resource consumption caused by multiple protocol conversions and gateway forwarding in the prior art, effectively realizing efficient, secure and flexible service access across clusters in the financial cloud island, and significantly reducing network transmission delay and resource consumption.

[0076] Optionally, the dynamic routing policy is dynamically updated by the service mesh. The dynamic routing policy includes: a whitelist of adjustable services after dynamic update, multiple alternative node paths, and target addresses corresponding to at least one adjustable service. The whitelist of adjustable services includes: identifiers of at least one adjustable service.

[0077] Among them, the dynamic routing policy dynamically updated by the service mesh ISTIO can be obtained by the XDS in the proxy component MOSN.

[0078] In an implementable manner, to ensure efficient and flexible communication of services deployed in different clusters, it is proposed that the routing policy can be dynamically adjusted based on dynamic mechanisms such as real-time security policies and access control times, so as to avoid relying on fixed routing policies and having problems such as security threats, such as difficult management, easy omission, and easy to be cracked after scale expansion.

[0079] In an implementable manner, to implement a fine-grained access control policy, the AuthorizationPolicy in the service mesh ISTIO is used for service-level access control to ensure that only authorized users or services can access sensitive resources, effectively supporting the needs of financial data authorized access and data isolation. Therefore, it is proposed that the dynamic routing policy includes: a whitelist of adjustable services after dynamic update, where the whitelist of adjustable services includes: identifiers of at least one adjustable service. For example, the whitelist of services that the order service can call includes: Service A, Service B, and Service C.

[0080] At the same time, to achieve traffic management during request forwarding, it is proposed that detailed routing rules can be defined using the VirtualService and DestinationRule of the service mesh ISTIO, including policies based on weights, request content, service health status, etc., to control how traffic flows between clusters and achieve intelligent cross-cluster traffic management and load balancing. Therefore, it is proposed that the updated dynamic routing policy also includes: multiple alternative node paths and target addresses corresponding to at least one adjustable service. For example, the whitelist of services that the order service can call includes: Service A, Service B, and Service C; the multiple alternative node paths are multiple optional node paths that can be passed through when forwarding the order service, such as Node Path 1, Node Path 2, and Node Path 3; the target addresses corresponding to at least one adjustable service include: the target address corresponding to Service A, the target address corresponding to Service B, and the target address corresponding to Service C.

[0081] Optionally, the present application provides a method for enhancing security and dynamically adjusting routing policies, which enhances the security of communication between multiple clusters and realizes fine-grained traffic control and security policy adjustment through dynamic configuration management, including but not limited to access control, flow limiting, circuit breaking, etc., ensuring the stability and security of services in a high-concurrency and changeable cloud environment.

[0082] Optionally, referring to Figure 5 As shown, step S402 described above includes:

[0083] S501. Determine whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist.

[0084] S502. If it has the permission, determine the destination address corresponding to the target service according to the identifier of the target service and the target addresses of at least one adjustable service.

[0085] S503. Determine the forwarding path of the service call request according to the destination address corresponding to the target service and multiple alternative node paths.

[0086] In an implementable manner, the whitelist of adjustable services in the dynamic routing policy and the identifier of the target service can be used to identify whether the first service has the permission to call the target service, that is, to implement permission restrictions on the mutual calls between services in different clusters, to ensure that only authorized users or services can access sensitive resources, to improve the security of communication between different clusters, and to meet the requirements for data security isolation in the cluster. When it is determined that the first service has the permission to call the target service, the identifier of the target service can be used to screen out the destination address corresponding to the target service from the target addresses of at least one adjustable service; then, according to the destination address corresponding to the target service and multiple alternative node paths, determine the routing information, that is, the forwarding path, of the service call request to implement cross-cluster forwarding of the service call request.

[0087] Optionally, step S501 described above includes:

[0088] Compare the identifier of the target service with the identifiers of each adjustable service in the whitelist. If the identifier of the target service is the same as the identifier of the first adjustable service, it is determined that the first service has the permission to call the target service.

[0089] In an implementable manner, traverse the whitelist and compare the identifier of each adjustable service in the whitelist with the identifier of the target service one by one. If the identifier of the target service is the same as the identifier of a certain service in the whitelist, it is determined that the first service has the permission to call the target service. For example, if the identifier of the target service is S1, and the identifiers of the adjustable services in the whitelist are S1, S2, and S3 respectively. After comparison, it is found that the identifier of the target service is the same as the identifier of an adjustable service in the whitelist, then it can be determined that the first service has the permission to call the target service, that is, the first service can call the business data in the target service.

[0090] Optionally, step S501 above includes:

[0091] If the identifier of the target service is not the same as the identifiers of all adjustable services in the whitelist, it is determined that the first service does not have the permission to call the target service.

[0092] In another implementable manner, traverse the whitelist and compare the identifier of each adjustable service in the whitelist with the identifier of the target service one by one. If the identifier of the target service is not the same as the identifiers of all services in the whitelist, it is determined that the first service does not have the permission to call the target service. For example, if the identifier of the target service is S4, and the identifiers of the adjustable services in the whitelist are S1, S2, and S3 respectively. After comparison, it is found that the identifier of the target service is not the same as the identifiers of all adjustable services in the whitelist, then it can be determined that the first service does not have the permission to call the target service, realizing the control of service call permissions and ensuring the security of cross-cluster communication.

[0093] Optionally, as shown in Figure 6 Step S503 above includes:

[0094] S601. Adopt a polling strategy to select at least one target node path from the first service's corresponding current address to the target service's corresponding destination address from multiple alternative node paths.

[0095] S602. Determine the forwarding path of the service call request according to each target node path.

[0096] In an implementable manner, each multi-alternative node path (such as `order-service-1`, `order-service-2`, and `order-service-3`) is distributed in different servers or clusters. That is, a polling strategy is adopted to determine whether each alternative node path is in an idle state. If so, the alternative node path in the idle state is used as a target node path, and service call requests are sequentially assigned to each target node path, and each target node path forwards the service call requests in sequence. For example, the service call requests will be sequentially distributed to `order-service-1`, `order-service-2`, and `order-service-3`, that is, `order-service-1`, `order-service-2`, and `order-service-3` are used as the forwarding paths of the service call requests, realizing intelligent cross-cluster traffic management and load balancing, and ensuring the efficiency when the service call requests are forwarded.

[0097] Optionally, in addition to the polling strategy, it is also possible to determine at least one target node path from multiple alternative node paths based on random, least connection, and adaptive load balancing strategies, such as dynamic load balancing based on request content, service health status, or historical response time, to ensure that requests can be assigned to the most suitable instance according to the real-time service status, thereby improving the overall service quality and user experience.

[0098] Optionally, the above step S403:

[0099] Adopt a preset request compression algorithm to compress the service call request, generate a compressed service call request, and transmit the compressed service call request to the target service via the communication network connecting the first cluster and the second cluster.

[0100] Exemplarily, the configuration parameters of the request compression algorithm include: compression threshold 1KB, window size 64KB, and check mechanism CRC32.

[0101] In an implementable manner, in order to reduce the consumption of network transmission bandwidth, it is proposed that a compression algorithm (such as GZIP, Snappy) can be used to compress the service call request, generate a compressed service call request, and forward the compressed service call request to the target service. Therefore, the request is compressed before forwarding, and after the proxy component MOSN deployed in the service mesh of the second cluster intercepts the compressed service call request, the compressed service call request is decompressed, reducing the network transmission delay and resource consumption, and improving the cross-cluster communication efficiency.

[0102] Optionally, it is also possible to support batch compression or forwarding processing of multiple service call requests, that is, design an adapter to support batch sending of requests and responses, reduce the number of network I / O operations, and improve communication efficiency.

[0103] Optionally, this application can also implement gray release, canary testing, rate limiting and circuit breaking mechanisms, security and observability, and service mesh monitoring and alarm optimization. Specifically as follows:

[0104] 1. Gray release and canary testing

[0105] Using the dynamic routing policy of the service mesh ISTIO for dynamic updates, gray release and canary testing of services can be achieved. Specifically, by configuring fine-grained routing rules in the VirtualService of the service mesh ISTIO, part of the traffic is directed to the new version of the service, while monitoring the performance of the new version to ensure stability during the service upgrade process.

[0106] 2. Rate limiting and circuit breaking mechanisms

[0107] Introduce the Ratelimiting and Circuit Breaker mechanisms to prevent service avalanches caused by sudden traffic surges. The service mesh ISTIO provides rich application programming interfaces (APIs) to configure these policies to ensure that core services can operate stably even under extreme traffic conditions.

[0108] 3. Security and observability

[0109] Utilize the Security function of the service mesh ISTIO to implement mTLS for communication between different clusters and enhance security.

[0110] 4. Service mesh monitoring and alarm optimization

[0111] Integrate tools such as Prometheus, Grafana, and Jaeger to monitor and perform link tracing on the service mesh ISTIO to ensure that problems can be quickly located. On the basis of integrating Prometheus and Grafana, alarm rules can be further customized to set threshold alarms for key performance indicators (such as request latency, error rate, resource utilization, etc.) to ensure that problems can be discovered and processed in a timely manner. When using Jaeger for distributed link tracing, consider introducing more advanced analysis tools such as Kiali, which can provide a topological view of the service mesh, traffic flow analysis, etc., to help quickly locate and solve problems.

[0112] 5. Automated operation and maintenance and continuous integration / continuous deployment (CI / CD)

[0113] Establish a complete CI / CD process to automate the deployment and update of the service mesh and its components, reduce human operation errors, and accelerate the iteration speed. Combine the self-healing capabilities of Kubernetes, such as LivenessProbe and ReadinessProbe, to ensure the high availability of services. At the same time, use automation scripts or tools (such as Argo CD) to manage configuration changes, achieve version control, and one-click deployment.

[0114] Therefore, through the above architecture design, a highly available and high-performance multi-cluster financial cloud island communication architecture based on Kubernetes, service mesh ISTIO, and proxy component MOSN can be constructed, which can effectively support inter-service communication of the Dubbo protocol at the same time.

[0115] Figure 7 A schematic structural diagram of an electronic device provided by an embodiment of the present application. The electronic device can be integrated into a terminal device or a chip of a terminal device, and the terminal can be a computing device with data processing capabilities.

[0116] Among them, each cluster in the cross-cluster data communication system provided by the present application can be independently deployed on one or more electronic devices. Among them, the proxy components deployed by the service mesh in each cluster run on the electronic device.

[0117] The electronic device includes: a processor 701 and a memory 702.

[0118] The memory 702 is used to store programs, and the processor 701 calls the programs stored in the memory 702 to execute the above method embodiments. The specific implementation manners and technical effects are similar and will not be elaborated here.

[0119] Optionally, the present invention further provides a program product, such as a computer-readable storage medium, including a program, which is used to execute the above method embodiments when executed by a processor.

[0120] In several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division, and there may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces, and the indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.

[0121] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0122] In addition, each functional unit in various embodiments of the present invention may be integrated in a processing unit, may exist separately as individual physical units, or two or more units may be integrated in one unit. The above integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0123] The above integrated units implemented in the form of software functional units can be stored in a computer-readable storage medium. The above software functional units stored in a storage medium include several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to execute some steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (English: Read-Only Memory, abbreviated as: ROM), random access memories (English: Random Access Memory, abbreviated as: RAM), magnetic disks, or optical discs that can store program codes.

Claims

1. A cross-cluster data communication method, characterized in that, A proxy component deployed in the service mesh applied to the first cluster, where the first cluster is a cloud cluster or an island cluster, and the method includes: Intercept a service call request sent by a first service, where the first service is any service deployed in the service mesh, and the service call request is used to indicate a call to a target service deployed in a second cluster. The service call request includes: an identifier of the target service and business parameters of the requested resource, and the second cluster is a cloud cluster or an island cluster; Obtain a dynamic routing policy issued by the service mesh, and determine a forwarding path of the service call request according to the dynamic routing policy and the service call request; According to the forwarding path of the service call request, transmit the service call request to the target service via a communication network connecting the first cluster and the second cluster, so as to call the business parameters in the target service.

2. The method according to claim 1, wherein The dynamic routing policy is dynamically updated by the service mesh, and the dynamic routing policy includes: a whitelist list of adjustable services after dynamic update, multiple alternative node paths, and target addresses corresponding to at least one adjustable service. The whitelist list of adjustable services includes: identifiers of at least one adjustable service.

3. The method according to claim 2, wherein The determining the forwarding path of the service call request according to the dynamic routing policy and the service call request includes: Determine whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list; If so, determine the destination address corresponding to the target service according to the identifier of the target service and the target addresses corresponding to the at least one adjustable service; Determine the forwarding path of the service call request according to the destination address corresponding to the target service and the multiple alternative node paths.

4. The method according to claim 3, characterized in that The determining whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list includes: Compare the identifier of the target service with the identifiers of each adjustable service in the whitelist list. If the identifier of the target service is the same as the identifier of a first adjustable service, determine that the first service has the permission to call the target service.

5. The method according to claim 3, wherein The determining whether the first service has the permission to call the target service according to the identifier of the target service in the service call request and the whitelist list includes: If the identifier of the target service is different from the identifiers of all adjustable services in the whitelist list, determine that the first service does not have the permission to call the target service.

6. The method according to claim 3, wherein The determining the forwarding path of the service call request according to the destination address corresponding to the target service and the multiple alternative node paths includes: Adopt a polling strategy to select at least one target node path from the multiple alternative node paths from the current address corresponding to the first service to the destination address corresponding to the target service; Determine the forwarding path of the call request according to each target node path.

7. The method according to claim 1, characterized in that, The transmitting the service call request to the target service via a communication network connecting the first cluster and the second cluster includes: Using a preset request compression algorithm, compress the service call request to generate a compressed service call request, and transmit the compressed service call request to the target service via the communication network connecting the first cluster and the second cluster.

8. A cross-cluster data communication system, characterized in that, The system includes: at least one first cluster and at least one second cluster, where the first cluster is a cloud cluster or an island cluster, and the second cluster is a cloud cluster or an island cluster; The first cluster includes at least one service mesh, and a proxy component is deployed in each service mesh, and the proxy component is used to execute the method steps of any one of claims 1-7.

9. An electronic device, characterized in that, Including: A processor, a storage medium, and a bus, where the storage medium stores machine-readable instructions executable by the processor. When the electronic device runs, the processor communicates with the storage medium through the bus, and the processor executes the machine-readable instructions to execute the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the storage medium, and when the computer program is run by the processor, it executes the method according to any one of claims 1-7.

Images