面向复杂度架构设计
指导思想
- 面向复杂度架构设计: 简言之就是要首先判断系统的复杂度在哪里, 是高性能, 高可用, 高拓展还是安全等, 然后进行拆解, 确定降低复杂度的架构方案
设计原则
- 合适原则, 合适优于业界领先
- 简单原则, 简单优于复杂
- 演化原则, 演化优于一步到位
具体应用:
- 设计出来的架构要满足当时的业务需要, 符合团队和技术的能力水平
- 先按照简单的方式来设计架构, 然后不断的在实际应用过程中迭代优化
- 当业务发生变化时, 架构要扩展, 重构, 甚至重写
架构设计流程
前期: 澄清需求, 分析系统的复杂度
- 理解系统常见利益干系人, 拿一个钱包案例分析如下
- 利益干系人诉求分组
- 时间: 项目周期, 交付时间
- 成本: 人力成本, 硬件成本
- 范围: 必做, 可做, 尽量做
- 质量:可维护性/可测试性/性能/安全/可用性...
- 诉求排序: 差异性, 冲突性
- 排序原则
- 取舍原则: 根据业务目标决定哪个优先
- 影响力原则: 按照影响力大小排序: 监管者>投资者>评估者>使用者>维护者
- 沟通方式
- 差异性诉求: 按照影响力沟通, 点对点
- 冲突性诉求: PK+老板拍板, 开会
中期: 设计备选架构
- 备选架构设计技巧
- 数量: 3-5个为最佳
- 差异性: 有比较明显的差异
- 粒度: 覆盖核心业务场景
- 架构评估方法
- 260度环评
- 将维度按照优先级排序, 逐级筛选
- 常见架构评估维度: 性能, 可用性, 可拓展, 成本, 安全, 技术复杂度, 团队技术储备
后期: 输出详细架构设计方案以及架构设计文档
- 备选架构, 详细架构以及方案设计的区别
- 备选架构: 主要是拆解系统, 得到4R, 给老板/利益干系人看的
- 详细架构: 给下一级架构师/开发团队看的
- 细化系统, 明确4R
- 2.优化系统, 提升质量
- 方案设计(设计师): 基于架构实现需求, 得到项目方案设计文档, 给到开发团队看的
- 详细架构的内容
- 架构规范(提升架构落地效率): 如交互协议(TCP, HTTP), 数据格式(XML. JSON), 开发框架等
- 架构质量(提升架构落地质量): 如可测试性设计(日志, 命令行), 可维护性(管理后台, 运维系统), 可观测性(日志, 监控系统)等
示例:
- 备选架构设计: zk中Follower将写请求转发给Leader
- 详细架构设计:
- Follower与Leader之间建立TCP连接
- 采用Jute作为序列化组件
- 请求头格式以及响应头格式设计
示例:
- 备选架构设计:
- 采用微服务架构, 划分为交易, 支付, 物流, 账务共4个微服务
- 采用Spring Cloud框架
- 详细架构设计;
- 采用Spring Boot 2.x版本
- 服务间采用JSON格式报文, 报文的基础格式(公用字段)(requestId..)
- 服务间接口响应不能超过50ms
- 架构设计文档大纲
- 业务背景: 要解决什么问题, 带来什么价值
- 约束&限制: 明确的, 无需进行设计的相关条件
善用系统边界黑盒图: 把系统当成黑盒, 描述系统与同级别其他系统交互和关联关系
- 总体架构设计: Rank, Role, Relation
- 详细架构设计: Rule(包含具体的架构规范)
系统边界白盒图: 把系统当成白盒, 描述系统内的Role与同级别其他系统交互和关联关系, 注意区分系统内部和系统外部角色
5. 架构质量设计: 可测试性, 可维护性, 安全, 规范等 6. 架构演进规划: 第一期, 第二期...