技术架构的演进
主要方向：
1.提高单位时间内的吞吐量，提高并发度；
2.对应用服务代码进行解耦合，使得开发效率得到提高；
3.运维成本降低；
4.成本降低，如购买云厂商资源，降低资源闲置可能性；
一、八大架构演进
分别是单机架构、应用数据分离架构、应用服务集群架构、读写分离/主从分离架构、冷热分离架构、垂直分库架构、微服务架构、容器编排架构；
二、单机架构
简介：应用服务和数据库服务共用一台服务器，即所有的服务都部署在一个服务器上；
出现原因：出现在互联网早期，访问量比较少，单机足以满足需求；
架构工作原理：以电子商城为例，可以看到通过应用(划分了了很多个模块)和数据库在单个服务器协作完成业务运行；
架构的优缺点：优点：部署简单并且成本低；缺点：存在严重的性能瓶颈；另外数据建库和应用服务在互相竞争资源；
三、应用数据分离架构
简介：应用服务和数据库服务使用不同的服务器；
出现原因：单机架构存在严重的资源竞争；
架构工作原理：应用服务和数据库服务在不同的服务器通过网络进行协作；
架构的优缺点：优点：数据库单独隔离，不会因为应用导致数据库破坏；缺点：还是无法应对海量数据；
解决方式：数据库服务和应用服务部署在不同的服务器上；
四、应用服务集群架构
简介：引入了负载均衡，应用集群方式进行运作；
出现原因：单个应用不足以支持海量的高并发请求；
架构工作原理：应用服务不在是一个，而是变成了多个，即将多个应用服务部署在多个服务器上，可以通过负载均衡实现海量的高并发；典型的负载均衡组件有Nginx(上限是50000并发)，LVS支持几十万的并发，F5支持百万至千万级的并发，前面两种是软件，最后一种是一种硬件设备；DNS可以抗住上亿级的并发；最终通过不断横向扩展和负载均衡分层，实现上亿级别的并发；
当DNS也扛不住时，请求达到百亿级别时，可以本地配置IP地址，不通过访问DNS来判断IP地址，提高并发；一般说来，使用了三层负载均衡；第一层是DNS，通过多个IP的返回实现；第二层是LVS/F5实现；第三层是Nginx实现；
架构的优缺点：优点：服务高可用，多个应用服务，防止一个服务挂掉，使得整个服务站点无法使用；应用服务已经具备一定的高并发，不经过数据库可以支持海量请求的快速响应；应用服务有一定的扩展能力，需要使用一定的中间件才能实现快速扩展；缺点：数据库成为了性能瓶颈，无法应对海量数据，单个数据库服务，没有高可用，运维工作增多，需要研发运维中间件进行快速地部署，硬件成本也增加了；
解决方式：搭建应用服务集群，使用横向扩展与负载均衡；
五、读写分离/主从分离架构
简介：将数据库的读写操作分散到不同的数据库服务节点上，搭建主从集群，主机负载写，从机负责读，同时还需要进行同步；
出现原因：随着架构的发展，数据库已经成为了高并发性能瓶颈；
架构工作原理：在应用集群架构的基础上，对数据库服务实现集群化，一个主机负责写，多个从机负责读，主机完成写之后同步给从机，应用与数据库中间还需要一层判断读写逻辑，常用的组件有mycat、tddl等；
架构的优缺点：优点：数据库的读取性能提高；由于读操作被其他服务器承担，间接地提高了写性能；多个从库，支持高可用；缺点：热点数据频繁读取会导致数据库负载较高；存在一定的同步延迟；
解决方式：对数据库服务使用读写分离与集群化，提高了并发度；
六、冷热分离架构
简介：引入缓存，实现冷热分离，将热点数据放入到缓存中，冷数据放入到数据库中，实现数据库的快速响应；
出现原因：之前的架构已经可以保证一定程度的并发，但是支持的并发量还是不够，还是会有海量的数据请求导致数据库负载过高，降低了站点响应速度，如秒杀产品的场景；
架构工作原理：由于秒杀场景会同一时间有大量的人员使用，这个数据请求就是热点数据，需要在缓存服务器和存储服务器中都进行写入，但是会存在不都成功的请款给，需要使用代码保证都成功；当进行秒杀查询时，会直接查询缓存服务器，不经过存储服务器直接返回响应，其他冷数据查询时，就会先查询缓存服务器，判断是否存在，不在就查询存储服务器，然后返回响应；常见的缓存组件：Redis内存级数据库；缓存服务器也是集群化的；
架构的优缺点：优点：降低了数据库的访问请求，提高性能，数据都是存放在内存中；缺点：产生了缓存一致性、缓存击穿、缓存失效、缓存雪崩等问题；数据库中所保存的数据量过大，导致查询的速度过慢；
解决方式：引入缓存数据库用来存放热点数据，不再需要和数据库进行交互，间接地提高数据库的并发性能；
七、垂直分库架构/分布式数据库架构
简介：数据库的数据被拆分，数据分布式存储，分布式处理，分布式查询，换句话说不再是一个服务器处理一个请求，而是多个服务器处理一个请求；
分库分表：由于数据存储量过大，先是将负责业务数据库垂直拆分成简单业务数据库，然后分配到多个服务器中，随着数据不断增加，将简单数据库水平拆分到多个服务器中，每个数据库中存放部分表结构；然后发现表太大，此时进行分表，使用哈希运算进行拆分多个子表，便于后续数据整合；但是执行语句的时候会导致需要发送多个语句的然后将数据进行合并的问题，此时就需要设计中间件负责打包完成这个过程；
分布式数据库：分库分表与打包执行中间件的设计实现分布式数据库；
出现原因：单个库存放在单个服务器中，大量的数据存储，减少了索引、IO等效率；
架构工作原理：在前面架构的基础上，添加多个存储集群，存放一个库中的多个表结构，每个集群都是主从集群；还需要在多个集群之上添加中间件，负责多个sql的执行和数据的合并打包，然后就实现了分布式数据库；常见的分布式数据库：Greenplum、TiDB、Postgresql XC、HAWQ 等，商用的如南大通用的 GBase、 睿帆科技的雪球 DB、华为的 LibrA 等
架构的优缺点：优点：数据库吞吐量大幅提升；缺点：产生分布式相关的跨库问题；由于应用代码整体耦合在一起，每次修改，都要将整个站点暂停，重新进行部署发布；
解决方式：数据库服务和应用服务部署在不同的服务器上；
模拟实现分布式数据库：
垂直分库架构：
八、微服务架构
简介：按照业务板块来划分应用代码，使得板块之间做到独立升级迭代，便于上层开发出来新应用服务来复用微服务；
出现原因：扩展性差(添加新功能，每次都要重新构建整个系统)、持续开发困难( 一个小的代码改动也需要重新部署整个应用)、不可靠(一个功能失效，导致整个系统失效)、不灵活(不支持多个语言进行开发不同功能)、可维护性差(代码耦合度高，修改起来不方便)；
架构工作原理：在先前架构的基础上，将应用服务的开发转变为微服务的开发和使用微服务构建大型服务(起其实是大型服务调用微服务)，需要考虑到微服务之间的协作和与缓存服务器集群，分布式存储服务器集群的交互；常见的微服务框架：Spring Cloud、Dubbo；
架构的优缺点：优点：开发效率高；支持多语言开发，因为http、rpc等协议支持跨语言；缺点：运维难度提高(运维量提高，复杂度提高)，如某些微服务不使用了，需要停止服务，可以使用一些自动化运维的工具提高运维效率，还有一个服务器上部署多个微服务要解决环境冲突问题，此外对于动态扩缩容场景，需要在新增的服务上部署环境；使用的资源增多，多个微服务创建的进程增加；排查故障困难；
解决方式：开发微服务模块，支持上层大型应用服务的开发；
九、容器编排架构
简介：借助容器化技术(docker)将应用和服务打包成一个镜像，然后使用容器编排工具(k8s)来动态分发和部署镜像服务，以容器化方式运行；
出现原因：运维成本较高；
架构工作原理：在原有架构的基础上，创建多个k8s集群，内部使用了不同的容器部署在不同的服务器上，不同的k8s集群分层通过通信来实现一个大型服务的实现；
架构的优缺点：优点：部署运维简单快速；隔离性好，多个容器不会相互影响；滚动性好，可以形成不同版本的部署方案，实现版本替换；缺点：技术栈增多，要求高；当大促来时，需要大量的服务器设备，结束时就会造成资源闲置，所以可以使用购买云服务器的方式，防止造成资源闲置；
解决方式：容器化技术docker、容器编排技术k8s，使用云厂商的技术，解决资源浪费问题；
十、互联网实战架构
缓存数据：内存中存放的热点数据；
对象存储：负责存储非层级结构的数据；
基础数据：存放层级结构数据，如文本文件；
ES集群：一种优秀的搜索引擎集群；
MongoDB集群：评论和描述都是大段文字，使用文档数据库存储比较方便；
Hadoop集群：对于数据量大且数据有价值的数据使用大数据分析；
由于不同的数据特征，需要调用不同的数据集群，会使用到大量的API，过程过于繁琐，此时就需要创建一个中间件，抽象出来一个统一数据服务层，屏蔽底层的差异，来快速地访问对应数据集群；
1.最后两层统一叫做数据层；2.向上使用k8s搭建不同的服务部署管理系统构成服务层，服务对外开放需要网关进行管理，所以每一个服务集群都可以配一个API网关进行管理；3.再向上使用负载均衡技术进行请求和响应的控制分发；4.再向上就是防火墙保证后端数据出入安全；5.之后就是DNS层提供域名转IP和负载均衡；6.最后一层就是用户使用的客户端/浏览器；
之后加入AI就需要在各层使用新的技术；
