原文：http://www.me115.com/post/151.html
架构设计中要考虑的核心五要素；
性能、可用性、扩展性、伸缩性、安全性
性能
性能的测试指标
-
响应时间
应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观地反映了系统的“快慢”。下表列出了一些常用的系统操作需要的响应时间。
-
并发数
系统能够同时处理请求的数目 - 吞吐量
单位时间内系统处理的请求数量;
如：TPS、QPS（每秒查询数）
随着并发数的增大，吞吐量随着增大；
超过阈值后，并发数继续增大，吞吐量下降，直到吞吐量降为0，网站宕机；
理解上述3个指标：类比高速公路行车
吞吐量就是每天通过的车辆数
并发数是正在行驶的车辆
响应时间是车速
性能测试方法
- 性能测试
以预期设定的性能值为目标，测试是否能满足预期 - 负载测试
不断加压到安全临界值 - 压力测试
超过安全负载直到崩溃下的最大负载
下图中的横坐标表示消耗的系统资源，纵坐标表示系统处理能力（吞吐量）。在开始阶段，随着并发请求数目的增加，系统使用较少的资源就达到较好的处理能力（a～b段），这一段是网站的日常运行区间，网站的绝大部分访问负载压力都集中在这一段区间，被称作性能测试，测试目标是评估系统性能是否符合需求及设计目标；随着压力的持续增加，系统处理能力增加变缓，直到达到一个最大值（c点），这是系统的最大负载点，这一段被称作负载测试。测试目标是评估当系统因为突发事件超出日常访问压力的情况下，保证系统正常运行情况下能够承受的最大访问负载压力；超过这个点后，再增加压力，系统的处理能力反而下降，而资源消耗却更多，直到资源消耗达到极限（d点），这个点可以看作是系统的崩溃点，超过这个点继续加大并发请求数目，系统不能再处理任何请求，这一段被称作压力测试，测试目标是评估可能导致系统崩溃的最大访问负载压力。
性能测试反应的是系统在实际生产环境中使用时，随着用户并发访问数量的增加，系统的处理能力。与性能曲线相对应的是用户访问的等待时间（系统响应时间），如图所示。
在日常运行区间，可以获得最好的用户响应时间，随着并发用户数的增加，响应延迟越来越大，直到系统崩溃，用户失去响应。
性能测试报告
测试结果报告应能够反映上述性能测试曲线的规律，阅读者可以得到系统性能是否满足设计目标和业务要求、系统最大负载能力、系统最大压力承受能力等重要信息，下表是一个简单示例。
可用性
高可用的应用服务器
构建高可用的应用服务器关键是session的处理，如果能使得每天机器上处理的请求都无状态，即可实现应用服务器的线性伸缩；服务器宕机后也可随时将请求放到其它机器上再次处理；
而对于需要处理状态信息的应用，解决方案是让每台机器使用共享的Session服务器，本地上还是无状态特征；
高可用的服务
设计要点
- 分级管理
区别核心应用和一般应用；在流量增加到超过网站的处理能力时，为了保证核心应用的可用性，可以将一般应用的服务停止，将资源让位给核心服务；
比如博客中的博文显示和博客的评论功能； - 超时设置
- 异步调用
- 服务降级
eg:twitter：随机拒绝部分请求 - 幂等性设计
保证多次调用结果一致
高可用的数据
CAP原理
一个提高服务的存储系统无法同时满足以下三个条件
一致性（Consistency）
数据可用性（Avalibility）
分区耐受性（Patition Tolerance，系统具有跨网络分区的伸缩性）
WEB架构设计中，通常为了保证高可用性，会牺牲一致性；
数据一致性分为：强一致、用户一致、最终一致；
大型WEB站点一般只保证数据的最终一致性；
扩展性
在网站新增业务产品时，实现对现有产品无影响，透明上线新产品。
主要手段
- 事件驱动
利用消息队列实现 - 分布式服务
将业务和可复用服务分离开
伸缩性
通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力。
可能加入的服务器有以下4类，其伸缩性能各不相同；
应用服务器
通过设计实现集群内服务器对等，使用合适的负载均衡可保证良好的伸缩性；
缓存服务器
缓存服务器伸缩性良好，但新加入服务器后可能导致缓存路由失效；
通过改进缓存路由算法，比如Memcached的一致性Hash，可实现加入新的缓存服务器后对原有缓存的影响尽量减少；
数据库服务器
很难做到大规模集群的可伸缩性
实现方式有：读写分离、数据表分库
（单表拆分：Cobar）
也可考虑伸缩性方案在数据库之外实现（通过路由分区）
NoSql产品
Nosql数据库就是为海量数据而生，可轻松实现集群规模的线性伸缩；
（Hbase使用Zookeeper选举master）
安全性
99.99%的设计标准：无单点、在线更新、自动切换
附：思维导图
卓越亚马逊地址： 《大型网站技术架构》
点击查看原图
