本论文结合作者的实践，论述了软件系统的架构评估。首先介绍了软件架构评估普遍关注的质量属性，并阐述了其中性能、可用性、可修改性、安全性的具体含义。本系统采用了层次架构结合SOA的模式，基于场景的评估方式中架构权衡分析方法ATAM进行架构评估，并详细描述了其评估过程，项目评估小组经过讨论生成了质量属性效用树，并分析了项目的风险点、敏感点、权衡点。通过合理的系统架构设计与实现，系统顺利发布，并持续迭代运营，累计C端用户两千多万，得到用户的好评与团队的认可。

正文

项目背景

移动互联网时代，用户对活动需求持续增长，但活动供需信息不对称，公司决定研发综合性活动平台，为中小微企业提供活动组织发布服务，同时为用户提供更丰富的活动搜索服务。

项目概述

平台主要应用有：官网站点群、活动管理系统、运营管理系统、活动搜索服务（App、公众号、小程序等终端）。平台支持多种活动类型，比如报名、预约、投票、抽奖、小游戏类营销等活动。

平台围绕活动提供以下服务：纵向上为B端用户主办方提供活动发布与管理服务，同时为C端用户提供全端活动搜索服务；横向上为B端用户提供不同类型的活动服务，如报名、投票等活动，同时为C端用户提供不同模板的活动呈现服务；运营管理系统提供运营管理中台服务，负责业务中台与数据中台配置管理，比如审核、统一配置、消息、客服、智能推荐、财务、日志分析、风控配置等。由于篇幅原因，不再细化功能介绍。

使用技术栈

考虑平台更倾向于移动端用户，且主要围绕微信生态，出于快速迭代快速验证的目的，采用成熟的lanmp体系，基于阿里云ecs集群，基于nginx的负载均衡SLB，在框架上选择了ThinkPHP框架、使用redis cluster分布式缓存、数据库采用阿里云DRDS云数据库、前端资源打包到云端CDN、使用阿里云消息队列MQ实现消息异步等

架构评估

架构评估中质量属性与含义

架构评估是软件开发过程中的重要环节，在软件架构评估中的质量属性有：性能、可用性、可修改性、安全性、可测试性、可靠性等，其中前4个是质量属性效用树的重要组成部分。

性能

是指系统的响应能力，即系统经过多长时间响应事件或一定时间内系统处理事件个数。
可用性

是指系统能够正常运行的比例，通过两次故障之间的时间长度或出现故障时系统能够恢复的速度来表示。
可修改性

是指系统能以较高的性价比对系统作出变更的能力。
安全性

是指系统能够向合法用户提供服务，同时拒绝未授权用户的使用或拒绝服务的能力。

常用的架构评估方法

常用的架构评估方法有：基于问卷调查的评估方式、基于场景的评估方式、基于度量的评估方式。

基于问卷调查的评估方式

是由多个评估专家通过问卷调查的方式回答问卷中的问题，对多个评估结果进行综合衡量，最终得到评估结果。其结果很大程度来自评估人员的主观推断，且对项目熟悉不足，不适合本项目。
基于度量的评估方式

虽然评价比较客观，但需要评估者对评估的架构十分的了解，否则不能获取准确的度量，也不太适合本项目。
基于场景的评估方式

只要求评估者对系统一定程度的了解，讨论和评价相对主观，由于这个项目需要从不同的角色得到对不同质量属性的意见和建议，所以我们采用基于场景的评估方式。

基于场景的评估方式又分为架构权衡分析法ATAM、软件架构分析法SAAM、成本效益分析法CBAM。本项目根据不同的质量属性采用ATAM作为系统架构评估方法。

评估过程

在评估过程，我们根据实际情况成立了评估小组。主要成员包括：小组负责人、项目决策人、用户代表、系统架构师、开发运维、测试人员、产品运营等相关负责人。我在小组中承担小组负责人与架构设计负责人。下面我们把ATAM评估的9个步骤归划分为4个阶段：描述介绍、分析架构、场景分级、评估结果。

在描述介绍阶段，我们介绍了ATAM方法，ATAM是基于场景的软件架构评估方法，对系统的多个质量属性基于场景进行评估，通过该评估确认系统存在的风险，并检查非功能性需求是否满足用户需求；同时描述了系统的目的和业务动机，项目通过为中小企业提供活动发布与管理服务，同时向C端用户提供全端活动搜索服务，同时提供部分付费服务，并获取流量导量到其他服务产品；最后我述了系统将采用的层次架构结合SOA思想的架构风格，并将系统进行应用拆分，并讲解各个应用与服务。

在分析架构阶段，B端用户代表提出：资金安全与快速提现问题，这是活动闭环的一个重要环节，优先级较高，我们考虑采用微信认证及微信企业支付保证资金安全并可随时提现；C端用户提出：用户重要操作需要得到消息通知，比如报名、支付退款、修改等；运营指出：活动富文本内容要求进行审核，建议系统初步自动审核，之后过滤分类人工复审，提高内容审核效率，内容安全优先级较高，我们考虑接入第三方易盾服务解决内容安全等问题；开发人员提出：注册登录短信容易成为攻击漏洞，建议应用前后端对称加密组件或人机验证组件，另外为了提高易用性，建议内容编辑器支持素材、模板拖拽自由组合方式等；经过该阶段的总结，我们得到了一份质量属性效用树。

针对提出的场景及质量属性效用树，我们分析了项目的风险点、敏感点、权衡点。经过分析，罗列项目中存在的一些风险点：如果没没有严格验证自助提现，将有可能导致资金流失；后期用户量剧增时，同步消息通知将会产生消息积压导致性能下降。敏感点：前后端加密组件及人机验证组件、编辑器支持素材模板拖拽组合方式；权衡点：由于提现没有经过人工审核，用户自助提现，存在较大风险，但为了功能特色吸引用户，在保证尽量安全的情况下，限制用户一定时间允许提现一定额度；平台内容自动审核规则严格程度决定活动的高质量，同时容易“误杀”活动，让B端用户产生反感。

在场景分级阶段，经过评估小组集体讨论后，确定了不同场景的优先级：系统可用性最高、安全性次之、再考虑性能和可修改性。在可用性方面，系统采用云服务集群，通过SLB检查异常及提供负载均衡，数据层同时准备数据库主备与缓存集群与主备方案，避免每一层出现单点故障导致整体服务中断。在安全方面，服务总线及外部回调统一采用加密与签名保证数据机密与完整性，应用层用户授权引入JWT，部分结合第三方授权认证保证用户数据安全。性能方面针对可能存在的瓶颈，从前端到后端每个环节优化，如引入CDN资源部署、负载均衡、应用层缓存、服务层消息队列、数据库读写分离、索引优化等

最后评估结果阶段，整理给出评估报告，最后以文档的形式表现。其内容包括架构分析方法文档、架构的不同场景及各自的优先级、质量属性效用树、风险点决策、非风险点决策及每次评估会议记录。

总结

项目经过内部多次版本迭代，经过2年多的补充与完善，累计C端用户两千多万，得到用户的好评和团队的认可。通过这个项目，我们实在的感受到软件系统架构评估的重要性，也感受到随着业务需求的增多和变化，给架构带来了各种各样的挑战，而通过合理的的软件架构，提高了系统的可维护性、可扩展性、可复用性，间接提高了开发维护效率、运营效率，同时降低各方面成本，加速了团队成长及产品验证速度。

论系统架构评估

目录

摘要

正文