从零开始学架构-学习记录

零开始学架构-学习记录

一、架构设计的目的

  为了解决复杂度带来的问题
  主要的软件系统复杂度有高性能、高可用、可扩展、低成本、安全、规模几种。

二、架构设计原则

原则1：合适原则，合适的架构优于业界领先的架构
      真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理的将资源整合在一起发挥最大功效，并且能够快速落地。
原则2：简单原则，简单的架构优于复杂的架构
      软件领域的复杂性体现在两方面：结构的复杂性，逻辑的复杂性。
原则3：演化原则，架构需要随着业务的发展而不断演化 
     

三、架构设计流程

1、识别复杂度
2、设计备选方案
3、评估和选择备选方案
4、详细方案设计

备选方案360度环评

四、存储高性能

4.1 关系数据库

4.4.1 读写分离

目的：分散数据库读写操作的压力
基本原理：将数据库读写操作分散到不同的节点上
复杂度：主从复制延迟和分配机制

读写分离的基本实现

1、数据库服务器搭建主从集群，一主一从、一主多从都可以。
2、数据库主机负责读写操作，从机只负责读操作。
3、数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。
4、业务服务器将写操作发给数据库主机，将读操作发给数据库从机。

主从复制延迟常见解决方法:

1、写操作后的读操作指定发给数据库主机服务器。
2、都从机失败后再读一次主机。（二次读取）。
3、关键业务读写操作全部指向主机，非关键业务采用读写分离。

分配机制

将读写操作区分开来，然后访问不同的数据库服务器，一般有两种方式：程序代码封装和中间件封装。

程序代码封装（中间层封装）

程序代码封装指在代码中抽象一个数据访问层，实现读写操作分离和数据库服务器连接的管理
著名开源实现：TDDL

基本架构：

特点：

1、实现简单，而且可以根据业务做较多定制化的功能。、
2、每个编程语言都需要自己实现一次，无法通用，如果一个业务包含多个编程语言写的多个子系统，则重复开发的工作量比较大。、
3、故障情况下，如果主从发生切换，则可能需要所有系统都修改配置并重启。

中间件封装

1、中间件封装指的是独立一套系统出来，实现读写操作分离和数据库服务器连接的管理。
2、中间件对业务服务器提供 SQL 兼容的协议，业务服务器无须自己进行读写分离。
3、对于业务服务器来说，访问中间件和访问数据库没有区别，也就是说在业务服务器看来，中间件就是一个数据库服务器。
著名开源实现：MySQL Router、Atlas

基本架构：

特点：

1、能够支持多种编程语言，因为数据库中间件对业务服务器提供的是标准 SQL 接口。
2、数据库中间件要支持完整的 SQL 语法和数据库服务器的协议（例如，MySQL 客户端和服务器的连接协议），实现比较复杂，细节特别多，很容易出现 bug，需要较长的时间才能稳定。
3、数据库中间件自己不执行真正的读写操作，但所有的数据库操作请求都要经过中间件，中间件的性能要求也很高。
4、数据库主从切换对业务服务器无感知，数据库中间件可以探测数据库服务器的主从状态；
例如：向某个测试表写入一条数据，成功的就是主机，失败的就是从机。

4.1.2 分库分表

分库

按照业务模块将数据分散到不同的数据库服务器
复杂度：
1、join操作问题：需要跨库，可以使用ER或全局表来解决
2、事务问题：需要分布式事务来解决
3、成本问题：

分表
分为垂直分表和水平分表：

水平分布复杂度：

1、路由
  常见路由算法：范围路由、Hash路由、配置路由
2、join操作
3、count()操作
   常见两种处理方法:count()相加、记录数表
4、order by操作   

4.2 NoSQL

常见的4类NoSQL方案：

1、K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
2、文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
3、列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
4、全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

4.3 缓存

4.3.1 缓存穿透

