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

微信后台架构与基础设施简介
展开查看详情

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 – 由于不需要自己设计各种状态保存数据结构,临时状态/ 变量在一片连续的栈中分配,性能比手写异步通常要高 – 非常方便地编写并发任务