Day01-05｜1.2.1 架构设计师的定义、职责和任务

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

一、学习目标

系统架构设计师不是“技术最强的程序员”，也不是只负责画图的人。架构师要把业务目标、技术约束和质量属性转化为可实施的系统结构，并在整个生命周期中持续维护关键决策。本节完成后，你应该能够解释架构师的角色定位，列出主要职责和任务，区分架构师与其他岗位的工作边界，并在案例题中回答“架构师应该做什么”。

二、架构设计师的基本定义

架构设计师负责根据系统需求和约束，确定系统的总体结构、关键技术选择、组件边界、交互方式、数据组织、部署关系和质量保障机制。架构师的工作对象不是某个孤立功能，而是会影响多个子系统和整个生命周期的架构决策。

架构师既要理解业务，也要理解技术；既要能够抽象，也要能够落地；既要做方案，也要承担方案的沟通、评审、实施指导和演化治理。一个架构方案如果无法被团队实现、测试、部署和运维，就不能称为完整的架构设计。

三、架构师的核心职责

1. 识别架构驱动因素

架构师要从需求中识别影响全局的因素，包括业务目标、质量属性和约束条件。业务目标例如支持多租户、快速上线、接入更多渠道；质量属性例如性能、可用性、安全性、可修改性和可靠性；约束条件例如预算、法规、遗留系统、团队能力和部署环境。

架构师不能只接受“系统要稳定”这种模糊要求，应推动其形成可验证的场景，例如：当某个节点发生故障时，系统在 30 秒内恢复服务，数据丢失不超过 1 分钟。只有这样，架构决策和验收测试才有依据。

2. 设计总体架构

总体架构设计包括系统边界、子系统划分、组件职责、接口、数据流、控制流、部署拓扑和外部依赖。架构师要决定哪些职责放在一起，哪些职责必须隔离，哪些调用同步完成，哪些工作可以异步完成，哪些数据由哪个系统拥有。

总体架构不等于所有细节都已经确定。架构师应优先确定影响全局、难以替换和风险较高的内容，把局部实现留给详细设计和迭代开发，同时记录假设、未决问题和验证计划。

3. 进行技术选型和权衡

技术选型必须围绕问题和约束。数据库、消息中间件、缓存、容器平台或开发框架都不是目的。选择时应比较性能、可靠性、可维护性、安全性、成本、团队能力、生态、迁移难度和厂商依赖。

例如，消息队列可以提高异步处理能力和削峰效果，但需要设计可靠投递、幂等消费、重试、死信、顺序和最终一致性；关系数据库适合强事务，但在超大规模分析和灵活文档查询场景中未必是最优。架构师的职责是说清“为什么选、什么时候不适合、如何控制风险”。

4. 建立架构文档和模型

架构文档要服务于沟通、评审、实现、测试和运维。常见内容包括上下文图、逻辑视图、开发视图、运行视图、部署视图、数据模型、接口契约、质量属性场景、关键决策记录、风险清单和演化计划。

文档必须保持一致和可追踪。一个组件在逻辑图中叫“支付服务”，在部署图中不能变成没有解释的“交易节点”；一个质量需求必须能够追踪到架构措施和验证指标；架构变化后要更新相关视图和决策记录。文档不是项目结束才补写的报告，而是设计过程的一部分。

5. 组织架构评审和验证

架构评审的目的不是证明架构师正确，而是尽早发现风险。评审应邀请业务、开发、测试、运维、安全和数据相关人员，从各自关注点提出问题。性能评审关注瓶颈和容量，可用性评审关注单点和恢复，安全评审关注信任边界和权限，开发评审关注可实现性，运维评审关注部署、监控和回滚。

对于无法仅靠讨论确认的风险，要使用原型、压力测试、故障注入、接口契约测试、数据迁移演练或安全测试验证。架构师要把验证结果反馈到方案中，而不是只保留一份静态设计图。

6. 指导实施和持续演化

架构师不一定亲自实现所有模块，但需要为团队提供边界、接口、规则和关键技术指导，处理架构级问题，审查重要实现，维护架构基线。上线后还要通过监控数据判断方案是否达到目标，并处理需求变化、容量增长、技术债务和外部依赖变化。

架构演化可以是增加能力、替换组件、拆分模块、迁移数据、调整部署或改变通信方式。演化必须考虑向后兼容、灰度发布、回滚、数据迁移和运行风险。没有治理的演化会导致架构腐化：依赖方向失控、重复建设、接口不一致、配置分散和关键知识只存在于个人经验中。

四、架构师与相关角色的区别

