边缘计算架构：端-边-云三层架构详解

聊边缘计算，我习惯先画一张图。不是那种花里胡哨的架构图，而是实实在在的「三层模型」——端、边、云。这个模型我用了快十年，每次给团队讲架构，我都会在白板上先画这三层。

端层：数据的源头

端层，就是那些真正「摸得着」的物理设备。传感器、PLC、摄像头、智能电表……它们负责产生数据，也负责执行动作。

我在一个智慧工厂项目里遇到过这样的情况：现场有200多个传感器，温度、湿度、振动、电流，五花八门。这些设备用的协议各不相同——Modbus RTU、OPC UA、MQTT、甚至还有几个老旧的串口设备。你想想看，如果让这些设备直接上云，云平台得疯掉。

边缘层：真正的战场

边缘层才是我们做边缘计算的人真正要关注的地方。它夹在端和云之间，承担着「承上启下」的角色。我个人习惯把边缘节点分成三类：

边缘节点类型	典型硬件	主要职责	适用场景
边缘网关	ARM架构工控机、RTU	协议转换、数据汇聚、本地路由	工厂产线、楼宇自动化
边缘服务器	x86服务器、NUC	本地数据处理、轻量级分析、缓存	视频监控、零售门店
AI 盒子	Jetson、NPU加速卡	实时推理、图像识别、异常检测	质检、安防、自动驾驶

嗯，这里要注意一点：很多人把边缘网关和边缘服务器混为一谈。其实区别很明显——网关更侧重「连接」和「转换」，服务器更侧重「计算」和「存储」。AI盒子则是专门为推理优化的，说白了就是带AI加速芯片的专用设备。

云层：大脑与仓库

云层负责全局调度、模型训练、长期存储和跨区域管理。它不参与实时决策，但提供「全局视角」。

举个例子：边缘节点可以独立判断「这个零件有缺陷」，但「缺陷的标准是什么」——这个模型是在云端训练好再下发的。边缘节点可以独立存储最近7天的数据，但「历史趋势分析」需要云端的海量存储和计算能力。

主流边缘计算框架：三足鼎立

框架选型是个头疼事。我这些年接触过不下十种边缘计算框架，真正在生产环境站稳脚跟的，就三个：KubeEdge、EdgeX Foundry、Azure IoT Edge。它们各有各的脾气。

KubeEdge：云原生玩家的首选

如果你团队里有人懂Kubernetes，那KubeEdge几乎是无脑选。它本质上是把K8s的能力延伸到边缘。

• 核心优势：原生K8s API兼容，边缘节点可以像云节点一样管理
• 离线自治：网络断了，边缘节点照样能跑，恢复后自动同步
• 轻量化：边缘端只运行一个叫EdgeCore的组件，资源占用极低

我记得有个风电场的项目，风机分布在几十公里的山脊上，网络时好时坏。用KubeEdge部署后，每个风机上的边缘节点独立运行，网络恢复时自动上报数据。运维团队直接在云端用kubectl管理所有边缘节点，体验跟管理云上Pod一模一样。

# KubeEdge 边缘节点注册示例
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-ai-inference
  labels:
    app: inference
spec:
  replicas: 1
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      nodeSelector:
        node-role.kubernetes.io/edge: ""
      containers:
      - name: inference
        image: myregistry/inference:v1.0
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"
EOF

EdgeX Foundry：物联网协议的大熔炉

EdgeX Foundry是Linux基金会旗下的项目，它的设计哲学是「微服务+插件化」。说白了，它把协议接入、数据路由、规则引擎、设备管理全部拆成独立的微服务。

我个人特别喜欢它的设备服务层。你想想看，一个工厂里可能有Modbus设备、BACnet设备、OPC UA设备……EdgeX通过不同的「设备服务」来对接，每个设备服务就是一个微服务，可以独立开发、独立部署。

EdgeX 层级	功能	典型组件
设备服务层	协议转换、设备连接	device-modbus, device-mqtt, device-rest
核心服务层	数据路由、元数据管理	core-data, core-metadata, core-command
支持服务层	规则引擎、调度、告警	rules-engine, scheduler, alerts
应用服务层	数据导出、外部集成	app-service-export, app-service-http

Azure IoT Edge：微软生态的深度绑定

Azure IoT Edge是微软推出的边缘计算框架，跟Azure云服务深度集成。如果你公司已经在用Azure，那选它准没错。

它的核心概念是「模块」——每个模块就是一个Docker容器，运行在边缘设备上。你可以把AI推理、数据过滤、协议转换都封装成独立的模块。

我曾经帮一个客户做冷链物流监控，用Azure IoT Edge在冷藏车上部署边缘节点。车上网络不稳定，但Edge的离线消息队列功能保证了数据不丢失。等车回到仓库连上WiFi，数据自动同步到云端。嗯，这个体验确实不错。

// Azure IoT Edge 模块部署配置（deployment.json 片段）
{
  "modules": {
    "temperatureFilter": {
      "version": "1.0",
      "type": "docker",
      "status": "running",
      "restartPolicy": "always",
      "settings": {
        "image": "mcr.microsoft.com/azureiotedge-filter:1.0",
        "createOptions": {}
      }
    },
    "aiInference": {
      "version": "1.0",
      "type": "docker",
      "status": "running",
      "restartPolicy": "always",
      "settings": {
        "image": "myregistry/ai-inference:1.0",
        "createOptions": {
          "HostConfig": {
            "Memory": 512000000,
            "CpuShares": 512
          }
        }
      }
    }
  }
}

如何选择？我的三点建议

1. 看团队技术栈：团队熟悉K8s就选KubeEdge，熟悉微软生态就选Azure IoT Edge，需要灵活对接多种协议就选EdgeX Foundry。
2. 看硬件资源：资源紧张（1核1GB以下）优先考虑KubeEdge的EdgeCore；资源充裕（2核2GB以上）可以上EdgeX的微服务架构。
3. 看离线需求：网络不稳定场景，KubeEdge和Azure IoT Edge都有成熟的离线自治方案。EdgeX的离线能力相对弱一些，需要自己额外开发。

说到底，没有完美的框架，只有适合的框架。我这些年换过好几次框架，每次切换都像搬家一样痛苦。所以我的建议是：前期花两周时间做POC验证，比后期花两个月重构要划算得多。

---