论软件系统架构评估及其应用

摘要

  2021年3月，我参与了某金融科技公司的基金网上交易系统的开发工作，该系统旨在为不同层次的客户提供优质的在线挑选和购买基金的服务，包括开户、风险评测、交易、资产明细查询、电子合同签署等功能。我在项目中担任系统架构师，主要负责系统的架构设计和技术选型。本文以基金网上交易系统为例，主要论述了项目中涉及到的软件系统架构评估及其应用。系统整体采用微服务架构，我们选用架构权衡分析法ATAM对架构进行了评估，评估过程共分为四个阶段进行。首先是描述与介绍阶段，对ATAM、项目需求和关键质量属性进行了介绍；接着是调查与分析阶段，构件了质量效用树；然后是测试阶段，评估了各场景下架构是否满足关键质量属性；最后是报告阶段，产出了全量的评估报告。系统最终顺利上线，取得了用户的一致好评。

正文

  近几年来，基金市场逐渐变得火爆，部分基金的管理规模突破千亿大关，购买基金的人也越来越多。鉴于业务量的暴增以及行业新规的不断发布，我司现有的基金网上交易系统已无法满足客户需求，于是在2021年3月决定对系统进行升级改造。原有系统采用单体架构，包括开户、风险评测、交易、资产明细查询、电子合同签署等功能，但业务功能模块耦合严重，修改某一功能时往往涉及到多个模块，工作难度大，且单一功能模块很难在水平方向上扩展，系统每次发版变得十分“厚重”。经过讨论与分析，我们决定采用微服务架构对项目进行升级改造，并使用架构权衡分析法对系统架构进行了评估。
  软件系统架构评估主要关注系统的质量属性，包括性能、安全性、可用性、可修改性、可测试性、易用性等。其中性能指系统处理请求的速度；安全性指系统保证正常用户合法访问的同时拦截非法访问的能力；可用性指系统在一定时间内正常运行的时间比例；可修改性指在成本限制下对系统进行修改的难易程度；可测试性指软件发生故障后快速定位故障的能力；易用性指从用户角度使用系统的难易程度。传统的架构评估方法主要包括问卷调查法、专家分析法、基于场景的架构分析法SAAM、架构权衡分析法ATAM等。其中，问卷调查法指通过向系统用户发送调查问卷的方式收集用户满意度以评估质量属性是否被满足；专家分析法指邀请领域的行业专家对系统进行评估；SAAM接受文档输入，以场景为中心，主要关注系统的可修改性；ATAM在SAAM的基础上改进而来，主要关注系统的性能、安全性、可用性和可修改性，在系统开发前对质量属性进行权衡取舍。系统架构设计完成后，我们按照ATAM的四个阶段依次执行了系统架构的评估工作。
  1、 描述和介绍阶段
  在描述和介绍阶段，首先由评估小组的负责人介绍了架构权衡分析法ATAM的基本概念，大致步骤和评估目标。然后由项目经理介绍了系统的业务需求和几个关键质量属性，基金网上交易系统的首要目标是合规的前提下提供优质的在线挑选和购买基金的服务，主要关注的质量属性是可用性和安全性，同时由于金融行业的强监管特性，合规要求始终放在第一位，故可修改性同样十分重要。最后由我作为系统架构师介绍了系统采用微服务架构进行升级改造的原因，以及各类中间件技术选型的优势。
  2、 调查和分析阶段
  在调查和分析阶段，我进一步对系统架构进行了拆分和详细介绍，并根据需求识别了不同关键质量属性的场景，构造了质量属性效用树。我们主要关注四种质量属性，分别是性能、安全性、可用性和可修改性。具体的，在性能方面，要求系统在正常负载情况下，访问基金列表和详情页面的时间不超过3秒，交易下单的响应时间不超过1秒；在安全性方面，要求系统对用户进行授权访问控制，身份证、手机号、密码等敏感信息需加密存储，并能抵御常见的CSRF攻击、DDoS攻击和SQL注入攻击等；在可用性方面，要求系统能提供24小时不间断的服务，在出现故障后5分钟内能切换到备用系统或恢复运行；在可修改性方面，要求当合规条件发生变化时，系统能在10人月内完成修改。
  3、 测试阶段
  在测试阶段，我们首先组织了头脑风暴收集尽可能多的场景，然后通过投票的方式对总结出的质量属性进行了优先级排序，最后根据场景按优先级分析系统架构是否满足质量属性。针对各质量属性，我们采取了不同的策略。例如，在性能方面，我们通过引入Redis缓存与，加快了获取基金列表和详情的速度，交易时使用异步下单，优先响应用户操作；在安全性方面，我们使用JWT技术实现了授权访问，使用AES算法对敏感信息加密后存储，通过自定义知识库抵御CSRF攻击；在可用性方面，我们使用双机热备技术，每个服务均同时部署在两个服务器上，当主服务器故障宕机后，从服务器能自动检测并完成替换操作；在可修改性方面，我们通过遵循面向对象思想，引入良好的设计模式进行编程，提高了程序的可读性和可扩展性。
  4、 报告阶段
  在报告阶段，我们详细记录了每次评估会议的内容并存档，并最终产出了一份评估报告。报告详细描述了系统对各质量属性的要求，以及在不同场景下系统架构对质量属性的满足程度。报告还包含了识别出的系统架构的风险点、敏感点和权衡点。例如，由于微服务架构天生的分布式环境，使得系统排查故障的难度较高，这是一个风险点；每个服务若选用了不当的设计模式进行编程，都会对系统的可修改性造成影响，这是一个敏感点；若要将加密算法换为安全性更高的非对称加密算法RSA，可能会对系统性能造成影响，这是一个权衡点。
  历时10个月的开发，系统最终于2022年1月正式上线，目前仍在正常运行，并受到用户的一致好评。在项目实现过程中，我们也遇到了一些问题。例如分布式环境下的分布式事务问题，我们通过引入开源的Seata框架，使用侵入性较低的AT模式，尽可能少地修改业务代码，借助经典的二阶段提交法解决了该问题；又例如接口幂等性问题，尤其是交易类接口，我们不仅在前端进行了一定地拦截，后端也进行了处理。通过拼接用户标识、接口标识与序列化入参得到唯一标识，存入Redis并设置过期时间，使用唯一标识拦截重复请求从而解决了该问题。
  实践证明，一个系统的稳定运行离不开良好的架构，这更突显了软件架构评估工作的重要性。通过本次对微服务架构的应用，以及架构评估的过程，使我加深了对软件架构的理解，也加强了自身面对未来各种技术挑战的信心。