架构师

互联网与软件技术
├── 业务研发主线（前端／后端／客户端）
├── 质量与稳定主线（测试开发／SRE）
└── 平台与治理方向
    ├── 安全工程师
    ├── 架构师 ← 本篇
    └── 技术项目经理（TPM）

定位一句话：架构师不写最多的代码，而是决定"系统怎么分层、边界划在哪、未来两年怎么演进"——他的产出是别人能照着执行的技术决策与约束。

为什么它属于"治理"类角色：业务研发交付功能，质量与稳定线保障可靠性，而架构决策的作用范围横跨所有业务线——一个服务边界的划分方式，会决定未来很多个团队的协作成本；一次技术选型，会决定几年的运维负担。这类决策一旦落下，改起来代价极高，所以它必须由专门的角色来负责判断，而不是由各团队各自决定。

一句话定义：架构师是负责系统整体结构与关键技术决策的技术岗位，工作内容包括业务域划分与服务边界定义、技术选型与关键方案评审、性能与成本的总体权衡、跨团队技术标准的制定，以及为中长期演进（迁移、重构、容量增长）预留结构空间。

职责边界（五类日常）

一、结构与边界设计

把业务拆成清晰的服务与模块，定义各部分的职责、依赖方向与数据归属。这件事的目标不是"拆得越细越好"，而是让变化被限制在局部：一个需求变更，理想情况下只影响一到两个模块，而不是牵动全系统。

• 判断依据：常见的划分思路有按业务能力划分、按数据归属划分、按变更频率划分。经验上，**"一份数据只能有一个归属方"**是最硬的一条约束——同一份数据被多个服务同时写入，后期几乎必然出现口径不一致与责任不清。
• 典型错误：按团队组织架构来划分服务边界。组织会调整，边界跟着调整就会造成连锁重构；边界应该跟着业务能力走，团队围着边界组建，而不是反过来。
• 产出：结构图、依赖约束、数据归属说明，以及"哪些允许依赖、哪些禁止依赖"的明确规则。约束写得越清楚，后面越省事。

二、技术选型与方案评审

选型的本质不是"选最好的技术"，而是选最合适的代价组合。引入一个中间件意味着同时引入一整套成本：部署与运维、监控与告警、故障模式、学习曲线、版本升级。技术方案评审时，真正值钱的不是指出"这里可以更好"，而是识别出容量、一致性、故障放大与不可回滚这四类风险。

• 容量：当前设计在数据量与并发量增长若干倍之后还成立吗？瓶颈最先出现在哪里？
• 一致性：跨系统操作如果中途失败，数据会停在什么状态？这个状态业务上可接受吗？
• 故障放大：一个依赖变慢会不会拖垮整条链路？有没有隔离与降级？
• 可回滚：方案上线后如果错了，多久能退回去？退不回去的方案要格外慎重。

三、非功能目标把关

性能、可用性、成本、可维护性如果不写成可验证的目标，就只是口号。

• 性能通常看分位值而不是平均值（平均值会被少数极快请求掩盖真实体验）；
• 可用性看故障恢复时长与影响面，而不是"全年没出过事"；
• 成本看单位业务量对应的资源消耗，而不是总账单；
• 可维护性看"一个新人上手修改某模块需要多久"这类可感知的指标。

写清目标之后，还要在上线前确认达标，否则目标会自然退化成愿望。

四、跨团队技术协同

推动公共能力沉淀（统一鉴权、统一日志、统一网关）是典型的架构工作：多个团队各自实现一遍，短期看快，长期是重复投入与口径分裂。但"统一"同时也意味着一次性的协调成本，必须在合适的时机做——太早会限制业务试错，太晚则治理成本高企。

• 收敛分歧的方法：技术分歧经常以"口味之争"的形式出现（用 A 还是用 B）。有效的收敛方式是把争论转成可验证的问题：定一个评判标准（吞吐、延迟、改造成本、团队熟练度），做小规模对比验证，用结果说话。
• 沟通要求：架构决策需要向不完全懂技术的相关方解释清楚，因此"能否把技术取舍翻译成业务语言"是一项硬技能。

五、演进与治理

• 演进路线：系统不会一次建对，重点是给出分阶段路径——先解决哪个瓶颈、中间状态是什么、每一步是否有独立价值。让每一阶段的中间状态都是可用的，比追求一步到位更现实。
• 技术债管理：列出债务清单，标注影响面与修复成本，与业务需求一起排序。技术债不分轻重地全部偿还并不现实，关键在于不让高风险项长期挂账。
• 大型重构与迁移：这类工作的难点通常不在技术，而在"边跑边换"——如何在不停止业务的前提下分批切换、如何做双向校验、如何在出问题时快速回退。

一个架构决策是怎么做出来的

