Day01-03｜1.1.3 软件架构的应用场景

教材版本：系统架构设计师教程（第 2 版）
教材章节：第 1 章 绪论 · 1.1.3
考试科目：综合知识、案例分析、论文
建议用时：120～150 分钟

一、学习目标

软件架构不是脱离业务环境的一套固定图形。同样的分层、服务化、消息或数据库技术，放在企业管理、实时控制、互联网交易、数据分析和嵌入式设备中，关注点完全不同。本节要建立“场景决定架构重点”的意识，学会从业务对象、交互方式、数据规模、实时性、可靠性、安全和部署环境分析架构。

完成本节后，你应该能够：

1. 识别不同应用场景的主要架构特征；
2. 根据场景提取架构驱动因素；
3. 解释为什么同一种技术在不同场景下会产生不同结果；
4. 设计场景到质量属性、架构措施和验证指标的映射；
5. 用案例分析语言说明方案适用性和边界。

二、应用场景为什么会改变架构

架构决策首先受系统目标和环境影响。一个内部办公系统可能更看重可修改性、权限和成本；一个支付系统更看重一致性、审计和可靠性；一个直播系统更看重低延迟、连接数和带宽；一个工业控制系统更看重确定性、实时性和安全攸关；一个数据分析平台更看重吞吐、存储扩展和查询能力。

如果忽略场景，架构师很容易犯两个错误：一是把成功案例中的技术原样复制，二是用单一质量属性评价所有系统。例如微服务能够支持独立部署，但小型内部系统采用微服务可能增加部署和运维成本；强一致数据库能够保证事务，但大规模分析任务直接使用交易库可能影响在线业务；消息队列能够削峰，但对必须即时完成的核心扣款流程不能简单全部异步化。

三、企业管理信息系统

企业管理系统包括人力、财务、采购、库存、客户和办公等应用。它们通常业务流程清晰、数据关联较强、组织角色复杂、合规和审计要求较高。架构重点往往是分层、模块化、权限控制、事务一致性、报表能力和长期可维护性。

典型结构是表示层、应用服务层、领域或业务层、数据访问层和基础设施层。表示层负责交互和输入校验，应用层编排用例，领域层承载业务规则，数据访问层封装存储，基础设施层提供数据库、消息、文件和外部接口。层次之间要保持依赖方向，避免把业务规则散落在页面和数据库脚本中。

企业系统的难点通常不在极端并发，而在流程变化、权限复杂、历史数据、跨部门协作和系统集成。架构设计应重视配置化、规则抽象、审计日志、主数据管理和接口版本。对于复杂审批，还要明确状态机、人工补偿和流程超时处理。

四、互联网交易与高并发系统

互联网交易系统面对用户规模大、流量波动明显、业务变化快和故障影响范围广等特点。架构重点包括水平扩展、缓存、限流、熔断、异步化、读写分离、分库分表、幂等、监控和灰度发布。

高并发并不只是增加服务器数量。首先要判断瓶颈是 CPU、内存、数据库、网络、锁、第三方接口还是线程池；其次要分析峰值是持续高负载还是瞬时尖峰；最后要区分核心交易和非核心后处理。商品详情可以使用缓存，订单创建需要可靠状态，短信通知可以异步，库存扣减则要根据业务一致性要求设计。

高并发系统常见的架构链条是：客户端或网关限流，负载均衡把无状态请求分发到应用节点，缓存承载热点读取，消息系统缓冲突发任务，数据库采用索引、读写分离或分片，监控系统采集指标和链路。每个措施都有代价，缓存会带来一致性问题，分片会增加跨分片查询难度，异步会引入最终一致性，限流可能影响用户体验。

五、实时系统与嵌入式场景

实时系统并不等同于“速度快”，而是系统必须在规定时间内产生正确响应。硬实时系统超过截止时间可能导致严重后果，软实时系统偶尔超时可能降低服务质量。实时系统需要关注响应上界、调度、优先级、资源竞争、时钟、故障安全和确定性。

嵌入式系统受到处理能力、内存、功耗、设备接口和环境条件限制，常常需要软硬件协同设计。架构不仅要描述软件模块，还要说明传感器、执行器、总线、操作系统、驱动、中断和任务调度之间的关系。安全攸关系统还要考虑故障检测、冗余、降级、失效安全和认证标准。

实时系统不宜简单套用互联网系统的无限重试和弹性扩容。无限重试可能造成任务堆积，动态资源调整可能破坏确定性。设计时要给出最大响应时间、任务优先级、队列容量、超时策略和故障状态。

六、数据密集型与分析系统

数据密集型系统的主要矛盾是数据量、数据增长速度、数据种类、访问模式和处理时效。数据仓库、数据湖、日志平台、推荐分析、物联网数据平台都属于这类场景。架构重点包括采集、传输、存储、计算、治理、质量和安全。

