大型网站及架构演进过程
大型网站及架构演进过程
标签（空格分隔）： 读书笔记
*通过前面的介绍，我们已经了解了分布式系统的相关知识，下面看一下大型网站架构演化及怎么用这个集群的。
大型网站的定义
看这个的我想都是有些经验的人了，就不啰嗦了，大型网站就是访问量&数据量都很大，必须同时具备这两个条件才可以，你整一堆静态页面 每天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%）。
