• 边缘计算在物联网(IoT)当中的运用「物联网架构探索系列」（边缘计算 iot）
• 5G将重新定义物联网和边缘计算
• C++在物联网中的物联网架构和协议支持
• C++模板在物联网中的运用？
• DGIOT物联网架构设计

边缘计算在物联网(IoT)当中的运用「物联网架构探索系列」（边缘计算 iot）

这里记录的是我对物联网架构的学习、探索和思考，希望对你有所启发……

　　边缘计算是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。其应用程序在边缘侧发起，产生更快的网络服务响应，满足行业在实时业务、应用智能、安全与隐私保护等方面的基本需求。目前，许多科技企业已经在边缘计算上开始自己的布局。

　　未来，我们会看到越来越多的像智慧城市、智能工厂、智能制造、智能零售等一系列创新商业模式，它们在运用物联网技术的过程中，需要用到数据采集、处理、上传数据的边缘端计算设备和网关设备。这些设备或者是相应的解决方案，配合分布式数据库和分布式的数据处理，就构成一个完整的边缘计算体系。但这个体系不是独立存在的，它会跟云计算产生非常多的数据和应用互动。

边缘计算简单架构图

　　提到边缘计算，我们会联想到秒杀时候，使用CDN进行负载分流；可能也会联想到数据中心和分布式服务器；或者想到数据中心和设备采集网关；或者想到华为AI神经网络芯片、离线地图，离线语音识别；或者自动驾驶，电动汽车等等……

　　这边不深入考究边缘计算的概念，具体可以查看维基百科或百度百科

　　边缘计算的架构图很简单，如下图所示(图片来源)：

为什么需要边缘计算？

　　也许你会第一反应是中心计算力不足，网络延迟，数据量庞大，这些都是常见的因素……

数据上涨

　　随着芯片计算力的发展、硬件成本的降低，加上网路提速，大概每十年一次变革，数据呈现指数级的增长。也许在2020-2030年，通过5G和AI的变革，计算机正在吞噬一切可以数字化的东西，那时候数据的增长不知道会是什么恐怖级别？

　　显然，这个时候的数据中心，已然无法承担集中式带来的各自延迟，缓慢，痛苦……

成本上涨

　　为什么边缘计算还能节省成本？

• 几十万用户的公司，只需要处理百级 QPS 的量，只需要 10 台左右的服务器；
• 上百万用户的公司，只需要处理千级 QPS 的量，需要有 50 台左右的服务器；
• 上千万用户的公司，需要处理万级到十万级 QPS 的量，需要 700 台左右的服务器；
• 上亿用户的公司，其需要处理百万级 QPS 的量，需要上万台的服务器。

　　以上数据不是完全标准的，但是可以确定的是像BAT，TMD这些大厂的服务器都是以万计算的。

　　如上图所示，十万用户到上亿用户，用户量也就多 100 倍，为什么服务器需要1000倍？因为，当架构变复杂了后，你就要做很多非功能的东西了，比如，缓存、队列、服务发现、网关、自动化运维、监控等……

　　如果我们能够把那上亿的用户拆成 100 个百万级的用户，那么只需要 5000 多台机器。

分担计算

　　海量数据则能够就近处理，大量的设备也能实现高效协同的工作，诸多问题迎刃而解。因此，边缘计算理论上可满足许多行业在敏捷性、实时性、数据优化、应用智能、以及安全与隐私保护等方面的关键需求。

　　这里举个简单的应用，假如一个项目有5万个设备点，每隔5分钟一次采集，那么一年后的测点数据可能就是100G量级。对这些数据的统计就会是一个耗时耗力的事情。

边缘计算应用场景

　　既然边缘计算是一种必然，那么边缘计算会应用在哪些场景呢？我觉得至少以下这些场景会用到：

• 处理一些实时响应的业务。它和用户靠得很近，所以其可以实时响应用户的一些本地请求，比如，某公司的人脸门禁系统、共享单车的开锁。
• 收集并结构化数据。比如，把视频中的车牌信息抠出来，转成文字，传回数据中心。我们知道大华，海康等主流摄像头设备本身自带车牌识别等功能就是一个典型的应用
• 实时设备监控。主要是线下设备的数据采集和监控。比如，设备告警、设备联动、设备管理、设备统计等
• P2P 的一些去中心化的应用。比如：边缘结点作为一个服务发现的服务器，可以让本地设备之间进行 P2P 通讯。 
• ……

