大型网站及架构演进过程

目录

• 大型网站及架构演进过程
  • 大型网站的定义
  • 架构演进
  • 关于负载均衡session的解决方案
  • 读取性能的优化

大型网站及架构演进过程

标签（空格分隔）： 读书笔记

---

*经过前面的介绍，咱们已经了解了分布式系统的相关知识，下面看一下大型网站架构演化及怎么用这个集群的。

大型网站的定义

看这个的我想都是有些经验的人了，就不啰嗦了，大型网站就是访问量&数据量都很大，必须同时具有这两个条件才能够，你整一堆静态页面 天天1000000000000000000000我的访问也不能称之为大型网站。只有当以上两个条件都具有的状况下，你才会有高并发的问题，才须要一个集群来支撑你的业务。

架构演进

这方面的文章确实很多，给你们介绍几个比较不错的演进过程
宜人贷：http://www.jianshu.com/p/410250e006cb
精品博客（包含不少案例）：http://www.hollischuang.com/archives/1036

---

关于负载均衡session的解决方案

关于负载均衡session问题的解决方案：
1.使用无状态(cookie)的会话请求
缺点是
安全性：毕竟cookie是可见的。若是要实现安全的cookie就要在技术上改进，好比加密或每次生成一个token等方式来规避不安全问题。
cookie长度限制：这个无解
带宽消耗及性能影响：每次请求都带有session数据，还要解密及设置新token，相对来讲确定对性能有必定影响。
若是对安全性要求不是很高，仍是能够选用这种方式。
2.ngxin使用ip轮询的方式(不稳定）
缺点是当使用ip轮询方式式，假如某一ip访问的机器挂了。把这个ip定位到其余机器上，就没有session了。以及nginx会变成一个有状态的节点，内存消耗会更大（不过能够加内存嘛），可是容灾会更麻烦。
3.session同步
如今主流的容器都有session同步功能，好比tomcat。
同步session形成网络带宽消耗，机器越多，消耗越大，相对来讲性能也越差。
每台机器都须要保存所有机器的session.这样session数据占用的内容会很严重。
4.使用会话集中管理，如membercache来集中管理回话。
这种是比较常见的实现方式。比以上3种方式都要好，可是也有必定的缺点，好比session存储须要远程读取，会有延时及不稳定性，不过通常咱们集群都是部署在内网的，这点能够忽略。另外一个问题就是要相应的作好session集中会话管理服务器的容灾工做。假如没有容灾，session会话管理服务器挂了。整个应用就会受到影响。

读取性能的优化

数据库优化

分库/分表/分区：这里建议采用分区操做，对sql比较友好，对orm层也没有变化。分表分库应为最后的优化手段，毕竟对数据层代码有影响。并且会存在分布式事务这个大麻烦。
读写分离：读库与写库分开，如今各类数据库都有这种技术，只不过相应的来讲，会有必定的延时性。可是性能提高是比较大的。

搜索

对于站内搜索，若是数据量比较大，可使用作一个搜索组件来代替like,毕竟like效率不是很高。

缓存

对于常常须要读不多改的数据，能够经过缓存来提升读取的性能。这部分就不用多说了，主要就是ehcache/redis等各类cache组件。
另外一个缓存的应用就是缓存页面，把常常访问的动态页面缓存起来，直接读取缓存，减少服务器的开销。好比ehcahce就能够缓存页面。
缓存使用的好很差的一个指标就是：缓存命中率，若是命中率很低，须要调整代码结构。

总结
总的来讲，全部的架构都是经历了从如下这个阶段
1.webapp&database:应用与数据库在一台机器上(all in one)。
2.webapp+database:分离数据库与应用，提升数据读写性能。
3.nginx+nwebapp+database：负载均衡+多个应用服务器+数据库。
4.nginx+nwebapp+cache+database：基于第3次改变，增长缓存设置，提升读取性能。
5.nginx+nwebapp+cache+ndatabase:添加多个数据库，实现读写分离，提升读取性能。
6.基于5的基础上，对数据库进行改造，包括分表分库分区或使用第三方的软件（mycat等）来加强数据库性能。同时对webapp进行拆分，拆分出多个服务中心，每一个服务中心负责专门的业务。期间涉及到的技术有(包括但不限于):redis/avtivemq(消息中间件)/mycat/zookeeper/nosql等

其实对于大型网站来讲，主要问题就是 1.服务的管理：这个比较麻烦，若是服务多了之后各类接口的调用及服务状态的监控 2.io：对于如今状况来看，咱们服务的主要瓶颈仍是集中在io层。主要是数据库的读写比较耗费时间，因此解决了这个问题，我想应用的速度是能够更上一层楼的。包括利用适合ssd的数据库，记得国外有个这样的数据库。还有好的中间件，如今的中间件都有较大的性能损耗（30%）。