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