缓存穿透是指缓存没有发挥作用，业务系统虽然去缓存中查询数据，但缓存中没有数据，业务系统需要再次去存储系统中查询数据。
两种情况:1、存储数据不存在；2、缓存数据生成耗费大量时间或资源

4.3.2 缓存雪崩

缓存雪崩是指当缓存失效(过期)后引起系统性能急剧下降的情况
缓存雪崩常见解决两种方法:1、更新锁机制；2、后台更新机制[(1)定时读取 (2)消息队列通知]

4.3.3 缓存热点

 缓存热点指大部分甚至所有业务请求都命中同一份缓存数据。

五、计算高性能

5.1单服务器高性能

单服务器高性能的关键之一：服务器采用的网络编程模型
网络编程模型两个关键：（1）服务器如何管理连接；（2）服务器如何处理请求
最终都和操作系统相关：（1）I/O模型：阻塞、非阻塞、同步、异步；（2）进程模型：单进程、多进程、多线程

PPC(Process per Conncetion):
    每次有新的连接就新建一个进程去专门处理这个连接的请求，这是传统的UNIX网络服务器所采用的模型。
prefork
    prefork就是提前创建进程（per-fork）。默认情况下最大支持256个并发连接。
TPC(Thread per Conncetion)
    每次有新的连接就新建一个线程去专门处理这个连接的请求。
perthread
    预先创建线程。Apache服务器的MPM worker模式本质就是一种perthread方案，Apache服务器会创建多个进程，每个进程里面在创建多个线程。
    这样做主要考虑稳定性，即使某个子进程里面的某个线程异常导致整个子进程退出.还有有其他提供服务。Apache服务器的MPM worker模式默认支持16 X 25 = 400 个并发处理线程。
Reactor（Dispatcher） 
   基础是I/O多路复用
   三种典型实现方案：
      单Reactor单进程/单线程
      单Reactor多线程
      多Reactor单进程（无性能优势、实际没有应用）
      多Reactor多进程/多线程 ：Nginx采用的是多Reactor多进程模式；Memcache、Netty采用的是多Reactor多线程模式。 
Proactor(非阻塞同步网络模型)      
        

5.2 集群高性能（负载均衡）

常见的负载均衡系统包括3种：
    DNS负载均衡：一般用来实现地理级别的均衡
    硬件负载均衡：用于实现集群级别的负载均衡
    软件负载均衡：用于实现机器级别的负载均衡
负载均衡算法：
    任务平分类：轮询、加权轮询
    负载均衡类：负载最低优先
    性能最优类：
    Hash类：源地址Hash、ID Hash

六、 CAP

6.1 CAP理论

    在一个分布式系统（指相互连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、
可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
  
1、一致性（Consistent）：
  对某个指定的客户端来说，读操作保证能返回最新的写操作结果。
2、可用性（Availability）
  非故障节点在合理的时间内返回合理的响应（不是错误和超时的响应）
3、分区容错性（Partition Tolerabce）
  当出现网络分区后，系统能够继续“履行职责”    
CAP细节：
 1、CAP关注的粒度是数据，而不是整个系统
 2、CAP是忽略网络延迟的
 3、正常运行情况下，不存在CP和AP的选择，可以同时满足CA
 4、放弃并不等于什么都不做，需要为分区恢复后做准备

6.2 ACID、BASE

ACID:
 ACID的应用场景是数据库事务，CAP关注的是分布式系统数据读写
 1、Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
 2、Consistency（一致性）：在事务开始之前和事务结束后，数据库的完整性没有被破坏。
 3、Isolation（隔离性）：数据库允许多个并发事务同时对数据进行读写和修改的能力。 隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
    事务隔离级别：读未提交（Read uncommitted）、读提交（Read committed）、可重复读（repeatable read）、串行化（Serializable）                                
 4、Durability（持久性）：事务处理结束后，对数据的修改是永久的，即便系统故障也不会丢失。
 
BASE：
 BASE是CAP理论中AP方案的延伸
 1、基本可用（Basically Available）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
 2、软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是CAP理论中的数据不一致。
 3、最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。