HUAWEI CLOUD International Edition Cloud Native Infrastructure: CCE Container Cluster and Microservice Architecture Overseas Deployment Guide
In the wave of enterprises going to sea, the "acclimatization" of technical architecture is the high incidence of overseas business abortion. Compliance is strict, network delay jitter, cross-border operation and maintenance time difference, each is a hard bone.
With its localized data centers in Asia Pacific, Europe, Latin America and other places, HUAWEI CLOUD International Edition has become the first choice for many overseas enterprises. This article does not talk about the macro concept of virtual, direct landing technology hard goods, talk about how to build a set of highly available, compliant and low-latency overseas cloud native infrastructure based on Huawei Cloud International Cloud Container Engine (CCE) and microservice architecture.
1. Overseas Compliance and Architecture Design: Take the First Step
Overseas deployment,
Compliance and disaster tolerance are the overriding bottom line
. Europe has GDPR and Southeast Asia has PDPA. If the domestic "one shuttle" structure is directly moved to the past, it will face huge fines at any time.
1. Data Compliance and Region Selection
HUAWEI CLOUD International has independent regions in Singapore, Frankfurt, Bangkok, and Sao Paulo. When planning a microservices architecture, you must
Data Flow Audit
:
User Privacy Data (PII): Must be stored locally. For example, for microservices of European users, their databases (such as GaussDB) and caches (Distributed Cache Service) must remain in the Frankfurt Region and must not be transmitted back to China across borders.
Non-sensitive business logic: It can be decoupled through microservices and deployed on the node closest to the user to reduce latency.
2. Cross-regional high availability (Geo-Redundancy)
The failure probability of overseas single data center is not lower than that of domestic data center, so overseas microservices must be deployed in multi-availability zone (Multi-AZ).
CCE cluster configuration: When creating a CCE Turbo cluster, at least three different AZs must be selected for the control node and the worker node.
Traffic distribution: The traffic portal uses Elastic Load Balancing (ELB), combined with Huawei Cloud Global Acceleration Service (GA), and uses Huawei's global backbone network to connect overseas user traffic to nearby and automatically balance the load among multiple AZs.
2. CCE Turbo Cluster Landing Overseas: Core Configuration Practice
HUAWEI CLOUD CCE(Cloud Container Engine) is divided into the regular version and the Turbo version. Sea business strongly recommended to choose
CCE Turbo
, it natively supports Huawei's self-developed
Yangtse (Yangtze River) Network Architecture
This is a sharp weapon to deal with the complex network environment overseas.
1. Container Network: Reject Secondary Virtualization
Traditional container networks (such as Calico VxLAN) have packet loss, which slows down RPC communication between microservices when the latency of overseas physical networks is high.
Hardcore Recommendation: Choose Cloud Native Network 2.0(Yangtse). It allows each pod to directly assign a real IP address in HUAWEI CLOUD VPC,
The cloud databases are on the same network plane.
Effect: Microservices call each other (for example, Spring Cloud calls through Feign or Go microservices communicate through gRPC) directly via VPC routing, reducing network latency by more than 40%.
2. Overseas Node Pool and Auto Scaling
Overseas users often have obvious "time difference effect" and "sudden traffic" (e. g. e-commerce promotion, game opening service).
Multi-specification node pool: For microservices, do not mix all pods on one ECS instance. Establish two node pools: compute-intensive node pool (C series): running API gateway and core business microservices. General node pool (S series): running log collection (Logstash/Fluentd), monitoring (Prometheus Exporter) and other auxiliary components.
HPA and CA linkage: configure horizontal Pod scaling (HPA) to automatically expand Pod based on CPU/memory utilization. At the same time, cluster automatic scaling (Cluster Autoscaler, referred to as CA) is enabled. When Pod is in Pending state due to insufficient resources, it will automatically apply to HUAWEI CLOUD for overseas ECS instances to be added to the node pool in seconds.
The landing of 3. microservice architecture overseas: governance and communication
How can microservices be managed efficiently in an overseas multi-region and multi-AZ environment? HUAWEI CLOUD provides
Microservice Engine (CSE)
, which is deeply integrated with ServiceComb, Spring Cloud Huawei, and the Istio service grid.
1. Registry and Configuration Center: Localization and Synchronization
If your business requires cross-country/cross-regional collaboration,
Don't let overseas micro-services connect with domestic registration centers.
.
Localized deployment: CSE is deployed independently in overseas regions (Nacos, ZooKeeper, and ServiceComb are supported). Overseas microservices are registered nearby.
Configuration management: Use CSE's configuration center to separate "business logic" from "overseas environment parameters" (such as Sercet Key of overseas third-party payment SDK and currency exchange rate interface addresses of different countries). After the configuration is modified, microservices are aware in seconds and do not need to repackage the image.
2. East-West Flow Governance (Service Mesh)
When the number of microservices exceeds 100, it is extremely painful to rely solely on code-level SDK (such as Spring Cloud) to manage overseas complex network timeouts and retries. It is recommended to adopt
Application Services Grid (ASM)
(HUAWEI CLOUD Istio-based managed service).
Circuit Breaker (Circuit Breaking): Overseas public network jitter is the norm. The fuse policy is configured through ASM. When an overseas third-party service (such as Google Auth or PayPal payment interface) fails five times in a row, the microservice is immediately fused.
, follow the local degradation logic to prevent full-link avalanche.
Canary Release (Canary Release): Overseas releases are extremely risky. Using ASM, accurate gray-scale release can be carried out based on HTTP Header (e.g. X-Country according to the user's country: SG). 5% of Singapore users can test new microservices first, and then push the full amount after stabilization.
4. Cross-Border CI/CD and Mirror Acceleration: Open R & D Delivery Links
R & D team in China, production cluster in overseas, how to safely and quickly deploy code across thousands of kilometers?
1. Mirror Repository (SWR) Global Replication
If the overseas CCE cluster is allowed to directly go to the domestic container image warehouse (SWR) to pull several G business images, it will be too slow to make people doubt their lives, and the deployment will easily fail due to network interruption.
Correct approach: build a SWR warehouse at home (e. g. Beijing IV) and overseas (e. g. Singapore). Take advantage of the mirror synchronization feature of SWR. The domestic CI/CD pipeline (such as Jenkins or GitLab CI) packs and pushes the image to the domestic SWR. Configure triggers to automatically synchronize images from SWR to SWR in Singapore through HUAWEI CLOUD cross-border leased lines. Overseas CCE cluster configuration pulls images from the local SWR and goes through the intranet line. The speed is shortened from a few minutes to a few seconds.
2. Safe transnational assembly line
R & D control: CI/CD console stays in China to ensure the safety of code assets.
Voucher hosting: Do not write Kubeconfig files of overseas CCE clusters directly into pipeline scripts. Use the DEW (Data Encryption Service) managed credentials of HUAWEI CLOUD, or use HUAWEI CLOUD IAM (Unified Identity Authentication) to grant the pipeline-minimized cluster operation permissions.
5. Overseas Observability: Seeing Microservices in the Black Box
After overseas business online, operation and maintenance often face "time difference blind zone". While domestic R & D is sleeping, overseas is experiencing a peak in traffic. A well-developed observability architecture is the only means of self-rescue.
1. Unified log management: LTS
Microservice distributed logs must be centralized. HUAWEI CLOUD Log Service (LTS) is natively integrated in CCE Turbo.
Configuration: Enable the LTS log collection plug-in of CCE to directly collect the standard output (Stdout) of the pod and the log files in the container.
Optimization: Set structured parsing in LTS (for example, extract userId and responseTime from JSON logs as indexes). Use the dump function of LTS to dump cold logs over 30 days to OBS (Object Storage Service) to meet the compliance requirements of overseas audits on the log retention cycle.
2. Application Performance Management: APM
Overseas microservices respond slowly. Is it a network problem, a database deadlock, or a third-party API stuck?
Deployment: Inject APM (Application Performance Management) probes for microservice pods in CCE (non-intrusive, Java/Go/Node.js support, etc.).
Monitoring core metrics: Keep an eye on the call topology and JVM heap memory. Through the distributed link trace (Trace) of APM, you can see at a glance which microservice node takes the longest time for a request.
Summary of 6. Seaside Pit Avoidance and Best Practices
Finally, summarize some of the blood and tears of deploying CCE and microservices overseas:
The security group (Security Group) must follow the principle of least privilege: overseas scanners are extremely rampant. Node nodes in CCE clusters must not be bound with elastic public network IP(EIP), all inbound traffic must pass through ELB, and only 80/443 and other necessary ports are opened.
Reasonable allocation of CoreDNS: frequent visits between microservices through Service domain names, overseas large concurrent CoreDNS can easily become a bottleneck. Be sure to enable NodeLocal DNSCache (node local DNS cache) in CCE to reduce the pressure on the core DNS of the cluster and avoid microservice call failure caused by domain name resolution timeout.
Pay attention to storage selection: If overseas microservices have persistence requirements (such as file upload), do not use pure local disks (local disks disappear with pod destruction). You should use HUAWEI CLOUD SFS Turbo (fast file storage), which supports simultaneous read and write of multiple pods, and the read and write latency can reach sub-millisecond level, which is very suitable for microservice shared storage scenarios.
Cloud native is not a simple replacement of virtual machines with containers, and overseas deployment is not a simple replacement of computer rooms. By finely configuring the CCE Turbo, Yangtse network and CSE microservice engine of HUAWEI CLOUD International, enterprises can build a solid and lightning-fast global business digital base in a complex overseas network and compliance environment.
