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年的那一次故障，我们开始整体优化微信后台的过载保护能力，也促使我们去提升整个微信后台的高并发能力。

协程到底是什么？可以说它是微线程，也可以说它是用户态线程。协程切换流程其实不复杂，它主要任务是把上下文保存起来。上下文只有两个部分，第一部分是内存和寄存器，第二部分是栈的状态。

协程服务，同步编程、异步执行，由于不需要自己设计各种状态保存数据结构，临时状态/变量在一片连续的栈中分配，性能比手写异步通常要高，重要的一点是编写并发任务很方便。

以上介绍了微信后台高可用、数据一致性、微服务、数据存储等实践。

微信10亿日活场景下，后台系统微服务架构实践相关推荐

微信架构总监：微信10亿日活场景下，后台系统微服务架构实践 15页ppt全解
01 微信发展主要的技术里程碑微信在2011年1月21日发布了1.0版本,以即时消息为主:2011年5月上线了语音对讲.查看附近的人:2012年4年发布了里程碑式的朋友圈功能:2013年游戏中心.表 ...
微信10亿日活场景下，微服务架构实践！15页PPT全解
点击"开发者技术前线",选择"星标????" 在看|星标|留言, 真爱来自:"技术领导力" 作者介绍:许家滔,微信技术架构部后台总监,专 ...
日10亿级处理，基于云的微服务架构
德比软件:基于云的微服务架构作者:朱攀,德比软件架构师,同济大学研究生,2007 年 2 月加入德比软件(DerbySoft),拥有 10 年以上的软件架构和开发经验.目前主要负责公司数据对接平台的 ...
快手架构师：3亿日活的快手微服务架构实践！8页ppt分享
点击"技术领导力"关注∆ 每天早上8:30推送作者| Mr.K 编辑| Emma 来源| 技术领导力(ID:jishulingdaoli) 本文整理了,快手基础平台架构师曹 ...
沙龙报名 | 数据存储与微服务架构实践，6月15日上海
架构是科学也是艺术,优秀的架构案例往往可以拓宽我们的思路,让问题迎刃而解.本期携程技术沙龙邀请了携程.百度和阿里的优秀工程师带来各自领域最新的架构实践成果,特别集中在数据存储.微服务体系演进和应用监控 ...
爱奇艺在 Dubbo 生态下的微服务架构实践
作者 | 周晓军爱奇艺中间件团队负责人导读:本文整理自作者于 2020 年云原生微服务大会上的分享<爱奇艺在 Dubbo 生态下的微服务架构实践>,重点介绍了爱奇艺在 Dubbo.S ...
dubbo 自定义路由_爱奇艺在 Dubbo 生态下的微服务架构实践
作者 | 周晓军爱奇艺中间件团队负责人导读:本文整理自作者于 2020 年云原生微服务大会上的分享<爱奇艺在 Dubbo 生态下的微服务架构实践>,重点介绍了爱奇艺在 Dubbo.Se ...
快手架构师：3亿日活的快手微服务架构实践
本文整理了,快手基础平台架构师曹福祥.大数据架构团队负责人赵健博,在技术大会上的分享,内容包括:快手微服务架构.大数据存储架构.Kafka技术演进等.从完整的技术架构视角,为你拆解3亿日活的快手App ...
学习下什么是微服务架构/平台
本文将介绍微服务架构和相关的组件,介绍他们是什么以及为什么要使用微服务架构和这些组件.本文侧重于简明地表达微服务架构的全局图景,因此不会涉及具体如何使用组件等细节. 为了防止不提供原网址的转载,特在这 ...

微信10亿日活场景下，后台系统微服务架构实践