Day01-01｜1.1.1 系统架构的定义及发展历程

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

一、学习目标

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

1. 用自己的话解释系统架构、软件架构和系统架构设计；
2. 区分架构、详细设计、技术栈和部署方案；
3. 理解架构从单体、分层、分布式到云原生演化的主要原因；
4. 从业务规模、质量属性和约束条件分析架构演化；
5. 在综合知识、案例题和论文中准确使用“结构、行为、视图、决策、权衡”等关键词。

二、为什么要先学“架构定义”

系统架构设计师的考试并不是技术产品记忆考试。题目可能出现数据库、网络、云平台、消息中间件、微服务、嵌入式系统或安全架构，但这些内容背后都在考同一个问题：如何在需求和约束下组织系统，使系统达到预期质量。

如果没有架构概念，学习者很容易把“使用某个框架”当成架构，把“画了一张模块图”当成设计，把“系统能运行”当成质量合格。第 1.1.1 节要建立的基础认识是：架构描述的是系统中具有全局影响的结构、关系、行为和决策。

三、系统架构的基本含义

系统架构可以理解为系统的总体组织方式。它回答系统由哪些部分组成、这些部分如何协作、数据和控制如何流动、系统如何部署，以及系统如何满足性能、可用性、安全性和可维护性等要求。

软件架构通常包含四个基本要素：

构件不是越细越好。拆成几十个服务不一定比三个清晰模块更优秀；连接件也不是越先进越好，同步调用、异步消息、文件交换各有适用边界；约束是架构的重要组成部分，没有约束就没有可验证的结构规则。

四、架构与详细设计的区别

架构关注会影响系统整体的决策，详细设计关注局部实现。比如“订单服务与库存服务通过事件通信”属于架构决策，因为它会影响一致性、故障处理、监控和部署；“订单对象使用哪个字段保存备注”通常属于详细设计。

但架构和详细设计不是完全隔离的。一个看似局部的选择，如果会影响多个模块，就可能上升为架构问题。例如统一异常格式、全局身份认证、主数据编码、日志追踪标识和事务边界，虽然可以在代码中实现，却会影响整个系统的协作方式。

判断一个问题是否属于架构问题，可以问三个问题：是否影响多个组件？是否影响关键质量属性？后期修改是否会造成较大范围返工？如果答案为“是”，就应在架构层面记录和评审。

五、架构是结构，也是行为

静态结构描述系统有哪些模块、层、节点和数据存储；动态行为描述请求如何流动、组件如何调用、消息如何传递、故障如何传播和系统如何恢复。只画静态结构而不说明运行行为，无法回答高并发、超时、重试和故障切换问题。

以支付系统为例，静态结构可以包括订单服务、支付服务、账户系统和消息系统；动态行为则要说明用户提交订单后如何创建待支付状态，支付请求超时如何处理，第三方回调乱序如何校验，重复回调如何幂等，最终状态如何对账修复。

因此，架构说明至少需要包含：

1. 逻辑视图：职责和模块如何划分；
2. 开发视图：代码、组件和团队如何组织；
3. 运行视图：进程、线程、并发和通信如何发生；
4. 部署视图：服务部署在哪些节点和网络区域；
5. 场景视图：关键用例如何穿过各个组件并验证设计。

六、架构发展历程

架构演化不是简单的技术潮流替换，而是业务规模、质量要求、组织方式和基础设施变化共同作用的结果。

1. 单体和主程序/子程序

早期系统常把功能集中在一个程序中，由主程序调用多个子程序。优点是调用简单、事务边界清晰、部署容易；缺点是模块之间容易形成隐式依赖，修改和发布影响范围大，难以独立扩容。

2. 分层架构

分层架构按职责组织系统，例如表示层、业务层、数据访问层和基础设施层。它通过依赖方向和接口约束降低复杂度，适合业务规则较稳定的企业应用。问题在于层次过多会增加调用链，边界不清会造成业务逻辑泄漏。

3. 客户机/服务器和分布式架构

当终端数量增加、数据需要集中管理时，系统将交互和服务拆到客户端与服务器。进一步地，计算、存储和网络资源分布在多个节点，形成分布式架构。分布式架构带来扩展能力和资源共享，也引入网络延迟、部分失败、时钟差异、数据一致性和运维复杂度。

4. 面向服务和微服务

