Industrial and Commercial Bank of China Service Mesh Implementation Case Study

Service Mesh is the next‑generation foundation for micro‑service architectures. Ant Group began exploring the technology in early 2018 and has since deployed it across thousands of applications, demonstrating significant benefits in infrastructure efficiency, development and operations productivity, and cost reduction. The following is a practical case study of Industrial and Commercial Bank of China (ICBC) applying Service Mesh.

1. Industry Development Status of Service Mesh

Since its inception in 2016, many open‑source Service Mesh products have emerged, such as Istio (Google+IBM+Lyft), Linkerd (Twitter), and Consul (HashiCorp). Istio enjoys the highest community activity and is often regarded as the benchmark.

Service Mesh is a dedicated infrastructure layer for handling service communication. It injects a Sidecar container into each business Pod to intercept traffic, connects the Sidecar to the control plane, and enforces policies for traffic governance, thereby decoupling framework capabilities from business services.

Figure 1: Service Mesh Diagram

Sidecar containers take over inbound and outbound traffic of backend services, enabling cross‑language and cross‑protocol communication. They also provide unified routing, security encryption, and monitoring capabilities.

2. Service Mesh Technology in ICBC

ICBC started its IT architecture transformation in 2015. Today, its distributed system covers more than 240 critical applications, with over 480,000 provider nodes and a daily call volume exceeding 12.7 billion. However, the platform faces common challenges such as high maintenance cost for multi‑language stacks and difficulty upgrading heterogeneous frameworks.

To address these pain points, ICBC introduced Service Mesh to decouple business systems from underlying infrastructure and enhance service governance.

(1) Integration with Existing Micro‑service Frameworks

The Service Mesh platform integrates the existing registration center, monitoring, and other infrastructure components. Core communication protocols remain in lightweight clients within business systems, while advanced capabilities are offloaded to the Sidecar, enabling a smooth transition.

Figure 3: Comparison of Sidecar and Micro‑service SDK

The control plane includes configuration, registration, security, governance, monitoring, and logging modules. The data plane Sidecar uses the same communication protocols (Dubbo/Spring Cloud) as the original framework, ensuring seamless interoperability.

Figure 4: ICBC Service Mesh Architecture

(2) Large‑Scale Deployment and Migration Strategies

Non‑intrusive traffic proxy for big‑data scenarios : By modifying Pod iptables rules via an Init Container, all traffic is redirected to the Sidecar, allowing transparent interception without code changes.

Figure 5: Transparent Traffic Hijacking Diagram

Low‑intrusive proxy for high‑frequency online services : A lightweight client redirects service registration and discovery to a local Sidecar (127.0.0.1), which then forwards requests to the actual service, preserving performance while enabling traffic control.

Figure 6: Port‑level Traffic Proxy Diagram

Smooth migration from traditional to mesh deployments : The platform supports both Dubbo and Spring Cloud protocols, allowing mesh instances and legacy services to coexist under the same registry and migrate gradually.

Figure 7: Smooth Migration Diagram

Performance challenges at scale : With over 480,000 providers, full‑state XDS pushes from Pilot can strain the control plane. ICBC introduced third‑party registration and configuration centers, enabling Sidecars to subscribe on demand and dramatically reducing Pilot load, achieving million‑instance capacity in tests.

Figure 8: Control Plane Component Evolution

3. Enterprise‑Level Service Governance

The open‑source Istio provides basic routing and observability, which is insufficient for enterprise needs. ICBC collaborated with the SOFAMesh team to build a financial‑grade Service Mesh with enhanced traffic control, monitoring, fault self‑healing, and security features.

3.1 Monitoring and Operations

The platform offers built‑in monitoring and alerting, exporting metrics to third‑party systems and triggering alarms based on request error rates. Alerts are automatically linked to rate‑limiting, circuit‑breaking, degradation, and self‑healing actions.

3.2 Traffic Management

Fine‑grained traffic matching based on identity tags enables precise control at label, method, service, or application level. Supported capabilities include rate limiting, circuit breaking, degradation, routing, traffic mirroring, encryption, authentication, fault injection, and isolation.

3.3 Fault Self‑Healing

Instead of manual emergency procedures, the platform provides an automated fault‑self‑healing system that monitors failure rates within a time window, isolates faulty nodes at client or server side, and restores connectivity once the node recovers, thereby improving high‑availability of distributed systems.

Figure 9: Fault Isolation Workflow

3.4 Security Management

The mesh supports national cryptographic standards and mainstream algorithms to establish encrypted channels, achieving zero‑trust networking. It can identify caller identities and enforce access control policies (black/white lists), preventing malicious attacks and protecting system availability.

Figure 10: Security Control Diagram

3. Future Outlook

Service Mesh, as the next‑generation micro‑service technology in the cloud‑native domain, has been evolving for over five years. Successful large‑scale production cases remain scarce, especially in the financial sector. ICBC’s mesh has validated multi‑language, heterogeneous, and edge‑scenario pilots, demonstrating advantages in traffic control and system extensibility.

Going forward, ICBC will expand pilot applications, refine platform capabilities, and further improve performance and stability, aiming to provide a best‑practice reference for the financial industry’s adoption of Service Mesh.