83 lines
5.6 KiB
Markdown
83 lines
5.6 KiB
Markdown
# 边缘计算
|
||
|
||
本节将为大家介绍什么是边缘计算、应用场景及开源项目。
|
||
|
||
## 什么是边缘计算？
|
||
|
||
关于边缘计算（Edge Computing）的定义莫衷一是，概括得讲，边缘计算是在移动网络边缘提供 IT ** 服务环境和计算能力 **；在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放 ** 平台 **；就近提供边缘智能的 ** 服务 **。
|
||
|
||
边缘计算与云计算是相辅相成的，是在云计算发展到一定阶段的产物，它有以下优点：
|
||
|
||
- 低延迟：计算能力部署在设备侧附近，设备请求实时响应；
|
||
- 低带宽运行：将工作迁移至更接近于用户或是数据采集终端的能力能够降低站点带宽限制所带来的影响。尤其是当边缘节点服务减少了向中枢发送大量数据处理的请求时。
|
||
- 隐私保护：数据本地采集，本地分析，本地处理，有效减少了数据暴露在公共网络的机会，保护了数据隐私。
|
||
|
||
## 边缘计算的适用场景
|
||
|
||
以下是边缘计算的适用场景：
|
||
|
||
- 第一类是前端采集的数据量过大，如果按照传统模式，将数据全部上传，成本高、效率低，例如风机发电场景；
|
||
- 第二类是需要即时交互的场景，如果数据全部上传，在中央节点处理再下发，往往传输成本高、时延长，比如无人驾驶场景；
|
||
- 第三类是对连续性要求比较高的业务，如果遇到网络问题或者中央节点故障，即便是短时间的云服务中断都会带来重大损失，比如智慧交通场景；
|
||
- 第四类是对安全要求比较高的业务，一些客户不允许数据脱离自己的控制，更不能离开自己的系统，这就需要使用边缘计算技术实现本地部署，比如人脸识别场景。
|
||
|
||
## 边缘计算开源项目
|
||
|
||
边缘计算是云原生领域的一个重要分支，该领域在几年来涌现了众多的开源项目，例如：
|
||
|
||
- [akri](https://github.com/project-akri/akri)：适用于边缘的 Kubernetes 资源接口。
|
||
- [baetyl](https://github.com/baetyl/baetyl)：将云计算、数据和服务无缝扩展到边缘设备。
|
||
- [eliot](https://github.com/ernoaapa/eliot)：用于管理物联网设备中容器化应用的开源系统。
|
||
- [iotedge](https://github.com/Azure/iotedge)： 由微软开源的 IoT Edge 开源项目。
|
||
- [k0s](https://github.com/k0sproject/k0s)：k0s 是一个包罗万象的 Kubernetes 发行版，配置了建立 Kubernetes 集群所需的所有功能，并被打包成一个二进制文件，以方便使用。
|
||
- [k3s](https://github.com/k3s-io/k3s)：由 Rancher 开源的轻量级的 Kubernetes.
|
||
- [kubeedge](https://github.com/kubeedge/kubeedge)：由华为开源的 Kubernetes 原生边缘计算框架，已贡献给 CNCF。
|
||
- [octopus](https://github.com/cnrancher/octopus)：由 Rancher 中国开源的用于 Kubernetes/k3s 的轻量级设备管理系统。
|
||
- [openyurt](https://github.com/openyurtio/openyurt)：由阿里云开源的，将原生 Kubernetes 扩展到边缘，已贡献给 CNCF。
|
||
- [superedge](https://github.com/superedge/superedge)：由腾讯开源的，用于边缘计算的边缘原生容器管理系统。
|
||
|
||
另外还有很多其他边缘计算相关开源项目请见 [云原生开源项目大全（Awesome Cloud Native）](https://jimmysong.io/awesome-cloud-native/#edge-computing)。
|
||
|
||
## 边缘计算对于编排调度的挑战
|
||
|
||
边缘云对编排调度提出了一些挑战。
|
||
|
||
### 没有网络连接 —— 自主操作
|
||
|
||
在许多情况下，边缘云需要在没有与集中式管理中心的网络连接的情况下运行，这是由长延迟或连接问题造成的。本地决策是在本地做出的，当连接存在时，它可以与集中式管理中心通信。
|
||
|
||
### 流动性
|
||
|
||
我们不一定能指望一个静态的数据中心。由于边缘云可能位于移动的交通工具中，如飞机、船舶、汽车等，我们需要考虑到地理上移动的边缘云与一个或多个中央数据中心之间的通信。把它想象成一个移动用户在基站之间移动。
|
||
|
||
### 资源限制
|
||
|
||
边缘的资源是稀缺的，你会发现自己缺少 CPU、内存和持久性存储。为了克服这个问题，你可能想用一个轻量级的调度器运行容器而不是虚拟机。
|
||
|
||
### 安全问题
|
||
|
||
安全是一个关键问题。你不希望恶意软件渗透到你的一个本地云，使其瘫痪，或者更糟的是，感染其他本地云或主云。你需要为访问控制、谁可以访问哪些资源和云间通信定义并执行严格的安全策略。
|
||
|
||
### 带宽成本
|
||
|
||
边缘的带宽可能是有限的或非常昂贵的。延迟可能会产生很长的 RTT（往返时间）。
|
||
|
||
### 容量
|
||
|
||
你把收集到的数以亿计的数据点放在哪里？本地云在资源上是稀缺的。你是否应用了老化技术，分阶段发布等？一个本地云边缘平台需要照顾到这些要求。
|
||
|
||
### 规模
|
||
|
||
规模化的许多边缘云的协调工作是具有挑战性的。你如何管理所有的边缘云？此外，你如何监测和收集来自数以百万计的边缘对象的 KPI？
|
||
|
||
### 自愈
|
||
|
||
本地边缘编排调度器应支持自我修复、零人工干预的场景。
|
||
|
||
### 服务构成
|
||
|
||
一项服务可能完全包含在本地边缘云中，仅这一点就需要自己的本地协调。但是，如果一项服务横跨本地云和主云之间，而你在中心点为多个本地云部署了共同的功能，那该怎么办？需要定义和执行一个服务组合。需要创建服务组合设计模式。
|
||
|
||
## 参考
|
||
|
||
- [The Birth of an Edge Orchestrator – Cloudify Meets Edge Computing](https://cloudify.co/blog/birth-of-edge-orchestrator-cloudify/) |