系统架构主题之六：软件系统架构风格

一 软件系统架构风格概念

关于架构风格，抓住几个关键词语：构件、连接件、连接关系、组织关系、惯用模式、高层抽象、系统级可传递、设计可重用、整体系统结构设计、指导构建规则等。

总的来讲，它是软件构件与其连接件连接约束的惯用模式，是经验的沉淀，有一定的复用价值。

这部分分类与旧的教材有一些差异。以新的为准。

1数据流体系结构风格，包括

1. 批处理体系结构风格：构件元素为独立程序，连接件为某种媒介，比如磁盘。比如，A程序写结果到文件，B程序从磁盘读取结果，处理后写入新的存储介质，C程序再读取处理。
2. 管道-过滤器体系结构风格：数据传输由管道负责，数据处理由过滤器实现。过滤器从管道中读取数据，经过处理后，输出到管道中。基本构件为过滤器，连接件为管道。比如媒体程序的处理，读取源，编码，压缩、解压缩、解码、显示就是一个典型的管道过滤器处理过程。

2调用返回体系结构风格，包括

1. 主程序、子程序风格：一般是线程内。构件为主程序和子程序，连接件为过程调用。比如C语言的函数调用。
2. 面向对象体系结构风格：构件是对象，连接件为消息。
3. 层次型体系结构风格：构件是虚拟机，连接件是交互协议。操作系统的层次构成就是这样的风格，硬件、虚拟机、操作系统、系统软件、应用软件。
4. 客户端服务器体系结构风格：资源不对等的情况。

3以数据为中心的体系结构风格，包括

1. 仓库体系结构风格：构件有中央数据仓库和操作数据的独立构件，连接件是二者的交互。
2. 黑板体系结构风格：

4虚拟机体系结构风格，包括：

1. 解释器体系结构风格：典型例子是专家系统，包含一个虚拟机，负责弥合程序语义与硬件语义之间的差异。
2. 规则系统体系结构风格：包括规则集，规则解释器，规则数据选择器及工作内存。

5独立构件体系结构风格，包括：

1. 进程通信体系结构风格：构件是独立过程，连接件是消息，同步或异步及远程过程调用。
2. 事件系统体系结构风格：构件不直接调用一个过程，而是触发或广播一个或多个事件。其他构件注册事件处理。比如调试器、编辑器等就都典型的应用了这种风格。

  

  顺便了解一下老的分类方式：

  管道过滤器

  面向对象

  基于事件的隐式调用

  分层系统

  C2风格

  仓库系统及知识库

  

以上概念了解即可。其实一个软件系统，从不同角度看，就可能看到不同的偏向上面介绍的某种架构风格。实际工程中，我们也会站在不同角度来讨论软件的架构风格，方便开发人员之间的沟通。下面的实践介绍中，大家会看到这一点。

  

二 系统构建中采用的风格及实际效果

仍然以前面介绍的某电力系统项目为例来展开讨论。

首先，系统的打包构建模块就是一个典型的批处理风格。编译程序将源代码编译为目标文件，连接程序读取目标文件，处理后，生成可执行文件。之后，构建程序将可执行文件和其他资源文件组装，生成安装包，发布程序将安装包推送到系统和设备，实现自动部署。这些工作在之前主要依赖脚本完成，现在的CI/CD理念的流行，我们可以通过Jenkins这类专业工具实现从代码提交到自动构建、自动测试、自动分发部署的全流程自动化的研发运维管理。

接着，从全局来看，整个软件系统采用了分层架构风格。最底层是硬件层，之上是操作系统和驱动层，再之上是平台层，通过引入、适配、融合各种开源工具，方便构建业务层逻辑。这类工具包括容器及其管理部署工具，平台化微服务处理框架工具，音视频编解码处理工具，事务处理框架工具等。在这些框架工具之上进行业务功能开发，可以提高效率，降低开发周期，提高稳定性，在软件非功能属性方面有更好的扩展性和更大的灵活度。平台层之上一般就是业务层，但考虑到项目特性属性，我们补充了网络层和数据层。网络层提供统一的网络封装框架，该框架支持对有线网络、无线网络、移动网络、卫星网络等各种异构网络的支持，也支持相关的安全协议处理，用于构建适用于电网安全要求的专用通道。除了物理通道封装外，框架还支持数据层面的汇聚，基于冗余分片技术，构建虚拟数据传输通道，通过捆绑物理通道，实现逻辑层面的大通道，用于支撑上层业务对高带宽、高可靠性、低延迟通信的需求。数据层部分则构建支撑结构化和非结构化统一管理的数据存储框架。整合MySql关系数据库用于支持传统的表模式业务，比如会议管理、终端管理、用户管理、结构化采样数据管理（电压、电流、温度、频率、定位、各种事件等）；整合基于Hadoop及HDFS的大数据基础组件，用于支持各类数据采集业务的二次加工分析处理，比如电压、电流、温度、局放、各种开入、开出信号，还包括设备本身产生的一些数据，比如操作命令、事件上报等。对于过程中产生的日志、图片、音频、视频数据，也通过HDFS平台存储。网络层和数据层之上是业务层。当然分层也不是绝对的，部分业务其实不需要网络层深度接入，在微服务开发模式下，团队采取了灵活的构建方式，这类标准通用服务使用现有框架即可满足。对于音视频业务及其绑定的深度融合业务，通过网络层提供更好的带宽支持和异构环境支撑，便于整体系统的统一完整，很多代码可以复用，业务模式的编写也更加规范化。业务层之上就是展示层。在本系统中，业务层与展示层是分离模式实现，通过远程过程调用方式通信。功能展示既可以使用原生界面框架开发，也可以通过浏览器展示。我们不仅在平台侧、PC端实现展示层和业务逻辑层的分离，也在移动端和设备端共享了支撑代码框架，实现了层间分离。这也是进程通信体系结构风格的应用。

