Web发展历程
CS时代：富客户端方案。卖软件可以赚钱。
QQ，影音，游戏
Web 1.0时代：主要是单向信息的发布。互联网内容是由少数编辑人员定制的，用户只有看的权限
三大门户网站：新浪、网易、搜狐。
Web 2.0时代：注重用户的交互。每个人都是内容的提供者。
博客、社区、微博、抖音
集群与分布式的区别
单机就是一台机器抗业务；集群就是多台机器抗业务；分布式就是将代码进行功能细化切分；
单机抗用户、商品、订单三个功能；当一台机器扛不住了，就用多台机器抗用户、商品、订单功能，就被称为集群；
分布式将用户、商品、订单功能进行拆分，用户服务可以部署在一台机器或者多台机器上组成一个用户服务集群；
架构演进
BS请求过程
当浏览器发起请求时，通过DNS域名解析将域名解析成具体的网站ip地址，然后去CDN加载网站的静态资源和加载网站的Html页面，最后通过浏览器渲染返回的文件数据展示在用户面前
架构一：早期架构
浏览器+服务器：只要提供静态页面的浏览需求
架构二：数据库开发
浏览器+服务器+数据库：只要提供静态页面的浏览需求，页面的数据从数据库中读取，业务逻辑简单，写sql查询数据处理
架构三：javaweb开发
Tomcat+servlet+jsp+mysql：一个war包打天下
项目框架结构：ssh、ssm组成的MVC架构
随着mysql查询的数据压力，产生了集群架构
架构四：javaweb的集群发展
硬件机器的横向扩展，对war包内部的项目结构无任何影响，还是一个war包打天下。
架构五：javaweb的分布式发展
将MVC架构中的service服务层单独分离出去，成为一个单独的项目jar，单独运行
web服务器通过rpc框架，对分离出去的service进行调用
架构六：javaweb的微服务发展
将controller、service、dao+数据库三层单独独立出来，每一个微服务都是一个完整的服务。
在微服务的内部，需要对外提供接口，包装成rpc接口，供外部服务调用。
交互模式
架构一：整页交互
浏览器请求皆为页面请求，每次请求都是一次页面跳转、刷新
架构二：页面+ajax混合
浏览器请求主要为页面级请求，数据请求为ajax局部刷新，页面体验更好
架构三：单页面应用
首次请求返回页面，后续请求都为restful接口数据请求
架构中常见解决方案
架构的依据：
并发数（TPS）Transaction Per Second ：每秒钟处理的事务数
数据量（QPS）Query Per Second：每秒钟处理的查询数
单Tomcat服务器能承受最大的TPS：–500，架构的最大并发数。如果超出则考虑集群和分布式方案。
Mysql数据承受最大的单表数据量–500万，架构的最大单表数据量。如果超出则考虑分库分表方案。
session跨域共享
方案：
1、使用缓存实现session共享
2、tomcat插件实现session共享
3、springsession插件实现session共享
缓存
1、先到缓存中查，如果缓存中存在值，则直接返回
2、无值（缓存穿透、缓存击穿）则调用接口或者查询数据库，并将值补入缓存区
3、缓存区数据和数据库中的数据可能不一致，使用过期时间调节等问题
4、若缓存区数据集中在某一时刻失效，将导致大量的缓存击穿（雪崩）
解决方案：
1、不设置过期时间，数据永久有效，避免雪崩；但是容易造成内存浪费
2、需要额外的机制来实现数据的同步更新
多线程
同步、异步：
同步调度（线程阻塞）：
1、调度期间，主调和被调线程被同时占用。
2、被调执行完成前，主调等待。
3、程序内部的调度，则为一单线程。
异步调度（线程不阻塞）：
1、主调与被调只是一次消息发送，信息到达即返回。
2、被调执行完成后，回调一次主调方，发送结果回来。
3、程序内部的调度，则回调函数是由被调线程执行。
多线程：空间换时间
消息中间件
1、每个应用启动，主动注册队列
2、后续收发信息，只管收发队列中数据
3、队列中数据的路由策略由mq管理者来配置，跟应用程序无关
数据分片
Redis/es/fastdfs，将数据按片切分：
1、切成6个片，每个片存储总量1/6数据
2、则两个库每个库分担三个片
3、若三个库，则每个库只需要承担两个片
4、路由管理，只记录数据与片柱的关系
此模式实现集群的动态扩容
