A. 系统架构概要

A. 系统架构概要

概述

• 历史
  • 第一次软件危机(20世纪60年代~20世纪70年代)
    • 解决方案：抛弃GOTO的结构化程序通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。
  • 第二次软件危机与面向对象(20世纪80年代)
    • 第一次软件危机的根源在于软件的“逻辑”变得非常复杂，而第二次软件危机主要体现在软件的“扩 展”变得非常复杂。
• 概念软件架构指软件系统的顶层结构
  • 系统与子系统
  • 模块与组件
    • 模块： 从业务角度分析，功能职责
    • 组件：从技术角度分析，功能复用
  • 框架与架构
    • 框架关注的是规范
    • 架构关注的是结构
• 基本思想
  • 技术：关键思维是逻辑和实现
    • 技术的基础是算法，解决的是具体的业务问题
  • 工程：工程的关键思维是判断和取舍
    • 工程的基础是架构和项目管理
      • 架构：解决的是具体的业务场景
      • 项目管理：解决的是人员协作问题
  • 行业解决方案：分析和解决领域问题的能力，制定行业标准
• 架构图
  • 逻辑/业务角度
  • 技术/物理角度
  • 架构 4 +1 视图
• 架构四元素：问题、模块、规则、系统
• 本质：面对复杂和变更的挑战，在有限的资源条件下，保证业务的响应
• 目的：架构设计的主要目的是为了解决软件系统复杂度带来的问题。

系统复杂度 - 高性能

• 衡量指标
  • 响应时间、TPS、服务器资源利用率等客观指标
  • 用户的主观感受（从程序员、业务用户、终端用户/客户不同的视角，可能会得出不同的结论）
• 单台计算机内部为了高性能带来的复杂度；
  • 软件方面
    • 批处理
    • 多进程
    • 多线程
  • 硬件方面：多CPU
    • SMP（Symmetric Multi-Processor，对称多处理器结构）
    • NUMA（Non-Uniform Memory Access，非一致存储访问结构）
    • MPP（Massive Parallel Processing，海量并行处理结构）
• 多台计算机集群为了高性能带来的复杂度。
  • 任务分配：任务分配器
  • 任务分解：任务分解带来的性能收益是有一个度的，并不是任务分解越细越好，而对于架构设计来说，如何把握这个粒度就非常关键了。
    • 简单的系统更加容易做到高性能
    • 可以针对单个任务进行扩展
• 解决方案
  • 垂直维度
    • CPU：算法优化、增加核数
    • 内存：增大内存
    • 磁盘IO：固态硬盘
    • 网络IO：升级带宽
  • 水平维度
    • 功能分解：基于功能将系统分解为更小的子系统
    • 多实例副本：同一组件重复部署到多台不同的服务器
    • 数据分割：在每台机器上都只部署一部分数据

系统复杂度 - 高可用：无中断、无单点、冗余机器

• 核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。
• 衡量指标
  • 网站不可用时间=完成故障修复的时间点 - 故障发现的时间点
  • 网站年度可用时间=年度总时间 - 网站不可用时间
  • 网站年度可用性=(网站年度可用时间/年度总时间) x 100%
• 可用性类型
  • 计算高可用
  • 存储高可用 - 数据一致性
    • 独裁式/单点
    • 协商式/主备
    • 民主式：一主多从
  • 集群高可用
    • 服务治理
    • 监控
• 解决方案
  • 架构角度
    • 应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。
    • 服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。
    • 数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。

系统复杂度 - 可扩展

• 目标
  • 伴随业务的发展、创新，运行环境的变化，对技术也就提出了更多、更高的要求。能够快速响应上述变化，并最大程度降低对现有系统的影响，是设计可扩展性好的架构的主要目的。
• 核心：正确预测变化、完美封装变化
  • 在业务维度，预测变化
  • 在技术维度，封装变化
    • 其他手段
      • 使用分布式服务(框架)构建可复用的业务平台。
      • 使用分布式消息队列降低业务模块间的耦合性。
• 原则：低耦合、高内聚

其他

• 低成本
  • 往往只有“创新”才能达到低成本目标
    • 引入新技术。
    • 开创一个全新技术领域。
• 安全性
  • 类型
    • 功能安全：比如说系统漏洞
    • 架构安全
    • 数据安全性
• 可监控
  • 需要考虑到监控问题，能够实时检测到故障
• 可追踪调试
  • 一旦发现故障，如何快速定位
• 规模：规模带来复杂度的主要原因就是“量变引起质变”
  • 功能越来越多，导致系统复杂度指数级上升
  • 数据越来越多，系统复杂度发生质变