系统架构设计师【论文-2015年 试题2】: 论软件系统架构风格（包括解题思路和经典范文）

真题题目（2015年 试题2）

系统架构风格（System Architecture Style）是描述某一特定应用领域中系统组织方式的惯用模式.架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的口软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。 请以“软件系统架构风格”论题，依次从以下三个方面进行论述：

• 1．概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。
• 2．分析软件系统开发中常用的软件系统架构风格有哪些？详细阐述每种风格的具体含义。
• 3．详细说明在你所参与的软件系统开发项目中，采用了哪种软件系统架构风格，具体实施效果如何。

论文解题思路

问题1要点：
简要描述所参与分析和开发的软件系统开发项目，包括：系统的背景、发起单位、目的、开发周期、交付的产品等。我的角色和担任的主要工作。

问题2要点：
分析在软件系统开发中常用的软件系统架构风格，详细阐述每种风格的具体含义。软件系统开发中常用的软件系统架构风格主要包括：

• 1. 管道和过滤器风格
     在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
• 2. 数据抽象和面向对象风格
     抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。
• 3. 基于事件的隐式调用风格
     基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
• 4. 层次系统风格
     层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现t由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。
• 5. 仓库风格
     在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行，仓库与构件间的相互作用在系统中会有大的变化。控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
• 6. C2风格
     C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：系统中的构件和连接件都有一个顶部和一个底部；构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；一个连接件可以和任意数目的其他构件和连接件连接；当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

问题3要点：
针对作者实际参与的软件系统开发项目，说明所采用的软件架构风格，并描述该架构风格所产生的实际应用效果。

经典范文赏析

摘要

本人于2022年1月参与浙江省某市公交集团"公交车联网一体化"项目，该系统为新能源营运车辆补贴监管、安全监控等方面提供全方位的软件支撑，在该项目组中我担任系统架构师，主要负责整体架构设计与中间件选型。

本文以该车联网项目为例，主要讨论了软件架构风格在该项目中的具体应用。底层架构风格我们采用了虚拟机风格中的解释器，因该公交共有几十种不同的数据协议，使用解释器风格可以满足整车数据协议兼容性需求。中间层关于应用层的数据流我们采用了独立构件风格中的隐式调用，这种风格主要用于减低系统间耦合度、简化软件架构，提高可修改性方面的架构属性。应用系统层我们采用了B/S的架构风格，统一解决公交行业性难题"实施推广难、维护难"问题。最终项目成功上线，获得用户一致好评。

正文

随着国家能源战略的深入和推广，该市公交集团自2022年1月起全面停止采购燃油机公交车，规划到2022年纯电公交车采购占比必须在70%以上，同时配套将车联网方面的系统建设列为工作重点。不管从新能源营运车辆补贴监管、安全监控或者公交公司自身的运营和机护需求，都要求有新的车联网系统对它们进行全方位的支持，而我司是该公交的主要仪表与can模块产品的主要供应商，全市4000多台车中有3000多辆是我司的产品，我司不仅掌握、熟悉该市公交整车数据，而且在车联网底层can数据有非常明显的领域知识优势，因此2020年1月我司被该市公交集团委托建设公交集团车联网一体化项目。本项目组全体成员共有27人(不含业务方)，我在项目中担任系统架构师职务，架构小组共4人，我的主要职责是负责整体架构设计与中间件选型，4月份完成架构工作，整个项目共耗时7个月，2022年8月顺利通过验收。

在架构工作开始阶段，我们便意识到，架构风格是一组设计原则，是能够提供抽象框架模式，可以为我们的项目提供通用解决方案的，这种能够极大提高软件设计的重用方法可加快我们的建设进程，因此在我司总工程师的建议下，我们使用了虚拟机风格、独立构件风格以及B/S架构风格这三种常用的风格。虚拟机风格中的解释器架构风格能够提供灵活的解析引擎，这类风格非常适用于复杂流程的处理。独立构件风格包括进程通信风格与隐式调用风格，我们为了简化架构复杂度采用了隐式调用风格，通过消息订阅和发布控制系统间信息交互，不仅能减低系统耦合度，而且还提高架构的可修改性。B/S架构风格是基于浏览器和服务器的软件架构，它主要使用HTTP协议进行通信和交互，简化客户端的工作，最终减低了系统推广和维护的难度，以下正文将重点描述架构风格的实施过程和效果。

