2020年1月

架构是什么

  • 系统

    • 定义：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。
    • 关键词：关联、规则、能力

  • 模块和组件

    • 模块定义：一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。
    • 组件定义：自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。
    • 两者区别：从逻辑的角度来拆分系统后，得到的单元就是“模块”；从物理的角度来拆分系统后，得到的单元就是“组件”。划分模块的主要目的是职责分离；划分组件的主要目的是单元复用。

  • 框架和架构

    • 框架定义：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
    • 架构定义：指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。
    • 两者区别：框架关注的是“规范”，架构关注的是“结构”。

  • 重新定义架构

    • 定义：软件架构指软件系统的顶层结构。

架构设计的目的

  • 架构设计的主要目的是为了解决软件系统复杂度带来的问题

    • 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
    • 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而是要识别出复杂点然后有针对性地解决问题。
    • 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

软件系统复杂度来源

  • 高性能

    • 高性能带来的复杂度主要有两方面

      • 单台计算机内部为了高性能带来的复杂度
      • 多台计算机集群为了高性能带来的复杂度

    • 单机复杂度

      • 批处理->进程->线程->CPU多核并行

    • 集群复杂度

      • 任务分配、任务分解

  • 高可用

    • 定义：系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

    • 计算高可用

      • 增加任务分配器、任务分配器与业务服务器之间的连接与交互、分配算法

    • 存储高可用

      • 存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响

    • 高可用状态决策

      • 通过冗余来实现的高可用系统，状态决策本质上就不可能做到完全正确
      • 决策形式：独裁式、协商式、民主式

  • 可扩展性

    • 具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化

    • 预测变化

      • 不能每个设计点都考虑可扩展性
      • 不能完全不考虑可扩展性
      • 所有的预测都存在出错的可能性

    • 应对变化

      • 方案1：将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”

        • 复杂点：系统需要拆分出变化层和稳定层、需要设计变化层和稳定层之间的接口
      • 方案2：提炼出一个“抽象层”和一个“实现层”

  • 低成本

    • 往往只有“创新”才能达到低成本目标

  • 安全

    • 功能安全：代码层面防范XSS 攻击、CSRF 攻击、SQL 注入等
    • 架构安全：访问控制策略

  • 规模

    • 规模带来复杂度的主要原因就是“量变引起质变”

      • 功能越来越多、数据越来越多

架构设计三原则

  • 合适原则

    • 合适原则宣言：“合适优于业界领先”
    • 不合适导致失败的几种原因：开发资源不足；技术积累不够；业务场景不存在

  • 简单原则

    • 简单原则宣言：“简单优于复杂”
    • 软件领域复杂性体现在：结构的复杂性、逻辑的复杂性

  • 演化原则

    • 演化原则宣言：“演化优于一步到位”

    • 软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大

      • 首先，设计出来的架构要满足当时的业务需要。
      • 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
      • 第三，当业务发生变化时，架构要扩展、重构，甚至重写。

架构设计流程

  • 识别复杂度

    • 将主要复杂度问题列出来（几个方面：高性能、高可用、可扩展、低沉本、安全、规模）
    • 根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题

  • 设计备选方案

    • 常见错误1：设计最优秀的方案

      • 根据架构设计原则中“合适原则”和“简单原则“的要求去设计

    • 常见错误2：只设计一个备选方案

      • 备选方案的数量以 3 ~ 5 个为最佳
      • 备选方案的差异要比较明显
      • 备选方案的技术不要只局限于已经熟悉的技术

    • 常见错误3：备选方案过于详细

      • 耗费了大量的时间和精力
      • 将注意力集中到细节中，忽略了整体的技术设计
      • 评审的时候其他人会被很多细节给绕进去，评审效果很差

  • 评估和选择备选方案

    • 360度环评：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。
    • 常见的质量属性点：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等
    • 按优先级选择

  • 详细方案设计

    • 详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行，一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

      • 架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解
      • 通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度
      • 如果方案本身就很复杂，那就采取设计团队的方式来进行设计