架构的演进
单机架构 -> 数据分离架构 ->
单机架构
应用服务和数据库都在同一个服务器中，在应用初期请求量少时使用
优点：部署简单，开发容易，容易维护，不需要专门的运维人员
缺点：数据库和应用服务竞争服务器资源，性能低
因为请求量变大了，服务器资源无法应对如此多的请求，于是数据分离架构应声而到
数据分离架构
将数据库和应用服务使用不同的服务器
优点：使得性能有了较大的突破，且硬件成本可控
缺点：还是无法应对海量的请求，单机的性能任然是有上限的
因为单机服务的性能有上限，那么我就可以引入多台的服务，
集群服务架构
部署多个服务，并且引入了负载均衡来平衡服务间的请求
优点：服务高可用，避免单点架构崩溃导致服务直接不可用，性能有较大的提升，支持服务器的横向扩展
缺点：数据库成为性能瓶颈，且为单点模式无法满足高可用，且多台服务部署复杂，运维压力大
一台nigin可以有5w并发量 并且nginx还可以横向扩张 对于更大的并发量 那么就还可以这样 对于多个nginx 再在上面套一个 LVS或者F5 这种更加高吞吐量的负载均衡来对流量进行分发 就能实现更高并发量
而这样很容易看出 我的并发量高了起来，数据库又顶不住了，而对于数据库的请求读多余写的，那么我就可以把数据库按读和写分开，于是读写分离架构应声而到
读写分离/主从分离架构
将数据库按写和读分开，主节点数据库只负责写请求，而其他的从节点数据库只负责读请求，通过主节点将数据同步到从节点
优点：有效的提高了数据库的读取性能，且因为读操作被其他数据库分担，那么写操作
性能也会提高，有了从节点，数据库的可用行页提高了，即使从节点挂了还有其他的可以用，主节点挂了也可以暂时使用从节点顶替
缺点：热点数据的频繁读取也对数据库造成很大的压力，且会有同步不一致导致数据的不同，成本也提高了，数据库也变复杂了
因为tomcat也不管你是读写操作，那就直接调用数据库，数据库也不管你是啥操作他也直接执行，那么分离读写操作，数据库和应用就解决不了了，那么就可以使用加一层的操作，让他来解决读写操作的分发，数据库中间件 mycat tddl就可以解决这
根据二八原则可以知道，对于百分之八十的请求使用百分之20的数据就可以数据解决，而这百分之20的就是热点数据，在请求量再次增加时，这些重复的请求会对数据库造成不少的压力，于是可以将热点数据储存在一个性能更高的数据库中，冷热数据分离架构应声而到
冷热数据分离
引入缓存 reids，将热点数据放入缓存中快速响应
优点：大幅度降低了数据库的压力，性能提升明显
缺点：带来了不少问题，缓存穿透，缓存击穿，缓存雪崩，缓存一致性，缓存失效等
成本进一步增加
且业务体量变大之后，数据库明显增加读写效率下降，数据库再次成为瓶颈
因为数据储存量过大数据库查询时间变得更长，数据库成为瓶颈
那么这时再把所有数据储存在数据库中就不能很好的应对业务的开发了
那么就得先办法减低数据库储存的数量，所以垂直分库架构应声而到
垂直分库架构
数据库的数据按表拆分，数据库中的数据变为分布式储存，分布式查询，处理
变为了分布式数据库
优点：数据库的吞吐连明显增加，数据库不再是瓶颈
缺点：带来了分布式事务问题，跨库join，还有因为关于数据库的代码耦合再一起，修改代码之后需要重新部署服务
对于分布式redis和数据库都有对应的逐渐实现了其功能
但是这样还是会有个问题 持续开发困难 是每次再修改代码之后，需要重新部署所有的应用，这样会使所有服务都给停机，wok，而且每个应用也可能因为一个bug而到值应用停机，这简直不能接受 而且不灵活，代码维护难
所以微服务架构应声而到，他能对单独的服务进行重新部署 而不会影响到其他的服务
微服务架构
微服务是一种架构风格，他将业务拆分为多个小的服务，不同服务之前可以交流，独立迭代
优点：每个服务的工作明确，且不会互相干扰，灵活性高，每个服务可以单独部署，迭代，下线，且整个系统的容错性高，兼容性强，可以使用不同语言的代码来编写服务
缺点：运维难度增加，随着服务数量的增加，同一台服务器上运行多个服务还会需要解决环境的冲突问题，且问题的排查也变的困难，再找一个bug可能要去查看多个服务的运行日志，而且像大促这类活动，需要横向扩张服务的性能，就需要运维去再开多个服务，过几天结束后有需要给停了，而这些纯手动会使运维变得无比的困难
微服务过多也会为设备硬件压力增大
为了解决运维的部署困难，那么就需要开发一个自动化的部署工具，那么容器编排架构就出来了
容器编排架构
通过容器包裹技术（docker）将服务打包为镜像，使用容器编排技术（k8s）将容器一键动态发布和部署，服务以容器化方式运行
借助容器化技术将服务包装在容器中运行，容器中所有的环境都和外界隔离，包括网络，内存，环境配置等，可以理解为一个新的设备了，而且支持一键部署，一行指令就能运行多个容器，使得服务的部署变得异常的简单
优点：隔离性好，容器之间文件，网络，内存资源都不共享，部署，运维简单，支持容器的回滚
缺点：技术栈变多，要求变高，资源要求高，成本变高
至此一个比较成熟的，应对高并发场景的框架就实现了