欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

(转)浅谈架构-从传统走向分布式

程序员文章站 2022-03-29 18:49:22
原文转自: https://www.cnblogs.com/Survivalist/p/8012266.html 随笔:最近再做这些年的知识整理,今天整理到了架构这方便,就索性拿出来和大家分享一下,有什么写错的,欢迎大家指正 架构拆分的演变: 1.传统项目的架构:特点: 1.all in one(所 ......

原文转自: https://www.cnblogs.com/Survivalist/p/8012266.html 

随笔:最近再做这些年的知识整理,今天整理到了架构这方便,就索性拿出来和大家分享一下,有什么写错的,欢迎大家指正

架构拆分的演变:
  1.传统项目的架构:
特点:
  1.all in one(所有模块在一起,技术也不分层),
  注:像05年06年那会儿,就是这样,把代码写在jsp里面,那时候还没有分层的概念,把所有的东西都写在一起,这就叫做all in one 
  2.servlet(jsp)
缺点:
  1.并发量差

  2.容错性差(不具有高可用性)

  注:不具有高可用性的意思是,比如当用户访问时,服务器后台因为一些原因导致服务器崩溃,用户就能直接看到错误页面,服务器也因为错误从而停止运行(宕机),这就叫做不具有高可用性。

解决方案:

  1.分层开发(可以提高并发量)

  2.mvc架构

  3.服务器的分离部署

用图说话:

(转)浅谈架构-从传统走向分布式

 

