HarmonyOS 鸿蒙Next 基于DFD系统设计后的模块建模和实现

HarmonyOS 鸿蒙Next 基于DFD系统设计后的模块建模和实现 背景

之前有通过DFD方法设计了一个框架的接入子系统，在设计中并没有谈及软件实现，为了达成设计和实现的完整，今天刚好有闲暇时间来看看如何对这个系统的雏形进行设计。

以框架的接入器为例，我们之前通过DFD方法将接入器分成了3个模块。

模块1，用于做协议业务。

模块2，用于做数据的订阅和拉取并快速分发。

模块3，用于执行数据解析逻辑并将解析后的内容快速传递给下游模块。

设计模块1的初衷是让其承载和设备通信的协议相关业务，如接入模型、标准模型、Bin4协议协议的报文校验和解析、Modbus协议的报文校验和解析，Ftp文件解析，该模块最终作为一个静态库供其它模块依赖。

对于模块2，我们的初衷是让其主动或被动地获取设备数据，并将原始设备数据快速同步或异步地传递给下游。

而模块3，其职责则相当单一，即根据协议解析规则、模型映射规则将原始数据解析成为网管能直接使用的业务数据后传递给下游。

前言

在实现一个模块之前，我们要做的第一件事就是做好模块级别的设计，不能直接就是开手干，这种细节设计最好使用Specification的形式来做，Specification就要求咱们的模块设计要Specific，要求精准，但不是绝对精准，而是相对的。

首先，我们在写Specification时，要对篇章中的概念要进行一一说明，对于业界已达成共识的概念：如线程、虚拟化，咱们千万不要重新定义一遍，否则有可能误导读者，显得不专业，比如说业界已达成共识的线程，其概念描述是AAAAAAAAA，你弄出来一个线程是BBBBBBBBBB，这样读者就懵了，我到底该相信既有的概念还是相信你；对于自己创建的概念，就要好好的讲清楚了，否则通篇下来，没人知道你的接入模型是啥，标准模型是啥，写了也是白写，在一开始概念就说不清楚，后面也就很难拆分或扩展了。

另外，在不同的层次都有其特定的概念模型，每一层设计都要做到概念的清晰表达，力求读者能懂。比如说在解决方案侧，他们对设备的概念抽象统称为网元(Network Element)；而到了咱们业务框架侧，为了方便存储和管理，就抽象出了管理对象(Managed Object)；到了再上层的业务侧，就有了公司(Company)、电站(Station)、设备(Device)这样的概念抽象，每一层的概念设计都是为了让设计在后续过程中具备良好的演进能力，而上层对下层要做到感知得越少越好，比如说咱们能源网管的上层业务最好是不要直接感知管理对象, 逆变器领域业务实现只要感知设备、电站、公司、设备属性等概念就好，通信能源只要感知到站点、油机、基站等概念就好，而越是底层要越抽象，越是上层就要越具体精确，这才是好的分层设计，LGZ大佬形象地将这个称为“小姐脾气”，小姐要吃牛河，那牛河这道食物的实现就是厨子来负责的，葱姜蒜辣怎么放，干炒还是湿炒那就是厨子的实现自由了，而软件设计也是这样的，上层的设计要给下层的设计留有较多的实现自由度，而不是做到面面俱到。

在进行概念描述之后，后面的软件设计就相当容易了，简直是行云流水，你可以选择不同的设计方法，你擅长使用传统的软件设计方法，那么“4+1视图”建模方法是你的首选，如果你想拥抱敏捷，那么你还可以使用“C4模型可视化”等方法，甚至你可以多种设计方法混用，来完成你的软件设计。

实践

第一步，描述好接入子系统中的概念模型。 接入子系统中主要的概念有如下这些，主要还是接入模型、标准模型和数据报文解析。

• 接入模型，用于将设备寄存器地址映射成框架的管理对象的信号。
• 标准模型，用于从接入模型接入信号全集中筛选出部分上层业务要用到的接入信号子集，映射成为标准信号。
• 通信协议，是网管和设备，设备和设备之间进行通信的一种通用语言，比如在逆变器领域，使用HUAWEI Modbus协议进行通信。是一种设备控制器间能认识的一种消息结构，可以理解为网管和设备、设备和设备间为了方便达成的一种共识以方便沟通交流。
• 消息帧，和TCP协议中报文类似，是特定的数据结构，往往包含地址域、功能码、数据、差错校验等部分组成。
• 报文校验，为了验证报文的完整性和合理性，是否有篡改，是否是标准的通信协议报文，保证报文能正确的解析且不会对设备或网管造成影响。
• 设备数据，包括设备的实时数据，历史数据，告警数据以及一些配置数据，网管应用会主动通过上述的“通信协议”和设备进行通信，定期主动的从设备处获取这些数据，或主动接受设备侧上报上来的设备数据。
• 数据解析，按照一定的解析规则和映射规则，将设备侧获取的原始设备数据解析后并映射成为特定的管理对象信号值。

第二步，确定好各个模块的业务模型。

协议业务

协议业务模块最终会作为一个静态依赖被其它模块引入，所以首先对这个模块进行建模。这个模块重要的模型包括“数据帧”、“帧解析器”、“解析后的帧”和“信号”这四个概念，出了信号是具体的类之外，其它的模型皆为接口，定义良好的接口是关键，因此我决定对上面的概念进行抽象，最终建模如下。

接入业务

数据接收和分发模块最终将会以服务的形式存在。该模块业务很简单，即主动和设备通信获取设备的数据，或被动接收设备上报的数据。主动采集的难点是要做到快速，比如采集实时数据时，如何快速完成一轮百万设备的数据采集（5分钟周期内）；而被动接收数据的数据时，难点在于如何解决C1000K问题，也就是极限情况下需处理百万设备的连接，对连接数的要求非常高，这也是我们为什么要引入Netty这种高性能异步网络库的原因。为了快速建模，我决定不对外部依赖的三方件建模，纯粹从业务维度进行建模，但是模型的实现将会依赖这些三方件。

首先看看主动采集数据部分，我们将数据抽象成为了Data, Data支持扩展，此外还引入了DataPuller从网元侧主动获取数据、DataDispatcher将获取到的数据向下游分发，这部分DataPuller将会基于一些异步I/O库和协程库来实现，保证采集动作做到少阻塞从而具备高效的采集性能，DataDispatcher将会基于消息三方件进行实现，要求消息间写入性能优秀，以达到快速分发的目的。

对于被动接收部分，我们引入了服务端通道和网元侧通道的概念，服务端通道由各种I/O事件和自定义事件驱动，以执行其业务逻辑，这块的实现建议基于多路复用库和异步I/O库来实现，这里其实是一个Reactor模式，要做到以尽可能少的资源处理尽可能多的连接。

由于操作系统对进程能打开的文件格式和整个计算机能打开的文件数据有限制，所以为了压榨单机的接入能力，我们往往不得不手动增大这些限制。

解析业务

最后一脚就是要做好数据解析了，解析入库模块是最没压力的部分了，只需完成上游分发下来的原始数据解析，入库入缓存即可，但是需要注意几点。

• 解析要在约定的时间规格内完成，尤其是实时和性能数据解析，否则可能造成历史数据到点了看不到数据、实时数据一直显示旧数据等问题。
• 解析的速度一定要快，否则会造成消息积压的问题，也就是数据消费速度达不到上游原始数据生产速率。
• 由于解析是比较复杂的计算逻辑，需要较强的计算资源，所以需要较好的CPU。