系统架构风格（System Architecture Style）是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。
请以“软件系统架构风格”论题，依次从以下三个方面进行论述：
- 概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。
- 分析软件系统开发中常用的软件系统架构风格有哪些？详细阐述每种风格的具体含义。
- 详细说明在你所参与的软件系统开发项目中，采用了哪种软件系统架构风格，具体实施效果如何。
试题出自试卷《2017年下半年系统架构设计师考试论文真题》
摘要
2018年9月，我所在的部门因公司业务发展需要，承担了公司的实时消息平台的研发工作。该平台提供了即时通讯、消息推送、社交圈等功能，满足C2C（用户对用户）、C2B（用户对商家）、B2C（商家对用户）的沟通需求，同时为公司内其它业务子系统间消息流转提供支持。我在该项目中担任系统架构设计师的职务，主要负责设计平台的系统架构和技术选型。本文以消息平台为例，论述了软件架构风格在项目中的应用，并阐述了选择层次结构、管道/过滤器和数据库系统三种架构风格在项目中组合应用的原因和效果，最后总结了在开发过程中遇到的问题及解决方式。实践证明，通过适当的架构风格选择和组合应用使开发工作取得了成功，消息平台于2019年1月验收上线，目前已稳定运行近2年时间，得到了领导和同事的一致认可和好评。
正文
随着移动互联网技术的迅猛发展，我所在的公司的在各业务子系统的开发过程中发现，用户、商户、客服之间进行沟通的需求越来越大，各业务子系统间进行消息流转的需求愈加频繁，且使用起来十分繁琐不便。为此，公司于2018年9月开始研发设计通用的实时消息平台（以下简称为“系统“）。该系统致力于为公司内各业务产品线提供基础通用的消息服务，降低公司内各业务子系统间进行信息交互的复杂度，满足C2C（用户对用户）、C2B（用户对商家）、B2C（商家对用户）的沟通需求。该系统为C端用户提供了私聊、群聊、密聊、聊天室、漂流瓶等多形式多场景的即时通讯功能，同时，该系统还支持公司内各业务子系统间进行消息流转，如B端商家通过该系统可以定向地为用户实时推送各种业务消息，如订单消息、活动促销消息等。本项目组全体成员共10人，我在里面担任系统架构设计师职务，主要负责项目计划制定，需求分析，整体架构设计与技术选型。下面，我将首先介绍软件系统开发中常用的软件架构风格及具体含义，然后详细介绍在“消息平台”的分析和设计过程中所采用的架构风格及原因。
在架构设计开始阶段，我意识到选择合适的架构风格对架构设计的重要性，因此在基本需求确定后，首先对常用的经典架构风格进行了分析：
数据流风格：数据以流的形式进行处理，构件之间相对独立，包括管道过滤器和批处理程序两种架构风格。它的特点是每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，产生输出数据流。优点是构件具有良好的隐蔽性、高内聚低耦合、维护简单、支持重用；缺点是不适合处理交互的应用。
调用返回风格：利用分治法思想，将大问题拆分为小问题解决。包括主程序/子程序、面向对象和层次结构三种架构风格。它的特点是将系统划分多个层组成一个层次结构，每一层为上层服务，并调用下层接口，优点是支持功能增强和软件重用，缺点是分层困难。
独立构件风格：每个构件都是独立的个体，构件之间不能直接通信，有效降低耦合。包括进程通信和事件驱动系统两种架构风格，它的特点是构件不直接调用过程，而是触发一个或多个事件后自动调用。优点是支持并发执行和实时/增量响应；缺点是放弃了对系统计算的控制。
虚拟机风格：虚拟机风格包括解释器风格和基于规则的系统风格，其具有良好的灵活性，可自定义规则。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用；缺点是执行效率较低。
数据仓储风格：由中央共享数据结构和独立构件构成。包括数据库系统、黑板风格和超文本系统三种架构风格，它的特点由中央数据源来保持当前数据状态，由独立构件对数据进行操作，优点是支持多种数据格式、扩展方便。缺点是需要一定的同步/加锁机制来保障数据结构的完整性和一致性。
软件架构风格可以为我们的系统提供架构级的通用解决方案，这种架构级的软件重用可以极大地提高系统开发效率。但是，单个架构风格的应用只能解决某一类问题，对于大型复杂业务系统往往需要多种架构风格混合并用。结合常用架构风格的适用场景和消息平台本身的业务特点，在本项目中我选择了层次结构、管道过滤器风格和数据库系统三种架构混合使用来满足系统要求。下面我将分别说明采用各架构风格的原因和具体应用：
分层架构风格，从提升系统的安全性、降低系统的开发和维护难度、保障系统的稳定性等维度考虑，我决定采用三层分层架构，将系统划分为接入层，逻辑层，数据层。其中，接入层负责处理来自客户端（PC/H5/App）的连接、断开请求，主要负责统一鉴权、保持长连接、初步攻防、加解密、压缩解压缩、限流等功能，接入层本身不含业务逻辑，它是无状态的，因此可以很方便地进行水平扩展。逻辑层，负责实现消息平台本身的核心业务逻辑处理，如私聊、群聊、密聊、聊天室、漂流瓶等业务场景，逻辑层还支持各个业务子系统接入到消息平台，实时推送业务消息给终端用户。数据层，负责提供数据存储访问服务，如数据库服务，缓存服务，文件服务，搜索服务等。
管道过滤器架构风格，消息平台中的核心业务逻辑是处理来自客户端发送的消息，其中，消息只有在接入层各组件校验通过后，才会转发到逻辑层进行后续处理，每一步的处理结果会带入到下一环节中，经过分析，以上特点符合管道过滤器架构风格。比如，在接入层中，用户发送的私聊信息，首先要经过解压缩过滤器得到压缩前数据，然后由解密过滤器解密出原始的消息内容，消息解析器得到符合我们平台消息协议的消息体，再经过限流器判断该发送者发送消息频率是否在正常阀值内，最后解析出消息中的接受者信息，根据接收者是否在线进行后续业务逻辑处理。从实际效果看，管道过滤器风格的应用，高效地解决了接入层中消息的解压缩、解密、限流等过程的性能问题，系统易于维护扩展。
数据库系统架构风格，消息平台中按照业务维度来划分主要有用户信息模块、群组信息模块、好友关系模块、即时通讯模块、消息推送模块等，为了保证业务处理的准确和及时，各模块间彼此需要共享数据，中央数据结构维护当前状态，业务逻辑组件在存储上执行操作，经过分析以上特点符合数据库系统风格。因该系统中各模块间数据存在大量复杂的逻辑关系，因此项目中使用了MySql关系型数据库。由于用户对数据的访问具有集中性，我们基于Redis实现了缓存服务，将用户访问频率较高的用户信息、群组信息、好友关系等置于缓存，减少对数据库的访问压力。从我们系统的业务特性来看，数据库操作是“读多写少”，所以我们对数据库进行了一主多从读写分离，提高数据访问效率，保障数据库服务的高可用。
结尾
实践证明，多种架构风格的组合应用，使系统模块间耦合度降低，增强了系统的可扩展性，提升了程序的稳定性和可靠性。2019年1月，该系统正式上线运行，至今已稳定运行了接近2年时间，满足了用户常用的即时通讯需求，同时为公司内各大业务子系统提供了稳定可靠的消息服务支撑，获得了领导和同事的好评。但开发过程中也遇到过问题，如我们接入层采用的负载均衡算法是加权轮转算法，过于简单，常常出现资源分配不合理的现象，可将算法改进为加权最小连接数算法来解决。在今后的工作中我将不断总结和提升专业技术能力，带领技术团队为公司业务保驾护航。
