【系统架构设计师-论文】软件架构评估

论软件架构评估在新媒体平台系统的实践

摘要

2021年12月，我所在的团队承接了某大学的媒体中心委托的《新媒体平台》的开发，我在项目中担任系统架构师，主要完成技术方案评估与实现，项目立项论证等工作。该系统以文章阅览功能为核心，分为文章搜索模块、用户评论模块、用户管理模块、社团管理模块等。本文结合作者的实践，以《新媒体平台》为例，讨论软件架构评估在项目中的具体应用。项目首先分析评估了软件架构种几个基础质量属性的具体含义。经讨论系统将采用MVC架构的设计方法，并在架构实现后采用基于场景的评估方式中的体系结构权衡分析法进行评估。评估过程中项目评估小组经过对系统的风险点、敏感点、权衡点的讨论生成了质量效应树。最终项目顺利上线并稳定运行，获得用户一致好评。

正文

随着移动信息化技术的迅猛发展，自媒体平台日益增多，各种平台之间的切换十分繁琐，每次都要在不同的平台发布同一内容，不利于媒体中心实时发布信息和全校师生阅览且不便于管理，而校官网又不便于发布日常文章。为了解决这一问题，校媒体中心制定了校园专属媒体平台战略，根据这一战略要求，新媒体平台（以下简称为“NMS”系统）应运而生，将全校院系社团的动态集中于该系统上，降低了全校师生对文章内容的检索难度，使师生可以快速准确地了解学校的最新动态。NMS系统以文章阅览功能为核心，分为文章搜索模块、用户评论模块、文章审核模块、用户管理模块等。文章搜索模块主要负责为用户提供检索文章的接口；用户评论模块负责对于各个文章中不同用户的评论内容的管理；文章审核模块允许管理员对申请发布的文章内容合法性进行审核；用户管理模块负责对以注册的用户信息进行管理；社团管理模块提供各院系社团管理自己发布内容的功能。2021年12月，我有幸参与了项目前期的一些工作，担任系统架构设计师的职务，主要负责设计平台系统架构和安全体系架构。

系统基于MVC架构进行开发，将系统划分为表示层、负载均衡层、控制层、持久层四个层级，并将各个模块根据其功能分别部署在不同的层面上。表示层使用vue框架实现，负责接收用户的输入数据以及将适当的数据显示给用户；负载均衡层采用了Nginx+LVS的技术实现对请求的分发处理，负责接收表示层发来的请求并根据轮询算法分发给控制层；控制层使用Redis进行分布式缓存处理，收到传来的请求后调用持久层的数据和数据处理接口响应相应的请求；持久层使用Mybatis+MySQL将数据进行存储和处理。最终将整个项目打包部署在docker容器上。

常用的架构评估方法有：基于问卷调查的评估方式、基于场景的评估方式和基于度量的评估方式。基于问卷调查的评估方式是由多个评估专家通过调查问卷的方式回答问卷中的问题，对多个评估结果进行综合，最终得到最终结果。其评价的具有主观性不太适合本项目。基于度量的评估方式虽然评价比较客观，但是需要评估者对系统的架构有精确的了解，也不太适合本项目。而基于场景的评估要求评估者对系统中等了解，评价比较主观，故本项目采用了基于场景的评估方式。基于场景的评估方式分为为架构权衡分析法ATAM，软件架构分析法SAAM和成本效益分析法CBAM。本项目中根据不同质量属性使用了ATAM作为系统架构评估的方法。在使用ATAM进行架构评估时，我们根据项目需要成立了项目评估小组。其主要成员包括：评估小组负责人、项目决策者、架构设计师、用户、开发人员、测试人员、系统部署人员、项目干系人等。我在这里的身份是项目的评估小组负责人和系统架构师。架构的评估经历了描述和介绍阶段、调查和分析阶段、测试阶段和报告阶段四个阶段。下面我分别从这四个阶段进行介绍。

