架构的设计与实践

一、对架构的疑问

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 技术架构图

• 功能需求技术架构图-逻辑架构图

  • 产品架构图和应用架构图为基础
  • 主要体现什么技术，技术实现逻辑
  • 将产品+应用+技术结合起来，呈现在图上

• 非功能性需求架构图-物理架构图

  • 偏向网络设计、集群设计、中间件设计、数据存储设计等
  • 体现流量访问、数据刘庄、数据存储和技术组件之间的运转

其他

• 欢迎关注我的博客&Github, Thanks!
• 也无言’s Blog
• 文章 Github地址