我也要谈谈大型网站架构之系列(4)——分布式中…

2018-06-22 06:28:36来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

 

  我们知道在面向对象编程中,总会想着各种办法来实现代码的解耦,从而让项目中的各种人员面对自己熟悉的业务进行开发,

做到术业有专攻,比如大家非常熟悉的三层架构,MVC,MVP以及MVVM模式,让前端设计专注于html的制作,让后端开发人员

更加专注于业务逻辑的编写,可以看到,我们这么做的目的就是想最大程度的做到系统的可扩展和可维护性,那么我们的大型网站

是不是也要遵守这种模式呢?

 

一:分层和分割

1:分层

    对于分层,我们可能非常熟知了,数据访问层,业务逻辑层,缓存层,应用层,层层专注于自己的业务,然后根据需要建立起

 各自的集群,各自分离部署,而从达到系统的扩展性和维护性。

 

2:分割

    如果说前面是横向切割,那分割就是纵向切割,我们可以把网站的整体业务切分成很多的小业务,比如博客园的导航栏,我们都

可以认为是一个独立的网站,配上各自的二级域名,建立各自的集群来实现系统的扩展性,当然这个粒度可大可小。

如果说这些子网站不存在相互调用,那么我们新增模块或者修改模块基本上都不会对其他模块造成影响,这也是我们做扩展性的终极

目标,现在既然都做到解耦了,下面的目标就是做如何通信了,通信可以分为“同步”和“异步”,这篇主要是讨论下异步操作,在分布式

系统中做到"异步操作“,当然少不了强大的消息队列。

 

二:消息队列

    在分布式的系统中使用消息队列后,我们的生产者只管向消息队列中甩完数据后立即返回,而不管是哪个消费者来消费,可以看到

其实消息队列有如下三个优点。

 

1.  加快网站的相应速度

    这个刚才也说了,应用层直接把消息给消息队列然后直接返回调用端,这样就避免了处理复杂的业务逻辑然后同步的插入到数据

  库后再返回造成的响应延迟,在很多网站上用户提交订单就是这么处理的,应用层生成一个订单号之后,将订单丢给消息队列,然后

  直接到订单成功页面,此时后端消费者对订单还没有处理完毕,因为后面会有比较多的数据操作,比如减库存,数据库同步等等,而

  用户如果想要看到订单详情,需要点击“订单号”才能进入到订单详情页,这种处理也是因为消息队列的非及时性,所以需要得到网站

  设计方改进和支持

 

2. 提供系统的可用性

    既然是异步操作,就造成了生产者不知道消费者的存在,而反过来消费者不知道生产者的存在,如果消费者挂了就不会影响到生产者,

  生产者还会照常无误的向消息队列甩消息,当消费者恢复正常后就会继续消费消息队列,系统的表现可能就是email或者短信延迟收到,

  不会对系统造成太大的影响。

 

3. 并发削峰

   既然是大型网站就免不了高并发的读写操作,很典型的一个例子就是电商中的秒杀,这种高并发的写操作,如果一下子都涌入到数据库

里面去了,会导致数据库的压力非常大,从而导致客户端的访问延迟,就是不挂也容易造成数据库的死锁从而造成很多灵异事件,遇到这

种一拥而入的情况,我们就必须进行线性化操作,在代码层面上我们可以用lock机制来串行化,在分布式中我们用“消息队列”来串行化,

而且还可以通过逻辑操作来对消息队列进行动态的防洪,控洪。

 

 在消息队列的选择上,微软有自己的MSMQ,但是在大型网站中,我们的消息队列同样需要集群,并且希望能跑在内存中,并且支持序列

化硬盘,同时在“伸缩性”和“可靠性”上要有好的作为,所以推荐大家用用开源的RabbitMQ,网址:http://www.rabbitmq.com/  不过很

多公司都有自己开发的消息队列,比如携程的CMessage,淘宝的MetaQ。

 

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:ASP.NET中上传并读取Excel文件数据

下一篇:我也要谈谈大型网站架构之系列(3)——死了都要说的缓存