底层架构我们使用解释器风格来满足整车数据协议兼容性需求。解释器风格是虚拟机风格中的一种，具备良好的灵活性，在本项目中我们的架构设计需要兼容好86种不同can数据协议，一般来说这种软件编写难度非常高，代码维护难度压力也很大，因此这个解释器的设计任务便很明确了，软件设计需要高度抽象、协议的适配由配置文件来承担。具体的做法如下，我们对各个车厂的can数据结构进行了高度抽象，由于can数据由很多数据帧组成，每个数据帧容量固定并且标识和数据有明确规定，因此我们将can协议中的ID和数据进行关系建模，将整体协议标识做为一个根节点，以canid作为根节点下的叶子节点，使用XML的数据结构映像成了有整车协议链——数据帧——数据字节——数据位这4层的数据结构，核心的代码采用jdom.jar与Java的反射机制动态生成Java对象，搭建一套可以基于可变模版热部署，这种可以将透传二进制数据直接映像成Java的可序列化对象，将数据协议的复杂度简化，后期数据协议更改不会对软件产生影响，仅仅更改协议模版文件即可，最终我们使用了86个协议描述文件便兼容了这些复杂的can数据协议，规避了can数据巨大差异带来的技术风险。

中间层我们使用独立构件风格中的隐式调用来简化构件间的交互复杂度，降低系统耦合度。主要的实现手段是，我们采用了一个开源的消息中间件作为连接构件，这个构件上apache基金会下的核心开源项目activemq，它是一款消息服务器，其性能和稳定性久经考验。由上文提到的解释器解析出对象化数据经过activemq分发到各个订阅此消息的应用系统，这些应用系统包括运营指挥调度、自动化机护、新能源电池安全监控等，这种多Web英语的情况非常适合采用消息发布与消息订阅的机制，能够有效解决耦合问题，我们在编码的过程中发现只要采用这种风格的Web应用，整个迭代过程效率极高，错误率极低，而且我们使用spring框架，消息队列的管理完全基于配置，清晰简单，维护性良好，例如整车安全主题、运营调度主题、机护维修主题等消息队列分类清晰，可以随时修改其结构，也能够随时增加其他主题的消息队列，不同的Web系统监听的队列也可以随时变换组合，基于消息中间件的架构设计能够让系统的结构话思路得到良好实施，总体来说，这种架构风格带来了非常清晰的数据流转架构，简化了编码难度，减低了项目二次开发的难度。

应用系统层我们主要采用B/S的架构风格，主要用于解决公交推广难、维护难的问题。公交行业有一个明显的特点，公交子公司分布在全市各个地区，路途很远，且都是内网通信，车联网也是走APN专网，一般是无法远程支持的，这给我们的系统推广以及后期维护带来了很大的难题，我们可以想象如果使用C/S架构更新客户端，一旦遇到问题很可能需要全市各个站点跑一遍。这让我们在系统推广和维护方面面临较大压力。我们采用B/S架构风格能够解决这个难题，并充分考量现在可用的相关技术成熟度，例如现在的HTML5完全能够实现以前客户端的功能，项目中我们使用了大量的前端缓存技术与Websocket技术，能够满足公交用户实时性交互等需求。这种风格中页面和逻辑处理存储在Web服务器上，维护和软件升级只要更新服务器端即可，及时生效，用户体验较好，例如界面上需要优化，改一下Javascript脚本或者CSS文件就可以马上看到效果了。

总结

项目于2022年8月完成验收，这1年内共经历了2次大批量新购公交车辆接入，这几次接入过程平稳顺利，其中协议解释器软件性能没有出现过问题，消息中间件的性能经过多次调优吞吐量也接近了硬盘I/O极限，满足当前的消息交互总量，另外，由于我们的项目多次紧急状态下能够快速适应can协议变动，得到过业主的邮件表扬。除了业主机房几次突发性的网络故障外，项目至今还未有重大的生产事故，项目组现在留1个开发人员和1个售后人员在维护，系统的维护量是可控的，系统运行也比较稳定。

不足之处有两个方面：第一，在架构设计的过程中我们忽略了PC配置，个别PC因为需要兼容老的应用软件不允许系统升级，这些电脑系统老旧，其浏览器不支持HTML5，导致了系统推广障碍。第二，在系统容灾方面还有待改善。针对第一种情况，我们通过技术研讨会说服业主新购PC，采用两台机器同时使用的方式解决。针对第二种情况，我方采用了服务器冗余和心跳监测等策略，在一台服务器暂停的情况下，另外一台服务器接管，以增加可用性。

更多内容请见： 备考系统架构设计师-核心总结索引