## 后端整体架构设计

感知平台后端整体架构设计如图所示

![image-20210809153536503](imgs/飞尚物联/image-20210809153536503.png)

​	保留现有采集控制模块(DAC)，然后将以DAC采集的数据以及其他相关的感知数据，存储到数据湖中，这部分数据一般是原始的采集指纹，我们对数据的采集频率和数值不做改动。ETL是后续数据处理流程，将原始数据转换为业务感知数据，即用户期望的数据格式，是一种半结构化的数据。感知平台将其持久化在存储媒介上，同时使用消息规则引擎，可以将数据推送到任意地方。感知平台还提供一部分的数据可视化分析功能。

​	目前，从技术上选型主要是用来`Apache Flink`和 `Apache IceBerg` 两个框架。Flink主要提供流式计算和批量聚合能力，IceBerg数据湖应用主要用于保存原始数据。技术框架整体的应用如下图：

![image-20210811114005563](imgs/飞尚物联/image-20210811114005563.png)

### ETL流程说明

​	我们着重于拓展ETL进程的功能，新增包括数据入湖、钩子接口、脚本化计算等功能，增强ETL的可扩展性。ETL的设计如下:



![image-20210811092806946](imgs/飞尚物联/image-20210811092806946.png)

我们引入[IceBerg](https://www.sohu.com/a/403477409_411876)数据湖方案，它支持Table Schema表格式定义，以及快速的upsert/delete操作，并支持ACID原子性语义保证。基于现有的HDFS分布式文件存储底层，打造存储设备采集结果的数据湖。IceBerg支持Streaming和Batch增量数据流接口，并可以和Flink流式计算框架很好的集成。

另外，数仓方面，依然采用ElasticSearch这个NoSql数据库，主要目的是保留目前技术栈，依赖其开箱即用分布式能力、高性能检索能力。另外日志这种需要全文检索的数据，也是储存在ElasticSearch中。

流程方面，采集数据通过kafka通道，进入ETL。这里的采集数据应该包括设备数据以及状态数据，经过ETL的Parse模块解析提取后，输出至ICEBERG的数据湖中，后面的流程基本跟原ET处理流程一致，经过计算（Map）和过滤（Filter），然后将感知数据存储至ElasticSearch中。这里保留Aggregation(RT)实时聚集功能，是为了得到近实时的增量聚合数据。最终，经过实时计算处理后的数据，输出到消息管道(Kafka)中。

其中相关进程模块说明如下：

> + Parse 数据解析
> + Map 数据计算转换
> + Filter 合理值过滤、数据降噪
> + Storage 存储到数据仓库(ElasticSearch)
> + Aggregation(RT) 实时增量聚合
> + Aggregation 定时聚合方法



告警保留原来的处理流程，如下图所示

![image-20210811105044185](imgs/飞尚物联/image-20210811105044185.png)

在解析提取(Parse)阶段，将告警原数据保存到数据湖。（这里保存的告警原数据，应该类似告警数据中详情数据，包含设备采集返回的错误码信息和错误内容）

后续步骤，跟原告警处理流程一致。该平台只保留Analyzer模块中阈值判断类数据告警，并提供业务钩子函数或脚本化功能，用户可以根据自己需求做定制。



### 钩子接口

为方便业务应用扩展，我们在ETL流程中增加部分hook接口(类似RPC的调用，用户可以实现自己的`FaaS`，提供函数计算服务，通过配置实现到自己的业务流程中)，以及通过脚本化方式扩展部分功能。接口钩子和脚本化调用主要包含在ETL中如下位置：

![image-20210811134932722](imgs/飞尚物联/image-20210811134932722.png)

位置说明：

> Hook 1 : Custom Map 扩展计算方法。
>
> Hook 2: Custom Filter 扩展过滤方法。
>
> Hook 3: Custom Before Storage 扩展后续计算。经过平台计算和过滤的数据，在存储前，可扩展业务计算。
>
> Hook 5: Custom Analyze 扩展告警判断。生成自定义告警
>
> Hook 6: Custom Deliver 扩展告警内容，在告警内容分发之前
>
> Scripts A: 脚本实现协议解析
>
> Scripts B: 脚本实现公式计算



### 视频

视频数据相对独立于传统设备数据。服务端只需提供数据推流服务拉取远端NVR，向前端推送RTMP协议的视频流数据。

将安心云平台的视频配置（NVR设置、摄像头配置）作为设备的一部分（特殊设备），在感知平台进行配置。



### 监控运维

感知平台扩展监控内容，除了设备接入，将感知过程中的数据、事件、状态，记录到 Promethus。这边的功能点可以参考：

+ 实时监控：数据指标、网络状态。

+ 运维大盘：显示设备创建数、激活、在线、活跃设备数（周统计和周同比）

+ 在线调试：需要设备在线，包括属性调试、服务调用、远程登录。

+ 设备模拟器：模拟数据调试

+ 日志服务：云端运行日志、设备本地日志、日志转储

+ OTA升级和远程配置



### 规则引擎、流程和联动*

> '*' 试验性功能，需进一步探索实现可能性

在以太规则基础上，增加数据源，包含ET计算后的感知数据和聚合数据，同时扩展输出方式。

探索流程引擎在数据流程控制中应用，使业务数据可以走ETL流程之外的自定义流程。

场景联动，通过数据/告警消息，触发动作执行：反向控制、告警输出、数据推送等。



## 功能设计和实现方案

### 一) 功能整合

梳理物联网感知平台的功能包含如下（具体参见《物联网接入服务架构思路》）

> + 数据接入
>   + 产品定义
>   + 协议开发
>   + 设备管理
>   + 部署
>
> + 感知转换
>   + 感知模型
>   + 提取转换加载ETL
>   + 数据聚合、清洗
> + 数据服务
>   + 数据存储
>   + 告警服务
> + 其他：视频、可视化



整体平台的架构基础，即实现两个平台感知能力的整合。以太的所有功能加上安心云的部分功能组合：

 ![image-20210809155449209](imgs/飞尚物联/image-20210809155449209.png)

设计飞尚物联平台架构，主要分以下几个步骤：

#### 第一步：Fork以太

沿用现在以太的代码，在此基础上开发。

代码层关于以太、iota等标签不需要改动，可沿用iota作为基础命名空间或关键词前缀。

UI层可做简单处理，包括登录页定制和logo替换、copyright修改等。

以下是以太目前服务列表（第三方基础服务设施未列出），本平台需要保留。

| 服务名称            | 描述                |      |
| ------------------- | ------------------- | ---- |
| iota-alert-server   | 以太告警服务        |      |
| iota-api            | 以太console端WEBAPI |      |
| iota-background     | 以太admin端WEBAPI   |      |
| iota-dac            | 以太采集服务        |      |
| iota-dac-test       | 以太DAC协议测试服务 |      |
| iota-message-center | 以太消息中心        |      |
| iota-orchestrator   | 以太DAC编排器       |      |
| iota-proxy          | 以太接入网关代理    |      |
| iota-rules-engine   | 以太规则引擎        |      |
| iota-web            | 以太Console端       |      |
| iota-web-background | 以太Admin端         |      |
|                     |                     |      |



#### 第二步：安心云服务选取/改造

安心云平台部分服务（主要是后端服务）和前端功能需要整合到新的感知平台，梳理其中应该包含的后端服务：

| 服务名称       | 描述                     |      |
| -------------- | ------------------------ | ---- |
| et             | 数据ETL进程              |      |
| alarm          | 告警进程                 |      |
| aggregation    | 聚集计算                 |      |
| config-center  | 配置同步redis            |      |
| et-hdfs        | HDFS数据文件转储进程     |      |
| et-recalc      | 重计算进程               |      |
| deliver        | 邮件短信推送服务         |      |
| weather        | 天气服务                 |      |
| pyrpc          | 计算服务(python rpc服务) |      |
| *report-master | 报表调度服务（暂定）     |      |
| *report-client | 报表生成服务（暂定）     |      |
|                |                          |      |

**改造：**安心云的服务端进程中，遗留部分业务逻辑代码，需在整合过程剔除。详见《[ET中业务专有代码]()》



整体的进程服务组织大致如下图：

 ![image-20210811110035960](imgs/飞尚物联/image-20210811110035960.png)



#### 第三步：模型定义+数据库整合 + 数据湖定义

感知模型定义，数据库表格设计。

数据湖Schema定义；

Flink结合IceBerg作入湖操做；



### 二） 扩展接口

主要包括两种方式的功能扩展方法：

1. 定义数据接口：通过rpc方式调用
2. 通过脚本语言交互



### 三) 功能优化

设备协议解析优化： 

1. 定义平台标准通用mqtt-json格式。实现标准java-sdk库作设备上的开发套件     

2. 可选标准协议（modbus）     

3. 可视化协议组件（协议组成选取指定类型解析、json格式字段映射配置）     

4. 扩展目前支持的脚本类型

规则引擎扩展：

1. 数据源扩展
2. 输出方式扩展
3. 扩展HTTP/MQTT输出规则的内容格式定义

场景联动：

1. 定义数据联动规则     

2. 触发能力接口     

3. 触发告警调用

简化设备接入：

1. 接入demo示范     
2. 接入流程向导指引



### 系统设计原则

简+

易扩展性+