第七章 随机应变：网站的可扩展架构

第七章 随机应变：网站的可扩展架构

• 网站的扩展性指在现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。
• 表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应
• 遵循开闭原则，系统增加新功能，不需要对现有系统的结构和代码进行修改

---

1. 构建可扩展的网络架构
   
   • 开发低耦合系统时软件设计的终极目标之一
     
     • 低耦合的模块更易复用，低耦合的系统开发维护更轻松并且易于管理和扩展
     • 架构师最大的价值在于具有将大系统切分为N个低耦合的子模块的能力
     • 可扩展架构的核心思想是模块化，利用分层和分割的方式进行软件分割，在此基础上，降低模块耦合，提高模块复用
   • 模块部署方式
     
     • 模块通过分布式部署方式，物理上分离模块之间的耦合性，进一步降低模块间的耦合性，提高复用
     • 模块分布式部署以后的聚合方式
       
       • 分布式消息队列
       • 分布式服务

2. 利用分布式消息队列降低系统耦合性
   模块间不存在直接调用，那么新增模块或者修改模块就对其他模块影响最小，可扩展性便更好

   • 事件驱动架构（Event Driven Architecture）
     通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作,例如操作系统中的生产者消费者模式

   • 分布式消息队列

     • 整体结构
       利用发布——订阅模式工作，消息发送者发布消息，一个或多个消息接收者订阅消息
       分布式消息队列部署到独立的服务器上，应用程序通过远程访问接口使用分布式消息队列，进行消息存取操作
     • 工作流程
       消息生产者将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者；消息队列服务器根据消息订阅列表查找消息消费者应用程序，然后将消息队列中的消息按照先进先出（FIFO）的原则通过远程通信接口发送给消息消费者程序
     • 优点
       网站访问高峰时，消息可以暂存在消息队列，消息接收者根据负载处理能力控制处理速度，减轻后端存储的压力

     • 产品
       Apache ActiveMQ

       • 伸缩性：消息队列服务器上的数据可看作被即时处理，因此类似于无状态服务器，伸缩简单
       • 可用性：内存空间不足时会将消息写入磁盘，将内存消息队列处理完后进行加载继续处理；为了避免宕机消息丢失，消息生产者服务器会保存消息，直到消费者服务器处理完成后才删除，如若处理失败则会选择分布式消息队列服务器集群中其他的服务器发布消息

       MySQL记录也可以实现简单的消息队列

3. 利用分布式服务打造可服用的业务平台
   分布式服务通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务调用
   
   • 巨无霸应用系统的问题
     
     • 编译、部署困难
     • 代码分支管理困难
     • 数据库连接耗尽
     • 新增业务困难
   • 解决方案为拆分，模块独立部署，降低系统耦合性
     
     • 纵向拆分：将一个大应用拆分为多个小应用，新增业务如果较为独立，直接单独部署为一个独立的Web应用系统
     • 横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块代码，面向接口编程，只要接口不变，内部逻辑变化不影响其他模块
   • Web Service与企业级分布式服务
     服务提供者通过WSDL（Web服务描述语言）向注册中心描述自身提供的服务接口，注册中心使用UDDI（统一描述、发现和集成）发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过SOAP（简单对象访问协议）和服务提供者通信，使用相关服务
     
     • 优点
       
       • 具有成熟技术规范和产品
       • 具有许多成功案例
     • 缺点
       
       • 臃肿的注册和发现机制
       • 低效的XML序列化手段
       • 开销相对较高的HTTP远程通信
       • 复杂的部署和维护手段
   • 大型网站分布式服务的需求和特点
     
     • 负载均衡
     • 失效转移
     • 高效的远程通信
     • 整合异构系统
     • 对应用最少侵入
     • 版本管理
       需支持多版本发布
     • 实时监控
   • 分布式框架设计
     国内较多实施成功案例的分布式服务框架是阿里巴巴的Dubbo
     
     • 服务消费者应用程序通过服务接口使用服务，而服务接口通过代理加载具体服务，可以是本地的代码模块，也可以是远程的服务，侵入性小
     • 服务框架客户端模块通过服务注册中心加载服务提供者列表（服务提供者启动后自动向服务中心注册自己可提供的服务接口列表），查找需要的服务接口，并根据配置的负载均衡策略进行请求发送，调用失败后客户端模块自动从服务提供者列表选择一个可提供同样服务的另一台服务器重新请求服务，实现了失效转移，保证服务高可用
     • 支持多种通信协议和数据序列化协议
     • 使用NIO通信框架，具有较好的性能
4. 可扩展的数据结构
   
   • 传统关系数据库为了保证运算正确性，设计时便需要指定标的schema——字段名称，数据类型等，并要遵循特定的设计范式，难以面对需求变更，使用预先的冗余字段应对也是一种糟糕的设计
   • NoSQL数据库使用ColumnFamily（列族）设计，创建表时只需要指定ColumnFamily的名称、无需指定字段，数据写入时再指定，因此可以随意扩展，查询时也可以随意查询，非常灵活
5. 利用开放平台建设网站生态圈
   
   • 开放平台
     大型网站把网站内部的服务封装成一些调用接口开放出去，供第三方开发者使用，提供开放接口的平台称作开放平台
     开放平台是网站内部和外部交互的接口，外部需要面对众多的第三方开发者，内部需要面对网站内诸多的业务服务
   • 开放平台的架构设计
     
     • API接口
       开放平台暴露给开发者使用的一组API，可以使RESTful、WebService、RPC等各种形式
     • 协议装换
       将各种API输入转换为内部服务可识别的形式，并将内部服务的返回封装成API的格式
     • 安全
       身份识别、权限控制；分级的访问带宽限制，保证平台资源被第三方应用公平合理使用，保护网站内部服务不会被外部应用拖垮
     • 审计
       记录第三方应用的访问情况，并进行监控、计费等
     • 路由
       将开放平台的各种访问路由映射到具体的内部服务
     • 流程
       将一组离散的服务组织成上下文相关的新服务，隐藏服务细节，提供统一接口供开发者调用