《大型网站技术架构-核心原理与案例分析》(李智慧著)第2章-大型网站架构模式

2.1 网站架构模式
- 分层
  横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责
  - 网站分层架构
    - 应用层：负责具体业务和视图展示，如网站首页及搜索输入和结果展示
      在实践中，大的分层结构内部还可以继续分层，如应用层可以再细分为视图层(美工负责)和业务逻辑层(工程师负责)
    - 服务层：为应用层提供服务支持，如用户管理服务、购物车服务等
      服务层也可以细分为数据接口层(适配各种输入和输出的数据格式)和逻辑处理层
    - 数据层：提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等
  - 好处
    - 通过分层，可以更好地将一个庞大的软件系统切成不同的部分，便于分工合作开发和维护，且各层之间具有一定独立性，只要维持调用接口不变，各层可以根据具体问题独立演化发展而不需要其他层必须做出相应调整。
  - 挑战
    - 必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次调用(比如应用层直接调数据层)及逆向调用(数据层调服务层，或服务层调应用层)
- 分割
  在纵向方面对软件进行切分
  - 分割方式
    - 网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元
  - 好处
    - 一方面有助于软件的开发和维护，另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力
- 分布式
  - 分布式方案
    - 分布式应用和服务
      - 做法：将分层和分割后的应用和模块分部署部署
      - 好处：改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。使不同应用复用共同的服务，便于业务功能扩展
    - 分布式静态资源
      - 做法：网站静态资源如JS、CSS、Logo图片等资源独立分布式部署，并采用独立域名，动静分离
      - 好处：减轻应用服务器的负载压力。使用独立域名加快浏览器并发加载的速度。由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术工种术业有专攻
    - 分布式数据和存储
      - 做法
        
        多台计算机存储以P为单位的海量数据
      - 好处
        
        提供大的存储空间
    - 分布式计算
      - 包括
        
        应用、服务、实时数据处理、搜索引擎的索引构建、数据仓库的数据分析统计等
      - 做法
        
        目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行批处理计算，特点是移动计算而不是移动数据，将计算程序分发到数据所在位置以加速计算和分布式计算
    - 分布式配置
      支持网站线上服务器配置实时更新
    - 分布式锁
      分布式环境下实现并发和协同
    - 分布式文件系统
      支持云存储
- 集群
  - 做法
    - 对于用户访问集中的模块(比如网站的首页)，将独立部署的服务器集群化，即多态服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
  - 好处
    - 因为服务器集群有更多服务器提供相同服务，因此可以提供更好的并发特性。同时因为一个应用多台服务器提供，当某台服务器故障时，负载均衡设备或系统的失效转移机制会将请求转发到集群中其他服务器上，使服务器故障不影响用户使用
- 缓存
  缓存就是将数据放在距离计算最近的位置以加快处理速度。
  - 实现方式
    - CDN
      内容分发网络，部署在距离用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商那里，在这里缓存网站一些静态资源，可以就近以最快速度返回给用户,如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN
    - 反向代理
      部署在网站前端，用户请求到达网站的数据中心时，首先访问反向代理服务器，其缓存网站的静态资源，无需将请求转发给应用服务器就能返回给用户
    - 本地缓存
      在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库
    - 分布式缓存
      将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通***问缓存数据
  - 好处
    - 加快数据访问速度
    - 减轻后端应用和数据存储的负载压力
  - 注意事项
    - 数据访问热点不平衡，某些数据会被更频繁的访问，这些数据应该放在缓存中
    - 数据在某个时间段内有效，不会很快过期，否则容易产生脏读影响结果的正确性
- 异步
  - 做法
    - 业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
    - 在单一服务器内部可通过多线程共享内存队列的方式实现异步，处在业务操作前面的线程将输出写到队列，后面的线程从队列中读取数据进行处理
    - 在分布式系统中，多个服务器集群通过分布式消息队列实现异步，分布式消息队列可以看作内存队列的分布式部署
  - 好处
    - 异步架构是典型的生产者消费者模式，两者不存在直接调用，只要保持数据结构不变，彼此功能实现可以随意变化不互相影响，这对网站扩展新功能非常便利
    - 提高系统可用性
      消费者服务器发生故障，数据会从在消息队列服务器中存储堆积，生产者服务器可以继续处理业务请求，系统整体表现无故障。消费者服务器正常恢复后，继续处理消息队列中的数据
    - 加快网站响应速度
      处在业务前端的生产者服务器在处理完业务请求后，将数据写入消息队列，不需要等待消费者服务器处理就可以返回，响应延迟减少
    - 消除并发访问高峰
      用户访问网站是随机的，存在访问高峰和低谷，即使网站按照一般访问高峰进行规划和部署，也依然会出现突发事件，比如购物网站的促销活动，微博上的热点事件，都会造成网站并发访问突然增大，这可能会造成整个网站负载过重，响应延迟，严重时甚至会出现服务宕机。使用消息队列将突然增加的访问请求数据放入消息队列中，等待消费者服务器依次处理，就不会对整个网站负载造成太大压力
  - 不足
    - 异步方式处理业务可能会对用户体验，业务流程造成影响，需要网站产品设计方面的支持
