大型网站架构体系的演变

互联网上有不少关于网站架构的各类分享，有些主要是从运维和基础架构的角度去分析的（堆机器，作集群），太关注技术细节实现，普通的开发人员基本看不太懂。

本文上篇将主要介绍大型网站基础架构的扩展，下篇则重点从应用程序的角度去介绍网站架构的扩展和演变。

 

草根时期，快速开发网站并上线。固然，一般只是先试水，用户规模也没有造成，经济能力和投入也很是有限。

有必定的业务量和用户规模了，想提高网站速度，因而，缓存出场了。

市场反响还不错，用户量天天在增加，数据库疯狂读写，逐渐发现一台服务器快撑不住了。因而，决定把DB和APP作分离。

单台数据库也感受快撑不住了，通常都会尝试作“读写分离”。因为大部分互联网“读多写少”的特性所决定的。Salve的台数，取决于按业务评估的读写比例。

 

数据库层面是缓解了，可是应用程序层面也出现了瓶颈，因为访问量增大，加上早期程序员水平有限写的代码也很烂，人员流动性也大，很难去维护和优化。因此，很经常使用的办法仍是“堆机器”。

 

加机器谁都会加，关键是加完以后得有效果，加完以后可能会引起一些问题。例如很是常见的：页面输出缓存和本地缓存的问题，Session保存的问题......

到这里，已经基本作到了DB层面和应用层面的横向扩展了，能够开始关注一些其它方面，例如：站内搜索的精准度，对DB的依赖，开始引入全文索引。

Java领域用的较多的是Lucene、Solr等，而php领域用的比较多的是sphinx/coreseek。

到目前为止，一个可以承载日均百万级访问量的中型网站架构基本介绍完了。固然，每一步扩展里面都会有不少技术实现的细节，后续有时间会写文章单独去剖析那些细节。

 

在作扩展知足了基本的性能需求后，咱们会逐渐关注“可用性”（也就是咱们一般听别人吹牛时说的SLA、几个9）。如何保证真正“高可用”，也是个难题。

几乎主流的大中型互联网公司，都会有用到相似的架构，只是节点数不一样而已。

 

还有一招用的比较多的，那就是动静分离。能够须要开发人员配合（把静态资源放独立站点下），也能够不须要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。有了单独的静态文件服务器以后，存储也是个问题，也须要扩展。多台服务器的文件怎么保持一致，买不起共享存储怎么办？分布式文件系统也派上用场了。

还有一项目前国内外用的很是广泛的技术CDN加速。目前该领域竞争激烈，也已经比较便宜了。国内南北互联网问题比较严重，使用CDN能够有效解决这个问题。

CDN的基本原理并不复杂，能够理解为智能DNS+Squid反向代理缓存 ，而后须要有不少机房节点提供访问。

 

截止目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么须要大面积的修改代码。

若是上面那些手段都用光了，仍是支撑不住怎么办？不停的加机器也不是办法啊？

随着业务愈来愈复杂，网站的功能愈来愈多，虽然部署层面是采用的集群，可是应用程序架构层面仍是“集中式”的，这样会致使不少耦合，不便于开发、维护，并且容易“一荣俱损”。因此，一般会把网站拆分出不一样的子站点来单独宿主。

应用都拆了，因为单个数据库的链接，QPS，TPS，I/O处理能力都很是有限，DB层面也能够去作垂直分库操做

拆分应用和DB以后，其实仍是会有不少问题。不一样的站点，里面可能会有相同逻辑和功能的代码。固然，对于一些基础的功能咱们能够封装DLL或者Jar包去处处提供引用，可是这种强依赖也很容易形成一些问题（版本问题、依赖关系等处理起来很是麻烦）。这样，传说中的SOA的价值就获得体现了。

应用、服务之间仍是会出现一些依赖问题，这时候，高吞吐量的解耦利器出现了

 

 

最后，还介绍一个大型互联网公司都用的绝技--分库分表。我的经验，不是业务发站和各方面很是迫切，不要轻易走这一步。

由于分库分表谁都会干，关键是拆完以后怎么办。目前，市面上尚未彻底开源免费的方案，能让你一劳永逸地解决数据库拆分问题。