许家滔 - 微信后台架构与基础设施简介

1 . E T B. N PU IT 

2 . E T 微信后台架构与基础设施简介 B . N P U IT 许家滔 / 微信技术架构部 sunnyxu@tencent.com 

3 . E T .N 回顾微信发展历程 B PU IT 

4 .2011.1.21 即时消息 2011.10 2012.7 连接人 照片分享 摇一摇 视频聊天 2014.10 连接设备 漂流瓶 小视频 连接服务 E T 1.0 2.0 3.0 4.0 B. N 4.2 5.0 6.0 Now P U IT 2012.4 2011.5 朋友圈 2013.8 语音对讲 游戏中心 查看附近的人 表情商店 微信支付 

5 . 微信后台系统架构 • 接入层 T – mmproxy E – mmwebproxy • 业务逻辑层 B. N U – 逻辑业务（Logicsvr） P – 基础业务 • 存储层 – PaxosStore ( table,value,set,queue,etc. ) – WFS IT – Media 

6 . 高可用与敏捷开发 • 高可用的关键技术 – 数据强一致 E T – 微服务框架 B. N • 敏捷开发的烦恼 PU – 内存泄漏 – Coredump IT –… 

7 . E T 数据存储与微服务框架 B. N P U IT 

8 . 数据业务背景与挑战 T •十亿级用户、百亿千亿级服务 •微信用户数：10亿 . N E B •微信消息数：1000+亿/日 U •朋友圈：10+亿发表和点赞/日，100+亿浏览/日 •开放平台，微信支付等业务活跃度持续增长 IT P 

9 . 目标 •可用性（正常工作时间/（正常工作时间+故障时间）） E T B. N P U IT 

10 . 挑战 T •机器故障是常态，微信希望提供连续无间断的服务能力 E –业界数据可用性通常通过RAFT，Paxos租约等来实现数据复制 N –机器故障的时候系统会进入等待租约过期并重新选主的状态，也即会产生30秒级别的服务中断， . 我们希望能够规避。 U B P •相对于传统的基于故障转移的系统设计，我们需要构建一个多主同时服务的系统 IT –系统始终在多个数据中心中运行 –数据中心之间自适应地移动负载 –透明地处理不同规模的中断（主机，机房，城市园区等） 

11 . 关键设计 •基于故障切换的系统 T –Raft E –基于租约Paxos Log 多主可用 N –“Paxos make live” –其他例如bigtable等等 B. 选主同步 复制 •基于多主的系统 –基于非租约Paxos Log PU 异步复制 IT –Google MegaStore –微信PaxosStore •多主系统相关难点 –Paxos Log管理，对存储引擎的设计要求 –代码假设在一个cas环境中运行 –服务随时可用，对cache，热点的处理 –追流水/恢复流程的时效性要求 

12 . 多主系统的收益 T • 7 X 24 E –应对计划内与计划外的停机维护 N –不再有尘封已久的切换流程 中充分体现 B. •由于多主可用，所以类似快照，数据对齐等行为已经在在线核心逻辑 U –变更发布 •资源调度 IT –流量控制和逻辑层类似简单P •成本 –数据中心之间动态共享工作以平衡负载 

13 .设计与实践 E T B. N PU IT 

14 . 实际成果 •万级服务器 •核心数据存储服务可用性达到6个9 E T . N – 99.9%（3个9）：一般应用，一年故障时间不超过8小时46分钟 B – 99.99%（4个9）：重要应用，一年故障时间不超过53分钟 U – 99.999%（5个9）：金融应用，一年故障时间不超过5分钟 •经验输出 – 数据库会议VLDB 2017 IT P “PaxosStore: High-availability Storage Made Practical in WeChat” http://www.vldb.org/pvldb/vol10/p1730-lin.pdf – 论文相关示例代码开源 github.com/tencent/paxosstore 

15 .PaxosStore广泛支持微信在线应用 E T B. N P U IT 

