FogBus: A Blockchain-based Lightweight Framework for Edge and Fog Computing
TL;DR 精炼摘要
FogBus是一个基于区块链的轻量级框架,旨在促进边缘、雾和云计算的集成,以支持延迟敏感和计算密集型的物联网应用。该框架提供平台独立的接口,帮助开发者构建和多应用执行,同时通过认证和加密技术保护敏感数据,具有易部署和经济高效的优势。
摘要
Recently much emphasize is given on integrating Edge, Fog and Cloud infrastructures to support the execution of various latency sensitive and computing intensive Internet of Things (IoT) applications. Although different real-world frameworks attempt to assist such integration, they have limitations in respect of platform independence, security, resource management and multi-application execution. To address these limitations, we propose a framework, named FogBus that facilitates end-to-end IoT-Fog(Edge)-Cloud integration. FogBus offers platform independent interfaces to IoT applications and computing instances for execution and interaction. It not only assists developers to build applications but also helps users to run multiple applications at a time and service providers to manage their resources. Moreover, FogBus applies Blockchain, authentication and encryption techniques to secure operations on sensitive data. Due to its simplified and cross platform software systems, it is easy to deploy, scalable and cost efficient. We demonstrate the effectiveness of FogBus by creating a computing environment with it that integrates finger pulse oximeters as IoT devices with Smartphone-based gateway and Raspberry Pi-based Fog nodes for Sleep Apnea analysis. We also evaluate the characteristics of FogBus in respect of other existing frameworks and the impact of various FogBus settings on system parameters through deployment of a real-world IoT application. The experimental results show that FogBus is comparatively lightweight and responsive, and different FogBus settings can tune the computing environment as per the situation demands.
思维导图
论文精读
中文精读
1. 论文基本信息
1.1. 标题
FogBus: A Blockchain-based Lightweight Framework for Edge and Fog Computing(FogBus:一个基于区块链的轻量级边缘和雾计算框架)
1.2. 作者
- Shreshth Tuli a,b
- Redowan Mahmuda, *
- Shikhar Tulic
- Rajkumar Buyya a
隶属机构: a. 墨尔本大学 计算与信息系统学院 b. 德里大学 计算机科学系 c. 阿米提大学 工程与技术学院
1.3. 发表期刊/会议
- 期刊名称: Elsevier Inc.
- 声誉和影响力: Elsevier是全球领先的科学、技术和医学信息产品与服务提供商之一,其出版的期刊通常在学术界享有较高声誉和影响力。本文被其期刊收录,表明其研究质量和相关性得到了同行评审的认可。
1.4. 发表年份
2019年4月13日
1.5. 摘要
物联网 (IoT) 应用程序通常对延迟敏感且计算密集,因此,将边缘 (Edge)、雾 (Fog) 和云 (Cloud) 基础设施集成起来以支持这些应用程序的执行变得越来越重要。尽管现有的一些框架试图实现这种集成,但它们在平台独立性、安全性、资源管理和多应用执行方面存在局限性。为了解决这些局限性,本文提出了一个名为 FogBus 的框架,旨在促进端到端的 IoT-雾(边缘)-云集成。FogBus 为 IoT 应用程序和计算实例提供了平台独立的接口,以实现执行和交互。它不仅帮助开发者构建应用程序,还支持用户同时运行多个应用程序,并协助服务提供商管理其资源。此外,FogBus 应用了区块链 (Blockchain)、认证 (authentication) 和加密 (encryption) 技术来保护敏感数据的操作。由于其简化和跨平台的软件系统,FogBus 易于部署、可扩展且成本效益高。为了验证 FogBus 的有效性,研究人员构建了一个计算环境,将指脉血氧仪作为 IoT 设备,通过基于智能手机的网关和基于树莓派 (Raspberry Pi) 的雾节点,集成了睡眠呼吸暂停分析应用。本文还评估了 FogBus 相对于其他现有框架的特性,并通过部署一个真实的 IoT 应用,分析了不同 FogBus 设置对系统参数的影响。实验结果表明,FogBus 相对轻量级且响应迅速,并且可以通过调整不同的 FogBus 设置来根据实际需求优化计算环境。
1.6. 原文链接
原文链接: /files/papers/691b152480efabfa5c6ee4c3/paper.pdf (已正式发表)
2. 整体概括
2.1. 研究背景与动机
当前,物联网 (Internet of Things, IoT) 范式正在迅速发展,预计到2025年,智能环境将包含超过1万亿个 IoT 设备,其中对延迟敏感的应用程序需求将增加50%。这些 IoT 应用(如远程患者监控、森林火灾检测、智能交通管理等)通常对计算能力和网络延迟有严格要求。
-
核心问题: 现有基础设施难以有效支持大规模、延迟敏感且计算密集型的
IoT应用。- 云中心的局限性: 传统的云数据中心距离
IoT设备较远,导致数据传输和应用服务交付存在高延迟,严重影响服务质量 (Quality of Service,QoS)。同时,大量IoT设备同时向云传输数据可能导致严重的网络拥塞。 - 雾/边缘计算的挑战: 雾 (Fog) 和边缘 (Edge) 计算旨在将计算资源下沉到靠近
IoT设备的地方,以解决延迟和带宽问题。然而,大多数雾节点 (Fog nodes) 资源受限且异构(计算能力、操作系统、P2P通信标准各异),这使得在这些有限资源上管理和执行多样化的IoT应用变得复杂。 - 现有集成框架的不足: 现有的
IoT-雾-云集成框架存在以下具体挑战或空白:- 平台独立性不足: 难以处理异构计算实例间的通信和应用运行时环境。
- 安全性薄弱: 仅关注部分安全方面,易增加集成环境的漏洞。
- 资源管理效率低: 通常采用集中式管理,当
IoT数据高频处理时,这种方法变得不可行,且难以充分利用边缘和远程资源。 - 多应用执行限制: 普遍不支持同时执行多个应用程序。
- 开发者/用户灵活性低: 为应用程序开发者和用户提供的调整框架的范围狭窄。
- 云中心的局限性: 传统的云数据中心距离
-
本文的切入点或创新思路:
- 本文提出
FogBus框架,旨在提供一个端到端 (end-to-end) 的IoT-雾(边缘)-云集成解决方案。 - 其创新点在于通过平台独立的接口,支持异构环境下的应用程序执行和节点间交互。
- 特别强调利用区块链 (Blockchain)、认证 (authentication) 和加密 (encryption) 技术来增强数据完整性、保护和隐私。
FogBus还支持多种并发/应用编程模型以及灵活的资源管理和调度策略。- 目标是构建一个轻量级、易于部署、可扩展且成本效益高的框架,以克服现有框架的局限性。
- 本文提出
2.2. 核心贡献/主要发现
本文的主要贡献如下:
- 提出轻量级集成框架: 提出了一个名为
FogBus的轻量级框架,用于整合IoT设备、雾和云基础设施,以根据应用程序需求利用边缘和远程资源。该框架采用区块链技术确保传输机密数据时的数据完整性。 - 设计平台独立架构: 设计了一个平台独立的应用程序执行和节点到节点交互架构,以克服集成环境中的异构性问题。
- 开发并评估真实应用系统: 开发了一个用于睡眠呼吸暂停数据分析的原型应用程序系统,评估了
FogBus的特性,并展示了如何使用SPMD(Single Program and Multiple Data) 模型构建的医疗保健应用,在集成的计算环境中利用FogBus的不同设置来处理IoT数据。
主要发现:
- 轻量级与响应性: 实验结果表明,
FogBus相较于其他现有框架(如Stack4Things,Cloudlet-based PaaS,Indie Fog),在核心节点的CPU和RAM使用率方面更低,系统初始化时间和数据检索时间也更短,显示出其轻量级和高响应性。 - 高效的资源管理:
FogBus能够同时利用边缘和远程资源,当雾节点过载时,可以无缝切换到云数据中心进行处理,从而显著降低了QoS期望缺失率。 - 灵活的配置与性能调优:
FogBus提供了多种设置(如“有/无间隔”、“有/无区块链”、“仅雾/仅云/集成”)来调优计算环境。研究发现,这些设置可以根据应用场景的需求,有效平衡请求数量、服务延迟、网络使用和能源消耗。例如,在低安全要求和高请求吞吐量需求下,禁用区块链和使用“仅雾”模式可以显著提高性能和降低能耗。 - 数据安全:
FogBus通过区块链技术、认证和加密技术确保了敏感数据的完整性、保护和隐私,这在处理如医疗健康数据等敏感信息时尤为重要。
3. 预备知识与相关工作
3.1. 基础概念
- 物联网 (Internet of Things, IoT):
IoT是一种网络范式,它通过传感器、机器和物体感知外部环境,并通过互联网交换数据。它利用应用程序进行数据集成和分析,以识别事件并通过执行器触发必要的动作,从而构建有限人类干预的物理信息系统 (cyber-physical systems)。 - 云计算 (Cloud Computing): 一种通过互联网提供计算服务(包括服务器、存储、数据库、网络、软件、分析和智能)的模型。
- 基础设施即服务 (Infrastructure as a Service, IaaS): 云提供商提供虚拟化的计算资源(如虚拟机、存储、网络),用户可以在其上部署和运行任意软件。
- 平台即服务 (Platform as a Service, PaaS): 云提供商提供一个完整的应用开发和部署平台,包括操作系统、编程语言执行环境、数据库和网络服务器等,用户只需关注应用程序代码。
- 软件即服务 (Software as a Service, SaaS): 云提供商直接提供可用的应用程序,用户通过互联网访问,无需关心底层基础设施和平台。
- 边缘计算 (Edge Computing): 一种在网络边缘侧(靠近数据源)执行计算的方法,旨在减少长距离数据传输,降低延迟,并节省带宽。
- 雾计算 (Fog Computing):
Fog计算是Edge计算的一种延伸,它在IoT设备和云数据中心之间提供了一个中间层。它利用靠近IoT设备的网络边缘资源进行决策制定和IoT应用程序的实时执行,管理分散在边缘网络中的计算实例(即雾节点)。在本文中,Edge计算被视为Fog计算的一个子集。- 雾节点 (Fog Nodes): 部署在边缘网络中的计算实例,具备处理核心、内存、存储和带宽,能够执行各种
FogBus操作。- 雾网关节点 (Fog Gateway Nodes, FGNs): 雾计算基础设施的入口点,协助
IoT设备配置到集成环境,并提供应用程序的前端程序供用户交互。它们还进行数据过滤、聚合,并转发数据。 - 雾计算节点 (Fog Computational Nodes, FCNs): 实际执行计算任务的异构雾节点,根据操作分为:
- 代理节点 (Broker nodes): 负责协调和管理计算任务的分配,与
FGNs、其他FCNs和云数据中心交互,进行资源调配和负载均衡。 - 通用计算节点 (General Computing Nodes, GCNs): 执行实际的计算任务,通过代理节点访问,可以形成集群以执行分布式应用程序。
- 存储库节点 (Repository nodes): 管理分布式数据库,用于数据共享、复制、恢复和安全存储,维护应用程序元数据和中间数据。
- 代理节点 (Broker nodes): 负责协调和管理计算任务的分配,与
- 雾网关节点 (Fog Gateway Nodes, FGNs): 雾计算基础设施的入口点,协助
- 雾节点 (Fog Nodes): 部署在边缘网络中的计算实例,具备处理核心、内存、存储和带宽,能够执行各种
- 区块链 (Blockchain): 一种分布式账本技术,由一系列不可篡改的、按时间顺序链接在一起的数据块组成。
- 数据完整性 (Data Integrity): 区块链通过加密哈希函数确保数据一旦记录就难以被篡改。每个区块包含前一个区块的哈希值,任何对历史数据的修改都会改变该区块的哈希,进而破坏整个链的有效性。
- 哈希值 (Hash Value): 对数据进行单向加密计算后得到的固定长度字符串,用于数据验证。
- 工作量证明 (Proof-of-Work, PoW): 一种共识机制,通过解决计算难题(即“挖矿”)来验证区块,防止滥用和篡改。
- 数字签名 (Digital Signature): 一种验证数据来源和完整性的加密技术,使用发送方的私钥对数据进行签名,接收方使用发送方的公钥进行验证。
- 服务质量 (Quality of Service, QoS): 衡量网络或服务性能的指标,包括延迟 (latency)、吞吐量 (throughput)、可用性 (availability) 和可靠性 (reliability) 等。
- 单程序多数据 (Single Program Multiple Data, SPMD): 一种并行计算模型,多个处理器同时执行同一个程序,但对不同的数据子集进行操作。
- RESTful API: 一种基于
HTTP协议的应用程序接口设计风格,用于不同服务间的数据交换。 - Java 虚拟机 (Java Virtual Machine, JVM): 一个运行 Java 字节码的虚拟机,使得 Java 程序可以跨平台运行。
- TCP (Transmission Control Protocol) / UDP (User Datagram Protocol): 传输层协议,
TCP提供可靠的、面向连接的数据传输,而UDP提供无连接的、不可靠的数据传输。 - CoAP (Constrained Application Protocol) / SNMP (Simple Network Management Protocol): 适用于受限设备和网络的协议,
CoAP是针对IoT设备优化的类似HTTP的协议,SNMP用于网络设备的管理和监控。 - Vector Clocks (向量时钟): 一种在分布式系统中用于确定事件偏序的机制,帮助识别并发事件。
3.2. 前人工作
作者将现有集成 IoT 系统与雾和云基础设施的框架大致分为两类:应用特定原型 (application specific prototypes) 和通用 PaaS 模型 (generalized PaaS model)。
1. 应用特定原型框架:
- Rahmani et al. (2018): 针对
IoT医疗保健系统,开发了一个基于原型的框架,具有智能网关,支持本地存储和数据处理。云作为后端基础设施进行数据分析和决策。依赖操作系统级别的安全特性,未强调平台独立性、多应用执行和去中心化管理。 - Dubey et al. (2017): 另一个智能医疗保健原型框架,使用
Intel Edison和Raspberry Pi作为雾节点。通过基于角色的认证确保数据隐私。部分采用云进行数据存储,未强调平台独立性、多应用执行和去中心化管理。 - Azimi et al. (2017): 层次化医疗保健解决方案原型框架。健康分析分为两部分,分别置于云和雾基础设施。遵循
MAPE-K模型(监控、分析、规划、执行-知识)支持多样化应用执行并提供数据加密。未强调平台独立性和多应用执行,采用集中式管理。 - Gia et al. (2017): 低成本健康监控框架,促进
IoT数据的自主分析。IoT设备具备计算能力进行预处理并低能耗转发数据。雾层管理分布式数据库进行数据分类和安全。未强调平台独立性、多应用执行和去中心化管理。 - Akrivopoulos et al. (2017): 允许用户共享健康数据并在紧急情况下通知。所有操作由云端的
Spark IoT Platform Core管理。使用加密和认证技术保障安全。采用集中式管理,未强调平台独立性和多应用执行。 - Chen et al. (2017) 和 Craciunescu et al. (2015): 分别开发了智能城市监控和气体泄漏监控系统的原型框架。雾基础设施进行必要的数据处理和决策,远程云部分用于管理
IoT数据记录。未提及安全特性或雾节点异构性管理,也未支持多应用执行。 - Hu et al. (2017): 面部识别系统原型框架,集中式云管理所有集成环境资源,并分流部分计算任务到雾基础设施。未提及安全问题,采用集中式管理,未支持多应用执行。
2. 通用 PaaS 模型框架:
- Yangui et al. (2016): 云中心
PaaS框架,自动化应用调配,支持多样化应用开发、部署和雾节点管理。可处理节点异构性,并扩展了Cloud Foundry架构的安全特性。未支持去中心化管理。 - Bruneo et al. (2016) (Stack4Things): 雾中心
PaaS框架,用于在具备计算能力的IoT设备上部署和执行多个应用。雾基础设施充当集中式可编程协调器。应用云端安全特性,处理实例异构性。采用集中式管理。 - Verba et al. (2017): 网关架构,提供
PaaS以集成雾节点和IoT设备。网关通过认证协助消息通信,支持网关和云数据中心的水平集成以进行应用部署和任务迁移。未强调平台独立性,未支持多应用执行。 - Yi et al. (2015a): 基于
Cloudlet的综合PaaS框架,要求资源丰富的雾节点运行,且包括IoT设备在内的每个节点都需要虚拟化。利用现有认证技术保障框架操作安全。未强调平台独立性和多应用执行。 - Vatanparvar et al. (2015):
PaaS框架,管理家庭和微电网级别的雾基础设施电力使用。处理雾节点和IoT设备的异构性,并加密数据。未强调平台独立性和多应用执行。 - Chang et al. (2017) (Indie Fog):
PaaS框架,利用用户网络设备执行IoT应用。核心服务和资源管理指令从云数据中心扩展到雾节点。支持雾节点集群和用户手持设备,运行注册服务保障安全。未强调平台独立性。 - Mohamed et al. (2017): 面向服务的框架,通过雾和云基础设施管理智慧城市服务。服务分为两类:核心操作(资源管理、安全)和特定应用需求。通过认证和访问控制机制确保安全。未强调平台独立性和多应用执行。
3.3. 技术演进
IoT 领域的技术演进主要经历了从 Cloud-centric 模型向 Fog/Edge-centric 模型的转变:
-
早期
IoT与云计算集成: 最初,IoT设备主要将数据发送到远程云数据中心进行存储和分析。这种模式简单,但随着IoT设备数量的爆炸式增长和应用对低延迟需求的提高,暴露出高延迟和网络拥塞的严重问题。 -
雾计算和边缘计算的兴起: 为解决云中心模型的局限性,雾计算和边缘计算应运而生。它们将计算、存储和网络服务推向网络边缘,更接近
IoT设备,从而降低了延迟,减轻了核心网络的负担。智能设备(如树莓派、智能手机、路由器)开始作为潜在的边缘资源发挥作用。 -
异构环境的挑战: 雾和边缘节点通常资源受限且高度异构,包括不同的硬件能力、操作系统和通信协议。这给应用程序的部署、资源管理、安全性和平台独立性带来了新的挑战。
-
IoT-雾-云协同模式: 认识到雾和云各有优势,未来的趋势是实现IoT、雾和云的无缝集成。雾层处理时间敏感、对延迟要求高的任务,而云层处理大规模、非实时的数据分析和长期存储。这种协同需要框架能够跨越基础设施和平台的多样性,并支持去中心化的资源管理。 -
安全和可靠性的强化: 随着
IoT应用涉及更多敏感数据(如医疗健康),安全性和数据完整性成为关键。区块链、认证和加密技术开始被引入,以增强整个集成环境的信任和隐私保护。本文的
FogBus框架正处于这种技术演进的最新阶段,旨在通过提供平台独立性、去中心化管理、强化安全(特别是引入区块链)和多应用支持,来应对IoT-雾-云集成所面临的挑战。
3.4. 差异化分析
以下表格总结了 FogBus 与相关工作中主要方法的区别和创新点,重点突出 FogBus 解决的现有框架的局限性:
| Work | Integrates | Platform independent | Security features | Supports multi-applications | Targets | Decentralized management | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| IoT | Fog | Cloud | Integrity | Authentication | Encryption | Developers | Users | ||||
| Rahmani et al. (2018) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Dubey et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Azimi et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Gia et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Akrivopoulos et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Chen et al. (2017) | ✓ | ✓ | |||||||||
| Craciunescu et al. (2015) | ✓ | ✓ | |||||||||
| Hu et al. (2017) | ✓ | ✓ | |||||||||
| Yangui et al. (2016) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Bruneo et al. (2016) | ✓ | ✓ | ✓ | ✓ | |||||||
| Verba et al. (2017) | √ | ✓ | ✓ | ✓ | |||||||
| Yi et al. (2015a) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Vatanparvar et al. (2015) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Chang et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Mohamed et al. (2017) | ✓ | ✓ | ✓ | ||||||||
| FogBus [this work] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
以下是 FogBus 与上述框架的核心差异点和创新点:
-
端到端集成能力: 许多现有框架只关注
IoT-雾或IoT-云的部分集成,或仅在云端进行部分管理。FogBus实现了IoT-雾-云的端到端集成,能够根据应用程序需求利用边缘和远程资源。 -
平台独立性: 大多数现有框架(如
Rahmani et al.,Dubey et al.,Azimi et al.等原型框架)没有明确支持平台独立性,这使得它们难以处理异构的雾节点。FogBus通过使用跨平台编程语言 (PHP和Java) 和可扩展的应用程序层协议 (HTTP),克服了操作系统和P2P通信级别的异构性。Yangui et al.的框架虽能处理异构节点,但未提供FogBus的全面集成和安全特性。 -
全面的安全特性: 现有框架通常只关注狭义的安全问题(如认证或加密)。
FogBus引入了区块链 (Blockchain) 来确保数据传输时的数据完整性 (Data Integrity),这在处理敏感数据(如医疗健康数据)时是关键优势。- 同时,它还结合了认证 (Authentication) 和加密 (Encryption) 技术,提供了更全面的数据保护和隐私保障。
- 相比之下,许多原型框架(如
Chen et al.,Craciunescu et al.,Hu et al.)甚至未提及安全特性,而PaaS框架(如Stack4Things,Cloudlet-based PaaS,Indie Fog)通常只利用云或特定平台的安全机制。
-
去中心化管理: 许多现有框架(如
Akrivopoulos et al.,Hu et al.,Stack4Things)采用集中式管理策略,当IoT数据高频处理时,这种方法容易导致QoS下降。FogBus采用分布式底向上 (distributed bottom-up) 的方法进行资源管理,通过代理节点 (broker nodes) 实现了去中心化决策,提高了效率和弹性。 -
多应用执行与可调优性: 许多框架难以同时支持多个应用程序的执行,且为开发者和用户提供的框架调优范围有限。
FogBus支持多种并发/应用编程模型 (SPMD,workflows,streams) 的应用程序执行,并为用户和服务提供商提供了服务调优 (service tuning) 的能力,可以根据个体需求进行定制。 -
轻量级和响应迅速: 实验证明,
FogBus相比于基线框架(如Stack4Things,Cloudlet-based PaaS,Indie Fog),在CPU和RAM使用率方面更低,系统初始化时间和数据检索时间也更短,表现出卓越的轻量级和响应性。综上,
FogBus在整合IoT-雾-云环境、提供平台独立性、强化数据安全(特别是引入区块链)、实现去中心化资源管理以及支持多应用执行和可调优性方面,超越了大多数现有框架。
4. 方法论
4.1. 方法原理
FogBus 框架的核心思想是构建一个能够无缝集成 IoT 设备、雾计算和云计算基础设施的统一平台。它通过一系列精心设计的软件组件,旨在克服异构硬件环境(不同的操作系统和 P2P 通信标准)带来的挑战,提供结构化的通信和平台独立的应用执行。
其背后的理论基础和直觉在于:
-
分层处理与资源优化: 识别
IoT数据处理的延迟敏感性和计算密集性特点,通过将计算任务分层处理——将实时、低延迟任务下沉到靠近IoT设备的雾层,而将大规模、非实时的分析和存储任务委托给云层,以实现整体资源的优化利用和QoS的提升。 -
平台抽象与互操作性: 认识到边缘设备的多样性,通过提供平台无关的接口和使用跨平台技术,抽象底层硬件和操作系统差异,确保应用程序和节点之间能够无缝交互。
-
分布式管理与弹性: 针对雾节点资源有限且易受单点故障影响的特点,采用分布式资源管理和调度策略,如主-从拓扑结构中的多主节点支持,以及基于区块链的去中心化数据完整性保障,增强系统的弹性、可扩展性和可靠性。
-
强化安全与信任: 在
IoT环境中数据安全和隐私至关重要,特别是对于敏感数据。FogBus引入区块链技术,提供分布式、不可篡改的数据完整性保障,并结合传统的认证和加密技术,构建多层次的安全防护体系。 -
开发者与用户赋能: 不仅为开发者提供构建
IoT应用的工具,还为用户提供运行多应用和定制服务的灵活性,同时帮助服务提供商有效管理其异构资源。通过这些原理,
FogBus旨在提供一个既能满足IoT应用严苛需求,又能有效管理和保护异构分布式环境的全面解决方案。
4.2. 核心方法详解
FogBus 框架通过整合多种硬件设备和一系列相互关联的软件组件来简化 IoT-雾-云集成。
下图(原文 Figure 1)展示了通过 FogBus 框架集成 IoT 设备、Fog 基础设施和 Cloud 基础设施的高层视图:
该图像是示意图,展示了通过FogBus框架集成IoT设备、Fog基础设施和Cloud基础设施的高层视图。图中包括Fog网关节点、Broker节点、Fog计算节点及存储节点,清晰描绘了各组件之间的连接关系。
4.2.1. 硬件设备 (Hardware instruments)
FogBus 框架的基础由以下硬件设备构成:
-
IoT 设备 (IoT devices):
- 包含传感器(感知环境)和执行器(将命令转换为物理动作)。
- 通常资源和能源受限,主要作为数据生产者或消费者,部分设备具备有限的预处理能力。
- 通过
Zigbee、Bluetooth和NFC等无线或有线协议连接到近端网关。 - 传感频率和数据格式可根据系统上下文进行调整。
-
雾网关节点 (Fog Gateway Nodes, FGNs):
- 分布式计算基础设施的入口点。
- 协助
IoT设备配置到集成环境,并部署和执行相应应用程序。 - 提供应用程序前端程序,供用户设置认证凭据、访问后端程序、传递服务期望、接收服务结果、管理
IoT设备和请求资源。 - 执行数据过滤、聚合,并将数据组织成通用格式。
- 通过
CoAP或SNMP与可访问的雾节点保持快速动态通信。
-
雾计算节点 (Fog Computational Nodes, FCNs):
FogBus可以同时处理许多异构FCNs,它们配备处理核心、内存、存储和带宽来执行FogBus操作。- 根据操作,
FCNs扮演三种不同角色:- 代理节点 (Broker nodes):
- 促进
FGNs连接到可访问的FCNs以运行IoT应用程序的后端程序。 - 如果本地资源不足,作为代理节点,它会与其他
FCNs和云数据中心通信以调配所需资源。 - 分布式计算任务,无缝监控和协调活动,执行负载均衡。
- 通过区块链和复制等安全和容错技术,确保与
FGNs、FCNs和云数据中心交互时的可靠性。
- 促进
- 通用计算节点 (General Computing Nodes, GCNs):
- 出于安全考虑,
FogBus不会将所有FCNs直接暴露给FGNs。它们用于通用计算目的,并通过代理节点访问,代理节点充当GCNs的防火墙。 - 代理节点管理
GCNs的资源,并转发数据和可执行的后端应用程序进行处理。 - 执行分布式应用程序时,
GCNs在特定代理节点的监督下形成集群。一个GCN可以与多个代理节点关联。 - 使用 向量时钟 (Vector Clocks) 进行系统同步,帮助
GCNs识别来自不同代理节点的并发命令。GCNs随后任意排序这些并发命令并通知相应的代理节点。 - 在执行命令时,
GCNs与关联的代理节点进行一对一交互。 - 为确保应用级一致性,一个
GCN在任何时候最多执行一个应用程序。
- 出于安全考虑,
- 存储库节点 (Repository nodes):
- 除了执行代理和计算操作外,一些
FCNs管理分布式数据库以促进数据共享、复制、恢复和安全存储。 - 提供接口以便即时访问和分析历史数据。
- 维护各种应用程序的元数据,包括应用程序模型、运行时要求和依赖项。
- 在应用程序执行期间可以保存一些中间数据,以便从任何异常驱动的停止点重新开始数据处理。
- 为确保数据级一致性,存储库节点以日志结构化方式管理所有数据,其驱动因素是更新时间戳和来源。
- 除了执行代理和计算操作外,一些
- 代理节点 (Broker nodes):
-
云数据中心 (Cloud datacenters):
- 当雾基础设施过载或服务需求对延迟不敏感时,
FogBus会扩展云数据中心的资源来执行后端IoT应用程序。 - 通过云数据中心,
FogBus将IoT应用程序的计算平台扩展到全球范围。 - 与雾存储库节点结合,促进广泛的数据存储和分发,使数据的访问和处理不受位置限制。
- 当雾基础设施过载或服务需求对延迟不敏感时,
4.2.2. 软件组件 (Software components)
为了简化 IoT-雾-云集成,FogBus 提供了各种相互关联的软件组件,这些组件可以处理不同硬件设备的操作系统 (OS) 和 P2P 通信级别的异构性。这些组件大致分为三类系统服务 (System Services):
-
代理服务 (Broker service): 管理代理节点的功能,并根据需要启动其他软件组件。
-
计算服务 (Computing service): 负责控制
GCN的操作。当代理节点本身启动后端应用程序的执行时,也会触发其内部的计算服务。 -
存储库服务 (Repository service): 可以在所有雾节点上运行,以管理与存储库相关的操作。
下图(原文 Figure 2)展示了
FogBus中不同软件组件的交互关系:
该图像是图表,展示了在使用区块链的情况下(a)和不使用区块链的情况下(b)不同体系结构的请求数量。图中显示了仅使用Fog、仅使用Cloud以及集成Fog-Cloud的请求数量。这些数据可用于评估FogBus框架在不同设置下的性能表现。
FogBus 软件组件的详细描述如下:
4.2.2.1. 代理服务 (Broker service)
-
代理安全管理器 (Broker Security Manager):
- 从
FGN接收用户认证凭据后,与存储库服务的Credential Archive协作验证这些凭据。 Credential Archive还为该组件提供远程云集成所需的安全证书。- 生成
公钥和私钥对,以促进端口敲门 (port knocking)、特权端口认证 (privileged port authentication)和基于属性的加密 (attribute-based encryption),确保相应代理节点与其他雾节点通信的安全。 - 作为区块链 (Blockchain) 接口,确保与多个实体交换数据时的完整性。在此过程中,借助
Data Manager从接收到的数据创建新区块。每个区块的哈希值 (hash values)和工作量证明 (proof-of-work)被发送到Credential Archive,以便分发给其他节点,从而确保链在不同目的地的一致验证。 - 与
Credential Archive和计算服务的Executor Security Manager一起管理FogBus中的进一步安全问题,并为其他组件提供对所需信息的灵活访问。
- 从
-
资源管理器 (Resource Manager):
- 负责选择合适的资源来执行应用程序。
- 从存储库服务的
Application Catalogue中识别不同应用程序的需求,并通过计算服务的Resource Monitor感知每个代理节点和GCN内的资源状态。 Cloud Integrator为Resource Manager提供基于云的实例(如虚拟机和容器)的上下文数据。- 获取所有信息后,
Resource Manager为应用程序在FCNs和云上调配所需资源。在此过程中,Resource Manager明确考虑了计算实例在处理能力方面的异构性。 - 计算服务的
Application Executor以及FCNs和云的内部软件系统分别帮助Resource Manager调配资源。 FogBus允许服务提供商在资源调配期间使用Resource Manager应用各种策略。- 维护一个
资源配置文件,跟踪FCNs和云实例的地址以及部署的应用程序,以便后续数据流可以直接发送到已分配的资源进行处理。此文件也与云共享,以在相应节点发生故障时恢复放置信息。
-
数据管理器 (Data Manager):
- 接收来自
IoT设备的感知和预处理数据。 - 可以聚合来自多个来源的数据,并根据上下文校准数据接收频率。
- 与
Broker Security Manager协作,利用这些数据创建区块及其链,以维护数据完整性。 - 随后将数据转发给计算服务的
Application Executor进行处理,并以加密方式存储在存储库服务的Data Container中以备将来使用。 - 在应用程序部署到已分配资源后,
Resource Manager将资源配置文件共享给Data Manager,以便它可以直接将后续数据流发送到处理目的地。
- 接收来自
-
云集成器 (Cloud Integrator):
FogBus与云的所有交互均由Cloud Integrator处理。- 将云实例的上下文通知框架,并将存储和资源调配命令转发给云。
- 通过此组件,
FogBus不仅为提供商提供开发定制云集成脚本的接口,还允许第三方软件系统(如Aneka)使用其应用程序编程接口 (API) 同时处理多个云数据中心。
4.2.2.2. 存储库服务 (Repository service)
-
凭据存档 (Credential Archive):
- 保存
IoT设备配置期间设置的用户认证凭据。 - 分发由代理服务生成的每个数据区块的安全密钥和详细信息。
- 为云集成提供
安全套接字层 (Secure Socket Layer, SSL)和传输层安全 (Transport Layer Security, TLS)证书。 - 支持
Data Container对存储数据进行加密和解密。 - 通过存储库服务的
Cloud Dilator,定期在云上更新其镜像,以便在发生意外故障后轻松恢复安全属性并分发给其他节点。
- 保存
-
应用目录 (Application Catalogue):
- 负责维护各种类型应用程序的详细信息,包括它们的操作、开发者推荐的系统属性、执行和编程模型。
- 明确应用程序及其成员任务的资源要求和依赖项。
- 可以通过
Cloud Dilator从云扩展此信息。 - 根据其提供的规范,代理服务的
Resource Manager为应用程序调配资源。 - 根据
Resource Manager的命令,还与计算服务的Application Executor协作,在已分配的资源上组装应用程序。
-
数据容器 (Data Container):
- 存储从
IoT设备接收到的数据,以便进行长期分析。通过应用加密技术确保数据隐私。 - 在应用程序执行期间,还会从
Application Executor接收一些中间数据,帮助FogBus从任何停止点重新开始数据处理。 Data Container基于数据库的架构可以在FogBus中根据不同IoT系统的要求进行定制和共享。- 与
Cloud Dilator保持同步关联,以获取远程数据并通过云分发本地数据。
- 存储从
-
云稀释器 (Cloud Dilator):
- 该组件促进存储库服务的其他软件组件与云进行交互。
- 在这种情况下,代理服务的
Cloud Integrator通过所需的命令协助Cloud Dilator扩展应用程序规范、传输安全属性和交换数据。
4.2.2.3. 计算服务 (Computing services)
-
执行器安全管理器 (Executor Security Manager):
- 在执行计算操作时,
FCN与其他节点之间的无缝安全交互由Executor Security Manager管理。 - 存储库服务的
Credential Archive为此组件提供所需的安全属性。 - 与
Credential Archive和Broker Security Manager一起,该组件在验证区块链方面发挥着重要作用。
- 在执行计算操作时,
-
资源监控器 (Resource Monitor):
- 与
Application Executor协作,监控计算资源的忙碌和空闲状态(例如:CPU使用率、内存占用、网络利用率、功耗等)。 - 根据这些感知到的信息,
Resource Manager为不同的应用程序调配资源。 - 在运行时跟踪已分配资源在满足应用程序
QoS要求方面的性能。 - 当资源负载超过服务提供商定义的阈值或发生意外故障时,此组件会立即通知
Resource Manager。 - 为了应对此类情况,
Resource Manager可以启动一些操作,如动态资源调配、应用程序执行迁移和中间数据存储。然而,在FogBus的当前版本中,这些操作以抽象形式保留,以便FogBus用户可以根据系统上下文定制其资源管理策略。 - 执行必要的同步操作以实现系统同步。
- 与
-
应用执行器 (Application Executor):
- 根据
Resource Manager发出的调配指令,此组件在相应的FCN上为不同的应用程序分配资源。 - 从
Application Catalogue扩展应用程序可执行文件,用于部署在已分配的资源上。 - 一旦应用程序部署完成,它便开始接收
Data Manager转发的数据进行处理。 - 定期向
Resource Monitor报告资源状态。 - 当检测到或预测到任何异常时,
Resource Manager会要求此组件从应用程序执行中提取中间数据并将其存储在Data Container中,以使框架具有容错能力。
- 根据
4.2.3. 网络结构 (Network structure)
FogBus 的软件组件之间共享大量数据和信息,因此需要框架的硬件设备之间建立持久稳定的网络通信。同时,要确保硬件设备不会因通信负担而过载,且网络必须安全、可扩展并具备容错能力。
下图(原文 Figure 3)展示了 FogBus 的网络结构:
该图像是图表,展示了在使用区块链和不使用区块链的情况下,服务延迟的对比。图中分为两部分,(a) 显示了有间隔和无间隔时的服务延迟,(b) 则是关注不同配置下的延迟变化。各条形图分别代表Fog Only、Cloud Only和Integrated Fog-Cloud的延迟数据。
FogBus 网络结构的不同方面如下:
-
拓扑结构 (Topology):
FogBus框架的网络结构设计采用主-从拓扑 (master-worker topology)。- 代理节点 (
broker nodes) 作为主节点 (masters),其他FCNs作为工作节点 (workers)。 - 作为主节点,代理节点从
FGNs接收数据流和用户信息,并发现工作节点进行处理和存储。 - 在应用程序运行时,主节点管理工作节点的功能,并将应用程序执行得出的服务结果交付给
FGNs。 - 此外,主节点还将
FogBus启用系统的雾基础设施与云基础设施连接起来。 - 为了促进数据共享并减少主节点的开销,工作节点也在主节点的明确监督下相互通信。
FogBus启用系统的主节点、工作节点和FGNs连接到由一个或多个路由器管理的公共无线局域网 (WLAN)。
-
可扩展性 (Scalability):
FogBus框架允许服务提供商根据系统上下文扩展活跃雾节点的数量。- 连接到同一
WLAN的FCN可以通过让自己对相应主节点可访问来简单地成为工作节点。 - 随后,主节点在该
FCN上配置所需的软件组件以执行所需操作。 FogBus支持WLAN中多个主节点共存,以便FGNs可以有多种选择来分派数据流进行处理。- 主节点之间也共享工作节点。在这种情况下,数据完整性和隐私不会受到影响,因为每个主节点都维护自己的区块链和工作节点上的独立数据库。
- 此外,在主节点上运行的软件组件促进雾基础设施同时与多个云数据中心集成。
-
可靠性 (Reliability):
-
运行多个主节点的功能隐式消除了
FogBus中主-从模型固有的单点故障限制。 -
基于向量时钟 (
Vector Clock-based) 的同步以及应用程序执行和数据管理期间的一对一交互支持它们在不同工作节点上各自操作的明确隔离和一致性。 -
框架允许每个主节点在其一个工作节点上复制其镜像。当该主节点发生意外故障时,此复制有助于相应工作节点获得主节点特权,并防止通信网络崩溃。
-
FogBus软件组件的平台独立特性在此处发挥关键作用。 -
主节点还定期检查其工作节点的状态,并将其中间数据和配置(包括已部署的应用程序)存储在不同位置。
-
当工作节点发生故障时,主节点会与其他工作节点共享该工作节点的信息,以便立即开始剩余数据处理。
-
如果主节点的所有工作节点都过载,则会考虑其他主节点的工作节点。在这种情况下,所有主节点之间保持内部通信。
-
因此,计算设施在框架内始终可用。
下图(原文 Figure 4)展示了
FogBus框架中如何确保可靠性,特别是主节点故障时的恢复机制:
该图像是图表,展示了区块链对网络使用的影响。图表分为两个部分,(a) 和 (b),分别比较在有间隔和没有间隔的情况下,Fog Only、Cloud Only 和集成 Fog-Cloud 三种模式的网络使用情况(bps)。可以看出,有区块链支持的情况下,Fog 计算资源的利用效率明显提高。
-
-
安全性 (Security):
FogBus网络中包含FGNs和FCNs需要适当的认证。这由管理WLAN的路由器明确处理。- 主节点还应用网络级访问控制和数据包过滤技术,以防止网络基础设施被入侵并消除恶意内容。
- 在
FogBus中,还存在多个通信链路以到达不同的雾节点。这有助于在感知到任何网络异常时重新调整路由路径。 FogBus框架在与不同云基础设施交互时,进一步使用了云提供的网络安全策略。
-
性能 (Performance):
FogBus框架专用于特定系统,利用网络带宽。由于网络资源不与外部实体共享,因此从网络角度来看,系统的整体性能不会下降。- 如果服务提供商打算增加框架中
FCNs的数量,对额外网络资源的需求也不会非常高。 - 此外,它促进了雾节点的轻松部署和更快地向用户交付服务。
- 作为本地化网络,其吞吐量也会随着时间的推移保持在可接受的水平。
FogBus支持网络资源的周期性调整,以便能够处理任何频率和数量的传入流量。FogBus的网络结构不依赖外部硬件设备来管理和配置网络操作,这隐式地降低了服务提供商的资本和运营支出。
4.2.4. 设计与实现 (Design and implementation)
FogBus 中使用的 API、执行环境、脚本和编程语言可以由集成环境中的每个硬件支持。这最终有助于 FogBus 超越其操作系统和 P2P 通信级别的异构性。FogBus 不同元素的实现描述如下:
4.2.4.1. 系统服务 (System services)
FogBus 的每个系统服务(代理服务、存储库服务和计算服务)都分为服务接口 (Service Interface) 和管理活动 (Management Activity)。
-
主节点 (Masters) 上的服务接口 (Service Interface):
- 协助从网关设备接收数据和用户规格,并呈现服务结果。
- 服务提供商还通过此接口向主节点通知工作节点的
IP地址。
-
主节点上的管理活动 (Management Activity):
- 包含资源调配和负载均衡策略,并更新配置文件。
- 生成命令并转发给工作节点。
-
工作节点 (Workers) 上的服务接口 (Service Interface):
- 作为相应节点的接收器,负责将应用程序的输出文件解码给主节点。
-
工作节点上的管理活动 (Management Activity):
- 根据主节点的命令执行资源分配、监控和状态共享。
- 将数据存储在关系数据库中,并为应用程序的后端程序创建输入文件。
-
安全方面: 除了区块链之外,不同系统服务的
Service Interface和Management Activity共同处理FogBus中主节点和工作节点的其他安全方面,如加密和认证。 -
技术栈:
- 服务接口 (Service Interface): 使用
PHP(一种HTML嵌入式服务器端脚本语言)作为Web程序实现,并使用基于HTTP协议的RESTful API在WLAN内的不同FCNs之间交换数据和共享信息。PHP基于的Web程序可以在Unix、Windows、Linux和NetWare等各种操作系统中运行。HTTP是一个应用层协议,可以适应与TCP和UDP等不同传输层协议一起运行。大多数嵌入式、网络和IoT设备要么内置HTTP通信协议栈,要么支持轻松安装。因此,FogBus系统服务的Service Interface可以跨不同类型的操作系统和P2P通信标准运行。FogBus中还在每个FCN中部署了Apache服务器来运行相应系统服务的Web程序。 - 管理活动 (Management Activity): 使用
Java编程语言开发。编译后的Java程序在Java Virtual Machine (JVM)上运行,JVM可以轻松安装在各种操作系统上。因此,FogBus系统服务的Management Activity可以在广泛的平台上运行。 - 数据库:
MySQL服务器安装在FogBus的不同FCNs中,以管理数据库及其操作。
- 服务接口 (Service Interface): 使用
4.2.4.2. 区块链 (Blockchain)
数据完整性和防止数据来自未注册来源对于系统可信度至关重要。
-
区块链原理: 区块链是分布式账本的集合,可以编程以记录和跟踪任何东西的价值。当分布式系统的实体接收到新数据时,它将数据形成一个区块。该区块具有哈希值,通常通过使用相应数据、区块在链中的索引、数据接收时间戳及其前一个区块在链中的哈希值创建。节点还将区块与链中的其他区块一起“挖矿”,为该区块创建工作量证明,使其哈希值遵循相似的模式。随后,数据和区块副本被发送到其他节点,以便与它们的本地链链接。在此操作中,节点挖矿区块以认证工作量证明。数字签名也用于在目的地验证区块的来源。如果任何区块的数据在某个节点上被更改,该区块的哈希值将改变并与存储在下一个区块中的哈希值不匹配。结果,链的后续部分将变得无效。要使链再次有效,需要重新计算无效区块的哈希值。此外,每个区块的工作量证明需要重新生成。这两个操作都耗时且计算密集。此外,区块链中这种欺诈性数据操纵不会成功,除非其分布式副本中有50%被单独重新格式化并遵循相同的操作集。因此,在严格的时间限制内更改区块链中的任何数据变得非常困难。
-
FogBus中的区块链实现:- 主节点从接收到的数据创建区块,并使用
SHA256算法根据数据、前一个区块的哈希值、时间戳和随机数 (nonce value) 计算每个区块的哈希值。 - 主节点还创建随机的公钥/私钥对,用于生成带有原始数据的唯一签名。
- 随后,它们将区块链详细信息、数字签名属性和
Base64编码格式的数据共享给工作节点。 - 通过主节点的公钥,工作节点可以验证数据是否来自合法来源。如果使用了任何其他密钥,该数据将被拒绝。此处的公钥-私钥对是每个区块动态生成的,以防止使用暴力破解技术生成私钥。
- 此外,每个区块及其哈希值在工作节点通过挖矿随机数(支持工作量证明)进行验证。
- 如果任何工作节点报告区块链篡改或签名伪造方面的错误,则网络中大多数节点的区块链将被复制到该节点。
FogBus还允许用户和服务提供商通过主节点上的Service Interface跟踪数据/区块流,显示每个工作节点上区块链副本的最新哈希值。这有助于用户和服务提供商对FogBus网络中的可疑活动采取必要行动。FogBus中的区块链使用Java编程语言开发,并在FogBus的不同FCNs中,此实用程序直接与相应的系统服务交互。
- 主节点从接收到的数据创建区块,并使用
4.2.4.3. 云插件 (Cloud plugin)
- 激活机制: 在
FogBus中,主节点上运行的Service Interface会提示用户指定其对数据处理的云集成意图。只有当用户希望扩展云资源进行计算时,部署在主节点上的FogBus云插件才会激活。对于其他操作(如存储和分发),主节点上的Management Activity直接与云通信。 - 灵活性:
FogBus为提供商提供了使用不同的定制或第三方云插件服务,以集成云和雾基础设施进行计算的灵活性。在使用第三方云插件服务时,主节点会根据该插件的要求进行配置。然而,为了开发定制插件,最好使用跨平台编程语言。 - 当前版本: 在
FogBus的当前版本中,Aneka(一个第三方软件)用于云集成以执行计算操作。Aneka是一个PaaS框架,旨在促进基于云的应用程序管理。它以面向服务的方式运行,配备一套软件组件来配置、操作和监控Aneka-Cloud环境。Aneka-Cloud可以由来自公共、私有或混合云的异构实例组成。Aneka为开发者提供多样化的API,用于在Aneka-Cloud中调配和调度物理和虚拟资源。开发者使用不同的编程模型来制定应用程序逻辑,并设置其部署和执行的运行时环境。- 目前
Aneka平台支持Bag of tasks、Distributed threads、MapReduce和Parameter sweep模型。 - 在
FogBus基于Aneka的云插件中,云实例的IP地址由提供商指定。此插件可以在Aneka-Cloud中启动任务模型 (task model) 和线程模型 (thread model),分别在单个和多个云实例上进行数据处理。 - 根据
FogBus内置的资源调配策略,首先利用雾基础设施处理数据。如果雾基础设施的负载增加到阈值,应用程序及其输入数据流将转移到云基础设施。 - 在这种情况下,主节点上的
Management Activity将数据存储在云输入文件中。主节点上的基于Aneka的云插件以每500毫秒的轮询周期解析此文件,并检查待处理数据。如果存在任何待处理数据,它会形成一个任务或线程,将数据封装在Aneka-Cloud中并启动到一个或多个云实例。在这种情况下,也应用了区块链来确保数据完整性。
4.2.4.4. 应用程序 (Application)
FogBus 支持执行和部署不同 IoT 系统的应用程序。在 FogBus 中,这些应用程序分为前端程序 (front-end program) 和后端程序 (back-end program)。虽然应用程序不是 FogBus 软件组件的一部分,但 FogBus 为开发者提供了一些指导方针,以构建与 FogBus 框架功能对齐的前端和后端程序。
-
前端程序 (Front-end program):
- 在
FGNs中运行。大多数FGNs的底层平台是Android、iOS、Windows、Tizen、WebOS和RTOS。因此,开发前端程序的编程语言应受这些平台支持。 - 某些应用程序的前端程序可能需要临时存储数据。在这种情况下,开发者应使用与这些平台兼容的数据库系统和模式。
- 前端程序处理来自
IoT设备的数据。大多数IoT设备使用Bluetooth Low Energy (BLE)网络技术进行通信,因为它们受能源限制。为了处理这个问题,前端程序应支持通用和低能耗蓝牙交互。 - 在
FogBus框架中,前端程序直接与主节点上运行的Service Interface相关联,用于转发IoT数据和用户信息,以及接收服务结果。为了简化这些交互,前端程序的用户界面可以设计成易于解析主节点Service Interface的Web程序。
- 在
-
后端程序 (Back-end program):
- 在
FCNs中执行。由于FCNs是分布式的,为了充分利用其能力,最好以分布式方式构建后端程序。开发者可以应用模块化开发。 - 后端程序的执行不应受
FCNs操作系统级别异构性的阻碍。为了解决这个问题,开发者可以使用跨平台编程语言(如Java)来开发后端程序。 - 在开发后端程序时,脚本中的某些特定点应明确指定,以便在执行期间可以在这些点存储应用程序的中间数据。
- 后端程序应能够提取输入文件并更新工作节点上的输出文件。
- 在
5. 实验设置
5.1. 数据集
本文采用 FogBus 框架部署和执行了一个名为睡眠呼吸暂停分析 (Sleep Apnea Analysis) 的真实世界应用程序。睡眠呼吸暂停是一种疾病,患者在睡眠期间空气停止流入肺部10秒甚至更长时间,从而降低血液中的氧气水平,降低心率,并类似于停止呼吸。为了确定睡眠呼吸暂停的强度,需要不时监测血液中的氧饱和度。
-
数据来源:
- 通过指脉血氧仪 (
finger pulse oximeter) 收集患者的血氧饱和度 (SpO2) 和心率数据。 - 该研究并未采用公开数据集,而是构建了一个实际的原型系统来实时收集和分析数据。
- 通过指脉血氧仪 (
-
数据特点与领域:
- 领域: 医疗保健领域,具体是睡眠呼吸障碍诊断。
- 数据类型: 时间序列数据,包括
心率 (heart beat rate)和血氧饱和度 (blood oxygen level)。 - 敏感性: 医疗健康数据属于高度敏感数据,对数据完整性、隐私和安全有严格要求。
- 应用场景需求: 传统的睡眠呼吸暂停分析通常需要医院或实验室设备进行通宵睡眠研究,成本高昂且具有延迟。本文提出的原型系统旨在提供低成本、易于配置且结果更快的本地处理方案,尤其适用于关键患者的监测。
-
数据分析逻辑 (数据分析在工作计算节点执行):
- 输入数据以文件形式提供,其中第一、二、三列分别解析为时间戳、心率和血氧水平。
- 一个布尔变量
dip用于跟踪血氧水平是否下降。当血氧水平低于88时,dip变为真,直到血氧水平再次高于88。 - 通过检查血氧水平下降附近时间戳的心率上升来验证下降。
- 分析中有一个计数器变量,记录
dip布尔变量变为真的次数,这被称为呼吸暂停-低通气指数 (Apnea-Hypopnea Index, AHI),用于衡量睡眠呼吸暂停的强度。 - 除了
AHI,分析还存储给定时间段内的最低氧气水平,以及心率数据的最小值、最大值、平均值和平均升降率。 - 此外,还过滤出血氧水平下降期间的心率模式,并生成心电图 (
ECG)。 - 识别这些信息和睡眠呼吸暂停强度后,分析结果将以文件形式交付,由主节点的
Service Interface解析并通知原型操作员。
5.2. 评估指标
本文分两个阶段评估 FogBus 的性能:框架特性评估和应用部署评估。
5.2.1. 框架特性评估 (Section 6)
该部分主要评估 FogBus 作为一个通用框架的底层性能和效率。
-
资源负载 (Load on resources):
- 概念定义: 计算处理器 (
CPU) 和内存 (RAM) 使用率是衡量框架对计算资源占用程度的指标。由于大多数雾节点资源有限,重量级软件系统会造成显著的计算开销。因此,雾计算环境中需要部署轻量级框架。 - 数学公式:
CPU使用率通常表示为百分比: 其中,Busy Time是CPU处于活动状态执行任务的时间,Total Time是观察的总时间。RAM使用率通常表示为百分比: 其中,Used RAM是框架及其组件占用的内存量,Total RAM是系统总内存。
- 符号解释:
CPU Usage:CPU使用率。Busy Time:CPU繁忙时间。Total Time: 总观察时间。RAM Usage:RAM使用率。Used RAM: 已用RAM。Total RAM: 总RAM。
- 衡量目标: 框架消耗的
CPU和内存越少,则被认为越轻量级。
- 概念定义: 计算处理器 (
-
QoS 期望缺失率 (QoS expectation miss rate):
- 概念定义: 由于管理开销和资源限制,框架通常无法满足用户的
QoS期望。较低的QoS期望缺失率反映了框架在管理和利用计算资源方面更高的效率。 - 数学公式:
其中,
Number of Failed QoS Requests是未能满足其QoS要求的请求数量,Total Number of QoS Requests是总请求数量。 - 符号解释:
QoS Miss Rate:QoS期望缺失率。Number of Failed QoS Requests: 未能满足QoS要求的请求数量。Total Number of QoS Requests: 总请求数量。
- 衡量目标: 期望缺失率越低越好。
- 概念定义: 由于管理开销和资源限制,框架通常无法满足用户的
-
时间基属性 (Time-based attributes):
- 概念定义: 系统启动时间 (
System initiation time) 和数据检索时间 (Data retrieving time) 对于指示框架性能至关重要。系统启动时间是指框架内所有组件互连并启动所需的时间。数据检索时间是指通过框架访问数据所需的时间。 - 数学公式:
System Initiation Time(系统启动时间): 衡量从框架启动命令发出到所有核心组件准备就绪所需的时间。Data Retrieval Time(数据检索时间): 衡量从数据请求发出到数据被成功访问并返回所需的时间。- 这两个指标通常以秒 (
seconds) 为单位直接测量。
- 符号解释:
System Initiation Time: 系统启动时间。Data Retrieval Time: 数据检索时间。
- 衡量目标: 这些时间基属性值越低,表示框架的响应性越高。
- 概念定义: 系统启动时间 (
5.2.2. 应用部署评估 (Section 7)
该部分通过一个实际的 IoT 应用(睡眠呼吸暂停分析)来评估 FogBus 的特定设置(例如区块链的使用、调度间隔和基础设施类型)对关键系统参数的影响。
-
请求数量 (Number of requests):
- 概念定义: 在特定时间段内,
FogBus处理的应用程序请求的总数。它反映了框架在给定配置下的吞吐量和处理能力。 - 数学公式: 其中, 是指示函数,如果请求 在时间 内完成则为1,否则为0。
- 符号解释:
Requests Count: 总请求数量。- : 总观察时间。
- : 指示函数。
- : 第 个请求。
- 衡量目标: 通常,请求数量越多,表示框架的吞吐量越高。
- 概念定义: 在特定时间段内,
-
服务延迟 (Service latency):
- 概念定义: 从应用程序请求发出到收到服务结果的总时间。它被建模为网络传播延迟 (
network propagation delay) 和任务完成时间(或应用程序执行时间)的总和。 - 数学公式:
其中,
Network Propagation Delay是数据在网络中传输所需的时间,Task Completion Time是任务在计算节点上执行所需的时间。 - 符号解释:
Service Latency: 服务延迟。Network Propagation Delay: 网络传播延迟。Task Completion Time: 任务完成时间。
- 衡量目标: 服务延迟越低越好,尤其对延迟敏感的
IoT应用。
- 概念定义: 从应用程序请求发出到收到服务结果的总时间。它被建模为网络传播延迟 (
-
网络使用 (Network usage):
- 概念定义: 框架在数据传输和组件间通信过程中消耗的网络带宽量。
- 数学公式: 通常以比特每秒 (
bps) 或兆比特每秒 (Mbps) 表示。 其中,Total Data Transferred是在指定时间段内通过网络传输的数据总量。 - 符号解释:
Network Usage: 网络使用量。Total Data Transferred: 总传输数据量。Time Period: 时间段。
- 衡量目标: 较低的网络使用量有助于减轻网络拥塞,尤其是在资源受限的边缘环境。
-
能源消耗 (Energy consumption):
- 概念定义: 框架运行过程中(包括计算、网络通信等)所消耗的电能。
- 数学公式: 通常以焦耳 (
Joules) 或瓦特小时 (Watt-hours) 表示。 其中,P(t)是在时间 的瞬时功率,积分表示在时间段 内的总能量消耗。 - 符号解释:
Energy Consumption: 能源消耗。P(t): 瞬时功率。- : 观察时间段的起始和结束时间。
- 衡量目标: 较低的能源消耗有助于延长设备寿命,降低运营成本,尤其对于电池供电的边缘设备。
5.3. 对比基线
在框架特性评估阶段(Section 6),FogBus 将其性能与以下现有框架进行比较:
-
Stack4Things (Bruneo et al., 2016): 一个雾中心 (
Fog-centric) 的PaaS框架,用于在具备计算能力的IoT设备上部署和执行多个应用程序。雾基础设施充当集中式可编程协调器。 -
Cloudlet-based PaaS (Yi et al., 2015a): 一个基于
Cloudlet的综合PaaS框架,要求资源丰富的雾节点运行,且包括IoT设备在内的每个节点都需要虚拟化。 -
Indie Fog (Chang et al., 2017): 一个
PaaS框架,利用用户网络设备执行IoT应用程序。核心服务和资源管理指令从云数据中心扩展到雾节点,支持雾节点集群。选择这些基线模型的原因是它们都是旨在集成
IoT、雾和云环境的现有框架,具有一定的代表性,可以用来比较FogBus在平台独立性、资源管理和性能方面的优势。
5.4. 实验环境与参数
5.4.1. 系统配置 (System configuration)
下图(原文 Figure 5)展示了 FogBus 框架下用于睡眠呼吸暂停分析的系统模型:
该图像是图表,展示了在不同条件下(有区间和无区间)采用区块链前后的能量消耗。图中分别展示了仅使用Fog、仅使用Cloud,以及集成Fog-Cloud的能量消耗情况,以焦耳为单位。
下图(原文 Figure 6)展示了 FogBus 框架下睡眠呼吸暂停分析的真实实现:
该图像是一个人物肖像,展示了一位男性的面部特征。他身穿浅色T恤,戴着眼镜,表情严肃。该图像没有提供具体上下文信息。
实验所用的硬件仪器配置如下:
- IoT 设备:
Jumper JPD-500F指脉血氧仪 (1.5V,Bluetooth Low Energy v4.2(BLE),UTF-8数据编码)。 - 网关 (Gateway): 智能手机
Oppo A73 CPH1725(Android 7.1.1)。 - 代理/主节点 (Broker/Master Node):
Dell Latitude D630笔记本电脑 (Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz,2GB DDR2 RAM, 32位,Windows 7,Apache HTTP Server 2.4.34,Java SE Runtime Environment (JRE) 1.6,MySQL 5.6,.net 3.5,Aneka 3.1)。 - 其他
FCN/ 工作节点 (Other FCN/Worker Node): 树莓派Raspberry Pi 3 B+(ARM Cortex-A53 quad-core SoC CPU @ 1.4GHz,1GB LPDDR2 SDRAM,IEEE 802.11, 64位,Raspbian Stretch,Apache HTTP Server 2.4.34,JRE 1.6,MySQL 5.6)。 - 公共云 (Public Cloud):
Microsoft Azure B1s Machine(1vCPU,1GB RAM,2GB SSD,Windows Server 2016,.NET 3.5,Aneka 3.1)。
5.4.2. 已安装软件包 (Installed package)
原型系统主要以雾基础设施为中心。然而,如果雾基础设施无法处理数据,则使用 FogBus 内置的基于 Aneka 的云插件将数据发送到 Azure VM。睡眠呼吸暂停分析的应用程序包包括一个 Android 前端和一个数据分析后端程序。
-
智能手机网关上的
Android界面 (Android interface at smart phone gateway):- 一个名为
HealthKeeper的Android可执行文件启动原型操作员的Android界面。 - 该可执行文件安装在智能手机上,使设备充当脉搏血氧仪和主节点之间的中介。
- 使用
MIT App Inventor(一个开源平台)开发。 - 界面分为主页 (
Home) 和会话 (Session) 屏幕。-
主页屏幕帮助操作员使用蓝牙将血氧仪与智能手机配对以接收患者数据,并输入主节点的
IP地址。 -
会话屏幕处理与主节点的所有交互,包括数据传输。它自动记录和传输数据,而不是通过
HTML表单手动发送。 -
当记录开始时,初始化一个空数据列表并重置计时器。从血氧仪接收到的每个数据值都附加到列表中。当记录停止时,列表被发送到主节点进行存储并分发给工作节点。
-
此屏幕还扩展了主节点上运行的
Service Interface,并在结果可用于主节点后向操作员显示结果。下图(原文 Figure 7)展示了
HealthKeeper安卓界面的(a)主页和(b)会话屏幕:
该图像是一个人像照,展示了一位穿着西装的男性,面向镜头,背景简单。此图可能与研究工作或个人介绍相关。
-
- 一个名为
-
工作计算节点上的数据分析 (Data analytic at worker computing nodes):
- 睡眠呼吸暂停分析的数据分析封装了两个开源程序 (
Manigadde (2018)和Initiative (2017))。 - 这些
Java程序存储在存储库工作节点中,并根据主节点的命令转发给计算工作节点进行安装。 - 数据分析以文件形式获取输入数据。输入文件的第一、第二和第三列分别解析为时间戳、心率和血氧水平。
- 在分析中,一个布尔变量跟踪血氧水平是否存在下降。当血氧水平低于88时,
dip布尔变量变为真,并保持为真直到血氧水平高于88。通过检查血氧水平下降附近时间戳的心率上升来验证下降。 - 分析中的计数器变量记录
dip布尔变量变为真的次数。此计数被称为呼吸暂停-低通气指数 (Apnea-Hypopnea Index, AHI),用于确定睡眠呼吸暂停的强度。 - 除了
AHI,分析还存储给定时间段内的最低氧气水平,以及心率数据的最小值、最大值、平均值和平均升降率。 - 此外,还过滤出血氧水平下降期间的心率模式,并生成心电图 (
ECG)。 - 识别这些信息和睡眠呼吸暂停强度后,分析结果将以文件形式交付,由主节点的
Service Interface解析并通知原型操作员。
- 睡眠呼吸暂停分析的数据分析封装了两个开源程序 (
5.4.3. 通信序列 (Sequence of communication)
下图(原文 Figure 8)展示了在睡眠呼吸暂停分析中的通信序列:
抱歉,我无法识别这张图片的内容。
在 FogBus 启用睡眠呼吸暂停分析的原型中,所有硬件设备都属于同一个 WLAN。其通信序列如下:
- 配置与数据感知: 首先,使用操作员的凭据将脉搏血氧仪与智能手机进行配置。血氧仪感知患者的
SpO2和心率,并通过蓝牙通信转发给智能手机。 - 数据传输至主节点: 智能手机将这些数据发送给主节点。
- 数据存储与确认: 主节点随后将数据存储在存储库工作节点上。存储操作确认从存储库工作节点发送给主节点。由于智能手机扩展了主节点的
Service Interface,此确认对操作员可见。 - 分析请求: 在记录数据一段时间后,操作员通过智能手机向主节点发出请求,要求分析存储的数据。
- 任务分配: 然后,主节点与合适的计算工作节点通信,并向其授予数据分析所需的权限。
- 数据与分析程序获取: 计算工作节点从存储库工作节点请求存储的数据和分析可执行文件。
- 数据分析: 接收到这些元素后,计算工作节点开始分析操作。
- 结果返回: 一旦分析操作完成,结果将发送回主节点。
- 结果显示: 智能手机从主节点拉取结果并显示给操作员。
5.4.4. 实验场景设置 (Experiment Scenarios for Application Deployment Evaluation)
在应用程序部署评估阶段(Section 7),实验针对不同的 FogBus 设置进行建模:
- With / Without Interval (有 / 无间隔):
- With Interval (有间隔): 主节点在接收到前一个请求的结果并经过一定间隔后,才向其计算工作节点发送下一个数据处理请求。此时间间隔有助于主节点和计算工作节点减少开销。
- Without Interval (无间隔): 主节点在前一个请求的结果一可用就立即向其计算工作节点发送下一个请求。这确保了
FogBus框架始终保持活跃,节点之间不存在空闲时间。
- With / Without Blockchain (有 / 无区块链):
FogBus提供了根据用户和服务提供商的需求启用或禁用其区块链安全功能的灵活性。此实验设置的不同部分基于FogBus中区块链功能的状态。
- Fog / Cloud Only / Integrated (仅雾 / 仅云 / 集成):
FogBus支持跨不同计算基础设施执行应用程序。此实验设置指应用程序执行是仅在雾、仅在云还是在集成基础设施上进行。
5.4.5. 监控工具与额外参数
-
性能监控:
- 主节点和
Azure VM上使用Microsoft Performance Monitor。 - 树莓派电路上使用
NMoN Performance Monitor。
- 主节点和
-
额外实验参数:
以下是原文 Table 2 的结果:
Parameter Value Analysis Task: Interval between creating sequential data processing requests 3 seconds Data recording time per processing requests Pulse Oximeter: 3 minute Signal length 18 KB Sensing frequency 2 signal per second WLAN: Download Speed 7 Mbps Upload Speed 2 Mbps
6. 实验结果与分析
6.1. 核心结果分析
本节分为两个主要部分:框架特性评估和应用部署评估。
6.1.1. 框架特性评估结果 (Framework characteristics evaluation results)
这部分评估了 FogBus 与现有框架在资源占用、QoS 满足率和响应速度方面的比较。
6.1.1.1. 框架的轻量级 (Lightness of frameworks)
下图(原文 Figure 9)显示了不同框架下核心节点的 CPU 和 RAM 使用情况:
该图像是一个人物肖像,显示了一位男士的面部特征,他佩戴眼镜,面带微笑,背景模糊。该图像可能与论文《FogBus: A Blockchain-based Lightweight Framework for Edge and Fog Computing》无关。
- CPU 使用率 (图 9a):
FogBus的CPU使用率最低。 - RAM 使用率 (图 9b):
FogBus的RAM使用率最低。
分析:
FogBus轻量化的原因:FogBus很少或不依赖第三方软件系统,这大大降低了其对核心/主/代理雾节点的CPU和内存资源消耗。- 其他框架较重的原因:
Cloudlet-based PaaS框架:系统操作未在多个雾节点上分布式执行,导致核心雾节点的CPU和RAM利用率更高。Indie Fog和Stack4Things:尽管协作操作雾节点,但其核心雾节点(Indie Fog的注册表和虚拟板)承担了额外的责任,如联邦资源、存储库和安全管理、服务发现、应用服务管理等,因此增加了核心雾节点的CPU和RAM负载。
- 结论:
FogBus作为一个轻量级框架,更适合资源受限的雾计算环境。
6.1.1.2. 资源管理性能 (Performance in managing resources)
下图(原文 Figure 10)显示了不同框架下 QoS 期望缺失率:
该图像是图示,展示了FogBus框架中不同软件组件的交互关系。图中包含了Broker服务、Repository服务和计算服务等多个模块,以及它们之间的连接与信息流动,体现了系统的结构与协同工作的方式。
FogBus的QoS期望缺失率最低。
分析:
FogBus优势:FogBus能够同时利用边缘和远程资源。当雾节点过载时,它会通过云数据中心资源继续处理输入,提供了更大的范围来满足用户的QoS期望。因此,FogBus的QoS期望缺失率较低。- 其他框架劣势:
Indie Fog:应用程序执行完全由雾节点资源管理,当负载增加时,其QoS期望缺失率较高。Cloudlet-based PaaS:核心雾节点上过高的CPU和RAM负载迫使其减慢输入数据流的管理操作,导致其QoS期望缺失率高于轻量级的FogBus。Stack4Things:通过部署在Cloudlet中的核心雾节点管理应用服务,其QoS期望缺失率略高于FogBus。
- 结论:
FogBus在资源管理方面表现出更高的效率,能够更好地满足用户QoS期望。
6.1.1.3. 框架的响应性 (Responsiveness of frameworks)
下图(原文 Figure 11)显示了不同框架在系统启动时间(图 11a)和数据检索时间(图 11b)方面的比较:
该图像是FogBus框架的网络结构示意图,展示了云、路由器、Broker节点和Fog网关等组件之间的连接关系。该框架支持多种IoT设备通过无线路由器进行数据处理和交互。
- 系统启动时间 (图 11a):
FogBus的系统启动时间最短。 - 数据检索时间 (图 11b):
FogBus的数据检索时间最短。
分析:
FogBus响应性高的原因:- 更少的第三方软件依赖: 减少了启动和初始化所需的时间。
- 按需云交互: 避免了不必要的云连接开销。
- 更多的横向连接而非纵向连接: 促进了快速的组件间通信。
- 本地分布式存储:
FogBus将数据存储在本地存储库节点中,而不是发送到云或任何集中式数据存储。这使得在应用程序执行期间可以轻松快速地访问数据。
- 结论:
FogBus具有更高的响应性,能够更快地启动系统并检索数据,这对于实时IoT应用至关重要。
6.1.2. 应用部署评估结果 (Application deployment evaluation results)
这部分通过睡眠呼吸暂停分析应用,评估了 FogBus 的不同设置(如是否启用区块链、是否有间隔、基础设施类型)对系统参数(请求数量、服务延迟、网络使用、能源消耗)的影响。
6.1.2.1. 请求数量 (Number of requests)
下图(原文 Figure 12)展示了在使用区块链的情况下(a)和不使用区块链的情况下(b)不同体系结构的请求数量:
该图像是示意图,展示了FogBus框架中的用户、主节点和工作节点之间的关系。图中显示,当主节点故障时,工作节点会被转变为新的主节点,以确保系统的可靠性和稳定性。
- 图 12a (With Blockchain):
Fog Only模式下请求数量最高,其次是Integrated Fog-Cloud,最低的是Cloud Only。Without Interval(无间隔)模式下请求数量显著高于With Interval(有间隔)模式。
- 图 12b (Without Blockchain):
Fog Only模式下请求数量仍然最高。Without Interval模式下请求数量显著高于With Interval模式。- 禁用区块链后,所有设置下的请求数量普遍高于启用区块链的情况。
分析:
- 雾优先的优势:
Fog Only模式下请求数量更高,因为雾基础设施能够快速交付前一个请求的结果,从而更快地生成下一个请求。 - 间隔的影响:
Without Interval设置下,主节点持续生成请求,确保框架持续活跃,导致请求数量显著增加。With Interval设置有助于减少主节点和计算工作节点的开销,但会降低请求吞吐量。 - 区块链的影响: 禁用区块链功能(图 12b)会使请求数量更高。这是因为在禁用区块链时,需要共享和处理的额外数据量减少,从而提高了接收前一个请求结果的速度。
- 结论: 在需要处理大量请求且安全要求不高的情况下,
FogBus可以设置为Fog Only模式并禁用区块链功能。通过调整请求创建间隔,可以在请求数量和基础设施开销之间进行权衡。
6.1.2.2. 服务延迟 (Service latency)
下图(原文 Figure 13)展示了在使用区块链和不使用区块链的情况下,服务延迟的对比:
该图像是示意图,展示了FogBus框架下用于睡眠呼吸暂停分析的系统模型。用户通过智能手机网关与脉搏氧饱和度仪连接,数据通过HTTP请求传输至Broker进行资源管理,然后分发到工人节点进行分析。
- 图 13a (With Blockchain):
Fog Only模式的服务延迟最低,其次是Integrated Fog-Cloud,Cloud Only模式的服务延迟最高。With Interval模式的服务延迟略低于Without Interval模式。
- 图 13b (Without Blockchain):
- 禁用区块链后,所有设置下的服务延迟普遍低于启用区块链的情况。
Fog Only模式的服务延迟仍然最低。
分析:
- 网络传播延迟的主导作用: 服务延迟是网络传播延迟和任务完成时间(或应用程序执行时间)的总和。由于本实验中数据块大小不大,任务完成时间在雾和云之间差异不显著,因此服务延迟主要受网络传播延迟影响。雾基础设施更接近数据源,网络传播延迟最低。
- 雾优先的优势: 在
Fog Only模式下,服务交付延迟最小。 - 区块链的开销: 禁用区块链功能会显著降低服务延迟,因为区块链管理会增加处理请求的额外时间。
- 间隔的益处:
With Interval设置减少了基础设施和网络的开销,有助于改善服务交付延迟。 - 结论: 这些设置有助于
FogBus处理具有严格截止期限的请求。对于延迟敏感型应用,应优先考虑Fog Only模式,并在可能的情况下禁用区块链功能,同时合理设置间隔时间。
6.1.2.3. 网络使用 (Network usage)
下图(原文 Figure 14)展示了在使用区块链和不使用区块链的情况下,网络使用的对比:
该图像是FogBus基础上进行睡眠呼吸暂停分析的真实实现示意图。图中展示了两台显示器和一台笔记本电脑,连接着几个指脉氧仪作为物联网设备,构成了一个计算环境,用于多应用并行处理和资源管理。
- 图 14a (With Blockchain):
Fog Only模式的网络使用量最低,Cloud Only和Integrated Fog-Cloud模式较高。Without Interval模式的网络使用量高于With Interval模式。
- 图 14b (Without Blockchain):
- 禁用区块链功能后,所有设置下的网络使用量普遍低于启用区块链的情况。
Fog Only模式的网络使用量仍然最低。
分析:
- 本地化网络优势:
Fog Only模式的网络使用量更低,因为它主要利用本地网络资源。 - 区块链的额外开销: 禁用区块链功能会减少网络使用量,因为需要跨基础设施传输的安全属性数据量减少。
- 持续请求的影响: 在
Without Interval设置下,持续生成请求会增加网络使用量,因为需要交换更多相关数据和信息。 - 结论: 通过调整后续请求生成间隔,可以在一定程度上降低网络使用量。这些调整使得
FogBus即使在为IoT系统分配的网络资源较少时也能正常运行。
6.1.2.4. 能源消耗 (Energy)
下图(原文 Figure 15)展示了在不同条件下(有区间和无区间)采用区块链前后的能量消耗:
该图像是图7,展示了基于Fog网络的HealthKeeper安卓界面的(a)主页和(b)会话屏幕。界面提供传感器配对和主节点IP输入功能,同时显示睡眠数据和血氧水平的图表。
- 图 15a (With Blockchain):
Fog Only模式的能源消耗最低,Cloud Only模式的能源消耗最高。With Interval模式的能源消耗低于Without Interval模式。
- 图 15b (Without Blockchain):
- 禁用区块链功能后,所有设置下的能源消耗普遍低于启用区块链的情况。
Fog Only模式的能源消耗仍然最低。
分析:
- 云虚拟机的能耗: 在
Cloud Only模式下,雾节点用于网络通信,而云虚拟机执行计算。由于云虚拟机比雾节点消耗更多能源,因此Cloud Only模式的能源消耗更高。 - 雾优先的节能: 在
Fog Only模式下,网络和计算都由雾节点处理,所需能源较少。 - 区块链的能源开销: 管理
FogBus的区块链功能会消耗额外的能源。禁用区块链功能可以节省一些能源。 - 间隔的节能作用: 基础设施在忙碌时间的能源消耗高于空闲时间。因此,在后续请求创建之间设置间隔有助于改善基础设施的能源使用。虽然这会导致
FogBus处理的请求数量减少,但可以通过有效调整间隔时间来克服。 - 结论: 这些配置有助于
FogBus在能源受限的环境下执行应用程序。
6.2. 数据呈现 (表格)
以下是原文 Table 1 的结果:
| Work | Integrates | Platform independent | Security features | Supports multi-applications | Targets | Decentralized management | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| IoT | Fog | Cloud | Integrity | Authentication | Encryption | Developers | Users | ||||
| Rahmani et al. (2018) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Dubey et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Azimi et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ||||
| Gia et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Akrivopoulos et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Chen et al. (2017) | ✓ | ✓ | |||||||||
| Craciunescu et al. (2015) | ✓ | ✓ | |||||||||
| Hu et al. (2017) | ✓ | ✓ | |||||||||
| Yangui et al. (2016) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Bruneo et al. (2016) | ✓ | ✓ | ✓ | ✓ | |||||||
| Verba et al. (2017) | √ | ✓ | ✓ | ✓ | |||||||
| Yi et al. (2015a) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Vatanparvar et al. (2015) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |||||
| Chang et al. (2017) | ✓ | ✓ | ✓ | ✓ | ✓ | ||||||
| Mohamed et al. (2017) | ✓ | ✓ | ✓ | ||||||||
| FogBus [this work] | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
以下是原文 Table 2 的结果:
| Parameter | Value |
| Analysis Task: | |
| Interval between creating sequential data processing requests | 3 seconds |
| Data recording time per processing requests Pulse Oximeter: | 3 minute |
| Signal length | 18 KB |
| Sensing frequency | 2 signal per second |
| WLAN: | |
| Download Speed | 7 Mbps |
| Upload Speed | 2 Mbps |
7. 总结与思考
7.1. 结论总结
本文提出了 FogBus 框架,旨在将不同的 IoT 系统集成到雾和云基础设施中。该框架促进了 IoT 应用程序的部署、资源监控和管理。FogBus 的系统服务使用跨平台编程语言 (PHP 和 Java) 开发,并与可扩展的应用程序层协议 (HTTP) 结合使用,帮助 FogBus 克服了不同雾节点的操作系统和 P2P 通信级别异构性。
FogBus 框架作为一个适用于集成雾云环境的平台即服务 (PaaS) 模型,不仅协助应用程序开发者构建不同类型的 IoT 应用程序,还支持用户定制服务,并帮助服务提供商根据系统上下文管理资源。考虑到某些 IoT 系统(如健康监测和公用事业服务计量)涉及敏感数据,FogBus 应用了认证技术以保护数据隐私,并引入区块链技术以确保数据完整性。为了在安全性较低的网络中保障数据传输,FogBus 还采用了加密技术。
研究团队基于 FogBus 原理开发了一个用于睡眠呼吸暂停分析的成本效益型原型系统。通过与现有框架的比较,实验结果表明 FogBus 的软件组件轻量级、响应性高,并能够有效利用边缘和远程资源。此外,通过调整 FogBus 的不同设置,可以根据多样化的应用场景需求,高效地处理应用程序执行。
7.2. 局限性与未来工作
论文作者指出了 FogBus 框架在未来可能改进的方面:
- 资源管理策略 (Resource management policies):
FogBus提供了应用定制化调配策略的灵活性。未来可以开发在现有静态管理策略之上的动态资源管理策略,旨在实现计算基础设施之间的负载均衡和QoS提升。 - 雾基础设施虚拟化 (Fog infrastructure virtualization):
FogBus协助雾计算与IoT系统的集成。尽管云计算可以虚拟化,但对于FogBus中的雾基础设施虚拟化,需要进行深入探索。 - 人工智能 (Artificial Intelligence): 目前
FogBus不支持任何人工智能技术来控制不同基础设施中的操作和提高系统的弹性。引入人工智能技术可以为FogBus带来显著的贡献。 - 应用放置技术 (Application placement techniques):
FogBus内在地支持分布式应用程序执行。在以分布式方式放置应用程序时,服务延迟、用户期望和部署成本成为主要考虑因素。在这种情况下,可以将不同的高效应用放置技术添加到FogBus的软件栈中。此外,未来还可以对FogBus在处理不同计算密集型、网络密集型和存储密集型应用程序方面的性能进行比较研究。 - 运行时应用迁移 (Runtime application migration): 如果预测到任何异常,运行时应用程序的迁移至关重要。可以为
FogBus开发不同的运行时应用程序迁移策略来处理此类不确定事件。 - 轻量级安全特性 (Lightweight security features):
FogBus现有的安全特性需要相对较高的计算辅助,这会影响服务交付延迟、能源和网络使用。因此,开发轻量级但有效的安全特性将有助于进一步提升FogBus。 - 嵌入式区块链功能改进 (Improvement of embedded Blockchain feature):
FogBus的嵌入式区块链功能是通用的。然而,它提供了抽象性,使其可以在未来区块链研究中发挥重要作用,例如减少数据检索时间、管理智能合约以及在集成雾云环境中实现“链中链 (chain of chains)”。
7.3. 个人启发与批判
7.3.1. 个人启发
FogBus 框架提供了一个全面的 IoT-雾-云集成解决方案,其设计理念和实现细节给我带来了多方面的启发:
- 全栈集成与实用性: 论文不仅停留在理论层面,而是详细描述了从
IoT设备到云端的硬件配置、软件组件、网络结构以及具体应用案例(睡眠呼吸暂停分析)的实现。这种全栈的视角和原型系统使得FogBus具有很强的实用性和可操作性,对于希望在实际环境中部署IoT-雾-云系统的开发者来说非常有价值。 - 平台独立性的重要性: 在异构的边缘计算环境中,平台独立性是实现广泛采纳的关键。
FogBus通过选择PHP和Java等跨平台语言以及HTTP协议,有效地解决了操作系统和P2P通信的异构性问题,为构建可在多样化硬件上运行的分布式系统提供了优秀的实践经验。 - 安全的多层次考量: 论文强调了在
IoT环境中,特别是处理敏感数据时,安全不仅仅是认证和加密。引入区块链来保障数据完整性,是一种前瞻性的、去中心化的安全策略。这种多层次的安全设计对于构建高信任度的IoT应用至关重要,特别是在医疗、金融等关键领域。 - 可调优性的价值:
FogBus提供了多种设置选项,允许用户和服务提供商根据具体场景(如高吞吐量 vs. 低延迟,高安全 vs. 低能耗)来调优系统性能。这种灵活性在多变且需求各异的IoT应用中具有巨大价值,避免了一刀切的解决方案。 - 主-从模型与可靠性增强: 在主-从拓扑中,单点故障是一个常见问题。
FogBus通过支持多主节点和主节点镜像复制到工作节点来实现故障转移,有效增强了系统的可靠性和可用性,这对于关键任务IoT应用至关重要。
7.3.2. 个人批判
尽管 FogBus 提供了强大的功能和创新点,但仍有一些潜在问题、未经验证的假设或可以改进的地方:
-
区块链的实际开销与轻量化权衡: 论文承认现有的区块链功能需要较高的计算协助,影响服务延迟、能源和网络使用,并将其列为未来工作的方向。虽然区块链提供了强大的数据完整性保障,但在资源极其受限的边缘设备上,其共识机制(如工作量证明)和数据存储开销可能仍然是一个瓶颈。如何在保证足够安全性的前提下,真正实现“轻量级”的区块链,需要更深入的研究,例如探索更适合边缘环境的轻量级共识算法或私有链/联盟链的应用。
-
动态资源管理策略的抽象性: 论文提到动态资源管理策略目前以抽象形式保留,以便用户可以定制。这固然提供了灵活性,但也意味着框架本身并未提供成熟的、即插即用的动态调度和负载均衡算法。实际部署时,性能的优劣将很大程度上依赖于用户自行实现的复杂策略,这可能增加了部署和维护的难度。未来应提供一些默认的、经过验证的动态策略示例。
-
多主节点协同的复杂性: 尽管多主节点设计提高了可靠性,但多个主节点之间如何高效、一致地共享工作节点、协调任务分配以及解决潜在的冲突(例如,多个主节点并发向同一工作节点发出命令,尽管论文提到使用向量时钟来识别并发命令并任意排序,但这种“任意”排序可能不总是最优的,并且其开销也需进一步分析),都是分布式系统中的复杂问题。论文中对这部分的详细描述相对较少,其在极端负载或频繁故障情况下的表现值得进一步探讨。
-
“轻量级”的量化与边界: 论文强调
FogBus的轻量级,并提供了CPU和RAM使用率的比较。然而,对于“轻量级”的量化边界,例如FogBus能支持的最大IoT设备数量、最大并发应用数量或最小雾节点配置,论文中未明确给出。这对于服务提供商规划基础设施容量而言是重要的信息。 -
应用部署的通用性: 论文以睡眠呼吸暂停分析作为案例研究,这是一个
SPMD模型下的数据处理应用。虽然论文提到FogBus支持workflow和stream模型,但并未深入探讨其他复杂IoT应用(如需要实时协同控制、复杂事件处理或机器学习推理)的部署细节和性能。不同类型的应用对资源、延迟和安全的需求差异巨大,FogBus在这些场景下的表现及其调优方法仍需进一步验证。 -
网络拓扑的弹性与广域网集成: 论文描述的网络结构基于
WLAN的主-从拓扑。虽然提到可以 readjust the routing path when any network anomaly is perceived,但对于更复杂的广域网环境、跨地域雾节点部署以及在网络不稳定情况下的性能表现和弹性机制,可以进行更深入的探讨。例如,如何有效处理雾节点之间的地理分布和网络分区问题。总而言之,
FogBus是一个非常有前景的框架,在IoT-雾-云集成领域做出了显著贡献,特别是在平台独立性和安全性方面。但其在动态资源管理、区块链开销优化和更复杂应用场景下的通用性等方面仍有广阔的未来研究空间。
相似论文推荐
基于向量语义检索推荐的相关论文。