软件架构师之基础理论

架构基础：

1. 介绍架构设计的本质、历史背景和目的，然后从复杂度来源以及架构设计的原则和流程来详细介绍架构基础。

2. 架构定义：三大易混淆核心概念

   • 系统与子系统：

     系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体。

     它的意思是“总体”“整体”或“联盟”。

   • 模块与组件：

     • 模块：业务逻辑角度拆分

     • 组件：物理部署角度拆分

   • 框架与架构：

     • 框架(Framework)：软件框架（Software framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。例如mvc, mvvm,

     • 架构(Architecture)：软件架构指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述。

       4+1视图：场景视图（用例图，需求）、逻辑视图（类图）、物理视图（物理架构图）、处理流程视图（流程图，时序图）和开发视图（e.g. MVC, MVVM, MVP） https://zhuanlan.zhihu.com/p/352590602

       4R定义架构：软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）

       Rank、Role 和 Relation 是通过系统架构图来展示的。

       Rule 是通过系统序列图（System Sequence Diagram）来展示的。

3. 架构设计的历史背景

   机器语言 -> 汇编语言 -> 高级语言 -> 第一次软件危机与结构化程序设计 -> 第二次软件危机与面向对象

4. 架构设计目的

   • 遵循这条准则能够让“新手”架构师心中有数，而不是一头雾水。

     架构也是为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

   • 从哪里开始下手进行架构设计呢？

     通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。

   • 识别核心特点不需要面面俱到

     而是要识别出复杂点然后有针对性地解决问题。

   • A & B该选哪一个？

     理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

   • 实例：学生管理系统，复杂性分析

     从性能， 可扩展性， 高可用，安全性，成本几方面分析

5. 复杂度来源----高性能

   多台计算机集群为了高性能带来的复杂度， 而计算机内部复杂度最关键的地方就是操作系统。

   实现高性能方式:

   • 任务分配，增加机器，实际性能为理论性能8折，首先增加硬件数量，未达到预期的性能提升。

     常用任务分配器有DNS 轮询、智能 DNS、CDN（Content Delivery Network，内容分发网络），GSLB 设备（全局负载均衡)

   • 任务分解， 提升性能的几大因素:

     • 简单的系统更加容易做到高性能。

     • 可以针对单个任务进行扩展。

     • 要把握粒度，适当拆分，否则增加系统调用复杂度

6. 复杂度来源----高可用

   本质通过“冗余”实现， 数据 + 逻辑 = 业务

   • 计算高可用，任务分配器有主备，主主。

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

   • 高可用状态决策

     常见决策方式：独裁式， 协商式主备决策（通讯中断，主备无法知道对方状态，可增加2,3连接），民主式（有脑裂问题）

   • 复杂度来源----可扩展性

     可扩展性的系统，有两个基本条件：正确预测变化和完美应对变化。

     • 预测变化：

       复杂性：不能每个都可扩展，不能不扩展，预测有错误

       心法：只预测 2 年内的可能变化，不要试图预测 5 年甚至 10 年后的变化。

     • 应对变化：

       方案一：提炼出“变化层”和“稳定层”，核心思想是通过变化层来隔离变化。

       方案二：提炼出“抽象层”和“实现层”，核心思想是通过实现层来封装变化。典型的实践就是设计模式和规则引擎

       方法论：Rule of three，Three Strikes And You Refactor，事不过三，过三重构，1 写 2 抄 3 重构。即相同的业务需求出现三次及以上则考虑重构。

7. 复杂度来源----低成本、安全、规模

   • 低成本：架构设计的附加约束。复杂度体现在，往往只有“创新”才能达到低成本目标。

   • 安全：分两类，功能上的安全 和 架构上的安全。

     • 功能安全：XSS 攻击、CSRF 攻击、SQL 注入、Windows 漏洞、密码破解等

     • 架构安全：防火墙

   • 规模：主要原因就是“量变引起质变”

     • 功能增加：复杂度计算公式：系统的复杂度 = 功能数量 + 功能之间的连接数量<V (G)=e-n+2>
     • 数据增加：mysql 推荐5000W行

8. 架构设计三原则：合适原则、简单原则、演化原则

   • 合适原则：合适优于业界领先。

     • 失败1：没那么多人，却想干那么多活，是失败的第一个主要原因。

     • 失败2：没有那么多积累，却想一步登天，是失败的第二个主要原因。

     • 失败3：没有那么卓越的业务场景，却幻想灵光一闪成为天才，是失败的第三个主要原因。

       总结：真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地

   • 简单原则：简单优于复杂。《UNIX编程》KISS原则（Keep It Simple, Stupid!）

     软件领域复杂性：结构的复杂性、逻辑的复杂性，需求的变更是复杂性的根本原因

   • 演化原则：

     根据业务发展不断变化这个本质特点，软件架构设计其实更加类似于大自然“设计”一个生物，通过演化让生物适应环境，逐步变得更加强大。

     软件架构设计同样是类似的过程：

     • 首先，设计出来的架构要满足当时的业务需要。
     • 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
     • 第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。

9. 架构设计原则案例：

10. 架构设计流程：第一步，识别复杂度

    • 场景：实际上大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误，即使真的认为要同时满足这三方面的要求，也必须要进行优先级排序。

    • 正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题

    • TPS、QPS，指标峰值2~8倍

11. 架构设计流程：第二步，设计备选方案

    成熟的架构师需要对已经存在的技术非常熟悉，

    对已经经过验证的架构模式烂熟于心，

    然后根据自己对业务的理解，

    挑选合适的架构模式进行组合，

    再对组合后的方案进行修改和调整。

    • 第一种常见的错误：设计最优秀的方案。

    • 第二种常见的错误：只做一个方案。

      • 备选方案的数量以 3 ~ 5 个为最佳。

      • 备选方案的差异要比较明显。

      • 备选方案的技术不要只局限于已经熟悉的技术。

    • 第三种常见的错误：备选方案过于详细。

      做法是备选阶段关注的是技术选型，而不是技术细节，技术选型的差异要比较明显。

12. 架构设计流程：第三步，评估和选择备选方案

    • 几种指导思想：最简派、最牛派、最熟派、领导派

    • 方法论：“360 度环评表”！具体的操作方式为：列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。选择方式为按优先级选择

    • 常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。

    • 质量属性资源评估和未来业务发展关系 = 当前的业务规模 * (2 or 4)

13. 架构设计流程： 第四步，详细方案设计

    • 方法论：

      • 架构师不但要进行备选方案设计和选型，还需要对备选方案的关键细节有较深入的理解。
      • 通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度

    • 可能产生的问题：

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