我也要谈谈大型网站架构之系列（2）——纵观历史演变（下）

我也要谈谈大型网站架构之系列（2）——纵观历史演变（下）

 

　　这篇文章原本准备前几天就得写的，谁也没想到这段时间公司的RC太多了，含酸苦逼的加班，加班。。。因此在大一点的公司上班，

写代码的责任心必定要强，或许就由于你的一些小bug，给公司带来很多损失。。。这在之前公司真的没多大致会的。

　　好了，继续说说架构的演变，从第四代架构中能够看到，咱们经过作应用程序层的负载均衡能够比较完美的解决了在整个架构中让应

用程序层再也不成为瓶颈，经过A10，咱们可让用户的访问请求分发到集群中的任何一台服务器上，当访问量继续膨胀的时候，咱们就可

以继续在集群中增长服务器来解决负载的压力，达到系统的可伸缩性，如今咱们的业务规模像滚雪球同样愈来愈大，用户数暴增。。。这

时候咱们缓存中的数据也愈来愈多，虽然咱们用了缓存，可是大量的“缓存过时从新读取”和“缓存不命中",致使数据库压力很是大，这时候

数据库的压力成为了咱们架构中的瓶颈。

 

五： 第五代架构

　　 既然数据库成为了咱们第四代架构的瓶颈，这时候必须解决数据库的压力问题，最多见的作法也就是“读写分离”，将写和读的库进行拆

分来缓解数据库的压力。

　　

如今咱们作了多个库，写的时候进主库，而后数据库分发到从库中，而后应用程序在从库中读取，这里为了让数据库对应用程序更加

透明，咱们一般加一个“数据访问层”，在携程里面就是在企业库上进行了一层封装以及安全性采用了all in one 模式，能够看到第五代

架构对数据库的压力有了很大的缓解。

   通过几个月业务喷井式的发展以后，咱们会发现数据库检索愈来愈慢，单表数据量已经差很少爆炸了。。。已经严重影响到系统性能，

用户抱怨不断，这时候“数据检索”成为了咱们系统的严重瓶颈。

 

六：第六代架构

  既然检索成了瓶颈，咱们必须对数据库进行拆分，尽量的减小检索中的数据量规模以及尽量的优化算法。

  1：业务分库

      咱们将不一样的业务分摊到不一样的业务服务器上，而不是将其耦合在一个数据库里面，从而创建起数据库集群，分流应用层对数

　　据库的压力。

  2：分表

　　能够采用时间划分，将三个月以后的数据放入到历史表里面，当前表只保存三个月以内的数据，而从极大提供单表的检索能力。

  3：采用nosql

 　  nosql就是为了web而生，分词，系统日志等等，同样都让很多nosql，并且nosql有其天生的负载均衡。

  4：优化算法

　    栈，队列，二叉树，哈希 等等变换和非变换的数据结构在这种大数据的场景下能够获得灵活运用，这也是区分高级程序员和低等

　　 码农的一条参考标准。

      当你的架构到这个程度的时候，差不到公司的人数也过千了，这时候咱们的业务会分红不少产品线的，好比：票事业部，酒店

事业部，旅游度假事业部，攻略社区事业部，每一个事业部只会负责本身的产品架构，从而将咱们的架构再次细分，从技术角度看，这些

事业部又能够提炼出公共的部门，好比登陆模块，订单处理等等这些可复用的模块，能够相应的成立公共平台事业部和框架架构部，当

这个架构继续往下发展的话，就有了如今的各类云，也就成了各类变钱的工具了，就好比如今的博客园托管在阿里云之上。。。

 

     终于在今天，结束了高层重视的IVR项目的全部事情，最后祭奠一下，自从猪猪侠拿到那些所谓的数据，致使咱们连续加班的日日夜夜。