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和热点处置惩罚的要求很高。同时它对于追流水/恢复流程有时效性的要求。

早期大家对Paxos算法都是认为很难实现的，近两年逐渐有一些公司开始对这方面有一些分享。上面提到的这个论文是微信PaxosStore的一点创新，孝敬出了一些简练的算法实现流程，大家可以很轻松的去明白和实现。06PaxosStore整体架构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年的那一次故障， 我们开始整体优化微信后台的过载掩护能力，也促使我们去提升整个微信后台的高并发能力。协程到底是什么？可以说它是微线程，也可以说它是用户态线程。协程切换流程其实不庞大，它主要任务是把上下文生存起来。

上下文只有两个部门，第一部门是内存和寄存器，第二部门是栈的状态。协程服务，同步编程、异步执行，由于不需要自己设计种种状态生存数据结构，暂时状态/变量在一片一连的栈中分配，性能比手写异步通常要高，重要的一点是编写并发任务很利便。

以上先容了微信后台架构实践，包罗高可用、数据一致性、微服务、存储架构等等作者：许家滔，微信技术架构部后台总监，专家工程师，多年来陪同QQ邮箱和微信后台发展，历经系统从0到10亿级用户的历程。现在卖力微信后台事情，包罗消息，资料与关系链，后台基础设施等内容。

本文来源：云开平台登录-www.dnllt.com