本篇开始进行对于Docker的学习，Docker是一个陌生的词汇，那么本篇开始就先从技术架构的角度出发，先对于技术架构有一个基本的认识

基本概念

1. 应用和系统：为了完成一整套服务的一个程序或者是一组相互配合的程序
2. 模块和组件：当应用量比较庞大时，会把整个目标划分为多个模块和组件
3. 分布式：系统中的多个模块被部署到不同的服务器上，那这样就可以叫做是分布式系统，换句话说，比如平时的web服务器和数据库放在不同的服务器上，那这就是一个分布式的系统
4. 集群：部署在多个服务器上，为了实现一个特定功能的组件，那这个整体就被叫做是集群，比如MySQL会工作在不同的服务器上，一起来进行数据库的服务目标，这样就可以被叫做是一组数据库集群
5. 中间件：一类提供不同应用程序用户相互通信的软件，也就是说是不同技术工具或者是数据库之间的桥梁，这种就是中间件
6. 容器：可以让开发者把应用以及依赖放到一个可以移植的镜像中，发布到各种操作系统的机器上，实现出一个虚拟化的功能
7. 容器编排：这是一个用于进行管理云平台上多个主机上的容器化的应用，可以让部署容器化的应用更加简单高效

架构演进

现在假设做了一个项目，这个项目会随着时间的推移不断复杂，那么就需要不断的更换架构

单机架构

在项目的最初期，由于工程量比较小，所以使用最基础的内容就可以了，因此，使用普通的基础的单机架构即可：

这也是最基础的架构，把所有的内容都放到了单机服务器上

应用数据分离架构

随着工程的升级，此时随着数据越来越多，原来的单机服务器已经不能够满足日常的需求了，因此就要想办法降低这个单机服务器上的数据量，因此就采取出了应用数据分离架构

这种架构模式也比较简单，直接把应用的数据存储在了应用服务器上，而把存储的内容数据，放到了存储服务器上，其实也就是把数据库服务部署在了一个存储服务器上

应用服务集群架构

随着用户的继续增长，数据量变得更多了，此时单台的应用服务器已经不能够满足日常的需求了，因此现在又要进行升级技术，下面给出两种方案：

1. 垂直扩展：购买更加优秀的应用服务器来进行应对这种更多的流量，优点是直接把项目换个机器部署即可，但是缺点是价格比较昂贵
2. 水平扩展：把软件的架构进行调整，增加应用层的硬件，把用户的流量分担到不同的应用服务器中，从而增加系统的承载能力，这样的方案优势是可以控制成本，提升空间大，但是缺点是需要技术的支持，因为直接相当于更换了一种存储模式

之后，这个项目采取了一个水平扩展的方案，引入了一个负载均衡的方案，把用户的流量合理的分发到了不同的应用服务器上，当然这也需要一个专门的系统组件，叫做流量分发，实际的负载均衡不仅仅说的是工作在应用层的是负载均衡，在网络层的也可能是负载均衡

下面是这种模式下的架构图：

读写分离/主从分离架构

在把用户的请求通过负载均衡发送到不同的应用服务器后，确实可以进行并行处理很多的问题了，并且随着用户的增长还可以使用扩张服务器的方法来进行压力的缓解，但是现在的问题是，不管扩展多少个服务器，这些请求都会从数据库来进行读写数据，这就导致数据库的压力会很大，那么如何解决数据库压力大的问题？

如果想要使用扩展数据库的方法来解决，其实是不可以的，因为数据是需要保持一致性的，采取多个数据库服务器，会导致整体上的数据一致性不能得到合理的保证，因此引入了一个主从服务器的概念

保留一个主要的数据库作为写入数据库，而其他的数据库都是从属数据库，从库的所有数据都来自于主库的数据，经过同步之后，从库可以维护着和主库一样的数据，为了分担数据库的压力，可以把数据的请求全部给主库来进行处理，但是读取的数据请求分散到从库中，这样就会导致压力进一步的减少，达到一个缓解的目的

下面是这种架构的模式图：

冷热分离架构

随着访问量的继续增加，就会发现业务中的一些数据的读取频率是要比其他数据的要高的，那么这些数据就被叫做是热点数据，对于热点数据来说，可以把其缓存起来，这样就可以减少访问数据库的次数，比如前面用过的Redis就是这样达到原理

垂直分库

随着业务的增加，大量的数据存储在一个库中是不可行的，一个主数据库已经完成不了这么多的数据了，因此就可以把数据进行分别存储，比如对于评论和数据，可以进行商品ID的hash，分别存储到不同的库中即可，具体的模式图如下所示：

微服务

随着项目的持续增加，整个项目可能会有很多个模块来组成，因此就需要把业务分发给不同的开发团队来进行维护，每个团队独立实现自己的微服务，相互之间对数据的直接访问进行隔离，总体来说就是可以进行一些相互之间的调用关联等：

容器编排架构

系统的资源利用率其实在上述的架构中是不高的，为什么这样说？因为有很多的资源是用来应对短时的高并发，而很多的资源在正常情况下都是用不到的，那这样的问题如何解决？容器化技术就带来了解决方案

目前最为流行的容器化技术就是Docker了，容器管理服务是K8S，可以把应用服务打包为一个Docker镜像，使用K8S来进行动态的分发和镜像的部署，Docker的镜像可以理解为是一个能够运行你的服务的最小的一个操作系统，里面放的是其对应的数据，那么把整个操作系统打包wield一个镜像之后，就可以分发到对应的机器上，直接启动这个Docker的镜像，就可以把服务打包起来，使得服务部署变得轻松简单

在实际的使用中可能还会有生产和研发的K8S集群，这样的集群不会公用，会有对应的研发和测试集群等

至此，一个高可用，高并发的系统模型就这样诞生了