现实项目中角色可能由同一个人兼任，但职责仍然要区分。架构师不应替代项目经理管理全部进度，也不应替代开发人员完成所有编码；项目经理也不能在没有技术评估的情况下单方面确定架构方案。

五、架构师的工作任务分解

可以把架构师任务分为六个阶段：

1. 理解业务：识别目标、角色、核心流程、业务对象和外部系统；
2. 提取约束：明确性能、可用性、安全、法规、成本和交付时间；
3. 形成候选架构：划分边界，选择风格、模式、接口、数据和部署方式；
4. 评估和决策：比较方案的收益、代价、风险和可逆性；
5. 指导落地：建立架构基线，支持实现、测试、部署和上线；
6. 持续治理：监控质量、管理变更、清理技术债务和规划演化。

这六个阶段不是一次性线性完成的。新需求、运行数据和故障复盘都可能推动架构重新评估。高级考试中的“架构设计方法”通常也强调迭代、复审和演化，而不是画完图就结束。

六、架构师的专业判断

架构师经常面对冲突目标。高一致性可能影响性能和可用性；高安全性可能增加操作复杂度；快速交付可能积累技术债务；高度解耦可能增加运维和排障成本；高冗余可能增加资源费用。架构师要把冲突显式化，说明优先级和选择理由。

判断方案时，可以使用以下维度：影响范围、实现难度、运行成本、替换难度、故障影响、组织能力和未来变化。对于不可逆的决策，如数据模型、核心协议和供应商绑定，应先做更多验证；对于容易替换的局部实现，可以保留灵活性。

七、案例分析

某保险公司计划建设理赔平台。平台需要接入多个渠道，自动审核部分材料，复杂案件由人工处理，理赔结果需要同步给客户和财务系统。系统要求敏感数据受到保护，规则经常变化，项目必须分阶段上线。

问题

1. 架构师首先应识别哪些架构驱动因素？
2. 架构师需要承担哪些主要任务？
3. 如何处理自动审核与人工审核的协作？
4. 如何保证系统能够分阶段交付和持续演化？

参考答案

架构驱动因素包括多渠道接入带来的可扩展性和接口兼容；敏感材料带来的安全、隐私和审计；规则频繁变化带来的可修改性；财务同步带来的一致性和可靠性；分阶段上线带来的兼容、灰度和回滚约束；自动审核带来的模型或规则可解释性与人工兜底。

架构师要完成需求和质量属性分析，划分渠道接入、案件、规则、审核、通知和财务集成等边界，设计数据和权限模型，确定同步与异步边界，选择规则配置或策略机制，编写架构文档，组织安全和架构评审，并用原型验证规则执行、接口兼容、数据脱敏和高峰容量。

自动审核结果不应直接覆盖人工判断，应设计案件状态机和人工复核入口；规则版本要记录，保证相同案件可追溯；复杂审核可以进入任务队列，允许人工补充材料和退回。结果通知和财务同步可采用可靠事件，但要有幂等和对账；核心案件状态变化需要明确事务边界。

分阶段交付可以先建设核心案件流程和统一身份，再逐步接入渠道、自动审核和财务系统。接口采用版本化和适配器，数据库迁移可采用双写、回填和校验，发布采用灰度和回滚，关键指标包括审核耗时、接口失败率、案件重复率、人工介入率和数据对账差异。

八、综合知识练习

1. 架构师的工作对象为什么不是某个模块？
2. 架构师为什么要关注文档和沟通？
3. 架构评审应重点检查什么？
4. 技术选型为什么必须考虑团队能力？
5. 架构师如何处理质量属性之间的冲突？

参考答案

1. 架构决策会影响多个组件、生命周期和整体质量。2. 架构需要被不同角色理解、实现、测试、部署和维护，沟通失败会造成错误实现。3. 需求覆盖、边界、依赖、质量属性、风险、可实现性、部署、监控和恢复。4. 团队不会使用或维护的技术会增加交付和运行风险。5. 明确业务优先级，比较候选方案，写出收益与代价，并通过指标和验证控制风险。

九、论文素材

适合积累“架构师在复杂项目中的职责与实践”主题。论文可以写架构师如何从业务目标出发识别质量属性，组织多角色需求分析，形成候选架构并通过评审和原型验证；实施阶段建立架构基线、接口规范、自动化测试和发布机制；运行阶段依据指标持续优化。要体现架构师是决策者、协调者、风险管理者和技术治理者，而不只是方案撰写者。

十、今日复盘

请闭卷回答：架构师与项目经理、系统分析师、技术负责人分别有什么区别？架构师从需求到上线要承担哪些任务？为什么架构评审不是形式？面对高一致性、低延迟和低成本互相冲突时，架构师应如何决策？