软件架构师
软件架构师负责的是结构：一个系统如何划分为若干部分、这些部分之间如何通信、整体必须守住哪些属性，以及它如何在数年之内改变形态而不必推倒重建。这类决定数量相对少，撤销的代价相对高。本指南说明这门学科覆盖什么、它与资深工程有何不同，以及这个角色如何介入开发团队的工作。
软件架构师做什么？
软件架构师决定一组系统如何被组织，以及这个结构如何演进。工作包括把业务领域拆分为服务或模块、定义它们之间的边界与契约、确立可用性、延迟、吞吐与恢复目标这类非功能性需求、依据这些需求选择技术、规划从现状到目标状态的迁移，以及把每个选择背后的推理记录下来，使其日后可以被理解和质疑。架构师通常跨多个团队工作，时间视野以数年计，动手程度一般低于实现这些决定的工程师。
把架构与优秀的资深工程区分开的，是判断错误的代价。多数工程决定可以在一个迭代内撤销。架构决定会把组织绑住：一条画错位置的边界要到一年半以后才被发现，那时已有三个团队围绕它构建，纠正就意味着拆开每一处跨越它的集成。正是这种不对称，使得架构师把过多的精力放在辨别哪些决定是单向的、哪些可以安全地推迟。
这门学科是被施加的约束。一个什么都允许的架构等于什么都没有决定，各团队随后会各自重新发现同样的问题，并给出不同的答案。有用的架构会收窄空间——边界在这里、服务之间这样通信、一个新组件上线前必须满足这些条件——同时在约束之内留出足够余地，让团队对自己的工作保有真正的自主。
这个角色反复出现的失效模式众所周知，值得点名。一位不再接触生产环境的架构师，其图纸描述的是设想中的系统而不是正在运行的系统，其标准以宣告而非提案的形式出现，结果就是被礼貌地忽略。真正算数的产出不是一份文档，而是一个团队确实照着构建的决定，而这通常要求架构师在问题被感受到的时候在场。
组织何时需要这项能力
架构一直在发生，问题只在于是否有人在有意识地做它。以下是隐式版本不再够用的几种情形。
多个团队在互相对着建
每个团队都在优化自己的交付，团队之间的接缝随之退化：数据重复且无人归属、同一个集成被以互不兼容的方式建了两次、一个服务的改动毫无预警地弄坏另外两个。没有哪个团队能独自修复它，因为问题存在于它们之间。
单体正在被拆分，或者拆分正在被回退
两个方向需要的是同一种稀缺能力——知道真正的接缝在哪里。按错误的线拆开，会得到一个具备单体全部耦合、却没有单体便利性的分布式系统，而这个结果远比相反的情况常见。
非功能性需求变成了合约义务
一位企业客户、一家监管机构或一项可用性承诺，把延迟、恢复时间、数据留存地或可审计性变成了义务。把这些属性事后补进一个设计时并未考虑它们的系统，往往比最初的构建还要困难。
一项重大的技术选型迫在眉睫
数据存储、消息骨干、身份提供方或云平台承诺，都会被沿用数年。这类决定往往是在时间压力下由声音最大的人做出的，而其后果在做决定的人早已离开之后才到来。
迁移必须与交付并行
在持续发布的同时替换一个核心系统，需要一套共存策略：过渡期什么走哪条路径、状态如何对账、每个阶段的回退是什么样子。迁移失败在排序上远多于在技术上。
没有人能解释系统为什么是现在这个样子
做出奠基性决定的人已经离开，推理也随之带走，于是当前的形态要么被当作神圣不可动，要么被当作随意的产物。两种读法都错，而且都会导致昂贵的失误。
核心能力
系统拆分
找到能反映业务实际如何变化的边界，使得一次典型的修改落在一个组件之内而不是横跨四个。沿技术分层而不是沿领域关注点划出的边界，通常正是「每个功能都需要多方协同发布」的系统的来源。
集成与契约
决定组件之间如何通信——同步还是异步、共享模式还是在边缘做转换——并定义稳定到可以依赖的契约。版本管理、废弃策略与向后兼容属于设计的一部分，而不是第一个消费方被弄坏之后的补救。
非功能性需求
把模糊的期待转化为关于可用性、延迟、吞吐、持久性、恢复、数据留存地与可审计性的明确目标，然后据此设计。没有被量化的需求无法被有意地满足，只能被偶然地满足。
技术选型
依据真正会咬人的需求来评估候选方案，包括运维负担、可招聘的人才范围、许可、退出成本与组织契合度。相关的问题很少是「抽象意义上哪个更好」，而是「哪个与这些约束以及将来运维它的人相匹配」。
取舍分析
明确说出每个选项付出什么、而不只是提供什么，并讲清楚正在牺牲哪些属性。一个被描述得没有缺点的架构，要么没有被分析过，要么是在被推销而不是被解释。
迁移策略
把从现状到目标状态的路径规划成一系列增量，每一步之后系统仍然可用，并把共存、对账与回退设计进去。困难的部分几乎从来不是目标设计，而是顺序。
决策记录
写下决定了什么、否决了哪些备选、假设了什么，以及什么情况足以让它被重新审视。价值在数年之后显现，那时有人必须判断某条约束是否仍然成立，还是已经悄悄失效。
失败与威胁分析
推理一个依赖只是劣化而非彻底宕掉时会发生什么、重试在哪里会放大负载、部分失败对用户呈现为什么样子，以及信任边界和数据流如何把系统暴露给攻击。
成本建模
理解一个设计在预期与非预期流量下的运行成本。技术上站得住、经济上不可持续的架构很常见，而这个发现通常伴随一张账单到来。
没有指令的影响力
让团队照着一个他们并未被强制接受的决定去构建。这项能力决定了上面这份清单是否会产生任何结果，而它恰恰是技术资历出色的候选人最常缺少的一项。
这门学科是如何实践的
架构不由一份产品清单定义，因此本节描述的是方法而不是工具。以下的实践、记法与产出物是业界普遍在用的——它描述的是这门学科的一般情况，而不是关于任何个人工作方式的说明。把它们说出名字很容易；值得寻找的证据是它们所承载的判断力是否真的存在。
建模与记法
- C4 模型
- 上下文图与容器图
- 时序图
- 领域模型与限界上下文
- 数据流图
决策实践
- 架构决策记录
- RFC 流程
- 架构评审会
- 技术雷达
- 结构化取舍分析
质量属性分析
- 延迟与错误预算
- 可用性与恢复目标
- 容量建模
- 威胁建模
- 失效模式分析
演进与迁移
- 绞杀者式迁移
- 防腐层
- 契约版本与废弃策略
- 分阶段切换与双跑
- 数据回填与对账规划
不靠守门的治理
- 适应度函数
- 自动化一致性检查
- 依赖与边界规则
- 铺好路的平台默认值
- 偏离与例外记录
证据收集
- 概念验证
- 负载与长稳测试
- 故障注入演练
- 生产遥测数据复核
- 运行成本分析
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某组织运行着一个由多个团队并行扩展的核心系统。各处集成是各自独立建起来的，共享数据的归属并不清晰，而一项客户承诺又带来了当前设计从未打算满足的恢复与数据留存地义务。需要一个结构性方向，同时交付不能停。
- 做法
- 追加的资深能力在客户自己的架构实践之内工作——客户的评审会、客户的标准、客户的决策记录、客户的技术方向。结构性权限仍留在原处；追加的能力为客户所做、并由客户拥有的决定提供分析、书面备选方案与实现投入。
- 为团队带来什么
- 该组织获得了投入结构性工作的经验能力，同时保留架构权限、产品所有权，以及对每一个约束其系统的决定的最终决定权。
相关领域
常见问题
- 软件架构师与技术负责人有什么区别？
- 影响半径与时间视野。技术负责人对一个团队数周到数月的技术工作负责，贴近代码，通常可以在一个迭代内纠正一个不好的判断。架构师跨系统、跨团队，以数年为视角工作，一个不好的判断会在无人察觉之前渗透进所有基于它构建的东西。两个角色是互补的：架构设定团队之间的约束，技术领导在约束之内做出好的决定。
- 软件架构师还应该写代码吗？
- 不一定要有产量，但需要与运行中的系统保持足够接触，好让自己对现实的模型保持准确。这种接触可以来自原型、评审、参与故障处理或阅读遥测数据，而不必是常规的功能开发。完全没有这种接触的架构师，会开始为一个「别人向他描述的系统」做设计，而这几乎就是所有象牙塔抱怨背后的机制。
- 规模较小的组织需要专职架构师吗？
- 通常不需要设为独立岗位。在只有一个产品和两三个团队时，架构决定的数量少到可以由资深工程师和一位技术领导者承担。需求出现在决定开始跨越团队边界时、在多个系统必须互操作时，或者在某项承诺让非功能性属性变得不可谈判时。在还没有需要归属的跨领域结构之前就设立架构师，往往会得到一套在寻找问题的治理。
- 架构决策记录到底带来什么？
- 它保存推理，而推理比代码衰减得更快。一份记录写明决定了什么、否决了哪些备选、假设了什么，以及什么会足以让方向改变。它的价值在日后显现，那时有人必须判断某条约束是否仍然成立。只记录结果、不记录被否决的选项与假设的记录，提供的价值非常有限，这也是许多团队认为这项实践是形式主义的原因。
- 如何分辨好的架构与昂贵的架构？
- 看复杂度是否在回应一个确实存在的需求。好的架构让预期中的变化变便宜，并说明它没有为哪些变化做优化。昂贵的架构为没有人提出过的变化预先构建灵活性，并在之后交付的每一个功能上收费。实用的检验方式是：架构师能否说出每一块结构分别是为吸收哪一种具体压力而存在的。
- 架构可以由一个群体而不是一个人来负责吗？
- 可以，而且在许多组织里效果更好。一群资深工程师共同做结构性决定，配合明确的收敛方式和一份决定记录，得到的决定比某个人下达方向更有认同度。群体不容易做到的，是在数年之间保持一致性而没有人为连贯性负责，因此常见的形态是共同决策加上一位有名有姓的记录守护者。
- 软件架构师如何与现有的工程团队协作？
- 作为您架构实践的参与者，而不是它的替代。在技术团队扩展的安排下，贵组织保留架构权限、技术方向、工程标准、路线图与产品所有权；结构性决定由您的人做出并批准，工作也由您的团队指挥。在 Talent.ID 一侧，这项安排只涉及雇佣：雇佣关系本身、薪资发放、员工福利与人才管理。架构决策权不会随之转移。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。