微信架构总监：微信 10 亿日活场景下，后台系统微服务架构实践
点击“ 技术领导力 ”关注 ∆ 每天 早上8:30 推送
作者| 许家滔 编辑| 老K
作者介绍： 许家滔 ，微信技术架构部后台总监，专家工程师，多年来伴随QQ邮箱和微信后台成长，历经系统从0到10亿级用户的过程。目前负责微信后台工作，包括消息，资料与关系链，后台基础设施等内容。
本文整理自，许家滔老师在“第十届中国系统架构师大会SACC2018）”的演讲内容整理而成，以下是正文：
01
微信发展主要的技术里程碑
微信在2011年1月21日发布了1.0版本，以即时消息为主；2011年5月上线了语音对讲、查看附近的人；2012年4年发布了里程碑式的朋友圈功能；2013年游戏中心、表情商店、微信支付等。直到现在有了小程序生态。
02
微信后台的系统架构
逻辑上讲，最前面会有一个终端，后面会有一个长链接接入层，在线有几亿的管理连接部分。
底层上，因为数据比较敏感而且数据量比较大，所以我们的存储并没有基于开源来搭建，而是自己开发了一整套存储，这也是迭代比较多的部分。
2011年，用的是第一代存储。早期的微信与QQ不同，它更像是一个邮箱。
后来逐渐完善，包括内部安全、管理等。
目前，最关注的有两个方面：
第一是，高可用。微信作为国民级应用，对高可用有着极高的要求，是不可以有服务暂停的。早期的微信迭代速度很快，几乎每两周一个版本，还包括大量的变更。
第二是，敏捷开发的一些问题。例如Coredump、内存泄露等等。
03
微信后台系统主要面临的挑战
微信的用户规模已达10亿，每天的微信消息达1000+亿，朋友圈每日发表和点赞数达10+亿，每日浏览数达100+亿，开放平台，微信支付等业务活跃度持续增长。
系统方面主要面临4大挑战：
1. 海量存储 。需要一个能容错、容灾的高可用存储与计算的框架。
2. 数据强一致性 。保障10亿用户数据不会出现问题。
3. 突发洪峰流量 。春节、元旦、以及突发热点事件。
4. 数据存取压力大 。后台数据服务节点，每分钟超过百亿次数据存取服务。
04
微信后台对高可用的定义
在高可用方面，我们先了解相关定义如下图所示：
最下面的2个9，是指一年故障时间不超过3.65天；最上面5个9 ，是指金融应用，一年故障时间不超过5分钟。
微信是一个什么样的应用场景？微信其实有金融应用，也就是大家常用的微信支付。
那么我们希望达到怎样的目标呢？有2大点：
1、机器故障是常态，微信希望提供连续无间断的服务能力
业界数据可用性，通常通过Paxos租约、RAFT等来实现数据复制。机器故障时，系统会进入等待租约过期并重新选主的状态，即会产生30秒级别的服务中断，这对于我们来讲也是不能接收的。
2、相对于传统的基于故障转移的系统设计，我们需要构建一个多主同时服务的系统，系统始终在多个数据中心中运行，数据中心之间自适应地移动负载，透明地处理不同规模的中断。
05
微信系统高可用的关键设计
最初，微信是异步复制，接着是选主同步复制，然后是多主可用。
基于故障切换的系统。包括两个主要的协议，Raft协议和基于租约Paxos Log。来保证数据的一致性，但对服务的可用性有一定影响。
基于多主的系统。是在可用性方面做的最彻底的系统，它是基于非租约Paxos Log，Google MegaStore以及微信PaxosStore。
多主系统有很多的难点，第一， 海量Paxos Log管理，对存储引擎的要求很高。第二，代码假设在一个cas环境中运行。要做到服务随时可用，对cache和热点处理的要求很高。同时它对于追流水/恢复流程有时效性的要求。
目前微信的核心数据存储服务可用性达6个9。整个系统有一个创新的技术点，具体细节我们发表在：
http://www.vldb.org/pvldb/vol10/p1730-lin.pdf
论文相关示例代码开源：github.com/tencent/paxosstore。
早期大家对Paxos算法都是认为很难实现的，近两年逐渐有一些公司开始对这方面有一些分享。上面提到的这个论文是微信PaxosStore的一点创新，贡献出了一些简洁的算法实现流程，大家可以很轻松的去理解和实现。
06
PaxosStore整体架构
PaxosStore整体架构，如下图。中间我们会把PaxosStore共识层和计算层、存储层分离起来，PaxosStore其实是一整套框架，它可以容纳不同的共识算法和存储。
下面是一个存储引擎。微信的存储引擎包括很多种，最早是Bitcask模型，现在广泛使用的是LSM，它可以支持比较多的业务。
最下面是迁移系统、备份系统、路由中心。PaxosStore支持类SQL的filter，format，limit，groupby等能力，单表可以支持亿行记录。下一步，我们可能会根据业务的需求去开展。
07
微信Chubby建设实践
Chubby是Google一个论文提到的系统，微信技术团队延伸了这样一个逻辑，基本上跟它的接口是一样的。
不管是Google Chubby论文提到的代码量，还是zookeeper的实际代码量都很大，但有了PaxosStore之后，根本不需要那么多的代码，所以接下来我们的处理也可能会考虑开源。
后来，我们基于PaxosStore也实现了分布式文件存储。
08
微信分布式文件系统
微信分布式文件系统Namenode 基于PaxosStore，DataNode基于Raft协议。Raft是基于租约机制的完美实现。基于Raft我们可以做到DataNode的强一致写。另外，它支持文件AppendWrite和随机读以及文件回收等功能。
09
微信微服务架构框架
微服务包含了服务定义、服务发现、错误重试、监控容灾、灰度发布等一系列面向服务的高级特性的统一框架。中间有一个配置管理和下发的过程，这一块也是PaxosStore实现的，它可以完全控制代码的安全性。
下面是一个发布的过程，因为微信有很多服务器集群，也有一个资源化系统，有可能一个服务会横跨几千台机器，内部是一套BT协议。
然后，我们有一些监控处理，最后我们会有过载保护保护，在系统里面过载保护是很关键的一块。因为在后台，当一个请求过来的时候，某些节点产生了一个慢延迟和性能差，就会影响整条链路，所以我们会有一个整套的过载保护的实现。
10
协程在微信系统中的应用
大家还记得微信2013年的那一次故障， 我们开始整体优化微信后台的过载保护能力，也促使我们去提升整个微信后台的高并发能力。
协程到底是什么？可以说它是微线程，也可以说它是用户态线程。协程切换流程其实不复杂，它主要任务是把上下文保存起来。上下文只有两个部分，第一部分是内存和寄存器，第二部分是栈的状态。
协程服务，同步编程、异步执行，由于不需要自己设计各种状态保存数据结构，临时状态/变量在一片连续的栈中分配，性能比手写异步通常要高，重要的一点是编写并发任务很方便。
以上介绍了微信后台高可用、数据一致性、微服务、数据存储等实践，如果觉得本文对您有帮助，请 点在看 、 分享朋友圈 ，感谢您的支持！
-END-
想看更多BAT大厂架构实践干货分享？
请关注“技术领导力”公众号
想加入社区，跟100位互联网大咖学习？
添加群助理Emma，注明“加群”
技术领导力社群
大家在看：
1. 阿里P9技术专家：我来聊聊百万年薪
2. 对不起，我年薪百万，给大家丢脸了!
3. 一张图看懂字节跳动8年创业史，太励志了吧
4 . 为何职场中的岗位，都被不能胜任的人占据？
5. 阿里中台架构15篇干货，100页ppt精选
6. 为啥你开发这么慢？5页ppt：硅谷效能提升
好看就点在看！ 
正文到此结束
- 本文标签： 高可用 并发 服务器 创业 zookeeper 管理 开发 http 高并发 微服务 备份 安全 领导 敏捷 ask 分布式 存储引擎 rmi 励志 Datanode 数据 App core 架构师 https Namenode UI 时间 src 希望 灰度发布 git 集群 金融 需求 自适应 文件系统 工程师 db 互联网 系统架构 代码 同步 cache 一致性 node 压力 配置 GitHub ORM 模型 分布式文件系统 协议 线程 sql Google 开源 QQ邮箱
- 版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
- 本文海报： 生成海报一 生成海报二
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
