大型门户网站的可伸缩性架构设计准则

层）来访问数据库（部署在独立的服务器上），最大的好处就是缓存和灵活性。缓存的内存占用比较大，我们要把它和网站进程分开，而且这样做我们可以很方便的去改变一些数据访问的策略，即使到时候数据库有分布的话在这里可以做一个调配工作，这样灵活性就很大了。还有好处是中间层可以做电线网通桥梁，可能网通访问双线再访问电信会比网通直接访问电信服务器快。

有人说我不分，我可以做负载均衡，对，是可以的，但是如果分的话，同样的10台机器肯定比不分10台机器可以承受更多的访问量，而且对硬件的需求可能不会很高，因为知道需要哪个硬件特别好。争取让每一个服务期都不空闲，又都不是太忙，合理进行组合调整和扩充，这样的系统伸缩性就高了，能根据访问量来调整的前提就是之前有考虑到分，分的好处是灵活性、伸缩性、隔离性以及安全性。

对服务器来说，我们有几点是要长期观察的，任何一点都可能是瓶颈：

1. CPU：动态文件的解析需要比较多的CPU，CPU出现瓶颈就要看是不是哪个功能过长时间占用线程，如果是就分出去。或者就是每一个请求处理时间不长，但是访问量很高，那么就加服务器。CPU是好东西，不能让他干等，不做事情。

2. 内存：缓存从IIS进程独立出去，一般对WEB服务器来说内存不够的情况不是很多。内存比磁盘快，要合理利用。

3. 磁盘IO：用性能监视器找到哪些文件IO特别大，找到了就分到独立的一组文件服务器上去，或者直接做CDN。磁盘慢，大规模读取数据的应用靠缓存，大规模写入数据的应用可以靠队列来降低突发的并发。

4. 网络：我们知道，网络的通讯是比较慢的，比磁盘还慢，如果是做分布式缓存，分布式计算的话，要考虑到物理服务器之间网络通讯的时间，当然，在流量大了以后，这可以提高系统的接纳能力一个等级。静态内容可以借助CSD分担一部分，在做服务器假设的时候还要考虑中国特色的电信网通情况以及防火墙。

对SQL SERVER数据库服务器来说[UPDATE]：

其实还是水平分割和纵向分割，一个二维表，水平分割就是横过来切一刀，纵向分割就是竖直切一刀：

1、纵向分割就是，我们不同的应用可以分到不同的DB中，不同的实例中，或者说把某个拥有很多字段的表拆分成小表。

2、横向分割就是，某些应用可能不负载，比如用户注册，但是用户表会非常大，可以把大表分开。可以采用表分区，数据存储在不同文件上，然后再部署到独立物理服务器增加IO吞吐以改善读写性能，土一点的做法就是自己定期把老的数据存档。表分区的另外一个优势可以增加数据查询速度，因为我们的页索引可以有多层了，就像一个文件夹中的文件不要太多，多分几层文件夹一样。

3、还可以通过数据库镜像、复制订阅、事物日志，把读写分开到不同的镜像物理数据库上，一般来说够用，如果还不行可以用硬件来实现数据库的负载均衡。当然，对于BI，我们可能还会有数据仓库。

架构上考虑到了这些之后，流量大了，就可以在这个的基础上再去调整或者做WEB服务器或者应用服务器的负载均衡。很多时候我们都是在重复发现问题-》找到瓶颈-》解决这个过程。

典型的架构如下：

 

 

 

 

动态WEB服务器配好点的CPU，静态WEB服务器和文件服务器磁盘好点，应用服务器内存大点，缓存服务器也是，数据库服务器当然内存和CPU都要好。