交易系统通常关注单笔事务的正确性和低延迟，分析系统通常关注大范围扫描、聚合、离线或流式计算。将二者分离，可以避免复杂报表影响在线交易，但会引入数据同步延迟、口径不一致、重复和丢失问题。架构师要设计数据血缘、主数据、质量校验、重放和对账机制。

流式处理关注事件时间、处理时间、乱序、重复、窗口和状态；批处理关注数据完整性、批次边界和失败重跑。题目出现“实时大屏”时，要问实时的定义是秒级、分钟级还是小时级；出现“数据最终一致”时，要说明最终由什么任务、状态机或对账机制保证。

七、云平台与分布式应用

云平台使计算、网络和存储资源能够按需申请和弹性调整，架构需要关注自动化、资源隔离、弹性、可观测性、持续交付和成本。云上系统要考虑区域、可用区、负载均衡、对象存储、托管数据库、容器编排、密钥管理和网络安全。

云并不能自动消除单点故障。若所有服务位于同一可用区，数据库没有备份，配置依赖人工修改，系统仍然脆弱。云原生架构更强调面向失败设计：服务无状态化、健康检查、自动恢复、弹性伸缩、配置外置、日志指标集中和发布可回滚。

云上架构还需要考虑成本这一质量约束。提高副本数可能增加可用性，也会增加计算费用；跨区域复制可以降低灾难风险，但会增加网络和存储成本；高规格数据库可以降低调优工作，却可能形成厂商锁定。案例题中写出成本、合规和团队能力，往往比堆砌云服务名称更有价值。

八、通信与物联网场景

通信系统和物联网平台通常具有设备数量大、连接长期保持、网络不稳定、协议多样和数据持续产生等特点。架构重点是连接管理、协议适配、设备身份、消息可靠性、边缘处理、数据缓冲和远程升级。

设备可能通过不同网络和协议接入，不能让业务服务直接理解所有协议。通常需要接入层或协议适配层统一设备模型，再将设备事件传给业务服务和数据平台。网络短暂中断时，要设计本地缓存、断点续传、重试和离线状态；设备固件升级要支持版本控制、灰度、失败回滚和安全校验。

九、场景分析方法

面对任何应用场景，可以使用“六问法”：系统服务谁？核心业务对象是什么？数据从哪里来、到哪里去？最重要的质量属性是什么？故障会如何影响业务？未来变化最可能发生在哪里？

然后建立映射：

十、案例分析

某城市停车平台需要接入摄像头、停车场闸机和支付平台。车辆进出事件要在数秒内更新，支付平台偶尔超时，管理部门每天需要生成统计报表，未来还要接入更多厂商设备。

参考答案

该系统同时具有物联网接入、实时交易、外部集成和数据分析特征，不能使用单一架构处理全部问题。设备接入采用协议适配层和统一设备模型，屏蔽不同厂商接口；车辆进出事件进入事件总线，由停车状态服务处理，必要时在边缘侧进行预处理；支付调用设置超时、有限重试、幂等流水号和人工补偿，支付结果通过验签回调更新状态；统计数据通过事件或数据同步进入分析库，避免直接扫描交易数据库；新增厂商通过适配器和契约测试接入。

关键质量属性包括实时性、可靠性、可用性、可扩展性和安全性。实时性要用端到端事件延迟验证，可靠性要测试重复事件、乱序和断网恢复，可用性要测试支付超时和单节点故障，可扩展性要测试新增设备类型和数据增长，安全性要验证设备身份、接口授权和支付回调验签。

十一、综合知识练习

1. 为什么企业管理系统常重视可维护性和权限？
2. 高并发系统为什么需要识别瓶颈而不是盲目扩容？
3. 实时系统和普通高性能系统有什么区别？
4. 为什么交易库和分析库通常分离？
5. 云平台为什么不能自动保证高可用？

参考答案

1. 企业规则和组织权限复杂且变化持续，系统生命周期长，必须控制变更影响和数据访问。2. 瓶颈可能在数据库、锁、网络或第三方接口，应用节点扩容不一定解决真正问题。3. 实时系统强调在规定截止时间内完成，关注响应上界和确定性；普通高性能系统可能只关注平均速度和吞吐。4. 两者访问模式不同，分析扫描会影响在线事务，分离后需要设计同步和数据质量机制。5. 单区域、单数据库、人工配置和缺少恢复演练仍会形成单点，云资源只是基础能力。

十二、论文素材

可以积累“复杂物联网平台架构设计”“高并发交易系统架构优化”“企业系统渐进式改造”三个主题。写作时先描述场景和规模，再提取质量属性，说明为什么采用分层、适配器、事件、缓存、数据分离或边缘处理，最后写测试指标和实施效果。不要把不同场景的技术混成清单，要说明每项技术对应的业务问题。

十三、今日复盘

请闭卷回答：为什么架构必须结合应用场景？企业应用、互联网交易、实时系统、数据分析和物联网分别最关注什么？如何使用“场景事实—架构驱动因素—设计措施—验证指标”完成案例分析？