架构设计思维导图模板_ProcessOn思维导图、流程图

定义

系统与子系统

系统

泛指由一群关联的个体组成， 根据某种规则运作， 能完成个别元件不能单独完成的工作群体。 它的意思是“总体”“整体”“联盟”

子系统

子系统也是由一群有关联的个体所组成的系统， 多半会是更大系统中的一部分

模块与组件

软件模块

是一套一致而互相有紧密关联的软件组织。 它分别包含了程序和数据结构两部分。 现代软件开发往往利用模块作为合成单位。 模块的接口表达了由该模块提供的功能和调用它时所需的元素。 模块是可能被分开编写的单位。 这使他们可再用和允许多个人员同时协作、编写及研究不同模块

软件组件

自包含、可编程的、可重用的、与语言无关的软件单元， 软件组件可以很容易被用于组装应用程序中

框架与架构

软件框架

通常指为了实现某个业界标准 或完成特定基本任务的软件组件规范， 也指为了实现某个软件组件规范时， 提供规范所要求之基础功能的软件产品

软件架构

指软件系统的“基础结构”， 创造这些基础结构的准则， 以及对这些结构的描述

目的

为了解决软件复杂度带来的问题

复杂度维度

性能

高可用性

可扩展性

安全性

成本

架构设计原则

合适原则

合适优于业界领先

简单原则

简单优于复杂

演化原则

演化优于一步到位

架构设计流程

1.识别复杂度

2.设计备选方案

3.评估和选择备选方案

4.详细方案设计

数据库集群

读写分离

分库分表

分库

问题

1.无法使用join

2.分布式事务问题

3.成本问题

分表

垂直分表

水平分表

路由

范围路由

常见以ID进行分段， 一般是100W~2000W之间， 优点：扩展方便 缺点：可能数据分布不均

问题是可能造成分段数据不均匀

hash路由

选取一列或多列值进行hash运算， 然后根据结果放到不同的表中， 复杂点在于初始表数量的选取， 表太多维护麻烦，表太少单表性能低， 增加子表数量非常麻烦，所有数据需要重排 优点：数据分布均匀 缺点：扩展麻烦

配置路由

用一张独立的表来记录路由信息， 优点：设计简单，使用灵活，扩展方便 缺点：需要多查询一次，性能受影响，路由表本身不能太大

join

水平分表后，数据分散在多个表中， 如果需要与其他表进行 join 查询， 需要在业务代码或者数据库中间件中进行多次 join 查询， 然后将结果合并

count

水平分表后，虽然物理上数据分散到多个表中， 但某些业务逻辑上还是会将这些表当作一个表来处理。 具体做法是在业务代码或者数据库中间件中对每个表进行 count() 操作， 然后将结果相加

order by

水平分表后，数据分散到多个子表中， 排序操作无法在数据库中完成， 只能由业务代码或者数据库中间件分别查询每个子表中的数据， 然后汇总进行排序

NoSQL

K-V存储

解决关系数据库无法存储数据结构的问题，以 Redis 为代表

文档数据库

解决关系数据库强 schema 约束的问题，以 MongoDB 为代表

列式数据库

解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表

全文搜索引擎

解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表

数据存储选型

1.管理型系统，如运营类系统，首选关系型

2.大流量系统，如电商单品页的某个服务，后台选关系型，前台选内存型

3.日志型系统，原始数据选列式，日志搜索选倒排索引

4.搜索型系统，指站内搜索，非通用搜索，如商品搜索，后台选关系型，前台选倒排索引

5.事务型系统，如库存、交易、记账，选关系型+缓存+一致性协议，或新型关系数据库

6.离线计算，如大量数据分析，首选列式，关系型也可以

7.实时计算，如实时监控，可以选时序数据库，或列式数据库

缓存

缓存穿透

缓存穿透是指缓存没有发挥作用， 业务系统虽然去缓存查询数据， 但缓存中没有数据， 业务系统需要再次去存储系统查询数据

缓存雪崩

缓存雪崩是指当缓存失效（过期）后引起系统性能急剧下降的情况

缓存热点

虽然缓存系统本身的性能比较高，但对于一些特别热点的数据， 如果大部分甚至所有的业务请求都命中同一份缓存数据， 则这份数据所在的缓存服务器的压力也很大

缓存热点的解决方案就是复制多份缓存副本， 将请求分散到多个缓存服务器上， 减轻缓存热点导致的单台缓存服务器压力

负载均衡

分类

DNS负载均衡

优点

实现简单、成本低

就近访问，提升访问速度

缺点

更新不及时

修改DNS配置后，缓存没有及时刷新

扩展性差

DNS 负载均衡的控制权在域名商手上

分配策略比较简单

DNS 负载均衡支持的算法少， 无法感知后端服务器状态

硬件负载均衡

优点

功能强大

全面支持各层级的负载均衡， 支持全面的负载均衡算法，支持全局负载均衡

性能强大

硬件负载均衡可以支持 100 万以上的并发

稳定性高

经过了良好的严格测试，经过大规模使用，稳定性高

支持安全防护

硬件均衡设备除具备负载均衡功能外， 还具备防火墙、防 DDoS 攻击等安全功能

缺点

价格昂贵

扩展性差

硬件设备可以配置，但无法扩展和定制

软件负载均衡

优点

简单

易于部署和维护

便宜

灵活

4 层和 7 层负载均衡可以根据业务进行选择； 也可以根据业务进行比较方便的扩展

缺点

性能一般

Nginx大约能支持5W并发

功能没有硬件负载均衡那么强大

不具备防火墙和防DDos攻击等安全功能

组合原则

DNS 负载均衡用于实现地理级别的负载均衡

硬件负载均衡用于实现集群级别的负载均衡

软件负载均衡用于实现机器级别的负载均衡

算法

分类

任务平分类

负载均衡系统将收到的任务平均分配给服务器进行处理， 这里的“平均”可以是绝对数量的平均，也可以是比例或者权重上的平均

负载均衡类

负载均衡系统根据服务器的负载来进行分配， 这里的负载并不一定是通常意义上我们说的“CPU 负载”， 而是系统当前的压力，可以用 CPU 负载来衡量， 也可以用连接数、I/O 使用率、网卡吞吐量等来衡量系统的压力

性能最优类

负载均衡系统根据服务器的响应时间来进行任务分配， 优先将新任务分配给响应最快的服务器

Hash 类

负载均衡系统根据任务中的某些关键信息进行 Hash 运算， 将相同 Hash 值的请求分配到同一台服务器上。 常见的有源地址 Hash、目标地址 Hash、session id hash、用户 ID Hash 等

轮询

收到请求后，按照顺序轮流分配到服务器上

优点

简单

缺点

无法感知服务运行状态

加权轮询

根据服务器权重进行任务分配，这里的权重一般是根据硬件配置进行静态配置的， 采用动态的方式计算会更加契合业务，但复杂度也会更高

优点

简单但比普通轮询更好

缺点

无法感知服务运行状态

负载最低优先

将任务分配给当前负载最低的服务器， 这里的负载根据不同的任务类型和业务场景，可以用不同的指标来衡量

优点

可以感知服务运行状态

缺点

实现复杂

性能最优

优先将任务分配给处理速度最快的服务器，通过这种方式达到最快响应客户端的目的

优点

可以感知服务运行状态

缺点

实现复杂

hash

根据任务中的某些关键信息进行 Hash 运算， 将相同 Hash 值的请求分配到同一台服务器上， 这样做的目的主要是为了满足特定的业务需求