超大流量分布式系统架构解决方案

一.脑图

 二.笔记

• 一.大规模服务化架构
  • 1.分布式系统的架构演变过程
    • 单机架构
    • 集群架构
    • 垂直拆分业务子系统
      • 根据系统业务功能的不同拆分多个业务模块，由不同的业务团队负责承建，分而治之，独立部署。
        • 以大型电商网站为例，拆分为首页、用户、搜索、广告、购物、订单、商品、收益结算等子系统
      • 注意把控拆分系统等粒度，如果拆分过细，会导致维护成本过高
      • 作用
        • 降低业务耦合、实现高内聚低耦合，提升系统容错性
        • 业务垂直化改造可以防止一些非核心模块的问题导致核心模块出现问题
    • 服务化架构演进
      • 前提
        • 进行服务化改造的前提条件: 用户规模逐渐扩大,多元化的业务出现,技术人员扩充导致多人维护一个模块时,就可以进行服务化的改造,否则都不太适合
      • 目的
        • 整合共同服务
        • 整合底层资源
          • 如 数据库连接
        • 减少功能开发维护难度（代码解耦）
    • 前后端分离架构演进
    • API网关服务
      • 职责
        • 系统入口，所有前端请求通过网关访问后端服务
        • 统一负责处理公共逻辑
          • 比如：鉴权、流控、日志记录、安全防护、负载均衡、灰度发布
          • 灰度发布
            • 通过一系列的规则和策略，先将一小部分的用户作为“金丝雀”，让其请求路由到新版本应用上进行观察，待运行正常后，再逐步导流更多的用户到灰度环境中
            • 作用
              • 快速试错，尽可能控制和缩小问题的影响范围
              • 收集用户的使用反馈，完善和改进当前产品
      • 选型
        • springCloud + Zuul
        • Dubbo + 自建WebServer
      • 网关层的引入并非必须，但是业务越复杂，网关的好处就会越明显
    • 分布式多活数据中心架构演进
      • 主中心负责核心业务的正常流转，其他数据中心负责数据备份及承担一些边缘业务
        • 假设主数据中心发生重大灾难，灾备数据中心可以接管，减少对用户的影响
      • 传统企业
        • 两地三中心
          • 生产数据中心
          • 同城灾备中心
          • 异地灾备中心
          • 好处
            • 较好的容灾和容错性
          • 坏处
            • 产生资源浪费
      • 互联网企业
        • 分布式多活数据中心
          • 将两个或两个以上的数据中心同时并行对外提供服务
        • 多活主要问题:
          • 多数据中心之间需要打通内网专线通道；
          • RPC调用需要做到就近调用；
          • 数据同步问题
  • 2.服务治理需求
    • RPC调用
      • 本质上是让服务提供方和服务调用方都能够以一种极其简单的方式来实现服务的发布和调用，使开发人员只需要关注自身的业务逻辑
      • 实现
        • Dubbo
    • 警惕因超时和重试引起的系统雪崩
    • 分布式事务
      • 强一致性
      • 最终一致性
        • 一般采用最终一致性，避免过多占用资源，增加系统复杂度
    • 注册中心性能瓶颈方案
      • 问题
        • 服务扩容时，应用启动异常缓慢
        • 冗余的服务配置项会增加存储压力和扩大网络开销
      • 改造方案
        • 阶段一
          • 增加Zookeeper的ObServer节点
          • 提升Zookeeper集群的QPS和分担带宽压力
          • 扩展ObServer节点不会降低集群的写入性能
        • 阶段二
          • 减少注册中心的配置，只写入关键信息，其他配置信息写入元数据中心，实现数据分离
          • 避免注册中心存在过多的冗余配置项而引起数据膨胀
          • 降低消费者灾拉取配置数据时的网络开销
          • Dubbo 2.7.0版本 支持精简注册配置项和元数据服务等功能
        • 阶段三
          • 更换注册中心，自研或Nacos
  • 3.服务治理之调用链
    • 梳理服务间依赖关系及调用顺序
    • 分布式调用跟踪系统其实就是一个监控平台，能够以可视化的方式展现跟踪到的每一个请求的完整调用链，以及采集调用链上每个服务的执行耗时、整合孤立日志等。
      • 淘宝的鹰眼（EagleEye）
      • Twitter的Zipkin
      • 新浪的Watchman
      • 京东的Hydra
      • 华为的SkyWalking
    • 论文
      • Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
    • 实现方案
      • 基于Dubbo filter + SkyWalking + es
      • 基于AOP的非侵入式
• 二.全链路压测
  • 线上实施全链路压测
    • 核心点
      • 业务系统、中间件如何配合改造升级
      • 如何将压测数据引流到隔离环境中
      • 压测数据如何构造
      • 超大规模的压测流量如何发起
    • 作用
      • 评估机器扩容数量
      • 验证系统的最大负载是否接近于预期
  • 业务系统如何区分压测流量
    • 压测流量打标
      • 在URL上进行打标
      • 在HTTP的header中进行打标
  • 压测数据隔离方案
    • 物理隔离
      • 缺点
        • 增加运维成本
    • 逻辑隔离
