网站案例架构（网站可扩展性架构）读书笔记

网站可扩展性架构
    扩展性
      保证系统可持续增加新功能；
    伸缩性
      增加服务器资源、提高系统的整体吞吐能力；
  1 构建可拓展的网站架构
    核心思想：
      1 模块化，降低模块间的耦合性，提高模块的复用性
      2 模块分布式部署以后，具体的聚合的方式主要有分布式消息队列和分布式服务。
  
  2 利用分布式消息队列降低系统间的耦合性
    原因：模块之间无直接调用，这样新增和修改对其他模块影响最小。
    事件驱动架构EDA（典型的EDA,生产者消费者模式）
      定义：通过在低耦合模块之间传输事件消息，以保证模块之间的松耦合，并借助事件的消息的通信完成模块之间的合作
      具体实现:
        手段繁多，最常用的分布式消息队列；
    分布式消息队列：
      实现原理：
        1 消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，
        2 消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生成者。
        3 消息队列服务器根据消息订阅列表查找订阅消息的消息消费者应用程序，
        4 将消息队列的消息按照先进先出的（first in first out）原则将消息通过远程通信接口发送给消息消费程序；
      伸缩性：
        当新服务器加入分布式消息队列集群中，通知生产者服务器更改消息队列服务器列表
      可用性：
      
        1 为了避免消费者进程处理缓慢，分布式消息队列服务器内存空间不足造成的问题，如果内存队列满了，会将消息写入磁盘，消息推送模块在
          将队列中的消息处理完成后，将磁盘内容加载到内存队列继续处理
        2 为了避免消息队列服务器宕机，造成消息丢失，会将消息成功发送到消息队列的消息存储在消息生成者服务器，等消息真正被消费者服务器处理后
          才删除消息；
        3 在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中其他服务器发布消息
      产品推荐
        ApacheMQ ,也可以考虑MYSQL
  3 利用分布式服务打造可复用的业务平台
    背景：传统的巨无霸系统的问题：
        1 系统比较重，编译部署困难；
        2 代码分支管理困难；复用的代码模块由多个团队共同维护，merge时候存在冲突，拖慢发布；
        3 数据库连接耗尽;巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的链接通常使用数据库连接池，以每个应用10个连接计，
          一个数百台服务集群的应用将需要在数据库上创建数千个链接，数据库连接上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据
          操作；
        4 新增业务困难：一脚踩进去，全是雷
          怪现象：
            新工程师来公司半年，还是不能接受业务，因为不知道水多深，于是就出现这种怪现象，熟悉产品的老人忙的要死，不熟悉网站产品的新人，一帮忙就出乱，跟着加班加点；
            整个公司热火朝天，加班加点，还经常出故障，新产品迟迟不能上线；
        5 解决方案：
          就是拆分：将模块独立部署，降低系统耦合性，拆分可以分为纵向和横向
          纵向拆分：
            就是将一个大应用，拆分为多个小应用，如果新增业务较为独立，那么直接将其设计部署为一个独立的web应用系统
          横向拆分：
            将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体的模块的代码，即可快熟搭建一个应用系统，
            而模块内业务逻辑变化的时候，这需要接口保持一致，就不会影响业务程序和其他模块
        6总结：
          纵向拆分较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的web应用，而对于横向拆分，不但需要识别复用的业务，设计服务接口，规范服务依赖关系，还需要
          一个完善的分布式服务管理框架；
    WebService与企业级分布式服务
      原理：服务提供者通过WSDL,向注册中心描述自身提供的服务接口属性，注册服务中心使用UDDI发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，
          通过SOAP和服务提供者通信，使用相关服务；
      缺点：臃肿的注册与发现机制
          低效的xml序列手段
          开销相对较高的HTTP远程通信
          复杂的部署与维护手段
    大型网站分布式服务的需求与特点
      WEBSERVIECE的注册与发现：
      服务调用：
      负载均衡：服务提供者集群部署
      失效转移：某个服务实例不可用，可转移到其他服务
      高效的远程通信；大型网站核心服务调用，每天的调用次数会达到数以亿计，如果没有高效的远程通信受端。服务调用会成为整个系统性能瓶颈；
      整合异构系统；网站服务可能使用不同语言开发，部署与不同平台
      对应用最少侵入；服务模块支持集中部署，也可分布式部署
      版本管理；服务提供者，在接口版本升级要，保留旧版本的服务提供请求的调用
      实时监控；没有监控的服务是不能实现高可用的；
      
    分布式服务框架设计(SOA)  Dubbo架构原理解析
      服务消费者程序，通过服务接口使用服务，而服务接口通过代理加载具体服务，具体服务可以是本地代码模块，也可以是远程服务，因此对应用较少侵入，应用程序
      只需要调用服务接口，服务框架根据配置自动调用本地和远程实现；
      
      服务框架客户端模块，通过服务注册中心加载服务提供者列表（服务提供者启动后自动向服务注册中心注册自己可提供的服务接口列表），查找需要的服务接口，并根据配置的
      负载均衡策略将服务调用请求发送到某台服务提供者服务器。如果服务调用失败，客户端模块会自动从服务提供者列表，选择可提供服务的另一台服务器重新请求服务，实现服务
      失效转移，保证服务高可用
      
      使用NIO通信框架，具有较高的网络通信性能；
  
      
  4 可拓展的数据结构
    NOSQL数据库：ColumnFamily(没用过)
    
  5 利用开发平台建设网站生态圈