真实的架构工作很少是"灵光一现"，更接近一套工程化流程：

1. 盘点约束——团队规模与技术储备、现有系统的改造窗口、预算与时间要求、合规与外部依赖。约束决定可行方案的边界，脱离约束谈架构设计意义有限。
2. 列候选方案——通常给出两到三个可选路径，而不是只有一条。
3. 做权衡表——把每个方案的收益与代价并列（改造成本、运行成本、风险、可逆性、对团队的要求），让取舍显式可见。
4. 写决策记录——把结论、理由、被放弃的方案及原因写下来。这一步常被省略，但恰恰最重要：半年后所有人都会忘记"当初为什么这么定"，没有记录就会反复讨论同一个问题。
5. 试点验证——先在一条业务线或一个模块上跑通，用真实数据检验假设。
6. 推广与约束——形成规范或工具，把好的做法变成默认选项。

其中"可撤销性"是判断决策质量的一个实用标准：信息不全时，优先选择容易改正的方案；不可逆的决策（如数据模型、存储选型）要多花时间。

相邻岗位辨析

三组最容易混的场景：

• 架构师 vs 资深研发：两者技术能力可能相当，差别在决策范围与责任性质。资深研发把一个模块做到极致，架构师要判断"这个模块值不值得这样做"。判断方法很直接：看他的输出是"代码与方案实现"，还是"约束与取舍结论"。
• 架构师 vs 技术负责人：小团队里常由一人兼任，于是在规模变大后容易错位——技术负责人天然会优先保本团队的交付，而架构师需要为整体判断，包括对本团队不利的结论。当两者由一人承担时，这类冲突往往被自己消化掉，长期埋成隐患。
• 架构师 vs 平台产品经理：都关注"平台能力建设"，区别在于平台产品关注用的人多不多、好不好用，架构师关注结构对不对、能不能长期承载。二者在平台类组织里高度交叠，需要事先约定决策归属。

判断口诀：定结构、定边界、定标准 → 架构师；写实现、保交付质量 → 研发；推项目、管节奏与对齐 → TPM；定功能与优先级 → 产品。

不同业务形态下的重心差异

• 高并发 C 端业务：容量与延迟是首要命题，缓存、分片、异步化、限流降级是主战场。
• ToB 与多租户系统：租户隔离、权限模型、可配置性与版本兼容是长期主线；单个客户的特殊需求如何不污染整体结构，是典型难题。
• 数据与算法平台：数据链路的稳定性、口径一致性与计算成本并重；"同一指标多个口径"是这类平台最常见的历史遗留问题。
• 金融类系统：一致性与可追溯优先于极致性能，任何"看起来更快但状态可能不一致"的方案都要格外谨慎。
• 传统行业数字化改造：往往面对既有系统的多、杂、旧，架构工作的重心是"如何在不停机的前提下逐步收敛"，而不是重新设计一个理想系统。

入行与转出（公开口径）

• 背景：绝大多数由资深研发（通常有 5 年以上一线经验）内部晋升或转岗而来；很少有校招直入架构岗——因为架构判断主要来自真实的踩坑经验与代价感知，很难靠书本建立。
• 前置知识：扎实的研发功底（至少一个技术栈能到深度）＋ 分布式系统常识（一致性、幂等、缓存、排队、故障隔离）＋ 数据与容量的量化感觉；对业务本身的理解往往比技术栈更关键。
• 面试通常怎么考察：以结构化的系统设计题为主——给一个业务场景，让你现场划分模块、定数据流、说明瓶颈与取舍，并在追问"如果量再涨十倍""如果这个依赖挂了呢"时保持逻辑自洽。相比背概念，这类面试更看判断过程。
• 常见入口：① 在成熟团队里主导过一到两个中大型系统的设计与落地；② 从性能优化或稳定性治理切入（这类工作的成果最容易被验证）；③ 跨境转岗——已有大型系统经验的人在新环境中常被赋予架构职责。
• 适配画像：能在信息不全时做出可撤销的决策；能承受"方案被质疑"的公开答辩；乐意把认知写成文档、讲清楚、让别人能接；不爱只靠加班解决问题。
• 三个常见认知误区：① 以为架构就是画图与堆技术名词——真正的难点在取舍与约束；② 以为文档是形式主义——决策记录写不下来，团队就会反复走回头路；③ 以为资历够了自然能做架构——缺少"为结果负责"的经历，换岗后容易只停在评审角色上。
• 职业特点：架构岗的总量少、门槛高，但一旦成立便具备跨团队影响力；这条线最大的风险是"只画图不落地"——能被记住的架构师通常都有能跑起来、且能长期维护的系统。
• 转出方向：转技术总监或研发管理（组织结构与人员）、转技术咨询与解决方案架构、转首席架构／技术战略、转创业或技术合伙人。