服务器划分
对于访问量大的网站而言，将网站的各个部分拆分分别部署到不一样服务器上是颇有必要的。例如将图片和web站点分开。通常而言，在网站的整个服务器部署上分为以下几种类型：css
文件服务器：通常存储系统的相关图片和文件，给各个子系统提供统一的文件调用html
代理服务器：通常使用linux+Nginx做为反向代理mysql
web服务器：.net中最经常使用的Web服务器IIS，Mono中通常使用Nginxlinux
应用服务器：负责系统中各个业务逻辑的提供，好比用户中心，结算中心，支付中心等git
缓存服务器：提供MemCached缓存服务web
数据库服务器：负责网站数据的提供，通常为Sqlserver,mysql,oracle等redis
带宽的计算
假设网站天天要承受100万pv的访问量，计算带宽要涉及到两个指标(峰值流量和页面平均大小),带宽单位为bps(bit/s)。sql
一、假设峰值流量为平均流量的5倍；数据库
二、假设每次访问的平均页面大小为100KB左右。windows
1B=8b---------------------1B/s=8b/s(1Bps=8bps)
1KB=1024B ------------- 1KB/s=1024B/s
1MB=1024KB------------1Mps=1024KB/s
100万pv访问量一天平均分布，折合每秒大约访问12次，页面大小为字节(Byte),总共访问页面大小就是12*100KB=1200KB,1Byte=8bit,则1200KB=9600Kb，9600Kb/1024大约9Mb/s(9Mbps)，咱们网站在峰值流量时必定要保持正常访问，则真实带宽应该在9M*5=45Mbps左右。
网站架构的演变过程之一
公司刚刚起步，业务量不大，每每可能在某个虚拟主机空间商租用一个虚拟主机和一个数据库就搭建了一个最基本的网站
网站架构的演变过程之二增长缓存
随着业务量增长，用户的访问愈来愈多，网站常常性的打不开，慢，甚至出现数据库连接达到最大限制数，这个时候须要针对网站作一些优化策略：
- 减小Http请求，压缩css，js，图片的大小
- 将Microsoft Ajax Minifier集成到VS2010对JS，CSS进行编译时压缩
- 增长页面缓存和增长数据缓存处理
- cnblogs上的缓存全解析
- 自购服务器进行IDC托管
- 自购服务器可以提高硬件的档次以及带宽能够自由控制，通常都是独享带宽，相比共享带宽来讲可以支撑更多的访问量
网站架构的演变过程之三增长web服务器
当系统访问量的再度增长，webserver机器的压力在高峰会上升到比较高，这个时候开始考虑增长一台WebServer，可是增长一台WebServer的时候意味着要在两台的服务器上分别创建相同的站点，那么就会出现以下问题：
如何让访问分配到这两台机器上？Nginx
如何保持状态信息的同步，例如用户session等？
正常考虑的方案有写入数据库、开启状态服务器、cookie、写入缓存等。
如何保持数据缓存信息的同步？
缓存服务器
如何让上传文件这些相似的功能继续正常？
采用文件服务器统一管理
网站架构的演变过程之四分库，分表，分布式缓存
经过增长web服务器享受了一段快速访问的幸福后，发现系统又开始变慢了，通过查找，发现数据库写入、更新的这些操做的部分数据库链接的 资源竞争很是激烈，致使了系统变慢，这下怎么办呢？
分库
分表
Memcache,Redis分布式缓存
水平分区 VS 垂直分区
| 水平 |
垂直 |
|
| 存储依赖 |
可跨越DB |
可跨越表空间,不一样的物理属性 |
| 存储方式 |
分布式 |
集中式 |
| 扩展性 |
Scale Out(横向扩展，增长便宜设备) |
Scale Up(升级设备) |
| 可用性 |
无单点 |
存在单点(DB数据自己) |
| 价格 |
低廉 |
适中，甚至昂贵 |
| 应用场景 |
web 2.0 |
架构演变过程之五Web园或增长更多WebServer
在作完分库分表这些工做后，数据库上的压力已经降到比较低了,这个时候可能到了下一个瓶颈，查看windows的性能计数器发现有大量的阻塞请求，因而能够作Web园或者添加一些webserver服务器。在这个添加webserver服务器的过程，有可能会出现以下几个问题：
一台Nginx服务器的软负载已经没法承担巨大的web访问量了，能够用硬件负载解决F5或应用从逻辑上作必定的分类，而后分散到不一样的软负载集群中
原有的一些状态信息同步、文件共享等方案可能会出现瓶颈，须要进行改进，也许这个时候会根据状况编写符合网站业务需求的分布式文件系统等；
在作完这些工做后，开始进入一个看似完美的无限伸缩的时代，当网站流量增长时，应对的解决方案就是不断的添加webserver。
架构演变之六读写分离和廉价存储方案
经过增长web服务器享受了一段快速访问的幸福后，发现系统又开始变慢了，通过查找，发现数据库写入、更新的这些操做的部分数据库链接的 资源竞争很是激烈，致使了系统变慢，这下怎么办呢，读写分离,订阅和发布
廉价存储方案Nosql
NoSQL = Not Only SQL 指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了不少难以克服的问题，而非关系型的数据库则因为其自己的特色获得了很是迅速的发展。
NoSql数据库大量应用于微博系统等事务性不强的系统
BigTable
MongoDB
http://tech.it168.com/topic/2011/10-1/nosqlapp/index.html
架构演变之七进入大型分布式应用时代和廉价服务器群梦想时代
通过上面这个漫长而痛苦的过程，终于再度迎来了完美的时代，不断的增长webserver就能够支撑愈来愈高的访问量了，可是原来部署在webserver上的那个web应用已经很是庞大 了，当多个团队都开始对其进行改动时，至关的不方便，复用性也至关糟糕，基本上每一个团队都作了或多或少重复的事情，并且部署和维护也是至关的麻烦，由于庞大的应用包在N台机器上复制、启动都须要耗费很多的时间，出问题的时候也不是很好查，另一个更糟糕的情况是颇有可能会出现某个应用上的bug就导 致了全站都不可用，还有其余的像调优很差操做（由于机器上部署的应用什么都要作，根本就没法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将 系统根据职责进行拆分，因而一个大型的分布式应用就诞生了，一般，这个步骤须要耗费至关长的时间，由于会碰到不少的挑战：
一、拆成分布式后须要提供一个高性能、稳定的通讯框架，而且须要支持多种不一样的通讯和远程调用方式；
二、将一个庞大的应用拆分须要耗费很长的时间，须要进行业务的整理和系统依赖关系的控制等；
三、如何运维（依赖管理、运行情况管理、错误追踪、调优、监控和报警等）好这个庞大的分布式应用。
通过这一步，差很少系统的架构进入相对稳定的阶段，同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量，结合这套架构以及这么屡次演变过程吸收的经验来采用其余各类各样的方法来支撑着愈来愈高的访问量。
参考：http://www.cnblogs.com/genson/archive/2009/10/22/1587836.html
| 博客地址： | http://www.cnblogs.com/jiekzou/ |
| 博客版权： | 本文以学习、研究和分享为主，欢迎转载，但必须在文章页面明显位置给出原文链接。 若是文中有不妥或者错误的地方还望高手的你指出，以避免误人子弟。若是以为本文对你有所帮助不如【推荐】一下！若是你有更好的建议，不如留言一块儿讨论，共同进步！ 再次感谢您耐心的读完本篇文章。 |
而你要的支撑scale out的、分布式的架构一般这样考虑问题：
1.storage & cache & replication
rdb sharding(OLTP) + redis cache + hbase(archive)(OLAP)
2.sync & consistency
zookeeper + curator (paxos)
3.stream computing
source : rdb(MySQL、SQL Server、Oracle)、hdfs、hive、hbase
replayble source : kafka
stream computing engine : samza、storm
4.communication
thrift
5.off-line computing
hadoop
6.memory computing & iterative computing
spark
have fun : ]