　　边缘计算的运用场景还是十分丰富的，还有很多是我们所想象不到的，我们正在期待神经网络芯片助力AI智能，未来的设备必然会更加强大，更加边缘化。

边缘计算的技术？

　　边缘计算涉及到的技术包括方方面面，这里截取要点分析。

API网关

　　API Gateway相当于一个门卫的角色，和设计模式的Facade（门面模式）很像，是系统的唯一入口。网关可以是一台服务器，也可以是一个比较强大的设备。

　　网关还可以进行往下分层级，像众星拱月一样，最后通过一个大的门卫作为唯一的入口。这种星型的网关架构可以控制每个子网关或者叫子边缘计算的粒度。当然这种架构也带来更大的复杂度。

　　一个网关一般包含以下这些组件：服务注册，请求路由，负载均衡，弹力设计，安全管控。此外网关对性能、集群和高可用也是需要考虑的一个要点，对于初创中的团队，这些其实可以放在最后去考虑，后续业务起来后依然是一个必须考虑的重点，比如单点故障导致的所有访问瘫痪，性能低下导致的请求延迟，或者没有使用异步机制导致的吞吐量低下等等……

服务函数化(Serverless)

　　传统的做法，我们都需要在服务器上持续运行进程以等待 HTTP 请求或 API 调用，而Serverless可以通过某种事件机制触发代码的执行。

　　"如果说微服务是以专注于单一责任与功能的小型功能块为基础，利用模块化的方式组合出复杂的大型应用程序，那么我们还可以进一步认为 Serverless 架构可以提供一种更加 " 代码碎片化 " 的软件架构范式，我们称之为 Function as a Services（FaaS）。所谓的 " 函数 "（Function）提供的是相比微服务更加细小的程序单元。"——左耳朵耗子

　　不同于微服务的是函数化更加碎片，而且无需进程等待，这是他的杀手锏。最后推荐两个GO语言的开源框架

• openfaas
• fission

数据同步

　　边缘和中心的关系千丝万缕，就物联网来说，中心需要的数据是什么呢？大部分是决策数据，也就是那些官老爷要看的数据，至于设备什么时候告警，什么时候出故障等等数据不一定要实时或者全部同步到中心，也就是说你的数据延迟一段时间并不妨碍，甚至隔天都问题不大。

　　如果要同步，一般如何做？

• 通过消息队列写时复制(Wirte And Copy)，这种方式实时性高，有很好的削峰填谷。
• 通过DB层面发布订阅进行数据同步，这种同步是日志级别的，性能有保障，但是调式有坑，不建议使用。

　　我所了解的建筑智能化设备设施这个行业，边缘设备只要不是闹人命的故障，比如电梯故障，火灾报警什么的，大部分的业务其实都和钱和安全没有多大关系，也就是对高可靠的依赖是非常弱的。当然不排除医院或者机场等特殊情况。

 总结

 　　本文主要探讨了物联网领域的边缘计算这个概念和简单架构图，接着简单介绍为什么需要边缘计算以及边缘计算的使用场景和关键技术。边缘计算和物联网一起兴起，还有很多未知等待探索，一起行动吧……

引用链接：

• 什么是边缘计算？
• 华为云IoT解决方案
• 边缘计算、雾计算、云计算区别
• 边缘计算：物联网的下一个风口

5G将重新定义物联网和边缘计算

比上一代蜂窝服务(4G)相比，5G提供的无线蜂窝连接性具有更高的带宽、更低的延迟和更高的设备密度。除10 Gbps的速度和1毫秒的延迟外，5G还可以在每平方公里支持数千台设备。

5G还支持网络切片，这使运营商可以将5G无线电访问网络划分为虚拟网段，每个网段都可以进行自定义以支持不同类型的应用程序。网络切片的另一个好处是可隔离一个网段的流量与其他网段的流量，以确保安全性。

5G使用各种频率，范围从现有的2.4 GHz频段到毫米波(MM wave)。毫米波频率支持更高带宽的信道，尽管会由于射频吸收而缩小范围。这意味着可部署更多的接入点，这将减少与每个AP关联的端点数量，并增加每个端点可用的带宽。

5G边缘计算、雾计算和IoT

边缘计算将数据处理集成到边缘设备中，这些边缘设备通常是数据收集器或过程控制器。边缘计算可快速处理原始传感器数据，而无需将数据传输到主机应用程序。通过在边缘设备附近或边缘设备内处理原始数据，可以减少传输延迟和带宽成本。

其中一个很好的示例是可编程逻辑控制器，它会收集和处理本地生成的数据，然后通过网络连接将摘要数据上传到综合监控应用程序，以执行其他数据处理和归档。

