架构设计
架构设计要素
规划
目标：做正确的事、适可而止
输出：可落地的架构
设计模式
分而治之：将一个不存在系统分到可以被实现的单元为止
迭代式设计
输入
功能性需求 + 限制 + 质量要求 + 资产和技术
输出
- 架构规划
- 研发设计
- 测试方案
- 部署方案
- 物理架构
- 非功能的实现
- 发布流程
- 采购目标
- RFP招标需求
- POC
- 招标和产品决策
原则
- 合适：合适的技术优于先进的技术
- [简单](/软件工程/软件设计/设计原则.html#KISS%20keep%20it%20simple%20and%20stupid)：简单的实现优于复杂的实现
- 演化：[演进的架构](/软件工程/架构/演进式架构.html)优于一步到位的架构
设计流程
识别复杂度
- 将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题
对于缺乏经验的新人，可以采取倒找法，就是通过已知的复杂性问题来对照本系统从而发现存在的复杂度
设计后备方案
单一方案设计很容易一条路走到黑，通过后备方案打开思路，避免陷入单一视角考虑问题
- 3 ~ 5 个
- 差异明显
- 不只局限于熟悉的技术
评估
综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序
- 列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案
详细方案设计
当进入了详细设计阶段后发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性
这可以通过一些方式来避免：
- 需要对方案的关键细节有深入的理解
- 多考虑细节，一个细节可能就会推翻讨论许久才决定的整个方案
- 集体智慧设计
方法论与思维
架构立方体
将设计的视角归为六类
- 应用：实现的总体功能
- 技术：支撑业务的基础架构（中间件、数据库）
- 功能：更为详细的功能
- 运行：描述软件什么时候在哪里
- 逻辑：技术已定型 产品未定型
- 物理：产品已定型
功能性需求 -> 功能性模型
质量性需求、限制性需求 -> 运行性模型
需求分析
需求贯穿了系统的整个生命周期
模块定义
- 耦合与内聚
- 粒度：粒度越细 成本越高
系统上下文
- 标识外部系统 表明需要将哪些外部系统纳入整体解决方案的范畴内
功能性模型
- 用例模型
- 整体架构草图：简单的流程与组成
- 鲁棒图
- 时序图
- ER图
运行性模型
关注点：监控、容量、系统核心维度
部署单元：安装单元、执行单元、展示单元、数据单元
- 应用逻辑运行视图
- 逻辑运行视图
- 物理运行视图
资产复用
- 方法资产：原则、策略、模式、方法论
- 工件资产：库、工具、参考架构
复用能加快项目、避坑、减少意见冲突
架构验证
- 架构流程：JAD ARB
- 测试（**验收测试**）
- RAID架构验证
- 风险是否规避
- 假设是否正确
- 问题分析记录
- 依赖识别验证
误区
- 过于微观 没有宏观视角
- 没有关注点分离 XYZ
- 过度设计、过于精妙无法变更迭代、技术冷门
- 专注于擅长的技术栈 忽略了更合适的选项
企业架构设计
- 企业架构：对企业事业信息管理系统中具有体系的、普遍性的问题而提供的通用解决方案
SCN策略能力网络
- 价值观和策略：为赚钱
- 能力：为实现价值观和策略
- 资源：为实现能力
CBM基于模块的业务模型
- 战略
- 管理
- 执行
信息架构
- 对某一特定内容里的信息进行统筹、规划、设计、安排等一系列有机处理的想法
技术架构三角模型
- 应用和外部对接
- 内部数据落地
- 底层基础架构支撑
策略差距
- 目标与能力的差距
架构转型
架构评估
ATAM评审
关注产品本身
表述：
- PMO
- 产品：描述目标 功能 上下文
- 架构：描述架构业务 组件流程等 梳理上下游链路
调查分析：
产品与架构讨论进行优先级场景、实现难度发现 安全性、性能预估等
场景讨论：
相关人士进行技术方案确定、风险点事项确认 识别出架构师没发现的风险点
报告生成：
得到会议纪要 共识事项 跟进事项 风险点等书面文档
CBAM成本效益分析方法
关注成本与效益
优先级评估：
选择前30%优先级的需求 在评估最好与最坏的业务场景下的性价比
ROI计算：
通过一系列计算得到投资回报率
系统容量评估
- 达到最高可用性 扩容缩容需要准备多少资源
流量预估：使用历史数据 模型预测 -> 系统容量评估：根据预估结果评估各业务方所需的资源 -> 业务预热 -> 全链路压测 -> 容量微调、生成报告 -> 限流降级方案（做误差兜底）
应用容量与水位
根据当前QPS与单机QPS计算得到当前的集群负载情况 这个阈值可以用来被监控预警及做扩容缩容的一个基准线
容量精调
- 模拟请求：jmeter loadrunner等 性能偏差大
- 流量复制、重播 需要基础设施支持
- 流量转发
- 网关路由权重
线上压测需要注意点到为止 达到性能阈值后要及时停止 防止影响线上业务
线上应急预案
- 预防问题 评估+数据+阈值规划
- 发现问题 监控
- 快速响应 人员响应 故障转移 容灾演练 复盘
故障等级：
- 核心主链路还是外围系统
- 影响范围 资损情况
故障预案：
- 人工降级
线上异常回退：
版本控制 + 金丝雀/灰度
架构设计文档模板
备选方案模板
1. 需求介绍[描述需求的背景、目标、范围等]2. 需求分析[全方位地描述需求相关的信息] 5W [5W 指 Who、When、What、Why、Where。 Who：需求利益干系人，包括开发者、使用者、购买者、决策者等。 When：需求使用时间，包括季节、时间、里程碑等。 What：需求的产出是什么，包括系统、数据、文件、开发库、平台等。Where：需求的应用场景，包括国家、地点、环境等，例如测试平台只会在测试环境使用。 Why：需求需要解决的问题，通常和需求背景相关] 1H 关键业务流程 8C [8C 指的是 8 个约束和限制，即 Constraints，包括性能 Performance、成本 Cost、时间 Time、可靠性 Reliability、安全性 Security、合规性 Compliance、技术性 Technology、兼容性 Compatibility]3. 复杂度分析[分析需求的复杂度，复杂度常见的有高可用、高性能、可扩展等]4. 备选方案5. 备选方案评估架构设计模板
1. 总体方案[核心内容就是架构图，以及针对架构图的描述，包括模块或者子系统的职责描述、核心流程]2. 架构总览3. 核心流程4. 详细设计5. 架构演进规划