- 冗余
  网站需要7 * 24小时连续运行，但是服务器随时可能出现故障，特别是服务器规模比较大时，出现某台服务器宕机是必然事件
  - 做法
    - 要想保证服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上
    - 访问和负载很小的服务也必须部署至少两台服务器构成一个集群，其目的是通过冗余实现服务高可用
    - 数据库除了定期备份，存档保存，实现冷备份外，为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现热备份
    - 为了抵御地震等不可抗力导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署灾备数据中心，网站程序和数据实时同步到多个灾备数据中心
- 自动化
  - 做法
    - 使发布过程自动化
      - 自动化代码管理
        开发工程师只要提交自己参与开发的产品代号，系统就会自动为其创建开发分支，后期会自动进行代码合并
      - 自动化测试
        代码开发完成，提交测试后，系统自动将代码部署到测试环境，启动自动化测试用例进行测试，向相关人员发送测试报告，向系统反馈测试结果
      - 自动化安全检测
        安全测试工具通过对代码进行静态安全扫描及部署到安全测试环境进行安全工具测试，评估其安全性
      - 自动化部署
        将工程代码自动部署到线上生产环境
    - 自动化监控
      - 对服务器进行心跳检测，并监控其各项性能指标和应用程序的关键数据指标。如果发现异常，超出预设的阈值，就进行自动化报警，向相关人员发送报警信息
    - 自动化失效转移
      - 在检测到故障发生后，系统会进行自动化失效转移，将失效的服务器从集群中隔离出去，不再处理系统中的应用请求
    - 自动化失效回复
      - 故障消除后，系统进行自动化失效恢复，重新启动服务，同步数据保证数据的一致性
    - 自动化降级
      - 网站遇到访问高峰，超出网站最大处理能力时，为了保证整个网站的安全可用，还会进行自动化降级，通过拒绝部分请求及关闭部分不重要的服务将系统负载降至一个安全的水平
    - 自动化分配资源
      - 必要时还需要自动化分配资源，将空闲资源分配给重要的服务，扩大其部署规模
- 安全
  - 做法
    - 通过密码和手机验证码进行身份认证
    - 登陆、交易等操作需要对网络通信进行加密，网站服务器上存储的敏感数据如用户信息等也进行加密处理
    - 为了防止机器人程序滥用网络资源攻击网站，网站使用验证码进行识别
    - 对于常见的用于攻击网站的XSS攻击、SQL注入、进行编码转换等相应处理
    - 对于垃圾信息、敏感信息进行过滤
    - 对交易转账等重要操作根据交易模式和交易信息进行风险控制
2.2 架构模式在新浪微博的应用
- 新浪微博的系统架构
  - 图片

- 分层
  - 基础服务层
    - 处于最下层，提供数据库、缓存、存储、搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了新浪微博的海量数据和高并发访问，是整个系统的技术基础
  - 平台服务和应用服务层
    - 处于中间层，新浪微博的核心服务是微博、关注和用户。这些服务被分割为独立的服务模块，通过依赖调用和共享基础数据构成新浪微博的业务基础
  - API和新浪微博的业务层
    - 处于最上层，各种客户端(包括web网站)和第三方应用，通过调用API集成到新浪微博的系统***同组成一个生态系统
- 集群的应用
  - 上述这些被分层和分割后的业务模块与基础技术模块分布式部署，每个模块部署在一组独立的服务器集群上。通过远程调用的方式进行依赖访问。
- 异步的应用
  - 在新浪微博的早期架构中，微博发布使用同步推模式，用户发表微博后系统会立即将这条微博插入到数据库所有粉丝的订阅列表中
  - 当用户量比较大时，会引起大量的数据库写操作，超出数据库负载，系统性能急剧下降，用户响应延迟加剧
  - 后来新浪微博改用异步推拉结合的模式，用户发表微博后系统将微博写入消息队列后立即返回，用户响应迅速，消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中，非在线用户登陆后再根据关注列表拉取微博订阅列表
- 缓存的应用
  - 由于微博频繁被刷新，新浪微博使用多级缓存策略
  - 热门微博和明星用户的微博缓存在所有的微博服务器上
  - 在线用户的微博和近期微博缓存在分布式缓存集群中
  - 对于微博操作中最常见的刷微博操作，几乎全部都是缓存访问操作，可以获得很好的系统性能
- 冗余的应用
  - 为了提高系统的整体可用性和性能，新浪微博启用了多个数据中心。
  - 这些数据中心既是地区用户访问中心，用户可以就近访问最近的数据中心以加快访问速度，改善系统性能
  - 这些数据中心同时也是数据冗余复制的备灾中心，所有的用户和微博数据用过远程消息系统在不同的数据中心之间同步，提高系统可用性
- 自动化的应用
  - 同时，新浪微博还开发了一些列自动化工具，包括自动化监控、自动化发布、自动化故障修复等，以改善运维水平提高系统可用性
- 安全的应用
  - 由于微博的开放性，新浪微博遇到一系列的安全挑战，包括垃圾内容、僵尸粉、微博攻击等
  - 除了使用一般网站常见的安全策略，新浪微博在开放平台上使用多级安全审核的策略以保护系统和用户