边缘计算可提高上游数据传输的效率，并提供对物联网边缘设备的实时控制。在边缘计算中，处理能力安装在边缘设备内部或附近。

而雾计算提供了另一种选择，它将计算和存储功能放在边缘设备附近，而不是在边缘设备内。它提供了本地设备到设备通信，提供更好的控制系统弹性，并将摘要数据发送到基于云的应用程序。

5G边缘计算组合为新的和改进的应用(包括IoT部署)带来机会，这主要得益于该标准的带宽延迟和实时控制功能。

5G的1毫秒延迟性(而4G的延迟为10毫秒)可支持实时应用程序–这些应用程序无法忍受4G的延迟性。常见的示例是自动驾驶汽车，其中汽车通过5G相互通信，共享传感器数据和驾驶意图，从而使每辆汽车都能就其预期路径做出明智的决策。

雾计算与5G的低延迟相结合，可支持实时应用程序，这是高延迟基于云的应用程序无法提供的支持。通过分布式架构—其中雾计算基础架构安装在IoT设备附近，还可以提高应用程序的弹性。

通过使用正确的架构，基于边缘和雾计算的应用程序仍可以在本地级别继续运行，即使与云的网络连接失败。

安全用例支持5G边缘计算

另外，通过使用专有5G网络切片，边缘计算安全可得到增强，因为5G网络切片受防火墙保护，构建在网络功能虚拟化基础架构上。同时，容器化将使定制软件更容易部署到边缘或雾计算系统。大型固态存储系统将能够存储大量数据。这种网络、计算和存储的组合为很多有趣且功能强大的系统打开大门。

我们再看看建筑物的环境、照明和安全系统。借助5G和雾计算基础架构，低成本传感器可以通过本地安全网络传输数据。雾计算系统基于从云下载的配置数据做出控制决策。而5G网络的低延迟和高密度意味着它可以从数百个温度调节器、入住客传感器、安全扫描仪和环境光监控器中实时收集数据。

雾计算系统通过5G网络将命令发送到建筑物照明、门锁以及供暖和制冷系统。如果云连接中断，系统仍将继续运行。同时，由于5G网络切片将传感器和控制数据与其他网络用户相隔离，因此安全性得到增强。

另一个很好的示例是装配厂控制系统。机器人彼此通信以互相传递零件，并依靠5G边缘计算进行通信。而基于雾的基础架构将在相邻机器人间增加另一级控制。你还可以轻松地将此概念扩展到化工厂过程控制系统。在这两种示例中，5G的网络切片都可增强安全性。

更多linux资讯请查看：https://www.linuxprobe.com

C++在物联网中的物联网架构和协议支持

c++++在物联网中提供广泛的架构和协议支持，其支持的分层架构、soa和eda架构，以及mqtt、http/rest、coap、zigbee和蓝牙等协议，有助于开发人员创建强大的物联网应用。通过代码示例，开发者可以实现zigbee设备连接和mqtt主题订阅，利用c++优势构建可扩展、实时的物联网解决方案。

C++在物联网中的物联网架构和协议支持

C++因其强大的性能、灵活性以及对各种协议和架构的支持而成为物联网应用开发的流行语言。

物联网架构

立即学习“C++免费学习笔记（深入）”；

C++支持以下物联网架构：

• 分层架构：将物联网划分为多个层（感知层、网络层、应用层等），每个层负责不同的功能。
• 服务导向架构（SOA）：使用松散耦合的服务提供物联网功能，从而提高可扩展性和可重用性。
• 事件驱动架构（EDA）：触发器响应事件而不是事先定义的流程，从而实现更灵活和实时的响应。

协议支持

C++支持广泛的物联网协议，包括：

• MQTT：轻量级消息队列传输，专为低功耗和受限设备设计。
• HTTP/REST：适用于通过网络通信数据的标准协议。
• CoAP：受限应用协议，专为受限设备和小带宽网络而设计。
• Zigbee：低功耗无线通信协议，用于创建网状网络。
• Bluetooth：短距离无线通信协议，用于连接各种设备。

实战案例

考虑一个温室监控系统。系统由传感器、网关和云平台组成。

• 传感器使用Zigbee协议无线收集温度和湿度数据。
• 网关将Zigbee数据转换为MQTT并传输到云平台。
• 云平台通过HTTP/REST接口分析数据并控制温室环境。

C++代码示例

以下是使用C++连接Zigbee设备并订阅MQTT主题的代码示例：

