快速了解边缘计算
技术诞生背景
物联网
- 物联网设备地理位置非常分散、响应时间、海量设备管理、数据安全性难以保证.
人工智能
- 人工智能应用需要大量的逻辑运算资源, 当对运算速度有更高的要求时候, 数据传输带来的性能消耗问题, 将会让 AI 应用响应延迟.
边缘计算解决思路
- 让计算更贴近数据的源头
总结
- 引入边缘计算, 在边缘侧直接完成运算, 从而减轻数据传输的压力!
- 边缘计算, 让计算更贴近数据的源头! 从而解决海量设备管理、数据传输等问题
边缘计算应用案例
交通、运输和物流行业
- 自动驾驶: 如果路况处理全部在云端, 那么如果信号不好或者网络延迟会造成很大的危险系数
- 交通大数据: 如果将采集到的所有数据都上报云端, 会造成很多无价值的数据上报
垂直交叉行业
- 无人机+安防: 自动处理数据 在不该有人的地方看到人自动上报数据 无需人工处理.
- 无人机+工地: 在危险区域自动触发报警系统.
零售业
- 自动检测人流量, 检测大家的购物需求, 进行相关的促销活动.
边缘计算应用场景
- 不稳定连接和数据移动性
- 需要实时决策
- 本地化计算能力
- 新的存储和安全需求
- 不定时供电
边缘计算 VS 物联网
物联网+边缘计算架构图
边缘计算 VS 云原生
边缘计算的发展趋势
边缘计算容器化
容器化的优点
- 解耦运行依赖
- 标准的应用分发
- 扩展应用类型
容器化能够解决边缘计算产品的运行环境问题, 但是随着生产环境的增多, 也暴露出来很多不足之处.
边缘计算容器化的不足之处
- 单机限制: 缺乏多机通信网络, 限制边缘总算力规模
- 编排限制: 缺乏多实例和拓展主机的连接能力, 限制了对复杂业务的描述能力
- 更新限制: 需要安装业务之外的应用才能对容器进行更新
- 管理限制: 边缘应用的定义和管理模式与应用分离, 限制了业务的敏捷性
边缘计算由容器向云原生演进
边缘计算 VS 开源社区
KubeEdge
- KubeEdge架构设计图
- 边缘设备端是通过
MQTT
协议进行交互的, 从而完成从云到边到端的架构设计.
OpenYurt
- 阿里开源
KubeEdge架构设计图
Baetyl
成员
项目架构
架构设计图
总结
- 底层基于
Kubernetes
, 将边缘节点抽象为Node
节点 - 边缘应用以容器 (
K8S Pod
) 方式运行 - 通过数据缓存和同步保证离线计算
- 云端管理, 边缘计算, 云边协同
边缘计算 VS 一线大厂
边缘计算岗位
云原生项目生态图
垂直交叉工作岗位
Kubernetes
相关岗位- 云原生相关岗位
Kubernetes 运维、开发、架构
云原生研发、架构
本章小结
- 边缘计算的技术背景
- 物联网+AI 的痛点与举例
- 边缘计算的应用案例
- 麦肯锡数据 在各行各业的应用 总结出共性
- 不稳定连接和数据移动性
- 需要实时决策
- 本地化计算的能力
- 新的存储和安全需求
- 不定时供电
- 麦肯锡数据 在各行各业的应用 总结出共性
- 边缘计算与物联网的联系
- 物联网架构
-->
边缘计算+物联网架构
- 物联网架构
- 边缘计算与云原生的联系
- 发展趋势
-->
容器化-->
云原生
- 发展趋势
- 边缘计算在开源社区的项目情况
KubeEdge --> OpenYurt --> Beatyl
- 边缘计算在一线大厂的岗位和薪酬情况
- 边缘计算
-->
K8S-->
云原生
- 边缘计算
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 ZkeqのCoding日志!
评论
ArtalkGiscus