评估小组成员在描述和介绍阶段的初始阶段并不是很熟悉所采用的评估方法，于是我先简单介绍了ATAM评估方法。它是一种基于场景的软件架构评估方法，对系统的多个质量属性基于场景进行评估。通过该评估确认系统存在的风险，并检查各自的非功能性需求是否满足需求。客户也交代了开发系统的目的和动机，该项目是为了实现校园信息的有效传递，整合全校各部门的动态信息，通过这个实时的信息丰富大学生的校园生活。我作为系统架构师描述了系统所采用的MVC架构并且讲解了系统各功能模块的部署关系，以及将其最终部署在docker容器中的决策。

调查和分析阶段，软件评估小组的成员基于各自的考虑对系统提出了多个要求。客户代表表示系统要保证具有良好的高并发高可用性，满足至少2万人的同时访问，系统一旦发生宕机故障必须在1分钟内恢复正常使用，此项优先级最高。在保证高可用的前提下，尽可能提升系统的性能，在用户发出请求后3秒内完成响应，该属性的优先级较高。安全分析人员提出：系统应该具有良好的容灾功能，系统一旦被攻击，数据将会发生大量丢失的现象。对于以上场景我们分析了开发过程中的风险点、敏感点和权衡点。该项目的风险点包括系统如果不能有效地阻挡攻击，数据将会丢失，破坏了完整性和一致性；系统中对消息的处理如果超过12小时，将会产生大量的消息积压。为解决这一问题我们在架构中额外增加了负载均衡层，并使用了容器技术完成了对可用性和性能的兼顾。敏感点有系统的高并发和可扩展性。权衡点有改变安全防护规则实现多重防护可以有效的提高系统防攻击的能力，但也会加大系统的开销，导致性能的降低。改变系统的加密级别对系统的安全性和性能都会产生影响。为了保证数据安全和系统容灾能力我们不得不改变原有架构中所采用的数据持久化方案。

在测试和评估阶段，所有风险承担者对需求优先级进行了票决，包括可用性、安全性、性能和可修改性。然而，它与我们最初的效应树存在一些不匹配的情况，这可能揭示了设计中的一些缺陷。首先，我们将可用性列为最高优先级，采用Docker容器和容器编排工具来实现高可用性。容器化使我们能够快速部署和水平扩展应用程序，而容器编排工具确保容器的健康状态和故障监测。然而，我们的设计没有充分考虑到容器编排工具在应对主节点故障时的选举过程和新主节点的升级可能会引入潜在的不稳定性,需要更多的测试来确保系统的高可用性。其次，就安全性而言，Redis混合持久化技术来确保数据的安全性和可恢复性效果很好，但仍需要关注数据备份和故障恢复的测试和演练。虽然我们可以依靠快照和AOF文件来恢复数据，但在实际应用中，这些机制的可靠性时刻影响着数据丢失的风险。同时，我们也需要考虑如何保证Redis服务器本身免受攻击的威胁，以确保系统的安全性。在性能方面.我们提到了混合持久化技术的性能优势,但对于快照生成的频率仍然需要进一步确定以避免对系统资源造成不必要的负担，确保系统在高负载下的稳定性。最后，使用Docker容器实现弹性伸缩来提供一定程度的可用性和性能。但在不同负载下动态调整容器数量和规模需要预设的规则和自动化工具的支持，我们需要确保这些规则的灵活性，以便根据不断变化的需求来修改系统。总之，在测试评估中出现的不匹配情况可以揭露架构设计中的缺陷，发现潜在的风险，提醒我们需要更加细致地考虑系统的各个方面，进行更多的测试和演练，以确保系统在各种情况下都能够稳定运行。

经过对架构的评估，确定了系统的风险点、敏感点、权衡点和非风险点，在报告阶段以文档的形式表现。其包括的内容包括：架构分析方法文档、架构的不同场景及各自的优先级、质量效应树、风险点决策、非风险点决策及每次的评估会议记录。

2022年6月，NMS系统正式上线运行，至今已稳定运行，获得了全校师生的一致好评。系统平稳经历了2次访问量激增、5次大量活动上线、等复杂运维状况，其中发生了3次主服务器宕机故障，但得益于系统的高可用性而平稳度过，获得了领导和同事的好评。