#include <ZCLinkJS.h>
#include <Mosquitto.h>

// Zigbee设备地址
const short addr = 0x1234;

// MQTT服务器信息
const char* mqttServer = "mqtt://broker.example.com";
const int mqttPort = 1883;
const char* clientId = "my-client";
const char* topic = "temperature";

void setup() {
  // 初始化Zigbee设备连接
  initZigbee();

  // 初始化MQTT客户端
  mqttClient.connect(mqttServer, mqttPort, clientId);

  // 订阅MQTT主题
  mqttClient.subscribe(topic);
}

void loop() {
  // 从Zigbee设备读取温度数据
  int temperature = readTemperature(addr);

  // 将温度数据发布到MQTT主题
  mqttClient.publish(topic, String(temperature));
}

通过利用C++对物联网架构和协议的支持，开发人员可以创建强大且可扩展的物联网应用。

以上就是C++在物联网中的物联网架构和协议支持的详细内容，更多请关注php中文网其它相关文章！

C++模板在物联网中的运用？

c++++ 模板在物联网中提供了代码重用和类型安全。通过使用模板，开发人员可以创建可应用于各种数据类型的可复用组件，从而提高开发效率和可维护性。

C++ 模板在物联网中的应用

简介：
C++ 模板是强大的工具，用于在物联网应用程序中创建可重用和泛型的代码库。通过将代码与数据类型分离，模板允许开发人员创建可应用于各种数据类型的可复用组件。

模板基本语法：

立即学习“C++免费学习笔记（深入）”；

template <typename T>
class MyClass {
    // 代码
};

• template 关键字表示这是模板定义。
• 表示模板的一个类型参数。

优点：

• 代码重用：模板允许开发人员创建可应用于各种类型的单一代码库。
• 提高效率：通过消除重复代码，模板可以提高开发速度和可维护性。
• 类型安全性：C++ 模板保证了类型安全，从而防止类型错误。

实战案例：

智能传感器数据处理：
想象一个传感器网络，它收集各种类型传感器（如温度、湿度、加速度计）的数据。使用模板，我们可以创建通用的数据处理组件：

template <typename T>
class DataProcessor {
public:
    T process(T data);
};

这个组件可以应用于各种传感器类型，因为它处理数据而不考虑其具体类型。

IoT 设备管理：
在设备管理系统中，需要管理不同类型的设备。使用模板，我们可以创建通用的设备管理组件：

template <typename T>
class DeviceManager {
public:
    void manage(T device);
};

这个组件可以管理各种类型的设备，因为它接受一个特定类型的设备作为参数。

结论：
C++ 模板是一个强大的工具，可用于创建可重用、泛型和类型安全的代码库。它们极大地提高了物联网应用程序的开发效率和可维护性。

以上就是C++模板在物联网中的运用？的详细内容，更多请关注php中文网其它相关文章！

DGIOT物联网架构设计

分层架构

在应用系统开发中，采用严格的、单一的、真正的的分层架构是可以的，但实际上我们已经采用了多种架构模式设计系统。当多种不同范式的架构混合在一起，你会不会出现“指鹿为马”的现象呢？

• 严格分层架构

在研究分层架构时，常通过概念性的定义或 OSI 七层应用（架构）来说明或解释分层架构：

架构模式 Layers 有助于将应用程序划分为多组子任务，其中每组子任务都位于特定抽象层。

图片取自《 POSA , Vol.I , p22 》

作为一个在项目中引入分层架构的应用者，我们应该从更具体的规范来实现分层架构：

• 相邻层之间必须是单向耦合。上层只能依赖下层，下层永远不能依赖上层。

• 相邻层之间必须是单向通信。上层去调用下层所提供的接口，下层永远不能调用上层的接口。

《 POSA , Vol.I 》 为我们提供了更多的实现规范，然而我要解决的是有关层的单向依赖问题。因为有一些人在使用分层架构时，尤其是将分层架构引入到项目的目录结构时，对于某些对象的划分（从属）存在一些混乱问题。

如果你有兴趣了解更多分层架构的实现规范，可参考：《 POSA , Vol.I 》第二十六页到第二十九页相关知识。

• 松散分层架构（Relaxed Layered System）

在领域驱动设计（DDD）中采用的是松散分层架构，层间关系不那么严格。每层都可能使用它下面所有层的服务，而不仅仅是下一层的服务。每层都可能是半透明的，这意味着有些服务只对上一层可见，而有些服务对上面的所有层都可见。

