"微信后台技术揭秘"系列读书笔记

一、微服务在微信的架构实践

原文链接: 《微服务在微信的架构实践》

摘要:

  • 背景是千人团队, 统一框架, 几千个微服务, 几万台机器, 敏捷开发, 快速迭代.
  • 微信的服务全球分布, 主要在四个数据中心: 深圳、上海、香港、加拿大.
  • 三层概览: 接入(长/短连接), 逻辑层(RPC, 分SET, 过载保护, 消息队列), 数据层(数据分片, 异地数据队列, PaxosStore).
  • 架构实践:
    • 服务布局: 多城自治(30ms+), 跨城备用UDP信道, 园区互备(2ms).
    • 基于 Protobuf 的协程 RPC 框架, 时间轮/同步原语, 支持标准 CGI.
    • 过载保护: 轻重分离; 基于队列耗时的反馈机制, 调用时有限流和快速拒绝, 队列大小不敏感; 分级拒绝策略.
    • 数据存储: PaxosStore 同城分布式存储, 一组6台机器, 可以扩SET, 非租约模式(区别于Raft), 防止故障时断时续的状况导致反复切换 Leader.

个人观点:

  • 多城多园区的部署值得学习, 涉及到数据分布、调度、跨城通信等多个方面, 当然, 这和巨大的产品量级也有关.
  • C++ 协程框架的实现已经普遍化, 这和微信的技术栈有关, 换个角度, 使用 java 或者 golang 就基本不需要关注这个问题.
  • 庞大的分布式系统中, 过载保护是个复杂的问题, 除了常见的轻重分离和快速拒绝等策略, 还有基于队列耗时的反馈机制, 很实用.
  • PaxosStore 基于 Paxos 协议的数据一致性, 取 CP 而舍 A, 但从跨园区和一组6台的结构, 可知具备一定的容灾能力, 可用性高, 并且经过微信的实践考验, 是一款优秀的存储组件. 不过目前看来, 仅仅是开源了部分核心代码, 离真正的开源社区还差的比较远, 学习的价值更大.

二、详解微信异步队列 MQ 2.0 的功能优化及拓展思路

原文链接: 《详解微信异步队列 MQ 2.0 的功能优化及拓展思路》

摘要:

  • MQ 1.0: 单机持久化, 本机消费, 框架介入整个生命周期: 入队、落盘、派发、处理、提交结果、销毁.
  • MQ 2.0 任务调度优化
    • 降低网络质量的依赖, 目的是构建去中心化的弹性消费网络, MQ 和 worker 分离按需部署
    • worker pull 模式, 宁可在 MQ 积压, 也不能接受 push 导致的 worker 积压
    • worker 感知 MQ 的积压: MQ 长连接广播通知 worker, 基于机器/园区/城市的分级策略
    • worker 消除 MQ 的积压: 基于机器/园区/城市的消费分级策略
    • 去中心化, 局部负载均衡
    • 局部 worker 故障具备自动容灾能力
  • MQ 2.0 高效任务处理
    • 类 MapReduce 任务处理框架, 并发调度, 并发池隔离防饿死
    • 支持流式任务框架, 提供了更轻量的逻辑异步化模型
  • MQ 2.0 过载保护
    • 保护自己不过载, 保护 worker 不过载
    • 前向限速, 通过观察数据主动限速任务派发, 数据指标包括: CPU使用率, 任务成功率
    • 后向限速, 根据业务反馈被动限速任务派发, 特定接口支持业务回调控制参数

个人观点:

  • 分布式的 MQ, 具备弹性能力, 扩容方便, 故障时能自动容灾并且局部负载均衡.
  • Pull 和 Push 的取舍, 以及分级策略应对消息积压, 都是值得学习的地方.
  • 任务处理的调度框架, 个人接触不多, 文中讲述的也比较简略, 略过.
  • 过载保护和前文《微服务在微信的架构实践》相呼应, 前后向两个维度限速, 全面且合理.
  • 个人认为这里有个难把握的点: 职责厘清, 哪些该 MQ 管, 哪些该业务管, 不怕 MQ 做的少, 就怕做多, 全文读下来感觉 MQ 2.0 的实践把握的挺好.

三、微信后台基于时间序的海量数据冷热分级架构设计实践

原文链接: 《微信后台基于时间序的海量数据冷热分级架构设计实践》

摘要:

  • 目标对象: 基于时间序的海量数据(PB级), 随时间不断生成, 访问量大且冷热分明, 数据的可靠性要求高.
  • 三层架构
    • L0, 内存层(热数据), 主要是缓存数据, 客户端只读, 每次读请求, 会带上内存层的缓存数据版本号, 穿透到存储层, 存储层比对版本号并做相应处理. 不会减少对存储层的访问, 但可以减少存储层的内存压力(只需要缓存版本号), 即相当于把内存层当成存储层的外部缓存.
    • L1, 存储层(次热数据), 内存 + SSD, lsm-tree 算法实现, 数据分层, 顺序写, 大量复用 leveldb 的数据结构, 减少动态策略, 定制化管理.
    • L2, 机械磁盘层(冷数据), 受限内存, 索引上浮到存储层; 三副本分园区部署; 自定义数据路由保证单调映射.
    • 客户端只写存储层, 三层都可读, 由时间和流量决定该读哪一层.
  • 数据一致性
    • 内存层版本号机制
    • L1 使用 Paxos 一致性协议保证, 无租约多副本
    • L2 三副本串行写入, 全部提交成功才算成功, 另外有校验和恢复机制.
  • 数据分区
    • 保证同层数据负载均衡, 一致性哈希桶虚拟节点映射.
    • 数据分区的独立单位是组, 一组包含多台机器, 组内数据均衡, 可以基于组扩容、迁移.
  • 工程实践
    • 定制的数据结构支持高效缓存, 定长、利用率高、支持共享内存.
    • 请求合并、批量操作等.

个人观点:

  • 三层架构可以看成传统的冷热分离的扩展, 内存-SSD-机械磁盘, 符合生产环境诉求.
  • L0 和 L1 的设计比较有意思, 通过版本号算法减少 L1 磁盘访问, 加多一层缓存, 以机器资源换读性能, 对热数据来说是划算的.
  • L1 和 L2 的实现借鉴了 leveldb, 根据实际场景做了定制化. L1 的亮点是加了 Paxos 算法, 保证了分布式集群的数据一致性. L2 则是简单的多副本冗余, 匹配读写慢价格低廉的特性.
  • 在负载均衡、数据结构、批量操作等实现细节上也有比较多亮点.
  • 整体来说是一个很赞的存储架构, 通过冷热分层, 以合理的机器资源, 有效的支持了海量数据的读写.

四、企业微信组织架构同步优化的思路与实操演练

原文链接: 《企业微信组织架构同步优化的思路与实操演练》

摘要:

  • 问题: 组织架构(多叉树结构)同步, 首次全量下发, 非首次服务器下发全量节点哈希, 客户端请求变更数据, 超大规模企业架构变更流量大, 有延迟.
  • 优化: 基于版本号的增量变更, 变更时数据分片, 数据结构优化, 断点续传.

个人观点:

  • 全文主要讲述了一种从全量变更到增量变更的优化方法, 并介绍了一些实施中的细节点.
  • 应用场景不大, 优化手段也比较常规, 学习价值相对一般.