分布式架构演进

单机架构：

早期阶段互联网刚刚发展，对于某一个应用来说短时间内的访问量不高，总是能在一台主机的承受范围之内，这时往往会把应用服务器和数据库服务器整合在一台主机之上，服务器之间直接通过进程通信的方式进行数据交换。这种模式就叫做单机架构。

单机架构的优点是部署简单，成本较低，便于维护，缺点也很显著，那就是存在严重的性能瓶颈，由于各个服务器都部署在一台主机之上，一旦后期用户的访问量急剧上升，各个服务对有限的硬件资源的竞争会非常激烈，导致访问速度严重下降。其次，由于数据库缺乏独立性，与应用服务器耦合度较高，受到破坏的概率较大，异地容灾能力差。因此演化出了应用数据分离架构。

应用数据分离架构：

顾名思义，就是把应用服务器和数据库服务器拆分开来，部署在不同的主机上，相互之间通过网络来通信
这种架构以较低的成本一定程度上降低了并发场景下的资源竞争问题，并且保证了数据库的独立性，提高其异地容灾能力，但是受限于能够提供服务的服务器数量，仍然无法满足海量数据的并发请求。因此又进一步产生出了应用数据集群架构。

应用数据集群架构：

所谓集群，简单得理解为提供同一性质的服务的一组组件集合，既然先前的应用数据分离架构是由于服务器数量的问题导致的性能瓶颈，那么应用数据集群架构的解决方法就是多加几个应用服务器(一般数据库服务器不会部署在多台主机之上，为了保证数据的一致性)

为了避免某一个应用服务器繁忙而其余应用服务器闲置的不合理情况，往往还会搭配使用负载均衡的中间件来实现负载均衡，比较常见的是Nginx，它通过特定的算法将用户的请求合理得分配给它所管辖的应用集群。
应用数据集群架构的优点是一定程度上提高了系统可用性，由于具有多个应用服务器的存在，即使某一个应用服务器因为一些不可控的原因而宕机，也不会导致整个系统的崩溃，缺点是数据库仍然是单点服务，一旦数据库发生崩溃，必然会导致整个系统出现问题，并且在海量请求的情况下对于数据库的读写请求非常频繁，要知道磁盘的访问速度是比较慢的，加上数据库需要保证一致性，必然会造成访问速度的下降。因此又进一步的衍生除了读写分离架构

读写分离架构

读写分离架构主要针对数据库进行优化，实际应用过程中发现读取请求的频次远远高于写入请求，既然如此，何不把数据库多备几份，只留作一份充当写数据库，把剩余的数据库充当读数据库，这就是读写分离架构。每一个读数据库平均分配着来自应用服务器的读取请求，至于少量的写入请求，由写数据库进行负责。

**优点：**由于多个读数据库的合力协作，大大提高了数据库的读取数据瓶颈，并且提高了数据库的安全性(即使有一个数据库崩溃，还能有另一个数据库补上)
**缺点：**依然无法满足更大数量的请求，对于一些热点数据的频繁访问，数据库起到作用是有限的，此时需要引入缓存技术；此外为了保证数据库的一致性(写数据库发生修改时必须短时间内同步给所有的读数据库)，对于网络的要求更为苛刻。

冷热分离架构：

上面提到了热点数据，所谓热点数据就是用户频繁访问的数据，实际中热点数据可以解决用户80%的需求，而其本身只占全部数据的20%，因此可以考虑引入缓存技术来实现内存级别的保存热点数据(内存读取速度远高于磁盘读取速度)，提高读取效率的同时减低数据库的负载，这就是冷热分离架构

虽然引入缓存技术给性能上的提升非常显著，但与此同时大大提高了系统维护成本，也需要应对偶现的缓存击穿，缓存穿透，缓存雪崩问题

缓存击穿:数据不在缓存中，只在数据库中
缓存穿透:数据既不在缓存，也不再数据库
缓存雪崩:缓存一旦崩溃，先前保存的数据全部丢失

分库分表架构：

上述所提到的所有架构，数据库终归是要保存所有的数据，随着时间的推移，数据库的体量愈来愈大，针对数据查询的效率逐步降低，可以通过将一个库拆分成多个库，一张表拆分成多张表的方式减少单库单表的数据量，提高查询效率

微服务架构：

微服务架构主要是针对应用服务器的优化，旨在于降低应用服务器的耦合度，提高其内聚性，方便人员维护。以一个电商应用服务器为例，应用服务器中应该具有用户模块，商品模块和交易模块，在先前的架构中，这三者是整合在一起的，带来的直接问题就是模块之间强耦合，扩展性差，微小的改动就需要整个服务器重新发布，牵一发而动全身，这是不合理的。因此需要把每一个模块细分出来，单独分配一个服务器。

容器编排架构：

容器编排架构主要针对某一块微服务的优化，未引入容器技术时，微服务之间的运行由于处于一个共享的空间中，出现数据资源冲突的可能性较高，并且不同的微服务之间所需要的环境配置各有不同，一旦涉及到增删操作，就需要改动环境，而这个过程容易出错，因为微服务之间的环境强耦合了，为此可以引入容器的概念，将每一个微服务所对应的代码，数据，环境配置打包为一个整体，分配到某一个服务器上，服务器中的各个容器相互隔离，保证各自的独立性，避免了环境冲突