注意：松散分层架构依然是单向依赖，表明上层只能调用下层的服务，下层不能调用上层的服务。

• 继承分层架构（Layering Through Inheritance）

同时在领域驱动设计（DDD）中也采用了继承分层架构，高层继承并实现低层接口。我们需要调整一下各层的顺序，并且将基础设施层移动到最高层。

注意：继承分层架构依然是单向依赖，这也意味着领域层、应用层、表现层将不能依赖基础设施层，相反基础设施层可以依赖它们。

领域层 UserRepository 接口：

package com.mallfoundry.user.domain;
public interface UserRepository {    User save(User user);}

基础设施层 JpaUserRepository 实现类：

package com.mallfoundry.user.infrastructure.persistence;
public class JpaUserRepository implements UserRepository {
    private final EntityManager entityManager;
    public JpaUserRepository(EntityManager entityManager) {        this.entityManager = entityManager;    }
    @Override    public User save(User user) {        return this.entityManager.merge(user);    }}

• 包（Package）与分层架构

我们确实使用包来划分层级，但是包名并不能真正表示分层。

• 资源库（Repository）

我们通常将资源库的实现放置在基础设施层，这是因为我们采用了继承分层架构。如果你现在采用的是松散分层架构，你需要将资源库的实现放置在领域层。这是层的单向依赖原则所致，你不应该破坏这个原则。没有任何理由需要破坏分层架构的单向依赖原则，除非你不采用分层架构。

• 三层或四层架构

我们应该从混乱到有序的这个历史过程去研究（分析）分层架构，尤其是我们现在处在前后端分离的环境下，应用系统使用分层架构又面临着什么样的划分变化。

• 第一个阶段：应用系统只有两层：表示（现）层和数据库层。在视图中直接使用数据库所提供的访问接口操作数据，如：JDBC，在视图中直接使用 ResultSet 表示数据。（需要特别注意的是：在视图中直接使用 ResultSet 。）

• 第二个阶段：应用系统划分为三层：表现层、领域层和数据库层。在这个阶段，我们已经开始意识到模型了，模型的出现意味着在视图中不在直接使用 ResultSet 了，而是使用从 ResultSet 相映射的编程语言中的结构体（struct）或者对象类（class）。这表示：从编程语言中的表示法可以抽象业务域中的概念结构了。

• 第三个阶段：应用系统划分为四层：表现层、应用（业务）逻辑层、领域层和数据库层。由于业务逻辑依然存在视图中，我们需要将视图中的业务逻辑与视图分离出来，此时出现了应用层。同时表现层也有所推进，表现层使用 MVC 架构。通过在 Controller 调用应用层所提供的接口并获得接口所返回的模型（model）数据，并在 Controller 中将 model 和 view 组合起来，最终完成渲染工作。正是因为在表现层使用 MVC 架构使得视图（view）与下层实现松耦合。

应用系统使用分层架构在第三阶段基本已经成熟。因为我们要探讨的是有关领域驱动设计（DDD）的分层架构，所以我们依然需要做进一步补充。具体包括两方面的补充：

• 第四个阶段：面向对象的发展与应用，这个阶段对总的层次划分没有大的变化。具体的变化的是有关应用层与领域层的内容，更具体的来说是领域层的变化。面向对象的出现使得大家开始使用面向对象来设计领域模型。这表示：由属性和操作所表示的对象模型用来抽象业务域中的概念模型。同时这又表示应用（业务）逻辑层中的业务逻辑也将被对象领域模型所承担，应用层只需要控制与协调有关对象领域模型的相关逻辑。非常幸运的是，Eric 对这一现象中的更多细节做了非常系统性的阐述，最终形成《领域驱动设计》这本书。

• 第五个阶段：前后端分离后对分层架构的影响。在前后端分离的项目中，表现层被完全的从后端剥离出来，后端只需要提供接口数据，如：RESTful , gRPC , Thrift , GraphQL 协议的后端接口。此时后端还是不是四层架构呢？这确实伴随着两条发展路线：一条是服务于前端的后端模式（BFF）。另一条是基于聚合对象的接口模式。它们的区别在于 BFF 频繁变化，后者不会因为前端频繁变化而变化。

关于边缘计算在物联网(IoT)当中的运用「物联网架构探索系列」和边缘计算 iot的介绍已经告一段落，感谢您的耐心阅读，如果想了解更多关于5G将重新定义物联网和边缘计算、C++在物联网中的物联网架构和协议支持、C++模板在物联网中的运用？、DGIOT物联网架构设计的相关信息，请在本站寻找。