http://blog.csdn.net/chaofanwei/article/details/29191073
扩展性是指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。
设计网站可扩展架构的核心思想是模块化，并在此基础上，降低模块间的耦合性，提供模块的复用性。模块通过分布式部署，独立的模块部署在独立的服务器上（集群）从物理上分离模块之间的耦合关系。
模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务。
1、利用分布式消息队列降低系统耦合性
如果模块之间不存在直接调用，那么新增模块或者修改模块对其他模块影响最小，这样系统的可扩展性无疑更好一些。
事件驱动框架：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的架构就是生产者消费者模式。在大型网站架构中，具体实现手段很多，最常用的就是分布式消息队列，如下图所示：
消息队列利用发布-订阅模式工作，消息发送者发布消息，一个或者多个消息接收者订阅消息。
由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的响应延迟；同时，在网站访问高峰，消息可以暂时存储在消息队列中等待处理，减轻数据库等后端存储的负载压力。
目前开源的和商业的分布式消息队列产品有很多，比较著名的有Apache ActiveMQ等，如下是分布式消息队列的架构原理：
2、利用分布式服务打造可复用的业务平台
使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息；那么分布式服务则通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用。
大型网站分布式服务的需求与特点：
- 负载均衡
- 失效转移
- 高效的远程通信
- 整合异构系统
- 对应用最小入侵
- 版本管理
- 实时监控
目前国内有较多成功实施案例的开源分布式服务框架是阿里巴巴的Dubbo，下图是Dubbo的架构原理：
服务消费程序通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地的代码模块，也可以是远程的服务，因此对应用较小入侵；应用程序需要调用服务接口，服务框架根据配置自动调用本地或远程实现。
服务框架客户端模块通过服务注册中心加载服务提供者列表（服务提供者启动后主动向服务注册中心注册自己可提供的服务接口列表），查找需要的服务接口，并根据配置的负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现服务的自动失效转移，保证高可用服务。
3、利用开放平台建设网站生态圈
大型网站为了更好的服务自己的用户，开放更多的增值服务，会把网站内部的服务封装成一些调用接口开放出去，共外部的第三方开发者使用，这个提供开放接口的平台被称作开放平台。
开放平台是网站内部和外部交互的接口，外部需要面对众多的第三方开发者，内部需要面对网站内诸多的业务服务。虽然每个网站的业务场景和需求都不相同，但开发平台的架构设计却大同小异，如下图所示：
API接口：是开发平台暴露给开发者使用的一组API，其形式可以是RESTfull，WebService，RPC等各种形式。
协议转换：将各种API输入转换成内部服务可以识别的形式，并将内部服务的返回封装成API格式。
安全：除了一般应用需要的身份识别、权限控制等安全手段，开放平台还需要分级的访问带宽限制，以保证资源被公平合理的使用。
审计：记录第三方应用的访问情况并进行监控、计费等。
路由：将开放平台的各种访问路由映射到具体的内部的服务。
流程：将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用。
