体系结构划分的演变：
1 .传统项目框架：特点：1) all in one ) )所有模块在一起，技术也不分层)、
注：像05年06年左右那样，我把代码写在了jsp上。 那个时候还没有分层的概念，把所有的东西都集中起来写。 这叫做all in one
2 ) servlet (JSP ) )
缺点：并发性差、容错性低(不具有高可用性)注意：不具有高可用性意味着，例如，当用户访问服务器时，服务器在后台由于某些原因崩溃，用户可以直接看到错误页面，而
解决方案：1.分层开发(可提高并发性) )
2.mvc体系结构
3 .服务器隔离部署
用图说：
群集配置：
集群体系结构：特点：1.项目采用多个服务器集群进行部署
2 .在多个服务器集群上部署2.mysql数据库
好处：1.提高合并量(1000 ) ) ) ) ) )。
2 .提高容错能力(高可用性) ) )
注：典型的it企业基本上都采用集群体系结构。 因为这种架构方式几乎可以满足需求。 但是在大型项目中，这种方式显然无能为力，只能采用分布式架构方式
但是，从上图中可以看出，这种集群部署存在两个问题。 有什么问题呢？
1.session如何共享？
2 .服务器这么多，我应该向哪里发送请求呢？
让我们逐一解答这两个问题。
会话共享问题的第一个问题，会话问题：
我们知道会话是会话。 也就是说，当一个用户访问服务器时，将生成会话。 此会话始终伴随此用户的访问，直到用户关闭浏览器并退出此会话。 那么，问题是，挖掘技术哪个更强？ 嗯，错了。 用户访问服务器时，这件衣服
如果服务器关闭，则原来存储在此服务器上的会话也将关闭。 这样的话，结果就是这个用户明明已经访问好了，但是现在突然没有会话了。 会话消失意味着需要用户重新登录才能执行某些操作，这是不可否认的。 这种服务用户
体验太差，满足不了互联网行业的用户需求。 那么，这会导致将现有session从一个服务迁移到另一个服务的session共享问题，如何解决呢？ 有很多方案，今天先说两种吧。
第一个解决方案：
要在Tomcat群集复制(广播模式)中共享会话：
该解决方案利用Tomcat进行群集复制，共享复制每个服务器上的session，以确保每个服务器上有一个用户的session数据
应用场景：传统项目中一般是这样使用的。 传统项目由于用户较少，可以承受压力，但一旦成为互联网项目，这种方法是绝对不可取的。 例如，如果用户数为100万，则需要在每台服务器上复制这100万用户的会话。 这样做，显然会大大消耗系统
资源使系统变得极其庞大和不稳定，所以在互联网项目上绝对不会采用这种方式
缺点：在有很多用户的情况下，服务压力会变成亚历山大，因此只适合用户访问次数少的传统项目
第二个解决方案：
使用第三方redis服务器保存会话
以这种方式保存session后，如果当前项目需要将所有session放入redis中并由其他项目使用，则只需直接从redis中检索session即可解决此问题
示例：
向哪个服务器发送请求现在第一个问题已经解决了。 让我们考虑第二个问题。 如何解决选择哪个服务器作为解释请求？
答案是在nginx服务器上分发请求以实现负载平衡。
此体系结构的并发量是多少？ 大概1000左右。 如果服务器更多的话，就会达到1000以上、1万以下，这能满足互联网的终极要求吗？ 答案当然不行。 虽然服务器可以不断扩展，但对公司的成本和维护成本来说一定非常昂贵
例如，如果一台最便宜的服务器的价格约为3万到5万，而要防止一万台服务器同时运行，一台服务器可以支持200个并发率，那么需要多少台服务器？ 五十辆！ 这还是点击版，集群也构建了吗？ 例如，构建三台服务器，3*50=150台，服务器构建完成，数据库呢？ 还需要数据库
必须构建集群！ 这又有几百辆。 这么算下来，大概费用是几百万。 这只是配置的费用，还没有计算维护的成本吗？ 例如，我们知道服务器对机房的要求非常严格。 例如恒温、清洁等。 (闲话少说，阿里把云计算基地定在杭州是因为喜欢
那里气温稳定，适合服务器集群配置)。 这样安排大型机房是必要的，综合以上情况，集群虽说以后能解决一部分问题，但并不是所有的问题都能解决。 无论从公司成本还是运营成本来看，这样的传输都是显而易见的
统的集群架构是不适应现在的互联网行业的，而且对于一般的公司来说也不可能去花大价钱做这种布置。
所以，这种情况下我们就必须对我们的架构来进行优化了，那么如何在服务器只有一定数量的情况下，让我们的项目的成本能达到一定控制，并且让我们的项目达到一个最优化的并发的访问量呢？那么就需要对现有的这种架构进行再次拆分，让我们的项目成为面向服务的分布式架构。
面向服务的分布式架构(SOA)：远程框架：
webservice如图所示，第一种方式还是有着明显的缺点的，如服务层的网路抖动或是服务层进程繁忙，可能有人对这两个名词不太理解，这里就解释一下：
网络抖动：当有大量用户访问时，可能会出现service层的延迟现象，而web层因为长期得不到响应，则会抛出时间超出异常
进程繁忙：这个的意思和前边的差不多，都是指service层业务太多，顾不上web层的请求，web层的请求就只能一直在那等着，时间长了也就抛出超时异常了
服务治理中间件： dubbo原理讲解：看了第一种webservice的方法之后，我们采用了第二种方法，即dubbo这种中间件的方式，采用这种方式有什么好处呢？
好处：
当服务器启动时service会把所有的对象通过dubbo注册给zookeeper，而以后每次需要请求获取对象时，就可以直接从dubbo中异步获取，不需要再去访问service层，这样就解决了
服务层网络抖动和服务层进程繁忙的弊端。zeekeeper可以看成是一个数据库，用来存储数据的，具体的原理以后会专门开篇文章描述它。
这种方式是目前最常用的，起码是我最常用的，顺嘴一提，dubbo是阿里巴巴开发的一款中间件，性能强大，而且这是由中国人自主开发的软件，有木有很自豪
springcloud这个软件是由外国开发，原理和dubbo差不太，就暂且不提了，有兴趣的可以自己百度一下
下面我们来总结一下分布式框架的优点：
优点：
1.大幅提高并发访问量(10000+)
2.可以节省成本(因为这种优化仅是从架构方面进行优化，而不需要去配置大量的服务器)
3.实现了服务层与表现层的解耦合
注：1.其实还有一种方式，即是提升带宽，把带宽搞多一点，但前提是服务器能承受这么大的量。
2.集群也不是越多越好的，越多的话就会发现，其实并发的提升是有限的。
总结：说道这里就基本已经讲解了架构的发展历史，当然现在目前还有一种比分布式更火的架构模式，叫做微架构，它是通过服务的原子化拆分，以及微服务的独立打包、部署和升级，可以让小团队的交付周期将缩短，运维成本也将大幅度下降，可以预见，这
种架构模式将会越来越受到广大企业的应用与喜爱，但由于笔者功力有限，目前也还是在学习了解阶段，就不在这里献丑了。(本文写的比较浅显，如有写错写漏处，欢迎指正！谢谢观看！)