Edge Computing Practices at NetEase: Architecture, Modules, and Real-World Scenarios

NetEase's rapid growth in IoT has driven a surge in demand for internal "everything connected" solutions, prompting the adoption of edge computing to enable low‑latency data acquisition, local processing, and cloud‑edge collaboration, thereby avoiding loss of control when devices lose network connectivity.

The article provides a systematic overview of NetEase's edge computing practice, summarizing challenges, risks, and mitigation strategies.

Background

Edge computing is defined as a reconstruction of the centralized cloud model, moving compute, storage, and networking capabilities closer to data sources. This reduces communication latency, enables fast business responses, and improves data privacy. It has evolved from mainframes to cloud data centers and now to edge nodes.

The Internet of Things (IoT) is a prime use case for edge computing because many devices operate in private, isolated networks and require real‑time control. Edge gateways provide sub‑second response times and local autonomy, while also handling confidential data locally before syncing processed results to the cloud.

System Architecture: NetEase "疾风" IoT

The early "疾风" platform built a cloud‑centric IoT system with device access, rule engine, and time‑series database services. With the rise of edge computing, the architecture was extended to the edge.

Initially, the edge stack mirrored the cloud stack, but cost concerns led to a streamlined design: stateful computations remain on Flink, while stateless tasks are offloaded to function‑as‑a‑service (OpenFaaS) and later to the lightweight Kuiper stream engine, forming a unified real‑time compute engine.

Offline workloads such as reporting and model training stay in the cloud, while the edge focuses on real‑time device control and data privacy. A custom "edge tunnel" enables seamless cloud‑edge synchronization, supporting hardware ranging from x86 servers to industrial PCs and gateway boxes.

Edge Architecture Modules

1. Hub (Device Access) – Supports multiple physical interfaces (RS232/RS485, Ethernet, Wi‑Fi, Bluetooth) and protocols (Modbus, OPC UA, BLE, MQTT). Non‑MQTT data is converted to MQTT via a converter that maps device fields to MQTT topics, allowing downstream compute engines to consume unified messages. Media streams (e.g., RTSP) are also converted to RTMP for further processing.

2. Compute Engine – Combines function compute and stream compute, dispatching tasks based on statefulness. Common rule types include forwarding, storage, reverse‑control, and audio‑video processing (transcoding, screenshot, recording, edge live streaming).

3. Edge Services – Provide time‑series storage, visualization dashboards, virtual device control, and hosted enterprise applications (e.g., production management, personnel management).

4. Cloud‑Edge Collaboration – Data and control synchronization is handled by Tunnel Agent (edge) and Tunnel Server (cloud). Data flows from edge to cloud via Kafka or CDN endpoints; control commands flow from cloud to edge through a TCP tunnel, enabling remote device management and configuration.

Practical Scenarios

Industrial – Real‑time monitoring of production lines, equipment status, and energy consumption. Edge gateways aggregate sensor data (temperature, humidity, power) and enable instant alerts, anomaly detection, and local decision‑making.

Smart Campus – Integrated management of lighting, HVAC, and air quality. Edge gateways collect environmental data (CO₂, temperature, humidity) and automatically adjust lighting and ventilation based on real‑time analytics, reducing energy waste.

Additional use cases include edge live streaming, image recognition, conference‑room occupancy detection, and livestock monitoring with RFID tags and environmental sensors.

The presentation concludes with a thank‑you note and an invitation to join the DataFunTalk community for further discussions on big data and AI applications.