16 .PaxosStore架构简介E T B. N P U IT 

17 .PaxosStore整体架构 E T B. N PU IT 

18 .PaxosStore：数据模型 丰富数据类型，为业务快速开发提供保障 键值 E T N 二维小表 大表 B. U 集合 P 队列 IT 二维小表：每个小表包含N行，用户自定义列属性， 对外提供类SQL操作，单表20M限制。 大表： 具备二维小表所有功能 单表支持上亿行，二级索引。 

19 . PaxosStore：数据分布与复制 E T B. N P U IT 按Set划分，Set间一致性Hash均匀分布 上下层间调用按Set对齐隔离单Set故障和提升批量 RPC效果 Set内三园区互为主备， 负载均衡 单机/园区分级容灾 单机 /单园区故障，服务不受影响 就近访问 

20 . 基于PaxosStore的在线基础组件 • 分布式元数据系统/文件系统/表格系统 T – 业界：Chubby/zookeeper, gfs/hdfs , bigtable/hbase • 远距离跨城常量存储 . N E B – 远距离 上海 – 深圳 – 天津 U 考虑故障的实际影响范围以及专线的物理情况 P 例如深圳与汕头，上海与杭州，杭州和杭州旁边的城市，这些都只是 短 IT 距离容灾 – 跨城写，本地读 • 针对微信支付复杂业务定制的事务容器 • 针对搜索推荐业务的高性能特征存储 

21 . 微信chubby T 元数据存储：小文件存储和目录管理 E GetStat/GetContent/SetContent . N MultiSetContent ：原子操作、CAS U B 支持分布式锁 P AcquireLock/ReleaseLock, IT ChekHeldLock/锁失效回调 

22 .微信分布式文件系统 E T Namenode 基于PaxosStore B. N DataNode基于Raft协议 PU 文件AppendWrite和随机读， IT 常用目录操作 支持回收站等功能 

23 .分布式表格：架构图 E T B. N PU IT 

24 . 微服务框架 • 封装了包含服务定义、服务发现、错误重试、监控容灾、灰度发布等一系列面向服务的高级 特性的统一框架 E T B. N P U IT 

25 . 业务逻辑Worker模型选择 优点 缺点 进程间相互独立，奔溃互不影响 E T 进程间通信开销大 N 多进程 . Maxloop特性，容忍偶发core或内存泄漏，支持业务快速迭代开发 资源无法共享 资源进程内共享 U B P 多线程 程序逻辑和控制方式简单 一个线程的奔溃影响整个程序 IT 性能好 协程 进程/线程内调度，性能好，并发能力高 cpu密集型服务会导致其它协程卡顿 25 

26 . E T . 主要介绍一下协程的应用 B N P U IT 

27 . Libco背景 • 同步模型 T – 支持业务快速迭代开发 • 问题 . N E – 一个请求占用一个业务进程（线程）同步处理 U B – 调用链路长，网络延迟抖动引发整个调用链路失败 P – 系统并发处理能力与业务请求量不匹配导致故障频繁 • 解决办法 IT – 切换到异步模型（工程量巨大） – 探索协程解决方案，少量修改代码达到同步编码，异步 执行效果 

28 . 举个例子 • 把Leveldb的本地文件切换为远程文件系统 E T N – 异步代码如何实现 – 协程如何实现 B. PU IT 

29 . 异步服务与协程服务的对比 • 传统基于事件驱动的异步网络服务 T – 优势，高性能，cpu利用率高 码拆分得支离破碎 . N E – 编写困难，需要业务层维护状态机，业务逻辑被异步编 – 并发任务难以编写与维护 U B – Future/promise等技术，趋近于同步编程，但仍然繁琐 • 协程 IT – 同步编程，异步执行 P – 由于不需要自己设计各种状态保存数据结构，临时状态/ 变量在一片连续的栈中分配，性能比手写异步通常要高 – 非常方便地编写并发任务