架构的设计与实践
一、对架构的疑问
1.1 什么是架构，对产品有什么影响
- 把木头加起来，组成一定的结构
- 系统中的架构要素(子系统、模块、应用服务)，结构是针对不同场景设计的，连接是描述要素之间的交互继承关系
1.2 架构有哪些类型
- 架构域
-
业务架构
-
战略
- 业务需求初期：梳理问题域，确定产品方向和功能范围，为产品架构提供输入
-
内容
- 业务规划
- 业务模块
- 业务流程
-
目的
- 对业务进行拆分，对领域模型进行设计，把显示业务转化为抽象对象
-
输出
- 企业战略方向图
- 问题域列表
- 业务流程图
-
-
数据架构
- 从业务架构分析业务流程、定义数据架构，流程和数据结合定义产品架构
-
内容
-
系统需要什么样的数据
-
静态数据
- 元数据
- 业务对象数据模型
- 主数据
- 共享数据
-
动态数据
- 数据流转
- ETL
- 数据全生命周期管控治理
-
-
如何存储这些数据
-
存储策略
- 集中式存储
- 分布式存储
-
-
如何进行数据架构设计
- 通过领域建模，清晰反映企业业务域，清晰描绘企业数据模型
-
ER图
-
实体
- 领域对象
-
属性
- 领域对象的属性
-
联系
- 领域对象之间的关系
-
-
-
产品架构
-
直接关系的功能模块组成子系统
- 解决相同问题域的子系统就能够形成一个功能层级
- 简介关系的功能模块通过直接关系的模块产生联系
- 产品架构分层
-
-
应用架构
-
承接业务架构，影响技术架构
- 说明产品架构要分为哪些应用系统，系统如何集成
- 考虑子系统之间的关系
- 考虑可复用的组件或模块进行下沉，为业务提供统一支撑
-
原则
-
简单性
- 层次清晰明确，耦合度低
-
灵活性
- 可适应业务的快读变化，保持稳定性
-
整合性
- 对外提供一致的服务接口，体现共享和协作
-
-
-
技术架构
-
落地
- 应对应用架构的技术需求，进行技术选型
-
问题
-
如何进行技术层面分层
- 微服务架构分层模型
- 单个应用的技术分层
- 开发框架的选择
- 开发语言的选择
- 非功能性需求的选择
-
-
各个技术点的分析、方案选择
-
关键技术清单
- 技术架构图
-
-
-
1.3 为什么要画架构图
-
梳理对产品和技术方向的判断
- 产品发展方向
- 功能迭代周期和落地
- 与其他产品的依赖关系
- 技术方案的演进
-
提供产品&技术&运营的输出
- 根据架构图，拆分里程碑
- 产出运营计划方案
- 产出技术架构方案
-
让人可视化的理解架构
- 勾画产品边界
- 勾画技术边界
- 指明发展方向
- 对产品结构、功能、技术有认知
-
提供面向不同人员的视图语言
- 气象学家眼里的中国地图
- 地理学家眼里的中国地图
- 面向产品给产品视图，面向技术给技术视图
1.4 何时需要画架构图
- 设计一个系统的、完整的系统时
- 随时都可以尝试，不论项目正在开展或者已经结束
1.5 架构图怎么画
- 根据架构域，进行架构分解
- 从无到有、从粗到细、从模糊到清晰
- 依次产出业务架构图、数据架构图、产品架构图、应用架构图、技术架构图
二、业务架构与产品架构设计实践
2.1 分解业务域/问题域/问题空间
-
根据原始需求，列出问题域
- 将当前需要解决或者未来可能需要解决的问题放入产品框架
2.2 确定产品方向
- 经过问题域罗列后，能够找到模糊的产品方向和功能范围
- 产品用户
- 核心目标
- 依赖系统
2.3 绘制业务流程
2.4 业务功能矩阵
- 分析业务流程，垂直拆分功能职责，识别业务功能和业务服务
2.5 功能架构分层
- 关注每个流程下，各个功能的枚举和模块之间的分解
- 将明显同一个产品范围、同一组产品功能的模块放在同一层级，得到基础的产品框架
2.6 明确功能边界
- 用户感知层
- 功能模块层
- 数据层
- 处理不同信息层级的边界
-
处理同一层级内子模块的边界
- 相互独立，界限分明
2.7 明确系统间边界
- 架构图用不同颜色区分不同系统
- 自己团队使用亮色标识，外部系统使用暗色标识
2.8 加入信息流
- 用箭头表明模块间信息流动的方式
- 可用不同颜色表名各个模块之间的信息交互
三、从领域模型提取数据架构
3.1 ER图
- 通过领域建模逐步提取系统数据架构图
-
业务架构-领域建模
-
四色原型法
-
时效性原型MI
- 关系
-
参与方地点物品原型PPT
- 实体模型
- 角色原型ROLE
- 描述原型DESC
-
- 梳理关键流程
- 领域模型骨干
- 领域模型角色
- 领域模型描述
- 提取ER图，并调整
-
四、单体式和分布式的应用架构
4.1 通过对产品结构，水平和垂直划分应用
- 水平划分
- 垂直划分
4.2 单体式应用
-
展现层/表现层
- 用户通过表现层与系统交互
-
业务层/应用逻辑层
- 解决业务需求
-
基础通用层
- 中间件/业务无关性
-
数据层
- DB/NoSQL/分布式文件系统
4.3 分布式应用
- SOA：通过服务形式相互调用
-
应用间调用关系
- 应用集成架构图，标注调用链路中的业务含义，标注应用之间发生的业务关系
- 外部系统调用
-
明确应用调用边界
- 源系统
- 内部应用
- 应用依赖系统
- 输出系统
五、技术架构的战略和战术原则
5.1 相关问题
- 如何进行纯技术层面分层
- 开发框架选择
- 非功能性需求
- 开发语言选择
5.2 战略层设计原则
-
合适原则
- 适合优于业界领先
-
简单原则
- 结构复杂性
- 逻辑复杂性
- 大道至简
-
演化原则
- 扩展、重构、重写
5.3 战术层设计原则
-
高并发原则
-
无状态
- 便于水平扩展
- 有状态配置的可通过配置中心实现无状态
- 子主题 3
-
拆分
- 系统维度拆分
- 功能纬度拆分
- 数据读写纬度
- 根据访问特征，AOP纬度
- 模块纬度
-
服务化
- 服务化演进
- 考虑分组、隔离、黑白名单、超市、重试机制、路由、故障补偿
-
消息队列
- 服务解耦，异步处理，流量削峰缓冲
- 牺牲强一致性，保障最终一致性
- 数据校对：解决数据丢失问题
-
数据异构
- 异构数据变更，原子化存储
- 数据闭环
-
缓存
- 用户层：dns/浏览器/操作系统dns/客户端缓存/浏览器缓存/app缓存
- 代理层：cdn缓存
- 接入层： nginx代理缓存/nginx +lua+redis做业务数据缓存
- 应用层：页面静态化，业务数据缓存，消息队列
- 数据层
-
-
高可用原则
-
降级
- 降级开关集中化管理
- 可降级的多级读服务器
- 开关前置化
- 业务降级
-
限流
- 防止恶意请求攻击或超过系统峰值
- 请求流量只到cache
- nginx做请求次数limit限制
- nginx对指定ip做黑名单决绝或者iptables
-
可回滚
- 应用版本可快速回退
-
-
业务设计原则
- 防重设计
- 幂等设计
- 流程定义
- 状态与状态机
- 后台系统操作可反馈
- 后台系统审批化
- 文档注视
- 备份
5.4 技术架构图
-
功能需求技术架构图-逻辑架构图
- 产品架构图和应用架构图为基础
- 主要体现什么技术，技术实现逻辑
- 将产品+应用+技术结合起来，呈现在图上
-
非功能性需求架构图-物理架构图
- 偏向网络设计、集群设计、中间件设计、数据存储设计等
- 体现流量访问、数据刘庄、数据存储和技术组件之间的运转
XMind: ZEN - Trial Version
