Meituan OCTO 2.0: Architecture, Service Mesh Features, and Operational Practices

OCTO 2.0 is Meituan's next‑generation distributed service‑governance system. It builds on the existing OCTO 1.0 platform and integrates a Service Mesh communication layer, delivering a new version of naming services, configuration management, performance monitoring, rate‑limiting, and authentication.

The OCTO platform provides a complete service‑governance solution for all internal services, including a naming service, data‑center, and user‑management platform. Previous articles have introduced various aspects of OCTO, such as the evolution of Meituan's naming service (MNS), the trillion‑scale data‑center computing engine, the open‑source core components (OCTO‑RPC, OCTO‑NS, OCTO‑Portal), and challenges of deploying Service Mesh at large scale.

This article continues the series by focusing on the Service Mesh evolution of OCTO, describing the design from a data‑plane perspective.

Overall Architecture

The system consists of four parts: infrastructure, control plane, data plane, and operation system. The infrastructure reuses OCTO 1.0 components (MNS, KMS, MCC, Rhino) and connects them to the OCTO 2.0 control plane to avoid costly rewrites. The control plane is fully self‑developed (instead of using Istio), the data plane is based on a customized Envoy, and the operation system handles upgrades and releases of data‑plane components.

Mesh Functions

1. Traffic Hijacking – Instead of Istio’s native approach, OCTO 2.0 uses iptables to intercept pod traffic, but due to performance loss and poor manageability, the final solution adopts Unix Domain Socket (UDS) direct connections between business processes and OCTO‑Proxy.

2. Service Subscription – Native Envoy’s CDS/EDS performs full service discovery, which is inefficient at Meituan’s scale. OCTO implements on‑demand discovery, requesting only the backend services actually needed.

3. Loss‑less Hot Restart – For short‑lived connections, a “drain” process ensures zero traffic loss. For long‑lived connections, additional client‑side logic is added to detect proxy restart signals and retry requests. Both client and server sides employ coordinated restart protocols to keep traffic uninterrupted.

4. Data‑Plane Operations – In Meituan’s single‑container deployment model, the LEGO platform provides process‑level management (health checks, fault‑restart, monitoring, version rollout). For cloud‑native environments, an operator‑driven lifecycle management is explored, culminating in a dual‑container hot‑restart design that works around Kubernetes’ limitation on modifying running Pods.

Future Plans

The roadmap includes moving operations, releases, and stability engineering toward cloud‑native practices, extending mesh to internal HTTP services to reduce gateway dependence, and achieving full‑link mTLS support.

Authors

Shu Chao, Shi Peng, Lai Jun – members of Meituan’s Infrastructure Development Group, responsible for OCTO 2.0 development.