服务器架构的演变过程
服务器架构的演变过程
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来管理,效率更高.
- b,可以采用session共享的方式,采用redis缓存服务器作为一个公共的存储用户信息的地方,在用户访问服务器1时,服务器1去redis中会查看是否有登录信息,在访问到服务器2时,服务器2也去redis服务器查看,这样把信息都让redis来管理,效率更高.
- 2)每个功能之间的耦合度依然很高,不便于新增或维护功能.于是便有了下面的架构模式–分布式
3 分布式架构
分布式架构比之传统的单一模式的改变就是 分布式架构把整个系统拆分为各个小的功能模块,每一个又独立成为一个系统,只是这个系统只提供单独的功能,而每个系统又分别放到不同的服务器中,这样形成了一个多个服务器架构的网,每个功能相互协作
* 优点:
1)解决了功能耦合度高问题,每个模块相互独立,如果某一个功能需要修复,只需修改这一个就好,不影响整个系统运行.而且如果需要添加新功能,非常容易切入到系统中来,且不改动其他的模块.
2)真正能够解决并发问题,因为每个功能模块拆分开了,如网站搞促销活动,商品浏览页面展示的访问压力大,可以有针对的添加集群,解决高并发问题,即可实现对每个节点(即每个独立的功能)添加集群.
* 缺点: 每个模块虽然独立,但是可能每个模块有一些通用的功能,而这些通用的功能在每个功能中都要写一遍,如何提高代码复用性,这是一个问题.于是便有了下面的架构模式
集群和分布式的区别
集群：即每个服务器上的提供的功能和服务相同, 只是人多,做的事情却是相同的; 相当于同一个工程代码拷贝多份部署到多台服务器，每台服务器单独独立部署运行。
分布式: 即每个服务器上功能不同,大家要相互分工, 协作完成整个工程; 把系统按照模块拆分成多个子系统；多个子系统相互协作才能完成业务流程系统之间需要进行通信。
4 SOA模式–(Service Oriented Architecture)面向服务架构
soa模式的服务架构,也是分布式架构,只是针对之前出现的问题,做了改进,即为了提高代码的复用性问题,
将整个系统主要分为2部分,把工程都拆分成服务层工程、表现层工程。
服务层中包含业务逻辑，只需要对外提供服务即可。
表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。工程都可以独立部署,而表现层又可以细分为各个不同的部分,而这些模块都是对外提供服务,只是具体分工不同,但是他们每个要进行逻辑处理时,可以调用服务层的同一个业务逻辑.这样一个业务逻辑可以供表现层的多个服务调用,代码复用性提高.
