初始简单架构结构
适用于前期用户少,访问少,所有的硬件软件资源都集成在一部服务器上面,对于一些小型的网站,要求并发比较少的可以满足。

数据库一般使用的是MySQL,开源免费易操作。但是可能WEB逻辑多时,需要多次查表或者更新的时候,读写速度就不太好了,瓶颈在数据库层。
可以调优MySQL,增加MySQL缓存等。下面是初始架构的升级版,增加memcached缓存来提高WEB应用的处理访问速度。
初始简单架构结构升级版

.png)
web应用需要修改,将取数据库的操作先去取memcached,然后再操作数据库。更新数据时也需要更新memcached和数据库。对web应用需要做的事情会更多。
在改进web应用时可以对某些耗时间特别长的逻辑做相应的改动。
这种架构的故障风险较大,memcached挂起了,会造成更长的访问时间。这个可以通过配置memcached.socketTO来做一些事情。
由于应用服务、数据库服务和缓存服务都在一部服务器上,风险大大增加。下面将对服务进行分离。
初始简单架构结构服务分离版

缓存可以放在应用服务器本地缓存里,也可以独立缓存服务器出来。
服务器分离后,各个服务器之间的交互会被网络带宽制约,这个是需要注意的。
如果任一台服务器挂了,会对整个服务都有影响,具体问题具体分析。
主从架构结构

采用负载均衡搭配分发,web应用搭建两部web服务器,缓存服务器一块,数据库采用两部MySQL,配置主从复制,保证数据一致。
如果任一WEB服务器崩溃,另一部可以提供服务,负载均衡会检测是否WEB服务器故障而做分发。同样的,一部数据库挂起,另一部同样可以提供服务。
主从架构升级版结构

可以搭载更多的WEB服务器,或者更多的数据库服务器,数据库架构的策略可以按实际情况而定,一般是一主多从,二主多从,双主备等...
集群架构结构

有两套集群,比较重要的是实现数据库数据同步和缓存数据同步。数据库的同步策略和存储策略是很值得研究和了解,网络上也有大量的这种模型。比如使用cobar对MySQL分库等。
还需要不断学习和实践,各位有想法可以提出来探讨辣。
博客园为原文:http://www.cnblogs.com/zhongshengzhen/p/deploy.html