对于开发者而言，他们主要关注程序的响应时间和延展性。
响应时间也是衡量一个应用程序的效率的指标之一。如果一个请求到响应时间超出了良好的感知范围，我们就可以认为这个程序的性能很糟糕。一般而言，最好能够在一两秒内得到想要的页面。
延展性，说了是添加了更多的硬件设备，应用程序能够线性地承受更多的请求。添加硬件的方式有两种：
l 向上扩展（垂直扩展）--增加CUPs数量或者在一个单一的盒子（指的是一台机器）里添加更快的CUP
l 横向扩展（水平扩展）--增加多个盒子（机器）。
通过添加更多的资源，应用程序能够处理更多的请求，并且不会影响程序的响应时间，我们就说这个应用程序表现得很好。然而，响应时间和延展性不是结合在一起的。应用程序可能得到一个满意的响应时间，但是不能够处理确定一定量的请求。反之，如果更够处理一定量请求数而响应性能很差。所以，在资源一定的情况下，我们不得不在响应时间和并发响应请求数上做一个很好的平衡。
产能计划。所谓产能计划就是，在生产环境下，解决所需要的硬件区处理希望的加载量的一种实践。通常情况下，它设法解决用几台机器提升整个应用程序的性能，并在一定并发量的测试中，达到预期的效果。
如果在多层架构的任意一层中是可扩展的，我们就说应用程序的架构是可扩展的。在下面图表中，它表示是线性扩展整个应用程序任意一个层次。
扩展负载均衡。负载均衡是能够横向扩展的，主要是通过指定DNS到多个IP地址，并且使用DNS Round Robin 负载算法实现IP地址查找。另外一种可选方式就是，在前端使用负载均衡并且将请求分发到下一级的负载均衡。多级的负载均衡很少会出现在单台运行着Nginx或者HAProxy负载均衡的机器上，这类型的软件负载均衡能够在每环境上每次处理2万次的并发请求量，比较于Web应用的容器中每次几千次而已，它的优势就比较明显。因此，一个单一负载均衡能够很好的管控几个web应用程序的服务器。
扩展数据库。扩展数据库是我们面对的一个很不通的问题。添加存储过程、函数会给数据持久层带来额外的管理经费和应用的复杂性。关系数据库（RDBMS）能够通过master-slave模式扩展，伴随着读写在master机器上，仅仅只有读在slave数据库节点上。但是，有些业务使用NoSQL可以明显提供整个系统的性能。我们知道，在并发的环境下，NoSQL无法实现数据的一致。因此，它通常用来提高程序的高可用性。比较流行的NoSQL有Redis，MongoDB等。
分离数据库。数据库可以被分离为垂直分区或者水平分片。
..................[待续]
原文地址：http://blog.csdn.net/john_f_lau/article/details/26406923
