架构实战营 - 模块三总结

教学目标

了解架构师基本职责

掌握架构师的结构设计流程

理解架构师在不同阶段的任务和做法

核心：降低不确定性，降低复杂度

架构师画像

架构师定位

• 架构师负责业务和技术的桥梁

• 架构需要既懂技术又懂业务

架构师核心能力

• 判断能力：判断业务和技术，具备沟通能力 --> 确定性思维

• 拆解能力：有技术深度/宽度（单领域内）和广度（跨领域） --> 创造性思维

• 取舍能力：能够实现设计/说服合作人以及决断能力 --> 系统性思维

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

架构设计 VS 方案设计

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

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

架构设计阶段划分

架构设计前期

沟通业务，确定架构和核心流程

架构设计中期

内部讨论，多架构 PK

架构设计后期

完善架构后才能进行开发。

架构验证阶段

架构落地后持续的迭代和优化

架构设计团队

精英团队形成小而美的高效团队

第二课 架构师设计前期怎么做？

教学目标

• 理解架构设计常见利益干系人和诉求

• 掌握利益干系人诉求和排序技巧

利益干系人分析

利益干系人分析框架

主要分为六类，不同人有不同的视角有不同的诉求

• 投资者：投资人

• 监管者：监管，例如银监会

• 构建者：开发测试

• 维护者：运维和主持人员

• 评估者：评估机构，例如消防安全

• 使用者：用户

利益干系人 - 投资者（爸爸）

内部投资人：主要是老板，人力投入，关注成本

外部投资人：“老板”，购买人员，关注价格

利益干系人 - 监管者（大爷）

政府监管者：按照法律法规，政府组织

媒体监督者：广播报道

利益干系人 - 构建者/维护者

构建者：开发/施工/供应商团队

维护者：运维和支持部门

利益干系人 - 使用者/评估者

使用者：主要是使用人员和使用者

评估者：评估/检测团队，也包括 ISO90001 外部评估者

诉求优先级排序

利益干系人诉求处理流程

分组 -> 排序 -> 沟通

干系人诉求分组

• 时间：周期和排期

• 成本：人力物力

• 范围：业务范围

• 质量：xxx 性

干系人诉求排序

差异性：诉求不同

冲突性：纬度不同冲突

干系人诉求沟通

取舍原则/影响力原则 进行排序

取舍原则：根据业务目标决定优先级

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

差异性 -> 影响力 -> 点对点

冲突性 -> PKor 老板 -> 开会

注意：这里面的 PK 不是干系人直接 PK，架构师要介入进行引导，发挥自己的影响力按照自己想要的架构。

第三课 架构设计中期应该怎么做？

设计备选方案

架构设计的误区：

1. 最牛的公司，最牛的技术

2. 最新的技术

3. 最熟悉的

什么是备选架构

• 架构模式

• 高性能：负载均衡，主备，集群，分片

• 高可用：数据复制，状态决策

• 可拓展：微服务，微内核

• 技术选型

• 存储：mysql，redis

• 负载均衡：DNS，nginx，lvs

• 分布式决策：zookeeper，raft

• ……

备选方案设计过程

• 头脑风暴：对于可选技术进行排列组合，得到方案

• 红线筛选：根据约束和限定否决方案，主要来源于监管/投资者等重要干系人

• 4R 设计：确定 role/relation 针对于核心场景设计 Rule

备选架构设计技巧

数量：控制在 3-5 个方案，按需考虑

差异性：方案之前有明显的差异性（参考上面的什么是备选架构）

粒度：覆盖核心场景，不需要全面覆盖

备选架构常见困难和应对技巧

• 加强技术宽度，多积累多了解

• 技术关键点，能够了解关键性能指标和竞品优劣势

比较学习法

学习 - 梳理比较维度 - 思考和对比

评估和选择备选方案

错误的方法

• Leader 来选择：leader 不一定是专业的，要做好备选和选择，说明原因

• 综合多维度打分：注意不同角度的不同的优先级

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

• 性能：按需

• 可用性：按需

• 可拓展：明确在预测

• 成本：综合成本

• 安全：非红线外综合成本考虑

• 技术复杂度：合适原则

• 团队技术储备：合适原则

• 可测试性：测试干系人团队

• 可运维性：运维干系人团队

第四课 架构设计后期应该怎么做？

详细架构设计

被选架构 VS 详细架构 VS 方案设计

• 备选架构：给老板和利益干系人

• 详细架构：给下一级架构师和开发

• 方案设计：指导开发

详细架构

• 架构规范

• 交互协议

• 数据格式

• 开发框架

• 架构质量

• 可测试性

• 可维护性

• 可观察的

• 更多质量设计

架构设计阶段核心设计，提高效率但是可更改

架构设计文档

内容大图

• 业务背景

• 约束 &限制

• 总体架构设计

• 详细框架设计

• 架构质量设计

• 架构演进规划

架构设计第一部分

业务背景

• 解决什么问题

• 带来什么价值

• 达成什么目标

• 完成什么任务

• 处于什么地位

约束 &限制

• 成本

• 时间

• 技术

• 质量

架构设计第二部分

总体架构设计

• Rank

• Role

• Relation

详细架构设计

• Rule

• 架构规范

架构设计第三部分

架构质量设计

• 可测试性设计

• 可维护性设计

• 可运维性设计

• 安全/成本设计

架构演进规划

• 分期落地规划

第五课 消息队列备选框架设计

背景说明

业务背景

游戏上线流程复杂，但是发布本身非常频繁。

另外系统复杂，系统间的通知调用非常复杂（没有维服务架构）

历史系统机构说明

系统间调用部都是同步并发架构并且通信协议不一致，需要考虑重试以及维护重试失败队列的机制。

技术背景

当前团队技术型和人力情况

利益干系人

干系人利益诉求

利益干系人诉求分析

• 差异性

• 差异性 1:运维和业务，自研和开源

• 差异性 2:老板和业务 &测试，阿里和开源

• 冲突性

• 老板和实际情况的需求

• 运维和测试需求 47*++++

• 
  

• 业务方历史踩坑 rabbitmq

利益干系人诉求排序

可用性 > 可维护性 > 成本 > 其他

复杂度分析

高性能：不需要

高可用：非常重要

可拓展：暂无需考虑

成本：时间和人力成本要控制

备选架构设计

备选架构 1 - 开源方案

备选架构 2 - 自研发集群 +  MySQL 存储

mysql 可以使用 hbase/redis 来实现

备选架构 3 - 自研集群+自研存储

备选架构 4 - 直接使用阿里的 RocketMQ