架构师不只是写 PPT

架构师画像

定位

架构师是业务和技术之间的桥梁。

架构师不能只顾技术，不懂业务。

架构师很容易两头不讨好。

三核心 &三思维

判断 -> 确定性思维

1. 业务理解力

2. 技术能力

3. 沟通能力

拆解 -> 创造性思维

1. 技术深度

2. 技术宽度

3. 技术广度

取舍 -> 系统性思维

1. 设计理念

2. 说服能力

3. 决断能力

架构设计流程和架构师职责

架构设计 & 方案设计

架构设计：影响系统结构的设计

方案设计：不影响系统结构的设计

Rank：改变系统分层的设计属于架构设计，例如将支付宝提升到和淘宝同级别。

Role：修改（增删改拆合）角色属于架构设计，例如微服务拆分。

Relation：修改角色关系属于架构设计，例如用消息队列代替接口访问。

Rule：修改角色之间的运作规则属于架构设计，例如 MongoDB 将选举算法从 Bully 改为 Raft。

架构设计阶段划分

架构设计前期

主要任务

澄清不确定性

1. 明确利益干系人的诉求；

2. 消除冲突的诉求；

3. 诉求优先级排序。

识别复杂性

1. 识别核心场景；

2. 明确或者预估质量需求；

3. 识别复杂度。

工作模式

1. 与业务方交流；

2. 与利益干系人交流。

关键输出

1. 总体业务架构图；

2. 核心场景流程。

架构设计中期

主要任务

设计备选方案

1. 头脑风暴；

2. 筛选方案；

3. 设计备选方案。

选择备选方案

1. 360 度评估；

2. 明确选择标准；

3. 选择最终方案，并汇报。

工作模式

1. 架构小组讨论；

2. 架构小组写文档；

3. 向利益干系人汇报。

关键输出

1. 备选方案；

2. 方案评估结论；

3. 方案汇报结论。

架构设计后期

主要任务

细化架构

按照 4R 架构定义细化架构。

完善架构

可维护性、可测试性、可运维性、成本、安全。

工作模式

1. 写架构设计文档；

2. 给技术团队宣讲架构。

关键输出

1. 完整的架构设计方案。

贯穿项目的架构验证阶段

主要任务

收集架构意见

1. 开发人员意见；

2. 测试人员意见；

3. 运维人员意见。

跟进架构落地效果

1. 性能测试结果；

2. 压力测试结果；

3. 线上运维情况。

工作模式

1. 总结复盘；

2. 收集吐槽。

关键输出

1. 架构优化建议；

2. 架构迭代计划。

架构设计团队

规模 精英团队，小而美。

组织 外科手术团队，主架构师 + 各个领域专家。

运作 虚拟团队，项目制。

决策 团队讨论，主架构师拍板。

思维导图

架构设计前期应该这么做

利益干系人分析

利益干系人分析框架

投资者

内部投资人

【定义】 俗称“老板”，指决定投入人力物力财力开发系统的管理者。

【利益诉求】成本、时间、竞争力

【举例】上级、业务负责人

外部投资人

【定义】也称“老板”，指决定购买系统的金主，适应于 2B 领域。

【利益诉求】价格、时间、竞争力

【举例】张老板、王老板、

监管者

政府监管者

【定义】按照法律法规对系统进行监管的政府组织。

【利益诉求】合规、处理投诉

【举例】消委会、银监会

媒体监督者

【定义】对系统相关的事件进行广泛报道的媒体。

【利益诉求】消息披露、事件回应

【举例】3.15 晚会、焦点访谈

构建者 &维护者

构建者

【定义】负责构建系统的人员。

【利益诉求】技术、复杂度、时间

【举例】开发团队、施工队、生产商/供应商

维护者

【定义】负责维护系统的人员或其他系统。

【利益诉求】可维护性、高可用

【举例】运维团队、IT 部门、IT 系统

使用者 &评估者

使用者

【定义】使用系统完成业务功能的人员或者其它系统。

【利益诉求】易用性、高可用

【举例】用户、下游系统

评估者

【定义】对系统进行评估的人员或者其它系统。

【利益诉求】可观测性、可测试性

【举例】评测团队/测试团队、运维监控系统

诉求优先级排序

诉求处理流程

分组 分组维度

排序 排序原则

沟通 排序结果

诉求分组

时间 项目周期、交付时间。

成本 人力成本、硬件成本。

范围 必做、可做、尽量做。

质量 可维护性/可测试性/性能/安全/可用性/可维护性……

诉求排序

差异性 相同维度，不同的诉求。

冲突性 不同维度，冲突的诉求。

诉求排序常见原则

取舍原则 无法做到面面俱到，需要根据业务目标决定哪个优先。

影响力原则 按照影响力大小排序：监管者 > 投资者 > 评估者 > 使用者 > 构建者 > 维护者。

诉求排序沟通

差异性诉求 按照影响力沟通（谁权力大听谁的） 点对点

冲突性诉求 PK + 老板拍板（听老板的） 开会

复杂度分析

利益干系人诉求、业务需求核心场景 -> 识别可能的复杂度 -> 明确复杂度

思维导图

架构设计中期应该这么做

设计备选方案

内涵

设计过程

设计技巧

常见困难和应对技巧

比较学习法

评估和选择技巧

360 度环评 + 优先级排序

常见架构评估维度和注意事项

思维导图

架构设计后期应该这么做

详细架构设计

备选架构、详细架构、方案设计

详细架构内容

架构设计文档写作

内容大图

第一部分

【业务背景】问题、价值、目标、任务、地位。

【典型案例】推荐系统、消息队列、系统重构、XX 买菜

【技巧】系统边界黑盒图描述系统定位（Rank 和业务背景）。

【约束 &限制】成本、时间、技术、质量。

系统边界黑盒图 - - 描述 Rank 和业务背景

第二部分

【总体架构设计】Rank、Role、Relation。

【详细说明】

1. 来源于备选架构设计文档；

2. 用系统边界白盒图来展示 Rank；

3. 用系统架构图来展示 Role 和 Relation。

【详细架构设计】Rule、架构规范。

【详细说明】

1. 结合备选架构的 Rule 和架构规范；

2. 用系统序列图来展示 Rule。

系统边界白盒图 - - 描述内外 Role 的关系

第三部分

【架构质量设计】可测试性设计、可维护性设计、可运维性设计、安全/成本设计。

【详细说明】可能会增加新的 Role，例如管理后台；不需要面面俱到，看实际需要。

【架构演进规划】架构分期落地规划。

【详细说明】主要是为了设定项目计划。