进一步到架构内部，对音视频流媒体的处理，是典型的管道过滤器风格。音视频流的处理有其规律特性，一般都是源端采集，然后进行编码压缩处理，之后传输，接收端在进行解压缩解码处理，最后还原输出。媒体数据流在整个链条上流动，很符合管道过滤器的风格特征。当然实际中，整个链条的处理不是这么单一的，编码压缩涉及不同的格式标准，解码解压缩也是一样，数据还可能存在融合要求，比如音频的混音，视频的多画面融合等。中间还可能存在二次编解码处理，进行录制、转码、再封装处理等。但是，无论如何变动，整个处理过程仍然是数据进入处理模块，流出后再进入下一个处理模块，这个结构关系、组织关系是不变的，因此管道过滤器的适用性是没有问题的，而且按这种方式实现，便于理解，便于代码维护，便于修改应对新的需求。

面向对象风格就更不用说了，整个系统就是面向对象设计的，这里的核心就是抽象。通过抽象和多态，极大的增强了系统应对变化的能力。在本系统中，最核心的就是数据流抽象，将音视频流和其他各类传感器采集的数据都抽象为数据流统一处理，使得整个代码处理框架统一高效。

最后就是事件系统体系结构风格的应用。这主要基于两个特性，一是系统中存在大量传感器设备，这类设备的数据获取，采用了事件风格。通过使用优秀的开源libuv事件库，使得各类传感器数据的获取变得简单且统一，避免了各类查询代码的泛滥。而且，通过异步事件库方式获取硬件设备数据，也能更加高效的利用CPU，降低CPU占用率，提升系统响应特性。进一步的，事件方式，通过统一回调接口获取数据，简化了系统设计实现，提升了稳定性。第二个特性是大量采用了异步调用的设计。基于这样的设计，虽然提升了效率，但是带来了逻辑实现的复杂度。为了解决这个问题，系统中同样采用了自研的各类事件统一管理框架库，统筹对系统中各类事件的处理，从底层的网络收发到上层的业务处理均是如此。采用这种风格，前期可能会有一些阵痛，主要是正向的调用流程会被打断，而且要对各种异常情况进行完善的处理，这类逻辑处理的增加一定程度上影响到了对工作逻辑的理解。但是借助框架的封装，上手后会觉得这种方式非常便利，对问题的关注点也会转移，更加注重业务逻辑本身的接口需求，而非传统的流程，在系统业务范围和接口需求膨胀时，其优势就越发明显的体现了出来。

当然，金无足赤，人无完人。任何方案、决策的拍板都是一个平衡、优化的结果。突出强化了这一点，就会在另一个方面显示弱化特性，对于架构风格的选择也是如此。对于事件系统体系结构风格来讲，上面的描述中已经提到了其缺点。前面其他风格的选择，也是如此，有优点，也有缺点。比如，对于数据流的抽象，虽然统一了代码处理风格、方式，复用了代码，简化了处理，但也在一定程度上影藏了差异。比如音视频流和传感器数据流就有明显的差异，一个是实时性要求较高的流，一个是没有那么高实时性要求的流，一个是可用偶尔丢弃一两包数据的流，一个是要求可达且只达一次的流。这种明显的差异，也给设计和实现带来了困惑，使得处理上与数据本身的特征结合的不够紧密，需要人为做一些转换操作，这是后续需要改进的一点。

最后再补充一点，对于系统平台层面、媒体层面、网络库部分，许多逻辑设计组装为构件，跨平台设计，可以重复应用，这在一定程度上也是构件连接件风格的应用。