架构演进了解技术处于什么位置，对分布式系统有一个大概的了解。架构的演进流程: 单机架构、应用数据分离架构、应用集群架构、

明确为什么要学习架构的演进

了解技术处于什么位置
对分布式系统有一个大概的了解

架构的演进流程: 单机架构、应用数据分离架构、应用集群架构、主从分离架构、冷热分离架构（redis)、垂直拆分架构（更进一步的分布式数据库）、微服务架构、容器编排架构（docker）；

单机架构

什么是单机架构

单机架构就是一个服务器内部同时运行应用服务和数据库服务。主要出现在计算机早期的系统设计。

单机架构的模型

单机架构的优缺点

优点

单机架构的优点是部署简单、成本低。
没有网络延迟，处理少量请求效率高。

缺点

并发量增大，资源竞争容易导致性能瓶颈
系统的扩展性比较差。
系统解耦性高，发生故障会产生连锁反应

单机架构的技术案例

java中的tomcat，就可以看作一个应用服务的软件； MySQL就可以看错数据库服务的软件。然后这两个服务在同一个服务器中对外提供服务，就叫做单机架构。

用户向浏览器/APP发起一个请求。

浏览器请求中的域名去dns进行域名解析，得到目标服务器的目的IP。

浏览器根据IP找到目标服务器。找到提供服务的应用。

应用根据请求中的要求直接从MySQL中insert数据或者check数据，无需网络传输。

完成服务进行返回。用户得到反馈。

应用数据分离架构

什么是应用数据分离架构

应用数据分离架构是将应用服务和数据库分离开来，两个服务分别部署于不同的服务器。两种服务专注于自己的服务。

架构模型

应用数据分离架构的优缺点

优点

应用服务与存储服务进行分离，让两者可以独立设计。
提高了系统的扩展性，使应用服务和数据库都可以进行横向扩展。
应用与存储独立使用自己的cpu资源，避免了两种服务之间的资源竞争。

缺点

提高了系统的成本，提高运维成本。
应用服务与数据库服务之间数据的传输效率变为网络传输，延迟增加。
当并发量和数据量进一步提升，应用服务器可能存在瓶颈。

技术案例

原本的单机架构应用程序直接从数据库中读取数据，是在一台服务器中读取，也就是在内存中的读取。应用数据分离架构变成了应用服务和数据库服务通过网络进行通信。

应用服务集群架构

什么是应用服务集群架构

将应用服务横向扩展——添加多台应用服务器分担并发请求。通过一台负载均衡器接收所有并发请求，然后通过算法将请求分发给多台服务器。

当请求的并发量提升，提升到一台应用服务器已经承受不住了，那么可以添加多台应用服务器分担这些并发请求。

但是只添加应用服务器如何分配这些并发请求就成了问题，所以需要在上层布置一台负载均衡服务器接收所有的并发请求，然后比较均匀的分发给下层的应用服务器。——这个负载均衡服务器要能承受所有的并发请求。

这么做后，理论上，应用服务器不够用，添加应用服务器。负载均衡服务器不够用，再在负载均衡器上面布置处理并发能力更强的负载均衡服务器，那么应用服务器就不会再称为瓶颈。

架构模型

应用服务集群架构优缺点

优点

应用服务器不再成为瓶颈。
应用服务器部署更加灵活，可以根据阶段用户请求的并发量部署应用服务器。
多冗余，系统可用性增强，单个应用服务器崩溃，不影响其他节点的使用，少影响整个业务的运行。

缺点

硬件成本增加，系统的复杂度提升，运维的成本增加
需要增加服务器之间数据同步机制。
当并发请求很多，数据库服务器可能称为瓶颈。

技术案例

当一台应用服务器不够用，添加多台服务器，并使用Nginx来作为负载均衡器。但是负载均衡器也有并发上限：

Nginx的并发量为50000左右，如果超过了，就只能多家几台Nginx，并且再上加一层负载均衡器，可以用LVS。

LVS的并发量百万级别，如果超过了，只能多增加几台LVS，并且再往上加一层负载均衡器，可以使用F5.

F5是硬件设备，价格高，并发量是千万级别，如果超过了，就要使用dns了， dns不仅仅是域名转换服务，也可以作为全局的负载均衡器。

读写分离架构

什么是读写分离结构

读写分离架构针对于数据库。数据库原本负责读写两个功能。读写分离架构就是添加多台数据库服务器，其中主数据库一般负责写，从数据库一般负责读。

读写分离架构也叫做主从分离架构，一台数据库服务器作为主服务器，然后为这台主服务器添加冗余（从服务器）。这样做的好处有很多，下面优缺点提到。

架构模型

优缺点

优点

可以应对更高的并发量，读写分离，从数据库分担了主数据库的读请求。
高可用性，增加了系统的冗余，当主数据库崩溃时，从数据快速顶替主数据库，不影响用户体验。
从数据库可以进行横向扩展，使数据库对于读具有扩展性。读请求理论上不再称为瓶颈。
主数据和从数据库通过网络实现数据同步一致。

缺点

