云计算发展史，就是虚拟化技术的发展史。近 20 年来云计算与互联网相互促进高速发展，中心云技术成为全社会通用的基础设施。随着物联网、人工智能等技术的不断发展，尤其是产业互联网发展落地，中心云计算开始相形见绌，分散式边缘计算在当下被重新寄予厚望。如果中心云计算是由技术创新驱动的，那么边缘计算一定是业务价值驱动的。
边缘计算的理解与思考
边缘计算的定义
边缘计算当前没有准确定义，从 IT 云计算领域视角，边缘计算被看作中心云计算的拓展。边缘计算产业联盟对边缘计算的定义：“在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业数字化在敏捷连接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求”。从 CT 电信领域视角，边缘计算最初也被称为移动边缘计算(MEC)。
欧洲电信标准协会(ETSI)对 MEC 的定义：“移动边缘计算在移动网络的边缘、无线接入网(RAN)的内部以及移动用户的近处提供了一个 IT 服务环境以及云计算能力”。
边缘计算的定义各有侧重，但核心思想基本一致——边缘计算是基于云计算核心技术，构建在边缘基础设施之上的新型分布式计算形式，在边缘端靠近最终用户提供计算能力，是一种靠近数据源的现场云计算。中心云计算凭借其强大的数据中心，为业务应用提供大规模池化，弹性扩展的计算、存储、网络等基础设施服务，更适用于非实时、长周期数据、业务决策场景;边缘计算则聚焦在实时性、短周期数据、本地决策等业务场景，比如当下热门的音视频直播、IoT、产业互联网、虚拟现实甚至元宇宙等，将工作负载下沉至离终端设备或者靠近最终用户的地方，以此实现更低的网络延迟，提升用户的使用体验。
“章鱼式”边缘计算
边缘是相对中心式计算的边缘分散式计算。边缘计算的核心目标是快速决策，将中心云的计算能力拓展至“最后一公里”。因此它不能独立于中心云，而是在云-边-端的整体架构之下，有中心式管控决策，也有分散式边缘自主决策，即章鱼式边缘计算。
如上图漫画中所示，章鱼全身神经元中心式脑部占 40%，其余 60% 在分散式腿部，形成 1 个大脑总控协调 + N 个小脑分散执行的结构。1 个大脑擅长全局调度，进行非实时、长周期的大数据处理与分析;N 个小脑侧重局部、小规模数据处理，适用于现场级、实时、短周期的智能分析与快速决策。
章鱼式边缘计算采用中心云+边缘计算的分布式云边一体化架构，海量终端采集到数据后，在边缘完成小规模局部数据的实时决策处理，而复杂大规模的全局性决策处理则汇总至中心云深入分析处理。
边缘计算的位置
边缘计算位于中心云及终端之间，将云计算能力由中心下沉到边缘，通过云边协同的架构解决特定的业务需求，能最大程度降低传输时延，这也是边缘计算的核心价值。但中心云与终端之间的网络传输路径经由接入网(距离 30 公里，延迟 5 到10 毫秒)，汇聚网，城际网(距离 50 到 100 公里，延迟 15 到 30 毫秒)到骨干网(距离 200 公里，延迟 50 毫秒)，最后才到数据中心(假定数据中心 IDC 都在骨干网)，耗时数据是正常网络拥塞的拨测统计值，即业务侧感知的实际延迟数据，虽不是非常精确，但足够辅助架构决策。
云计算能力由中心逐步下沉到边缘，节点数量增多，覆盖范围缩小，运维服务成本快速增加。根据国内网络(国内有多张骨干网，分别是电信 CHINANET 与 CN2，联通 CNCNET 以及移动 CMNET)现状，骨干网节点，城际网节点，汇聚网节点，接入网节点，以及数以万计的业务现场计算节点都可以安置边缘计算，因此范围太广难以形成统一标准。因此我们说中心云计算由技术定义，边缘计算由网络与业务需求定义。
边缘计算生态参与者众多，云厂商、设备厂商、运营商三大关键服务商方以及一些新型 AI 服务商等，都是从各自现有优势延伸，拓展更多客户及市场空间。设备商借助物联网逐渐构建单一功能的专业云;云厂商从中心化的公有云开始下沉，走向分布式区域云，区域云之间通过云联网打通，形成一个覆盖更大的云。运营商在互联网时代被公有云及繁荣的移动应用完全屏蔽只能充当管道，但在边缘计算时代，业务及网络定义边缘计算，运营商重新回归焦点，不可替代。
边缘计算的类型
1、网络定义的边缘计算
通过优化终端与云中心网络路径，将中心云能力逐渐下沉至靠近终端，实现业务就近接入访问。从中心到边缘依次分为区域云/中心云，边缘云/边缘计算，边缘计算/本地计算三大类型：
区域云/中心云：将中心云计算的服务在骨干网拓展延伸，将中心化云能力拓展至区域，实现区域全覆盖，解决在骨干网上耗时，将网络延迟优化至 30ms 左右，但逻辑上仍是中心云服务。
边缘云/边缘计算：将中心云计算的服务沿着运营商的网络节点延伸，构建中小规模云服务或类云服务能力，将网络延迟优化至 15ms 左右，比如多接入边缘计算(MEC)、CDN。
边缘计算/本地计算：主要是接近终端的现场设备及服务能力，将终端部分逻辑剥离出来，实现边缘自主的智能服务，由云端控制边缘的资源调度、应用管理与业务编排等能力，将网络延迟优化至 5ms 左右，比如多功能一体机、智能路由器等。
总的来说，基于网络定义的边缘计算，更多是面向消费互联业务及新型 2C 业务，将云中心的能力及数据提前下沉至边缘，除了经典的 CDN，视频语音业务外，还有今年大火的元宇宙等。当前大部分面向消费互联业务都是通过安置在骨干网的中心云计算能力支持，时延在 30ms 到 50ms，远小于本身云端后端业务处理的延迟;算力下沉至边缘的初衷，主要是实现中心云海量请求压力分散，用户体验优化等，对业务都属于锦上添花，而非雪中送炭。
这里说一下运营商网络，中心云计算技术，是将数据中心内部网络全部虚拟化，即云内网络，衍生出 VPC，负载均衡等诸多产品;数据中心外部几乎完全屏蔽运营商网络，只提供弹性公网 IP 及互联网出口带宽服务，中心云计算与运营商网络没有融合;但从中心云计算演进到边缘计算，是强依赖网络将中心云与边缘链接起来，如果中心云是大脑，边缘计算是智能触角，那么网络就是神经，就是动脉血管，但实际上整体网络规划与建设发生在云计算发展之前，并不是专门服务云计算的，所以中心云计算与运营商网需要融合，即云网融合，云网融合最终目标是实现云能力的网络化调度编排，网络能力的云化快速定义。希望借助新型业务需求和云技术创新，驱动运营商网络架构深刻变革升级开放。
当前，网络的能力极大限制了云计算的发展，在边缘计算及物联网建设过程中尤为明显。云网融合与算力网络依然还是运营商的独家游戏，新一代 5G 颠覆性技术变革，引爆整个领域的颠覆性巨变，也只解决了海量设备接入及设备低延迟接入的问题，后端整体配套及解决方案明显跟不上。就当前情况来看，依然还是 5G 找业务的尴尬局面，未来 5G 在实体产业领域(港口、 码头、矿山等)领域，相比消费者领域，相信会带来更大变革与价值。
2、业务定义的边缘计算
除了面向消费者的互联网边缘场景，边缘计算更多的是面向实体产业及智慧化社会衍生的场景。
对于实体产业场景来说，由于历史原因，在边缘及现场存在大量异构的基础设施资源;通过业务需求驱动边缘计算平台的建设，不仅要整合利用现有基础设施资源，还要将中心云计算技术及能力下沉至边缘及现场，实现大量存量业务运营管控上云，海量数据统一入湖，以此支持整个企业的数字化转型。对于智慧化社会衍生场景来说，越是新型的业务，对网络时延敏感越高，数据量越大，结构化数据逐渐转化成非结构化数据，需要人工智能，神经网络等高等智能化技术支持。当前对网络时延敏感的新型业务场景，都是通过云端总控管理，设备现场实时计算这种分布式架构策略，以此减弱对网络的强依赖。面向业务将边缘计算分为智能设备/专业云及产业边缘/行业云两种类型：
智能设备/专业云：基于云计算能力之上，围绕智能设备提供整体化，有竞争力的解决方案，包含智能设备、云端的服务以及端到云之间的边缘侧服务，比如视频监控云、G7 货运物联等;
产业边缘/行业云：也基于云计算能力之上，围绕行业应用及场景，提供套件产品及解决方案，比如物流云、航天云等。
总的来说，基于业务定义的边缘计算，更多是面向智能设备及实体产业，对智能设备，从 AVG，密集式存储，机械手臂等单一功能的智能设备，到无人机，无人驾驶车等超复杂的智能设备，云计算能力不仅支撑设备控制管理应用的运行，同时借助中心云计算能力拓展至边缘侧，解决这种产品上云，无法集中化标准化管理难题;对产业边缘，通过云计算技术，结合行业场景的抽象总结，构建行业通用的产品及解决方案，随着整个产业互联网加速建设，是边缘计算未来发展的重点方向。
小结
对于规模较大的企业，云边场景非常复杂，中心云计算平台与边缘计算平台建设，不仅应对业务需求，还要面临诸多基础设施问题：在中心云计算面临多云使用多云互通问题;在边缘网络链路面临多运营商的骨干网，多云运营商网络及多云的云网融合问题;在端侧接入网面临多运营商 5G 网络的共享的问题等，很多问题只能通过治理的手段应对，无法从技术平台层面彻底解决。
总的来说，边缘计算范围大，场景泛，目前整个行业缺少经典的案例及标准。因此推动边缘计算落地，一定是面向真实的业务场景及需求整体规划，面向价值逐步建设。
Kubernetes 从中心走向边缘
Kubernetes 遵循以应用为中心的技术架构与思想，以一套技术体系支持任意负载，运行于任意基础设施之上;向下屏蔽基础设施差异，实现底层基础资源统一调度及编排;向上通过容器镜像标准化应用，实现应用负载自动化部署;向外突破中心云计算的边界，将云计算能力无缝拓展至边缘及现场，快速构建云边一体基础设施。
将云原生技术从中心拓展到边缘，不仅实现了云边基础设施技术架构大一统，业务也实现了云边自由编排部署。相对于 Kubernetes 在中心云的革命性创新，在边缘场景虽优势明显，但缺点也很致命，因为边缘侧存在资源有限、网络受限不稳定等特殊情况，需要根据不同业务场景，选择不同 Kubernetes 边缘方案。
Kubernetes 架构及边缘化的挑战
Kubernetes 是典型的分布式架构，Master 控制节点是集群“大脑”，负责管理节点，调度 Pod 以及控制集群运行状态。Node 工作节点，负责运行容器(Container)，监控/上报运行状态。边缘计算场景存在以下比较明显的挑战：
- 状态强一致且集中式存储架构，属于中心云计算的大成产品，基于大规模的池化资源的编排调度实现业务持续服务。
- Master 管控节点与 Worker 工作节点通过 List-Watch 机制，实现状态任务实时同步，但是流量较大，Worker 工作节点完全依赖 Master 节点持久化数据，无自治能力。
- Kubelet 承载太多逻辑处理，各种容器运行时各种实现的兼容，还有 Device Plugin 硬件设备驱动，运行占用资源高达 700M;对资源有限的边缘节点负担太重，尤其是低配的边缘设备。
边缘计算涉及的范围大、场景复杂，尚无统一标准;Kubernetes 开源社区的主线版本并无边缘场景的适配计划。
Kubernetes 边缘化运行方案
针对中心云计算及边缘计算这种云边分布式架构，需要将 Kubernetes 适配成适合边缘分布式部署的架构，通过多集群管理实现统一管理，实现中心云管理边缘运行，整体分为三种方案：
- 集群 Cluster：将 Kubernetes 标准集群下沉至边缘，优点是无需 Kubernetes 做定制化研发，同时可以支持 Kubernetes 多版本，支持业务真正实现云边架构一致;缺点是管理资源占用多。方案比较适合区域云/中心云、边缘计算/本地计算以及规模较大的产业边缘场景。
- 单节点 Single Node：将 Kubernetes 精简，部署在单节点设备之上，优点与集群 Cluster 方案一致，缺点是 Kubernetes 能力不完整，资源的占用会增加设备的成本，对业务应用无法保证云边一致的架构部署运行，没有解决实际问题。
- 边缘节点 Remote Node：基于Kubernetes 二次开发增强扩展，将 Kubernetes 解耦适配成云边分布式架构的场景，中心化部署 Master 管理节点，分散式部署 Worker 管理节点。
此外，一致性是边缘计算的痛点，在边缘增加一个 Cache 即可实现断网特殊情况的边缘自治，同时可以保证正常网络情况的数据一致;还有就是 Kubelet 比较重的问题，随着 Kubernetes 放弃 Docker 已经开始精简;同时硬件更新迭代较快，相比少量硬件成本，保持 Kubernetes 原生及通用性为大。其实更希望Kubernetes 社区本身提供适配边缘化方案，同时考虑为 Kubelet 增加缓存机制。
Kubernetes 边缘容器快速发展
Kubernetes 已成为容器编排和调度的事实标准，针对边缘计算场景，目前国内各个公有云厂商都开源了各自基于 Kubernetes 的边缘计算云原生项目，比如阿里云向 CNCF 贡献的 OpenYurt，采用边缘节点 Remote Node 方案，是业界首个开源的非侵入式边缘计算云原生平台，秉承“Extending your native Kubernetes to Edge”的非侵入式设计理念，拥有可实现边缘计算全场景覆盖的能力。
华为、腾讯、百度等，也都开源了自己的边缘容器平台。边缘容器的快速发展带动了领域的创新，但一定程度上也导致构建边缘计算平台时难以抉择。从技术架构来看，几个边缘容器产品总的架构思路主要是将 Kubernetes 解耦成适合云边、弱网络及资源稀缺的边缘计算场景，本质上无太大差异;从产品功能来看也是如此，基本上都涵盖云边协同、边缘自治、单元化部署功能等。
如何构建云边一体化云原生平台
现阶段，围绕 Kubernetes 容器平台，构建云边一体化云原生基础设施平台能力是边缘计算平台的最佳选择，通过云端统一的容器多集群管理，实现分散式集群统一管理，同时标准化 Kubernetes 集群规格配置：
- 标准集群(大规模)：支持超过 400 个节点的大规模集群，配置为 ETCD + Master 3 台 8c16G，Prometheus + Ingress 5 台 8C16G， N * Work 节点;主要是业务规模较大的云原生应用运行场景;
- 标准集群(中等规模)：支持超过 100 个节点以内的集群，ETCD + Master + Prometheus 3 台 8c16G，N * Work 节点;主要是业务规模中等的场景;
- 边缘原生容器集群：在云端部署集群管理节点，将边缘节点单独部署业务现场，支持运行单业务场景的应用，比如 IoT 物理设备接入协议解析应用，视频监控分析 AI 算法模型等业务场景。
按照业务场景需求选择最优容器集群方案，其中边缘容器集群方案，与其他集群方案差别较大，其他集群依然保持中心云集群服务一致，基础资源集中并且池化，所有应用共享整个集群资源;而边缘容器集群Master 管理节点集中部署，共享使用;Worker 节点都是分散在业务现场，按需自助增加，自运维且独占使用。当前边缘容器领域短时间内很难有大一统的开源产品，因此现阶段建议通过标准的 Kubernetes API 来集成边缘原生容器集群，这种兼容所有边缘容器的中庸方案，如果非要择其一，建议是 OpenYurt，非侵入式设计，整体技术架构及实现更加优雅。OpenYurt 以上游开源项目 Kubernetes 为基础，针对边缘场景适配的发行版。是业界首个依托云原生技术体系、“零”侵入实现的智能边缘计算平台。具备全方位的“云、边、端一体化”能力，能够快速实现海量边缘计算业务和异构算力的高效交付、运维及管理。
总结
边缘计算平台的建设，以 Kubernetes 为核心的云原生技术体系，无疑是当前最佳的选择与建设路径。但是云原生体系庞大，组件复杂，将体系下沉至边缘会面临很大的挑战与困难，同时充满巨大的机遇及想象空间。业务应用想要真正践行边缘的云原生体系，需要从理念、系统设计、架构设计等多方面来共同实现，才能充分发挥边缘的优势及价值。
