边缘计算生态发展现状
从学术界来看，在Google Scholar上搜索Edge Computing关键词，在11月底已有390万条结果了，而10月份却只有130万，所以说Edge Computing在今年尤其进入了一个飞速发展的状态。
全球领先的信息技术研究和顾问公司 Gartner每年都会进行来年十大战略性技术趋势的预测。边缘计算从2018年开始已经连续4年被Gartner列为未来的十大战略性技术趋势之一。
开源社区目前主要有三个主流框架。KubeEdge是面向边缘计算场景、专为边云协同设计的业界首个云原生边缘计算框架，在 Kubernetes 原生的容器编排调度能力之上实现了边云之间的应用协同、资源协同、数据协同和设备协同等能力，完整打通了边缘计算中云、边、设备协同的场景。
边缘计算场景分类
如图所示：
边缘计算如何落地？
案例一：中移在线云边协同平台
案例一是一个典型的 High rate场景，主要侧重于云和边。该案例已入选信通院发布的《分布式云与云边协同十佳实践案例集(2020年)》
案例背景：
目前已连续合作三年
打造了全球最大的容器化的呼叫平台
2018-2019年，云中心建设：将所有的业务都容器化，部署在K8s集群
2019-2020年，云边协同建设
在2018 -2019年我们已经建设了一个中心云，但像10086全国有几十个分公司，每个分公司都有许多机器，最少的可能10多台，多的可能是几十台，甚至上百台的。当时面临的问题是这些分公司也要容器化，通过总公司的云中心来做这些应用的统一发布升级。也就是说数字化转型需要从云中心再延伸到各个分公司，分公司的一些业务架构，统一使用一套CRCD发布流程,每个分公司的计算都自行处理，可以把原先统一在云中心的一些计算下沉到各个分公司自己的机房里。
当时我们做了很多探索。考虑如下图两种基本架构，一种是在每一个分公司都搭建K8s集群，然后把它纳入到云中心的K8s集群，另一种是每个分公司的机器都作为一个节点，纳入到云中心统一进行管理。
如果用第一种方式，有一些缺陷，像10086这种产品，每个分公司可能少的也有10多台机器，如果要建立高可用K8s集群，则需要三个节点master，那么它的资源利用率是很低的。
另一方面多集群的管理即使使用k3s，但其运维难度并不亚于K8s，因此我们一直在寻找是否还有其他方案。在2018年年底，我们发现了KubeEdge的开源方案，也投入了研究，最终采用了第二种架构的形式。
云边协同平台：
中心云是基于谐云的边缘计算云平台搭建了一个云中心，包含高可用的k8s集群、Master以及CloudCore。在各个分公司作为 edgecore加入到云中心，在云中心做统一的资源调度。
从云中心到每个分公司，传统运维会比较麻烦，现在可以通过云中心用隧道远程做分公司节点方面的运维，云边的弹性伸缩，边的区域化管理。
监控是用了现在比较通用的Prometheus联邦集群来监控。故障隔离方面我们也做了很多适配。
中移在线云边协同平台的能力
节点跨地域接入：拓展中心云纳管边界，将边缘计算资源接入中心云
边缘自治性：针对云边弱网场景，应用可持续运行并提供服务
资源复用：基于星型拓扑架构，复用分公司老旧服务器，联合打造计算资源池
技术升级：助力分公司应用部署运维模式转型升级
降本增效：配合先进的容器云标准交付平台CI/CD流水线，分公司应用运维效率提升35%以上
计算下沉：计算临近数据源，减少数据传输成本和中心云存储成本
潜力中台：探索5G场景下视频业务中台建设、5G场景下分布式呼叫客服系统建设
最终的成效
案例二：某跨海大桥终端设备监控数据采集
该跨海大桥上面有许多的终端设备，比如用来收集温度湿度、做雨雪（在上面加滴水，立即就能够展示出来）、用来采集粉尘能够更加细腻度感知PM2.5等设备，这些设备都需要一个载体将其接入我们这块板子上面，板子是基于单点系统的，所以我们最终将板子作为edgecore，接入整个边缘计算云平台。
边缘计算盒子是集成了5G模块，统一将数据采集上来后，会集中到北斗监测站。
整体架构图
除了上文提到的去对接一些雨雪偏发电、百叶箱、IMU的设备也可以对接一些流失的数据，将这些数据采集后，一部分可以直接上报，一部分通过MQTT Broker经过一层数据处理，将数据再上报转换，再放到云端数据库去处理。整个边缘云平台提供设备接入以及数据可视化、边缘的资源管理数字大屏，同时我们也在做一些边缘压的工作。
总结
KubeEdge致力于将Kubernetes的能力拓展到边缘，在2020年9月晋级为CNCF孵化项目，目前已有3.3k Star，900+ Fork，500+贡献者，也建立了3个社区SIG，我们也一直加强与产业各界的合作，希望共同推动云边协同应用创新发展。希望大家能够积极参与KubeEdge社区，贡献智慧和力量。
