网站架构设计参考（图文）
转载请注明出处：http://blog.csdn.net/anxpp/article/details/51614973，谢谢！
1、概述
本人并未经历过一个网站从小到大的演化过程（这种机会本来就太小，而且越来越小），现在很多网站，从建立之初就搭建在大型网站提供的云计算服务之上，需要的一切资源都可以按需购买，并且极易伸缩。不过我觉得还是有必要了解一下大型网站的演化过程。下文是参考多方资料整理得出。
2、大型网站架构演化过程
下面就是本人参考多方资源总结而得。
2.1、初始阶段的网站架构
网站一开始，使用的人并不多，访问量比较小，使用一台服务器就已经完全满足要求的。我们的个人主页、博客，都可以使用如下架构：
应用程序、数据库和文件等资源，都在同一台服务器上。通常也使用一些开源免费的软件来将成本最低化。
2.2、应用服务于数据服务分离
随着业务的发展，一台服务器终将不能满足需求。这是，可以按需将应用服务和数据服务分离：应用服务器、数据库服务器和文件服务器。
他们根据各自的特性，对cpu、内存和硬盘等的需求也各不相同：
应用服务于数据服务分离后，不同特性的服务器担任不同的角色， 系统整体性能将大大提高。
2.3、使用缓存改善性能
我们很清楚，并不是所有的资源都被平均访问到，刚好相反，一部分资源可能会被非常频繁的访问，而另外一些则几乎不会被访问。
如果我们将最常被访问的资源直接放到内存中（或其他的缓存方式），由于不再需要从数据库（硬盘）中读取，速度将会大大提高，不过也会增加对内存的需求。
而缓存一般分两种，应用服务器本地缓存和远程缓存。本地缓存因内存原因，不适合放太多，所以可以专门部署大内存的服务器，当远程缓存服务器（速度比本地缓存会慢些）。而目前的缓存技术也比较多，常见的NoSQL数据库也常被用来当缓存工具使用，本地缓存也能借助一些框架实现，这时的架构如下：
使用缓存后，数据访问压力会大大减小。
2.4、使用服务器集群
业务继续发展后，高并发的访问不可避免，使用服务器集群是比较常用的有效手段。
这相当于将一台应用服务器复制多个，然后通过负载均衡服务器，将请求分发到不同的应用服务器，他们干的是相同的事，不过压力会大大减小：
根据高并发的情况，可以增加或者减少其中的应用服务器，从而使系统有较好的伸缩性。
2.5、数据库读写分离
虽然缓存能一定程度上优化数据访问，但是当业务发展一定程度时，数据库的负载压力可能还是会过高，从而成为瓶颈。
目前主流的数据库，都支持配置主从数据库，利用这一特性，我们可以部署两台数据库服务器，一台用于写操作，这是主数据库，而从数据库用于读，主数据库会将数据以数据库提供的机制，增量同步到从数据库，这样就改善了数据库的负载压力：
为了便于应用服务器的扩展以及更容易的访问主从两个数据库，通常会从应用服务器中独立出来一个专门用来访问数据库的数据访问模块。
2.6、使用反向代理和CDN加速访问
CND和反向代理都是使用缓存的原理，区别在于前者部署与网络提供商的机房，使用户咋请求资源时，从就近的机房获取数据；后者部署于应用服务器前端，用户请求到达后，会有限返回服务器中缓存的可用资源。
这两种技术主要目的就是加速用户的访问，使数据返回更快，同时还能减轻后端服务器的负载压力。
2.7、分布式文件服务器和分布式数据库
随着业务的日益增长，任何单个强大的服务器都不能满足业务的需求，这时可以使用分布式数据库和分布式文件服务器。
在数据已经达到服务器不能支持的时候，就可以拆分业务，让他们使用的数据库服务器部署在不同的物理服务器上：
2.8、使用NoSQL和搜索引擎
通常使用NoSQL和搜索引擎技术来处理复杂的数据存储和检索：
2.9、业务拆分
随着业务的进一步发展，也使其变得更加复杂，导致整个系统难以维护。
这时就可以将整个业务拆分成不同的产品线，再按需将各个产品线拆分成不同的应用，并对这些应用单独部署维护，然后以超链接、消息队列数据分发和访问统一的数据存储系统来关联这个完整的系统：
2.10、分布式服务
随着业务的拆分得越来越小，整个系统的关联上也变得日益复杂，部署维护依然是一件非常困难的事。
这时可以将这些业务中一些通用的地方提取出来独立部署加以复用，提供统一的服务：
3、其他
目前，实现以上架构都有大量成熟稳定的技术支持，博客后续也会陆续更新添加相关技术的文章。
对于架构的选择，不能一味追求大而全，应该以当前业务及后续发展合理选择，既能节约直接成本，还能降低开发、部署和维护的成本。