面向服务强调把业务能力封装为可复用服务，通过标准契约进行协作。微服务进一步强调独立部署、独立扩展和围绕业务边界拆分。它们能够降低组织和发布耦合，但也会引入服务治理、调用链、数据一致性、配置管理和故障定位问题。

5. 云原生和弹性架构

云原生架构利用容器、自动化编排、服务治理、弹性伸缩、可观测性和持续交付，适应动态资源环境。它解决的是资源利用、交付速度、弹性和运维自动化问题，并不意味着所有系统都必须拆成微服务。单体应用也可以容器化和云化，架构选择仍要结合场景。

七、架构演化背后的驱动力

架构演化的关键是识别真正的驱动力。例如，业务团队多不一定必须微服务，只有当独立交付、独立扩展和边界自治的收益大于分布式成本时，拆分才有意义。

八、综合知识易错点

第一，架构不是产品名词的集合。Redis、Kafka、Kubernetes 只是实现工具，必须说明它们服务于哪个架构决策和质量属性。第二，分布式不等于高可用。多个节点如果共享同一个单点数据库，仍然可能整体不可用。第三，微服务不等于低耦合。若服务共享数据库、接口互相嵌套调用，耦合可能比单体更严重。第四，云原生不等于上云。云原生还涉及自动化、弹性、可观测性、持续交付和面向失败设计。

九、案例分析题

某连锁零售企业原有单体系统，部署在一台服务器上。随着门店和用户增加，促销期间出现响应变慢；新接入一个支付渠道需要修改多个模块；系统发生故障时无法快速定位。企业希望逐步改造，但不能一次性重写全部代码。

请回答：

1. 该系统当前面临哪些架构问题？
2. 应如何确定改造优先级？
3. 是否应该直接改造成微服务？请说明理由。
4. 给出一个渐进式架构演化方案。

参考答案

当前问题包括部署单点和可用性不足；高峰期缺少容量和弹性设计；支付渠道与核心业务耦合，导致可修改性差；缺少统一监控和链路追踪，故障定位困难。

改造优先级应先处理高风险、影响面大且可以验证的问题，例如增加监控和容量基线，再隔离支付渠道和高频查询，最后根据团队能力和业务边界决定是否服务化。不能直接以“微服务”作为目标，因为一次性拆分会引入网络调用、分布式事务、部署治理和数据迁移风险。

渐进方案可以是：先建立统一日志、指标、链路追踪和健康检查；对商品查询增加缓存和读扩展；通过适配器隔离支付渠道；将非核心通知改为可靠事件；在边界稳定后再把支付或库存等模块独立部署；每一步通过性能、故障和回归测试验证，再逐步迁移流量。这样既改善质量属性，也控制重构风险。

十、综合知识练习

1. 软件架构的基本要素包括哪些？
2. 为什么架构既要描述静态结构，又要描述动态行为？
3. 分层架构解决什么问题？它的主要代价是什么？
4. 分布式架构新增了哪些问题？
5. 为什么不能看到微服务和云原生就直接套用？

答案：1. 构件、连接件、配置和约束。2. 静态结构说明系统组成，动态行为说明调用、消息、故障和恢复，二者共同决定系统实际质量。3. 分层通过职责和依赖控制降低复杂度，代价是调用链变长和层次泄漏风险。4. 网络延迟、部分失败、一致性、时钟、数据分布和运维治理。5. 架构必须由业务目标、质量属性、约束和团队能力驱动。

十一、论文素材

本节适合积累“单体系统渐进式架构演化”主题。论文结构可以这样写：项目初期采用单体和分层架构，随着业务规模、发布频率和团队数量增长，出现性能、可修改性和故障定位问题；通过监控治理、缓存优化、接口适配、事件解耦和边界服务化逐步演进；改造过程中权衡了实时一致性与异步吞吐、拆分收益与运维成本；最终用响应时间、发布周期、故障恢复时间和错误率说明效果。

不要把“架构升级”写成技术堆砌。论文必须回答为什么改、改了什么、如何验证、有哪些代价，以及后续还要如何演化。

十二、今日复盘

请闭卷回答：

• 什么是系统架构？
• 构件、连接件、配置和约束分别是什么？
• 架构和详细设计如何区分？
• 为什么分布式架构会增加复杂度？
• 架构演化的真正驱动力是什么？

如果你能结合一个实际系统回答，而不是只背定义，本节才算完成。