其实要设计一个高可用、高负载的系统还是有一定的规矩可循的，其手段无外乎向上扩展(Sacle Up 硬件扩展)或者向外扩展(Scale Out 软件扩展)，这两种方案在某一阶段时期，会显著改善网站的性能，但不久之后，问题依旧。本文参考网上相关资料，试图提供一个可行的 "有限" 解决方案。
早期
1. 对业务应用进行垂直分割，将不同的业务边界划分出来。程序员常说的 "多层体系" 只是纵向解决了不同编程层次的划分，相对于业务而言，并没有做出什么处理。现在 SOA 大行其道，除了人们认识到面向服务带来的互联、扩展性以外，它也将不同服务的变化区分开来，各自拥有独立的实现和存储机制。每个服务使用不同的数据库或数据表，从一定程度上减轻了以往单个数据库频繁造成的 "锁" 和 I/O 瓶颈问题。
2. 将网站系统中的动态内容和静态资源分离出来，使用单独的更加高效的服务器(诸如 Apache + Linux)提供静态信息。多数情况下，流量的极大部分来源于图片、视频等，用多台服务器同时提供页面显示除了可以提高页面响应和现实速度外，同时他将流量分解到多台服务器上。另外，我们应该避免使用动态解析 (ASPNET_ISAPI.dll / HttpModule / HttpHandler) 来处理静态数据的过滤和路径重写。
3. 使用缓存机制，包括使用诸如 ASP.NET Cache、PageCache、创建静态页面等手段。设计良好的缓存机制能极大提高系统性能和响应速度。
4. 使用 64 位数据库系统。SQL Server 2005 在 64 位系统上可以使用更多的内存(最高64GB)，而且在多 CPU 下也拥有更好的性能。有了更大的内存，我们甚至可以将某些常用且极少变化的表(比如分类目录表等)设置为内存表以提高响应速度。
5. 关闭操作系统的某些安全设置，比如 Windows 2003 预防 DDOS 攻击的一些设置，也可以避免一些意外的访问瓶颈。
运行期
6. 建立多数据库体系。使用单个或多个用于数据更新的数据库服务器，然后利用数据库的复制和订阅功能同步到其他多台专门用于显示的数据库服务器上，这样可以有效减少因为更新带来的数据库访问等待。当然，这种体系并不适用所有的业务。
7. 对大数据表进行分区。现在的主流数据库基本都支持数据表分区功能，我们可以横向分区，将不同时期的数据存放到多个分区表中;也可以纵向分区，将不常用的字段放到其他分区表中。分区表并不会影响到我们的开发模式，无须对代码进行调整，但数据表尺寸从 TB 减小到 GB 所带来的好处是无法忽略的。
8. 使用负载均衡等手段提升性能。包括DNS负载均衡、代理服务器负载均衡、地址转换网关负载均衡、协议内部支持负载均衡、NAT负载均衡、反向代理负载均衡等，负载均衡作为最常用的上扩手段，其效果也非常明显。
9. 使用 SAN 等专用的存储系统来提高 I/O 性能。SAN 使用光纤通道连接多个存储设备，可以改善多个服务器硬盘之间使用网线传输数据的性能问题。此外，SAN 还可以动态调整存储容量，更加有利于系统备份和恢复。
10. 电力备份。如果是自主机房，除了配置 UPS 电源外，最好拥有独立的发电设备。当然，对中小型网站而言，这过于奢侈了些。