集群的配置:
    (转)浅谈架构-从传统走向分布式

  集群架构:

  特点:

    1.项目采用多台服务器集群部署

    2.mysql数据库采用多台服务器集群部署

  优势:

    1.并发量提高(1000+)

    2.容错性提高(具有高可用性)

  注:一般的it公司,基本都是采用集群架构,因为这种架构方式已经基本能满足需求了,但是一些大型项目,这种方式就显然是力不从心了,只能采用分布式的架构方式

  但是,通过上图我们发现这种集群部署存在两个问题,什么问题呢?

  1.session如何共享?

  2.这么服务器,请求该往哪发送?

  下面咱们就针对这两个问题一一解答:

  首先第一个问题,session的问题:

    我们都知道,session是会话,即一个用户访问服务器的时候,就会产生一个session,这个session会一致伴随着这个用户的访问全程,直到用户关闭浏览器结束这次会话,那么问题来了,问,挖掘技术哪家强?咳咳,错了,是如果用户访问服务器时,这台服

  务器挂掉了(宕机),那么原先保存在这台服务器上的session也肯定挂掉了,那么就会产生一个后果,就是这个用户原本访问好好的,现在突然session没有了,而session没有了就意味着需要用户重新登陆才能进行一些相应操作,这显然是不行的,这样的服务用户

  体验实在太差了,根本不能满足互联网行业的用户需求,那么这就涉及到一个session共享的问题,即怎么把原有的session从一台服务器转移到另一台服务器上,但是怎么解决呢?有多种方案,但咱们今天先说两种:

  第一种解决方案:

    用Tomcat集群复制(广播模式)来共享session:

    这种解决方案是利用Tomcat来进行集群复制,把每个服务器上的session都共享式的都复制一遍,保证每个服务器上都有着一个用户的session数据

    应用场景:在传统项目中一般这么应用,因为传统项目的用户量少,可以承担压力,但当到互联网项目时,这种方式就绝对不可取了,打个比方,比如用户量有100万,那么就需要在每个服务器上都复制这100万个用户的session,这样做显然会极大的消耗系统资源,使系统变得极为臃肿和不稳的,所以在互联网项目里是绝对不会采用这种方式的

    缺点:当有大量用户时,服务器的压力会亚历山大,所以只适合用户访问量小的传统项目

  第二种解决方案:

    用第三方redis服务器来存储session

    用这种方式来存储session的话,只需当前正在使用的项目把所有session都放在redis里面,当有其他项目需要使用时,就可以直接从redis中直接获取session,从而解决了这个问题

  示例如图:

  (转)浅谈架构-从传统走向分布式

  现在第一个问题解决了,我们来考虑第二个问题,怎么解决选择哪个作为解释请求的服务器呢?

    答案是:用nginx服务器来分发请求,实现负载均衡。

    (转)浅谈架构-从传统走向分布式

     这种架构的并发量是多少呢?大概是1000+左右,如果服务器更多的话,能达到1000以上,一万以下,但是这能满足互联网的极致要求呢?答案当然是不能了,虽说也可以不断的扩展服务器,但是对于公司的成本和维护成本来说,无疑会达到一个非常高昂的

  消耗,比如说一台最便宜的服务器的价格大概是3到5万,假如要抵御一万的并发,每台服务器能支持200的并发率,那么需要多少台服务器?50台!这还仅是单击版的,还构建集群呢?比如说构建3台服务器,3*50=150台,服务器构建完了,数据库呢?数据库也需

  要构建集群呀!,这就又是好几百台,这么一算下来大概的费用就是好几百万了,这仅仅是配置的费用,还没有计算维护的成本呢?比如说我们都知道服务器对于机房的要求是非常苛刻的,比如恒温,无尘等等(题外话:阿里之所以把云计算基地定在杭州就是看中了

  那里气温稳定,适合布置服务器集群)。这样一来又需要布置大型的机房,综合以上所述,虽说集群能后解决部分问题,但并不能解决所有问题,无论是从公司成本还是运营成本来说,显然这种传统的集群架构是不适应现在的互联网行业的,而且对于一般的公司来说也不可能去花大价钱做这种布置。

    所以,这种情况下我们就必须对我们的架构来进行优化了,那么如何在服务器只有一定数量的情况下,让我们的项目的成本能达到一定控制,并且让我们的项目达到一个最优化的并发的访问量呢?那么就需要对现有的这种架构进行再次拆分,让我们的项目成为面向服务的分布式架构。

  面向服务的分布式架构(SOA):

  远程框架:

    1.webservice

  (转)浅谈架构-从传统走向分布式

  如图所示,第一种方式还是有着明显的缺点的,如服务层的网路抖动或是服务层进程繁忙,可能有人对这两个名词不太理解,这里就解释一下:

  网络抖动:当有大量用户访问时,可能会出现service层的延迟现象,而web层因为长期得不到响应,则会抛出时间超出异常

  进程繁忙:这个的意思和前边的差不多,都是指service层业务太多,顾不上web层的请求,web层的请求就只能一直在那等着,时间长了也就抛出超时异常了

  服务治理中间件:

    2.dubbo

  (转)浅谈架构-从传统走向分布式

    原理讲解:看了第一种webservice的方法之后,我们采用了第二种方法,即dubbo这种中间件的方式,采用这种方式有什么好处呢?

    好处:

      当服务器启动时service会把所有的对象通过dubbo注册给zookeeper,而以后每次需要请求获取对象时,就可以直接从dubbo中异步获取,不需要再去访问service层,这样就解决了

      服务层网络抖动和服务层进程繁忙的弊端。zeekeeper可以看成是一个数据库,用来存储数据的,具体的原理以后会专门开篇文章描述它。

    这种方式是目前最常用的,起码是我最常用的,顺嘴一提,dubbo是阿里巴巴开发的一款中间件,性能强大,而且这是由中国人自主开发的软件,有木有很自豪

    3.springcloud

      这个软件是由外国开发,原理和dubbo差不太,就暂且不提了,有兴趣的可以自己百度一下

 

   下面我们来总结一下分布式框架的优点:

   优点:

      1.大幅提高并发访问量(10000+)

      2.可以节省成本(因为这种优化仅是从架构方面进行优化,而不需要去配置大量的服务器)

      3.实现了服务层与表现层的解耦合

   注:1.其实还有一种方式,即是提升带宽,把带宽搞多一点,但前提是服务器能承受这么大的量。

     2.集群也不是越多越好的,越多的话就会发现,其实并发的提升是有限的。

     总结:说道这里就基本已经讲解了架构的发展历史,当然现在目前还有一种比分布式更火的架构模式,叫做微架构,它是通过服务的原子化拆分,以及微服务的独立打包、部署和升级,可以让小团队的交付周期将缩短,运维成本也将大幅度下降,可以预见,这种架构模式将会越来越受到广大企业的应用与喜爱,但由于笔者功力有限,目前也还是在学习了解阶段,就不在这里献丑了。(本文写的比较浅显,如有写错写漏处,欢迎指正!谢谢观看!)