硬件资源的成本增加，运维成本增加
单点写瓶颈，写并发极高时主数据称为瓶颈
数据不一致性，数据网络同步需要时间，用户写入后想要立即读取，可能读取不到最新更新信息。
主数据库同步时崩溃会导致数据丢失。

技术案例

写情况

用户使用域名访问服务器，先访问dns， dns返回一个IP地址。

用IP地址进行路由访问应用服务器。访问哪一个？先到达最外层的负载均衡服务器，由最外层的负载均衡服务器将这个请求分发下层自己管理的某个服务器。

这个服务器接收到请求，如果这个服务器还是一个负载均衡服务器，就重复刚刚类似的操作。

如果这个服务器是一个应用服务器，那么应用服务器对请求进行解析。

如果是写请求，就去主数据库中写入数据，将数据通过网络发送给主数据库服务器。然后就返回写入情况，是写入成功还是失败。对于应用服务集群来说，应用服务器集群一层一层向上返回请求处理情况；对于主从数据库集群来说，主数据库要将刚刚写入的数据同步给从数据库。

读情况

用户拿着域名访问应用服务器，然后域名交给dns进行解析，返回IP地址。

浏览器用IP地址路由到对应的服务集群中。具体访问哪一个应用服务节点，由上层的负载均衡服务器一层

一层向下分发决定。

应用服务节点拿到请求后，对请求进行解析。解析成功认为是读请求，那么就直接去主从数据库集群里面的从数据库节点读取数据。然后返回读取结果。

冷热分离架构

什么是冷热分离架构?

冷热分离是将数据分为冷数据和热数据。热数据存放在内存缓存中。冷数据放在磁盘中。一个数据库服务器或者集群作为缓存数据库服务器，存储热数据。然后另一个数据库集群用来存储冷数据。

架构模型

优缺点

优点

分担了读取的压力，减少了从库的数量，优化成本。
利用内存存储数据，内存的读取速度远高于磁盘IO。提高了数据查询的效率，优化效率。

缺点

增加系统的复杂性，增加运维成本。
数据同步过程中如果数据库崩溃，造成数据丢失和数据不一致问题。
写的高并发仍然可能是系统的瓶颈。

技术案例

读数据

发送请求， dns返回IP地址，然后路由到应用服务集群，应用服务集群再一系列分发处理将请求送到应用服务器。

当解析后，如果是读数据，那么就看一下缓存服务器中是否有这个数据，如果有直接返回。

如果没有找到对应的数据，就要去主从数据库集群中去读取数据。

写数据

写入数据时是否写入到缓存数据中还是写入到主数据库中根据业务场景决定，一般情况下直接写入到主数据库。

写入到主数据库后，主数据库有两种策略：一种是直接同步到缓存数据库，一种是给缓存数据库发送一个数据失效标记。第一种的优点是高一致性，但是高延迟。第二种的优点是低延迟，但是最终一致性（允许数据短暂不一致）

垂直分库架构/分布式数据库

什么是垂直分库架构

根据业务的模块划分，将不同业务的数据放到不同的数据库中。比如一个电子商城有商品业务，用户业务，交易业务。那么数据库对应的里面有商品表，用户表，交易表。那么采用垂直分库架构，就是将里面的每一个业务板块的表作为单独的一个库：商品库，用户库，交易库。

架构模型

整个的流程就是用户想要访问一下交易服务，但是交易服务可能要用到商品服务，所以就去访问了一下商品服务，然后商品服务去检查热点数据，找到了，就返回结果然后把服务结果返回给交易服务。交易服务拿到结果后，再去热点数据进行查找，没找到，就又去冷库里面读取，然后读取到数据返回给用户。

优缺点

优点

减少了不同业务之间的资源竞争，增加了索引的效率。
显著分担了并发请求，增加了应对高并发尤其是写并发的能力。
减少了业务代码之间的耦合，业务出现问题更容易定位问题的位置。

缺点

跨库查询困难，无法直接使用JOIN
数据一致性问题，比如订单库增加，商品库就要减少。
系统的复杂性上升，运维成本增加

技术案例

分布式数据库

分布式数据库架构是垂直分库架构的进一步演进。垂直分库架构通过业务模块纵向拆分数据库。而分布式数据库属于根据数据分片横向拆分数据库。同时分布式数据库还有多副本、分布式事务、负载均衡、一致性模型、透明性等特性。

分片：分片就是在按照业务模块拆分的基础上。对每一个业务数据库再划分为一个一个的子集，即进行横向扩展。就比如原本用户表、商品表都是使用一个主数据，多个从数据库。现在将每个表划分为多个子集，每个子集又有自己的主库和从库。

多副本：将每一个分片都设计成一个主从集群，分布式数据库应用了读写分离架构架构来提高冗余和提高并发处理能力。

分布式事务：对于垂直分库架构来说，跨库事务是难点。分布式数据库支持跨库的事务处理。保证多个节点的（分片之间或者主从之间)的ACID。这也说明分布式数据库具有一致性的特性，比如TiDB的强一致性。

透明访问：提供统一接口，底层设计对上层透明。

负载均衡：请求自动被分发给流量少的分片，分片之间能够流量均衡。