每个技术方案的出现都有着其深刻的发展背景和演变过程，我们观察和了解是它的演变过程，可以掌控它的优势和缺点，在方案设计过程中做出最合适的选择。
前言
一、架构演变
说了这么多题外话，我们来逐个拆解“云边端”的架构设计方案。我们先要明白，“云边端”整个方案出现是在云计算兴起之后，其本质就是用来解决云计算的不足出现方案。所以这里云指的就是云计算，云计算、云资源这里就不再详细描述，现在云计算已经作为一种基础的信息服务能力，有各大厂商提供。这里我们先来看计算架构模式这么多年来的是演变发展。
- 在上个世纪，我国大部分的计算机都是单机运行，那时候上网使用拨号上网，所以大家买了计算机多半都是在运行单机程序，例如以前我很喜欢玩的单机游戏红色警戒。在运行这些游戏的时候，所有的计算资源都是由买的计算机提供的，也就是你的电脑能跑多快，决定了你能运行什么样的程序，跑什么样的游戏。
- 后来，网吧流行传奇（是兄弟就来砍我），奇迹这种网络游戏。这种游戏的模式是C/S架构的模式，即：Client / Server 模式，游戏客户端作为计算的主要节点，为用户提供画面、打怪、地图渲染等工作，而服务器负责进行数据交换，即：将电脑上的部分关键数据上传到服务器后，服务器将数据进行保存、或是和其他玩家进行交互互动。可以看出来这时候主要的计算资源依然是在本地的计算机上，即：Client端。所以那时候大家都喜欢去更新的网吧，要求有更高性能的电脑，你能玩什么样游戏，取决于网吧给你的电脑有多快。所以那时候可以看到网吧经常会分区收费，或是按游戏分区收费，例如运行xx游戏的游戏区。当年很多韩国游戏风靡，所以网吧每隔一段时间就会出现一个新的游戏区域，我印象中早年奇迹就有专门的游戏区，收费比别的区域电脑要贵很多。
- 云计算出现后，上面所有的情况就在转变。云计算是将很多高性能的服务器集中在一起形成一个超级庞大的云计算中心，然后给每个用户去分配计算资源使用。这种技术下面，我们来看现在的网吧模式。现在网吧基本上很多也是一个云计算中心的模式，然后网吧每个用户只给一个显示器即可。玩家直接使用云计算中心的计算资源，这样不再要求每一个用户都要有高性能的计算机。所以在这种架构模式下，计算资源已经不再是限制，理论上你能获取到的计算资源就是无限的（当然这只能是理论上）。那么理论上我们可以将很多占计算资源的东西都放到“云端”来运行，这也就是我们国家前几年轰轰烈烈的“上云运动”。
- 云计算的模式看起来已经很好，但是随着业务场景的发展，很快就出现更多的挑战。当计算资源不再成为核心障碍，当大家讲本地的业务场景全部开始搬到云端的时候，发现数据传输成为了障碍。以物联网应用为例，当一个物联网场景中数以亿计的物联网设备、传感器需要接入的时候，这些设备产生的数据流量变成了“数据洪流”，严重的时候，甚至会出现类似DDOS攻击的效果。云端服务架构在应对这种情况的时候，显得有些力不从心。另外一个案例是智能工厂、智慧XX的出现。智能工厂、智慧XX都对低延迟有着天然的需求，然而数据从设备到云端，计算结束后再从云端返回到设备的这个过程所花费的时间就已经无法接受，这时候单纯依靠于云计算的弊端开始显现出来，大家开始寻求新的架构方式，这种背景之下，就出现了“云边端”的架构设计方案。
二、云边端架构
在云端架构无法满足超低演示、巨量接入设备的背景下，云边端架构方案开始被使用。云边端架构图如下：
上图中：
- 云：云计算服务，负责下发控制命令，以及将所有的采集设备数据进行汇总和分析
- 边：边缘设备，负责将控制数据转发给采集设备，或是将它管理的采集设备的数据进行汇集，并进行初步的数据分析
- 端：采集设备，负责最基本场景数据的采集
在这种架构中，当采集设备采集到数据之后，将采集数据交给边缘设备，边缘设备设备将采集设备的数据进行汇总，并进行初步的数据分析，然后将分析结果上传给云端；如果云端想要控制采集设备，也是将控制命令先发送给边缘计算设备，边缘计算设备接收到控制命令之后，将控制命令进行分析，转换为采集设备的沟通协议进行下发。
依据上面的描述，可以看出来边缘设备除了承担云端和采集设备“缓冲层”，还有一个重要的作用是将不同的采集设备对云端进行屏蔽。例如：云端下发一条指令：“将1楼303房间的空调温度调到24℃”。云端的指令格式可能如下：
{"commands":[{"callType":"5","callVale":{"no": "1#303""temp": "25"},"taskId":"T000001","sn":"300XXXX"}]}
很明显，这种命令格式不可能被空调设备进行识别，将这个命令传输到边缘计算终端后，边缘计算终端通过查询采集设备和地址的对应表，可以知道1楼303房间的设备是YORK空调，设备通讯地址为03，这时候通讯计算设备就将云端下发的控制命令依据设备类型进行转换为通讯控制协议，最终发给空调设备的数据可能如下：
03 01 00 00 00 09 FD EE最终空调收到这个指令后，执行这个指令，将空调温度调整到24℃，完成了整个控制过程。
上面就是详细描述了“云边端”架构中，数据通讯的方式和流程。下面我们就来看几个"云边端"方案的具体业务实现架构。
电力行业“云边端”架构：
在这个架构中可以看到，他们将边缘计算节点形成一个机组集群，称之为“边缘计算中心”，还特别标注：“众多小型服务器机组”。单从这张图来看，这个架构并非传统意义上标准的“云边端”架构。前面我们介绍过，“云边端”架构提出的背景之一是解决低延时问题，而这张图中边缘设备依然作为服务器集群被放置在远离设备本身的地方，所以这里的边缘计算中心更像是将云端功能的下放和拆分，形成类似二级处理中心的概念，主要是用来分摊计算压力，或是用来对屏蔽系统差异。
上面这张图就是比较标准的“云边端”架构，其中IPC作为端侧，将数据汇总到边缘计算的节点中，各个计算节点再将数据汇总提交到是云端。
上面这个图是最符合传统标准"云边端"架构的设计方案，而且每个层的功能划分也是符合常规的"云边端"划分。这里除了架构，我们还应该注意到这个图中的"边缘层"，这个边缘层中标注了两个点：“云边同步”和“”操作系统+容器“，因吹斯汀，这里就引出了另外一个概念：边缘计算平台。
三、”云网边端“架构
我们这里先将还边缘计算平台的概念放一下，先介绍一下”云边端“的另外一种”变体“模式：”云网边端“。”云网边端“和”云边端“其实本质是都是同一种架构模式，只是一种架构在运用过程中，对于细节的关注点延伸。回顾一下”云边端“架构中的数据传输链路部分。在标准的架构模型中，端侧和边侧一般会直接采用通讯线直连的方式，因为这里一般讲究的就是稳定性；而边侧到云端的这个数据通讯链路中，可以选择的通讯方式就有很多种。例如：城市主干光纤线路、4G/5G通讯线路、卫星通讯线路等等。”云网边端“架构中强调出现的网，就是指边侧到云端这部分的数据通讯链路。为什么会特意强调一下”网“这个通讯链路，就目前多个实施项目来说，个人认为可能是通讯链路的技术方案的强调或是架构成本的强调。
1、通讯链路技术方案的强调
所谓的通讯链路技术方案的强调就是说在边侧到云端通讯的过程中，其使用的通讯链路技术有其特殊性，例如使用4G/5G等通讯链路。现在看来4G/5G的通讯链路方式不值得特别将“网”这个提出来进行说明，但是在前几年5G风行的时候，全国从上到下都在强调5G的高可靠性、低延迟性和高带宽特点，因此无论是建设方案也好，宣传发文也好，不带5G通讯的内容，就和现在没有AI的信息系统一样，有人会怀疑这个方案有什么建设意义。所以在原本“云边端”架构中，特意提及“网”这个通讯链路，从整个架构模式中就已经说明在通讯方式中采用了特别的链路，而这个链路就可以转换为设计方案或是宣传发文中的：”本项目中，我们使用5G专网融合通讯模式，实现了低延迟、秒切换的系统特性，使得系统的故障切换能力提高到毫秒级别；构建起“5G+工业互联网”的工业项目设计，推动XXXX的数字化转型“。就这一段话，这个项目整体的高度是不是噌的一下就被拔高了不止一个等级。例如：随着马斯克星链建设的成功，国内也开始积极推进商业航天、低位通讯卫星，我观察到国内今年有推出物联网卫星通讯方案，针对于基站覆盖不足，信号差的地方，作为一种补充通讯方案。所以如果我公司以后接了这种物联网数据采集项目，我也会积极在方案中强调自己使用“云网边端”的设计方案，然后在设计方案、宣发文章中写：“针对于xx地区基站覆盖不足，无通讯能力的问题，本项目采用目前国内先进的物联网卫星通讯方案，攻克边端设备和卫星通信设备的适配难题，整体性的提高了项目的抗毁坏性能力，实现XXXX公司卫星通信项目的首次落地，为后续卫星通信方案提供宝贵的项目经验和技术经验......”。就这段话，怎么也能体现出来一个项目“首创”的荣誉。
2、架构成本的强调
架构成本的强调是指在"联网"这件事情上，花了成本。例如我公司的端侧采集设备和边缘计算设备，均有RJ45版本、WiFi版本和4G/5G版本，以应对于多种项目现场。这三种设备的成本由低到高分别是：RJ45版本 < WiFi版本 << 4G/5G版本，其中RJ45的网线版本和WIFI版本设备价格相差100块钱左右，但是WiFi版本和 4G/5G版本版本价格相差在300左右。这个设备价格差异，最终肯定是需要在报价中体现，因此如果采用 4G/5G版本的设备，我们在建设方案中一般也会特意指出来使用了“”云网边端“的架构，然后将"网"这部分在方案中特意进行阐明：”鉴于XX项目现场网络架设问题，我们采用云网边端的技术架构，公司边缘计算设备通过4G/5G通讯能力，实现网络通讯的稳定性........“。这种也算是让客户对技术方案买单的一种体现。
这里额外讲了这么多，下一节我们就回到上一节中最后的那个概念：边缘计算平台。
四、边缘计算平台
上一章节说的"云边端"架构划分大家应该很清楚了，那让我们来思考一个几个问题：
- 由于终端设备数量极多，导致边缘计算设备数量庞大，这些设备如何进行管理？这里管理就包括了：设备故障、设备升级、设备注册、设备权限四个方面的管理。
- 边缘计算设备如何和云端进行信息交换？也就是在"云边端"架构中常提到的：云边协同。
如果大家对于云服务架构有所了解，必然对于K8S不会陌生。Kubernetes（简称K8s）是Google开发的开源容器编排引擎，用于自动化部署、扩展和管理容器化应用。其核心功能包括资源调度、负载均衡、服务发现及集群运维，支持多云环境和混合云部署。我们可以看到K8S里面有两个核心功能：资源调度和集群运维，因此是基于云服务架构特性，进行迁移，做出来一个K3S的设计方案。
K3S是一个专为边缘计算、物联网等资源受限环境设计的轻量级Kubernetes发行版，它通过一系列优化，将Kubernetes的强大功能浓缩在一个不足100MB的二进制文件中，大幅降低了部署和运维的复杂度，它对硬件要求很低，使其能够顺畅运行在从边缘服务器到ARM架构的设备中（如树莓派）。
这些方案可以看做是容器编排在边缘计算的一种扩展，现在在边缘计算领域用的挺多了，在很多电网的可研和招标讲的边缘计算集群、云管边、计算单元编排等都是指这个。
当然，我上面介绍的仅仅是边缘计算的一种解决方案，实际上目前的边缘计算有多种解决方案，这里做个汇总，有兴趣的读者可以去逐个了解。
- akri：适用于边缘 Kubernetes 资源接口
- baetyl：将云计算、数据和服务无缝扩展到边缘设备
- eliot：用于管理物联网设备中容器化应用的开源系统
- iotedge： 由微软开源的 IoT Edge 开源项目
- k0s：k0s 是一个包罗万象的 Kubernetes 发行版，配置了建立 Kubernetes 集群所需的所有功能，并被打包成一个二进制 文件，以方便使用
- k3s：由 Rancher 开源的轻量级的 Kubernetes
- kubeEdge：由华为开源的 Kubernetes 原生边缘计算框架，已贡献给 CNCF
- octopus：由 Rancher 开源的用于 Kubernetes/k3s 的轻量级设备管理系统
- openyurt：由阿里云开源的，将原生 Kubernetes 扩展到边缘，已贡献给 CNCF
- superedge：由腾讯开源的，用于边缘计算的边缘原生容器管理系统
在边缘计算层，很多公司都有其自己的实现方案，而且很多时候都是和公司业务方向极其相关。我们公司也是在公司自研的IoT Edge的边缘终端数据采集方案的基础上，做了与之配套的边缘计算平台，用于对边缘计算设备的设备注册、设备权限管理、设备升级管理和设备在线监测的全链路管理，并且因为设备资源的限制，我公司的边缘计算平台的终端安装包仅有2M，单个文件直接注册到系统服务中运行即可，这个方案在我们做异地设备管理和海量设备管理极其有效。在我们做的空调采集项目中，远在恩施的设备进行设备监控和管理，对空调采集、控制程序进行升级更新；在航修厂的项目中，我们实现几百台设备的在线监控、管理和维护。
我们再回到上一节内容最后的那个内容：边缘层中标注的两个点“云边同步”和“”操作系统+容器“。这里的云边同步就是指云边协同，操作系统+容器，意味着这家公司大概率采用的是k0s、k3s、kubeEdge、octopus和openyurt 这种类似方案中的一种。
说到这个边缘计算容器，我这里分享另外一个案例：
大家可以仔细阅读里面描述的技术方案，看看是不是能拆解出这里面边缘集群系统的技术实现路线。
这里额外在提一句，这种边缘计算平台的架构中可以看出，云平台可以通过边缘计算平台实现容器编排、自动化部署、扩展和管理容器化应用，因此在部分方案或是设计理念中，也同步提出来一个“云管边”的概念，这里就不再详细解释这个概念，只要大家理解了边缘计算平台，其实也就可以对这种概念的设计模式也会有清晰的认识。
五、扩展一下
前面已经介绍了“云边端”技术架构，并且详细介绍边缘计算平台的技术路线。那我们再来看一个“云边端”架构图：
这个是辅助驾驶车联网的架构图。我们来看这个架构很明显是一个很边缘计算终端的方案，我们再来看一张图：
这是模块化自动驾驶的示意图，依据上面的无人驾驶车联网示意图，你应该能看出来这部分就是边缘计算终端的功能，也就是智能汽车的模块功能。我前段时间注意到特斯拉汽车使用的是“端对端”的无人驾驶方案，然后详细了解了一下什么是“端对端”的技术方案。我这里将两种方案分别列出来：
1. 传统智驾
简单来说，模块式智驾就是一个流水线，主要有感知、预测、规划、控制四个流程。首先，感知部分的任务就是把车辆的雷达、摄像头等传感器的数据进行处理，然后分析车辆周围物体的具体位置、道路轨迹，以及辨别它们到底是行人、自行车、轿车、还是卡车等。紧接着，感知模块就会把以上的信息传给预测模块，预测模块会根据以上的信息分析周边交通参与者下一步的运动状态，比如周围的车辆接下来是要转弯、直行、还是停车等。通过进一步分析后，预测模块会提供一条或者多条本车接下来可参考的行驶路径以及车速。随后预测模块又把本车的道路行驶方案发给规划模块，规划模块会根据车辆自身状态、导航等信息来决定车辆接下来该具体怎么做。等到规划模块确认好行驶路径和速度后，就将命令传递给控制模块，最后再由控制模块去计算和操作车辆的方向盘、刹车以及油门。一个看似简单的智驾功能，就是通过以上步骤实现的。
优势
通过以上介绍不难看出，模块式智驾把简单的驾驶行为分解为多个步骤，而且每一步的逻辑都严丝合缝。在车企和供应商看来，模块式智驾本身是个非常好的方案，因为不同的团队可以负责相应的模块，发挥分工合作的优势，从而把智驾从概念迅速变为装车量产状态。
其次，模块式智驾有一套职能和责任都非常清晰的系统框架，因此当智驾系统在使用中发现BUG的时候，车企和供应商都能立即找到BUG的具体原因，并通过OTA迅速修复。比如车辆在高速行驶时出现了误刹车，那么通过数据分析，车企就可以知道故障是因为感知模块的数据有误，还是预测、规划模块给出了错误的判断。
缺点
虽然模块式智驾便于量产和修复BUG，但是要想让它能像人一样控制车辆，就需要学习诸多的交通规则和驾驶经验，而这一切都要靠工程师们事先去定义规则，也就是把交通规则和人的驾驶经验变成一行行软件代码。
但是光靠工程师写代码就能把现实中所有的驾驶场景都覆盖吗？当然是不可能的！关于这个问题，业内就有一个经典的案例，如果你在两侧停满车的狭窄道路驾驶车辆，此时道路一侧突然飘来一个气球，那么一般的逻辑会认为，道路一侧可能会有小孩蹿出来，所以此时车辆应该立即刹车。但同样的场景放在高速上，如果智驾系统仍旧采取立即刹车的方式控制车辆，那很可能演变为一场追尾事故。换言之，工程师如果没有针对这类驾驶场景事先定义好规则，比如高速检测到气球后系统不刹车，那么智驾系统遇到类似场景就会产生安全风险。按照小鹏汽车的说法，一个比较稳定的量产智驾系统，大约有10万条规则。而如果智驾系统要接近人一样的水平，大约需要人工编写10亿条规则。对于软件工程开发来说，这几乎是一件不可能完成的事情。正因如此，我们可以看到传统智驾系统在日常使用中或多或少会出现各种错误，以至于驾驶者不得不进行干预。
2. 端对端智驾
基于以上原因，专注于自动驾驶的车企一直在想办法解决传统智驾需要预设规则的问题，于是便有了端到端。所谓的端到端，其实就是将传统的感知-预测-规划-控制这些子模块全部神经网络化，也就是用先进的算法模型取代了传统的算法和人工编写的规则。
因此在工作流程上，端到端与传统的模块式有着较大的不同。传统模块式的工作顺序是感知-预测-规划-控制依次进行的，而端到端的顺序是传感器数据（雷达、摄像头）-神经网络-驾驶参数（方向盘、油门、刹车），也就是说，传统的感知、预测、规划、以及控制模块的工作全部由神经网络完成。端到端中的核心技术就是神经网络，当神经网络应用到汽车上之后，就意味着人们可以不断地训练智驾系统，从而使它学习适应更复杂的驾驶环境。
因此在功能层面，端到端最大的变化就是系统具有自主学习的能力，这是传统模块式智驾不具备的功能。如此一来，在处理各种意想不到的真实驾驶场景时，端到端可以通过神经网络计算得出合适的规则，而不需要人工事先编写好规则，这也就为智驾应对现实中无穷无尽的驾驶场景提供了解决方案。
缺点
神经网络对于人们来说是个“黑盒”，当智驾系统出现明显的逻辑错误时，在模块式系统上车企可以非常迅速找到问题出在哪个模块，然后人工编写一个新的规则。但在端到端系统上，车企并不知道复杂的神经网络中哪一个参数或者结构存在问题。
正因如此，基于神经网络打造的端到端智驾系统，有时候它能在很复杂的场景中给出合理的规则，但有时又会犯十分低级的错误，比如分不清红绿灯，于是有人就把端到端形容为：“上限很高，下限很低”。
(上面关于传统传统智驾和端对端智驾的描述来源于百度百家号)
我这里特意来说无人驾驶的方案，肯定还是和本文一直说的“云边端”架构相关。如果无人驾驶全部采用端对端智驾模式，神经网络的能力至关重要，而众所周知，神经网络是需要算力支撑，那么要实现这种方案有两选择：
1. 神经网络内置于汽车车机中，所有的输入信号都是在汽车车机中来完成。这种架构来说，相当于摄像头、雷达就是“端侧”，汽车车机就是“边侧”，而云端会将无人驾驶的训练数据推送到骑车车机中，这个过程可以称之为“云边协同”;
2. 汽车车机无法支撑起车机的神经网络算力需求，这时候需要将数据在汽车车机中做初步处理之后，交由云端进行进行算力支撑，即主要处理是由云端来完成，这种模式下，请我们再次回顾一下，“云边端”架构要解决两个核心问题：低延时和“数据洪流”；这就是这种方案主要要解决的问题。
据可以查阅的资料来看，特斯拉的FSD V12版本不需要联网可以启用，依据表现来看，特斯拉应该是采用了上面第一中方案，他们的车机芯片应该很强大；如果有智驾汽车不联网就无法启动高阶辅助驾驶，这种应该是采用了上面说的第二种方案。
这里我再额外扩展说一些，就算FSD V12是可以使用车机来本地独立完成自动驾驶，但是依据看到的宣传视频来看，马斯克意图将特斯拉打造成一个智慧终端，例如可以理解司机意图等，这种大概率不可能仅仅依赖于边端来实现，通过云端处理是较为合理的设计方案，只要需要云端实现就摆脱不了低延时和“数据洪流”的问题，那么马斯克如何解决，其实答案很明显：Dojo 和 星链。
最后
"云边端"架构作为目前物联网、工业领域很重要的一个设计模型和设计方式被反复提及和使用，但是我们一样要清楚这种模式带来的复杂性和挑战，例如：添加的边缘侧导致云端失去了对于端侧的直接掌控，因此端侧的掌控完全依赖于边缘侧的能力，这样边缘侧架构设计难度提升；同时因为引入边缘侧设备，也导致云端的架构设计复杂度成倍提高（一个架构节点的加入，对于整体架构影响并非只是增加一个节点）。所以目前还有相当数量的部分厂商依然采用的是“端侧”到“云端”直连直控的方案，这也算是一种架构设计和投入成本直接的平衡，并没有什么对错之分。
我曾在《数字化的表现形式》一文中提出，“每一个方案能被市场所大范围接受，必然有着它的生存空间，我们所要做的就是分析方案本身最基本的表达内容，将其最有效的一面结合业务展示出来”。同样，每个技术方案的出现都有着其深刻的发展背景和演变过程，我们观察和了解是它的演变过程，可以掌控它的优势和缺点，在方案设计过程中做出最合适的选择。
下一篇我们将回到企业数字化的内容，欢迎大家持续关注。