• 三.流控方案
  • 限流方案
    • 扩容
      • 增加节点数量
    • 静态化
      • 通过CDN缓存静态化数据，避免请求直接访问数据中心
      • 静态数据和动态数据分而治之
    • 缓存
      • 提高系统读写能力
    • 队列
      • 异步处理
    • 限流
      • 限流算法
        • 令牌桶算法
          • 桶容量不变，以平均速率向桶中放入令牌
          • 限制流量的流入速率
        • 漏桶算法
          • 桶容量不变，任意速率流入桶，固定速率流出水滴
          • 限制流量的流出速率
        • 计数器算法
          • 计数器负责计数，与阈值进行比较，当等于阈值时，便触发限流逻辑，达到时间临界点时，才重置计数器，处理新的请求
      • 接入层限流方案
        • Nginx的限流模块
          • 令牌桶算法
        • Nginx+Redis+Lua
          • 计数器算法
      • 应用层限流方案
        • 基于Sentinel进行扩展
          • 引入权限控制
          • 扩展限流维度，支持接入层限流
          • 扩展限流返回信息，支持自定义返回类型
          • 将Sentinel控制台的监控功能集成进Grafana
      • 基于时间分片的削峰方案
        • 活动分时段进行实现削峰
        • 通过答题验证实现削峰
          • 12306
      • 消息队列
        • ActivieMQ、Kafka、RocketMQ、RabbitMQ
          • Kafka、RocketMQ为互联网场景下拥有高并发、大流量的分布式系统而设计
        • 解耦
        • 削峰
        • 最终一致性
• 四.读/写优化方案
  • 本地缓存
    • 优点
      • 读写性能好
    • 缺点
      • 占有系统内存资源，与JVM争夺内存
      • 数据一致性问题
    • 选型
      • Ehcache
      • GuavaCache
      • mapDB
  • 分布式缓存
    • 场景
      • 解决数据共享
      • 解决数据一致性
    • 选型
      • 单点
        • jedis
      • 集群
        • 路由算法
          • Hash算法
          • 一致性Hash算法
          • 分槽算法
  • 高并发读难题
    • 单个热点key集中于同一个缓存节点
    • 方案
      • 多级缓存
        • 本地缓存
          • 更新策略
            • 被动更新
            • 主动更新
          • 实现
            • Guavacache
        • 分布式缓存
      • RedisCluster模式
        • 一主多从读/写分离方案
  • 高并发写难题
    • InnoDB行锁
    • 基于Redis乐观锁的库存扣减方案
      • 避免超卖的解决方案
        • 基于乐观锁实现库存扣减
        • 结合Lua脚本实现库存扣减
• 五.分库分表方案
  • 关系型数据库架构演变
    • 常见性能瓶颈
      • 大量的并发读/写操作，产生单库难以承受的负载压力
      • 单表存储数据量过大，检索效率低下
    • 数据库读写分离
      • master存在TPS较高的情况，master与slave之间存在数据同步延迟
        • 在写入master之前，将同一份数据落在缓存中，避免高并发情况下，从slave中获取不到指定数据的情况发生
    • 垂直分库
      • 企业根据自身业务的垂直划分，将原本冗余在单库中的数据表拆分到不同的业务库中，实现分而治之的数据管理和读/写操作
        • 当单表数据量超过500万行时，读操作就逐渐成为瓶颈，即使创建索引也无法解决数据膨胀带来的检索效率低下等问题
        • 数据库的卸任操作不会因为数据膨胀而成为瓶颈，但是读操作会存在上限
    • 水平分库与水平分表
      • 水平分表
        • 将原本冗余在单库中的单个业务表拆分为n个“逻辑相关”的业务子表
        • 不同业务的子表各自负责存储不同区间的数据，对外形成一个整体，这就是Sharding操作
      • 水平分库
        • 将水平分表后的业务子表按照某种特定的算法和规则分散到n个“逻辑相关”的业务子库中
        • 需要专门的Sharding中间件负责数据的路由工作
      • 作用
        • 解决高并发场景下单库的性能瓶劲，并充分利用分布式的威力提升数据库的读/写性能
      • 关注
        • ACID特性如何保证
        • 多表之间的关联查询如何进行
          • 基于Solr的多维度复杂条件查询
        • 无法继续使用外键约束
        • 无法继续使用Mysql提供的Auto_Increment生成全局唯一和连续性ID
  • sharding中间件
    • Mycat
      • 架构
        • Proxy
    • shark
      • 架构
        • 应用集成
  • 数据库HA方案
    • 基于配置中心实现主备切换
    • 基于Keeplived实现主备切换
    • 基于MHA实现主备切换
  • 订单业务冗余表需求
    • 实现方案
      • 数据同步写入
        • 增加处理耗时
      • 数据异步写入
        • 增加系统复杂度
    • 场景
      • 实现不同维度买家/卖家对订单信息的查询
  • 数据最终一致性方案
    • MQ
    • Binlog增量同步方案