服务器架构的演变过程

1,传统单一模式

一个项目系统包含所有的功能,如登录,注册,验证,前台展示,后台管理等,所有的功能在一个项目中实现

缺点:
1)不便于维护,系统的每个功能耦合性太高,如果某一个功能出现bug,整个项目都得下线维护修复,会影响整个功能模块;
2)横向拓展性不好,特别是目前互联网项目,需求变化很高,代码都不能写死,就是为了便于后面需求变化,增加新功能,而因为每个功能之间耦合性太高就导致修改一处,可能导致需要修改很多处.功能的修改或增加麻烦
3)因为整个项目放在一个服务器中,存在并发量问题,如果用户多了,并发问题亟待解决.于是变出现了下面的模式–增加集群的方式.
这里写图片描述

2 集群模式

  集群模式为了解决访问量大的情况,把项目放到多个服务器上,通过添加服务器的方式来缓解用户访问大的压力.
这中集群模式在一定程度上能够增加并发量,但也面临问题.

这里写图片描述

缺点:

1)重复登录问题;这个模式添加集群,就得使用负载均衡服务器(通常使用nginx作为服务器),如果一个用户第一次登录访问被分配到了1号服务器,服务器存储了该用户的信息(session域中),但是用户下次的请求就不一定再被分配到这个服务器了,假如这次被分配到了2号服务器,则该服务中没有该用户的session信息,则会要求该用户重新登录,用户体验不好.

解决:针对上诉问题,解决方案
- a,服务器之间session广播,但是广播是要占用网络带宽的,即会占用网络资源,在用户访问已经很大的时候,应该尽可能减少消耗,不然用户登录网站也会缓慢,体验不好等,这时,服务器的集群数量也不能太多,超过一定数量后,session广播消耗的资源的坏处可能比搭建集群带来的好处还大,所以优势会随着集群数量呈现先增长再下降的负向的抛物线趋势.
- b,可以采用session共享的方式,采用redis缓存服务器作为一个公共的存储用户信息的地方,在用户访问服务器1时,服务器1去redis中会查看是否有登录信息,在访问到服务器2时,服务器2也去redis服务器查看,这样把信息都让redis来管理,效率更高.
2)每个功能之间的耦合度依然很高,不便于新增或维护功能.于是便有了下面的架构模式–分布式

3 分布式架构

分布式架构比之传统的单一模式的改变就是分布式架构把整个系统拆分为各个小的功能模块,每一个又独立成为一个系统,只是这个系统只提供单独的功能,而每个系统又分别放到不同的服务器中,这样形成了一个多个服务器架构的网,每个功能相互协作

这里写图片描述
* 优点:
1)解决了功能耦合度高问题,每个模块相互独立,如果某一个功能需要修复,只需修改这一个就好,不影响整个系统运行.而且如果需要添加新功能,非常容易切入到系统中来,且不改动其他的模块.
2)真正能够解决并发问题,因为每个功能模块拆分开了,如网站搞促销活动,商品浏览页面展示的访问压力大,可以有针对的添加集群,解决高并发问题,即可实现对每个节点(即每个独立的功能)添加集群.
* 缺点: 每个模块虽然独立,但是可能每个模块有一些通用的功能,而这些通用的功能在每个功能中都要写一遍,如何提高代码复用性,这是一个问题.于是便有了下面的架构模式

集群和分布式的区别

集群：即每个服务器上的提供的功能和服务相同, 只是人多,做的事情却是相同的; 相当于同一个工程代码拷贝多份部署到多台服务器，每台服务器单独独立部署运行。
分布式: 即每个服务器上功能不同,大家要相互分工, 协作完成整个工程; 把系统按照模块拆分成多个子系统；多个子系统相互协作才能完成业务流程系统之间需要进行通信。

4 SOA模式–(Service Oriented Architecture)面向服务架构

 soa模式的服务架构,也是分布式架构,只是针对之前出现的问题,做了改进,即为了提高代码的复用性问题,
  将整个系统主要分为2部分,把工程都拆分成服务层工程、表现层工程。

服务层中包含业务逻辑，只需要对外提供服务即可。
表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。工程都可以独立部署,而表现层又可以细分为各个不同的部分,而这些模块都是对外提供服务,只是具体分工不同,但是他们每个要进行逻辑处理时,可以调用服务层的同一个业务逻辑.这样一个业务逻辑可以供表现层的多个服务调用,代码复用性提高.
这里写图片描述