写点什么

架构实战营 - 模块三总结

用户头像
凯迪
关注
发布于: 2021 年 05 月 09 日

教学目标

了解架构师基本职责

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

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


核心:降低不确定性,降低复杂度

架构师画像

架构师定位

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

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

架构师核心能力

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

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

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

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

架构设计 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

发布于: 2021 年 05 月 09 日阅读数: 23
用户头像

凯迪

关注

环球梦还在,做自己! 2020.06.01 加入

记录一些日常的记录和随笔,回首往事有迹可循,人间一趟,难得清醒难得糊涂。

评论 (2 条评论)

发布
用户头像
华仔的课吗?
2021 年 05 月 09 日 22:19
回复
嗯嗯,对的
2021 年 06 月 05 日 21:43
回复
没有更多了
架构实战营 - 模块三总结