软考：软件架构风格与论文模板
一、质量属性：敏感点与权衡点
- 敏感点：为了实现某种特定的质量属性，一个或多个构建所具有的特性
- 权衡点：影响多个质量属性的特性，是多个质量属性的敏感点
二、软件架构风格
1. 数据流风格
批处理风格
- 场景：日志处理、每日的数据清洗
- 优点：实现简单、便于调试、可处理大批数据
- 缺点：实时性差、资源利用率低
管道-过滤器
- 优点：并行可插拔、易维护、可拓展
- 缺点：不适合交互、单向数据流不适合复杂业务系统、IO 传输有性能开销
- 场景：Unix 命令、编译器、音频处理、数据流处理
2. 调用/返回风格
主程序/子程序
- 场景：小型软件
- 优点：结构简单、开发成本低、易理解
- 缺点：耦合度高、拓展性差
层次
- 定义：每一层根据职责不同划分不同的层次，下层为上层提供服务，上层仅依赖下层，禁止跨层调用或反向依赖
- 场景：MVC 架构
- 优点：可维护性高、易分工开发
- 缺点：多层交互性能消耗大、多层冗余
面向对象
- 定义：将数据（属性）和操作数据的逻辑（方法）封装成对象，对象之间通过显式调用进行交互，支持继承和多态
- 场景：大型系统
- 优点：高内聚低耦合，可维护性强
- 缺点：调用产生性能损耗
C/S
- 定义：由客户端和服务器组成，客户端负责发送请求，由服务端统一处理请求
- 场景：移动 APP
- 优点：职责清晰、资源利用高
- 缺点：可维护性差、维护成本高
3. 以数据为中心
仓库
- 定义：以中心数据仓库为核心，组件间的交互通过读写仓库实现。仓库通常是结构化存储，组件通过标准化接口操作仓库
- 场景：强调数据一致性的场景，订单、政务系统
- 优点：数据一致性强、数据可复用、易修改
- 缺点：单点问题突出、仓库成为性能瓶颈
黑板
- 定义：以全局共享数据区为中心，各知识源通过读写黑板实现异步通信。黑板存储问题的状态和中间结果，知识源根据黑板状态自主决定操作黑板，知识源无需直接交互，由控制模块控制知识源的执行顺序
- 场景：复杂问题、不确定问题、语音识别、股票预测
- 优点：较灵活、无固定流程、适合复杂问题
- 缺点：逻辑复杂、性能消耗高、调试成本高
4. 虚拟机风格
解释器
- 定义：通过虚拟执行环境（虚拟机），解释自定义语言，将高级语言/脚本转换为机器码并执行。虚拟机屏蔽了底层硬件差异，使得程序可以在不同操作系统运行
- 场景：脚本、JVM
- 优点：灵活、跨平台、开发高效
- 缺点：性能低、执行效率低、消耗高
规则系统
- 定义：通过规则集定义业务逻辑，通过规则引擎将输入匹配为动作并执行，实现业务逻辑与代码分离，规则可动态增删改，无需修改核心程序
- 场景：业务频繁更新的系统、专家系统、业务复杂系统
- 优点：易维护、逻辑透明
- 缺点：表达有限、冲突难处理、性能瓶颈
5. 独立构件风格
进程通信
- 定义：由多个相互独立的进程（构件）组成，进程间通过标准的通信协议交互，无共享内存，有自己独立的上下文和空间
- 场景：分布式系统（RPC、HTTP）、跨平台协作
- 优点：高可用、扩展性
- 缺点：性能低
事件系统
- 定义：以事件为中心，通过“发布-订阅”的方式进行交互，生成者将事件发布在订阅总线上，消费者根据总线订阅进行消费，构件之间无直接调用
- 场景：异步通讯
- 优点：异步、解耦
- 缺点：顺序性、一致性
三、论文模板
论文按“概述 + 三个论点 + 总结”五段式展开，下面先把通用模板句式归拢到一起，再给出完整范文。
通用骨架与模板句式
1. 概述
[xxx] 年，我参加了某公司的 [xxx（自己熟悉的，电商、医疗等等）] 项目，该项目耗时 [xxx] 月，投资 [xxx] 元，该项目旨在解决 [与之前项目相关的问题，随便写] 问题，我在该项目中担任系统架构设计师，负责【题目相关模块】的开发和管理。本文以该项目为例，从【题目相关角度，比如云数据库、秒杀、软件测试】进行论述，计划从 1.【项目整体概述，切题点 1】2.【切题点 2】3.【切题点 3】几个角度（可对题目进行适当补充，添加自己的理解）进行论述。再说一下项目上线后的收益等等。
2. 论点过渡句
本项目正是以该框架推动【xxx】的具体实现，将【xxx】分为多个迭代周期，每个迭代周期完成风险最高的一部分。
3. 总结句
该项目验证了合理的【xxx】在业务系统复杂、业务需求多变的情况下的价值，合理的【xxx】既是系统稳定运行的基石，更是业务持续发展的保障。我深刻地意识到：任何技术方案没有银弹，必须立足业务实际需求，在质量、效率与成本之间持续权衡；方案落地后的度量验证与复盘改进，与方案选型本身同等重要。
范文：互联网智慧医院项目的性能测试
概述
患者在复诊时要先到医院进行挂号排队，复诊后还要拿着复诊单进行线下取药，平均单次复诊的耗时为半天。在 2024 年用户满意度调查中，收到了超过约 42% 的用户反馈的“流程慢”问题，且该情况在 2025 年持续恶化。为响应国家“互联网+”的号召，该医院于 2025 年底启动互联网智慧医院项目，投入约 40 万资金，一期预期开放预约挂号、在线问诊、电子处方、在线缴费、药品配送、报告查询六大业务，首期接入临床科室约 32 个，并预留市电子医保、区域档案平台的对接能力。
随着互联网应用规模化、业务场景复杂化，系统在高并发、大数据量场景下的性能表现直接影响用户体验与业务连续性——响应延迟、并发处理能力不足、资源耗尽等问题可能导致用户流失或重大业务损失。项目采用前后端分离模式，后端采用 SpringCloud 微服务架构，服务间基于 RPC 通信，并利用 Redis 建立缓存，使用 MySQL 作为数据持久层，前端使用 React 框架以及 Ajax 进行前后端交互，经过多轮测试，利用 K8s 搭建集群，并搭建 CI 持续流水线，部署于政务云。本人在项目中担任系统架构设计师，负责整个测试链路的搭建，包括性能测试的各类方法、指标基线，主持召开多轮用例评审，并负责整个微服务链路的设计编排，带领 20 余人的团队完成整个立项到上线全流程。
论点一：敏捷开发模式下的迭代测试策略
本项目使用敏捷开发作为开发模型。敏捷开发以迭代、增量的形式进行交付，强调反馈变化优于遵循计划。项目整体采用 Scrum 模式，利用待办需求表推动迭代，每两周为一个迭代周期，依次展开计划会、每日站会、评审会、回顾会。敏捷开发适用于需求不断变更的场景、需要及时反馈，其核心价值在于压缩反馈环路——反馈在两周内到达，而非一个月。本项目正是以该框架推动性能测试的整体实现，将测试节奏分为多个迭代周期，每个周期优先进行风险最高的测试。
论点二：测试的分级落地
本项目采用分级测试体系，搭建测试金字塔：底层为单元测试——主要针对单个函数的正确性；中层是接口契约测试——主要针对接口设计规范，未通过测试则回滚；上层为端到端的系统测试和性能测试——主要为模拟项目可能遇到的生产情况，根据指标基线对系统进行整体性验证；最后是灰度测试以及 A/B 测试——对新增或更新的功能模块进行的小流量真实测试。在 A/B 测试时，利用哈希算法，动态将对象分为被测试版本和新版本，在相同周期内检测核心指标，利用统计显著性验证排除数据抖动，通过对比核心指标，监控错误率、超时率，确保变量可重放可回退。对比结果形成后反馈至需求列表，推动下一轮迭代目标的产生，形成了“迭代——测试——放量——对比——迭代”的核心迭代链路。在本项目中，我们对预约挂号、在线问诊模块连续灰度放量了两周，在没有系统异常后全量发布。
论点三：流水线持续集成
本项目采用持续集成流水线。持续集成（CI）是指开发人员频繁将代码合入主分支，每次合入都自动进行验证与构建的工程实践。我们将流水线分为五个步骤：提交触发——代码在提交后自动触发编译和打包；静态检查——自动对代码进行圈复杂度检查，未通过则阻断检查；自动测试——自动进行单元测试和接口契约测试，未通过则发送通知；自动部署——代码自动发布至测试环节并进行冒烟测试；一键回滚——生产发布采用蓝绿发布机制，出现异常实现分钟级回滚。该实践使缺陷在引入当天被发现，版本发布由原先的一月一发优化至一周两发，发布效率显著提高，发布过程中的异常率由原先的 49.2% 下降至 6.1%，显著提高发布质量。
总结
经过 9 个月的建设，项目按预期上线，收获用户一致好评。该项目验证了合理的性能测试在业务系统复杂、业务需求多变的情况下的价值：合理的性能测试既是系统稳定运行的基石，更是业务不断演进的保障。我深刻地意识到：任何技术方案没有银弹，必须立足业务实际需求，在质量、效率与成本之间持续权衡；方案落地后的度量验证与复盘改进，与方案选型本身同等重要。
项目也曾出现不足。其一，项目初期曾存在职责模糊不清的现象，后经三轮评审才矫正，反映了团队对新方案的经验尚显不足；其二，测试用例文档中对压力测试模块的吞吐量颗粒度表述不清，给项目进行压力测试埋下了隐藏的沟通成本，后续将“低、中、高”等模糊的需求描述改进为明确的数值；其三，运维同学的时间有限，灰度上线的排期被迫拉长，导致项目整体进度不符合预期，后续我引入了 CI 流水线自动部署上线，将发版转入自动化流程中，持续提高了代码发布的效率和质量。
