微信后台微服务架构及存储架构设计.docx

PAGE 2 微信后台微服务架构及存储架构设计  目 录 TOC \o 1-3 \h \z \u 1． 微信发展主要的技术里程碑 3 2． 微信后台的系统架构 3 3． 微信后台系统主要面临的挑战 4 4． 微信后台对高可用的定义 5 5． 微信系统高可用的关键设计 7 6． PaxosStore整体架构 10 7． 微信Chubby建设实践 12 8． 微信分布式文件系统 13 9． 微信微服务架构框架 14 10． 协程在微信系统中的应用 15  微信发展主要的技术里程碑 微信在2011年1月21日发布了1.0版本，以即时消息为主；2011年5月上线了语音对讲、查看附近的人；2012年4年发布了里程碑式的朋友圈功能；2013年游戏中心、表情商店、微信支付等。直到现在有了小程序生态。 微信后台的系统架构 逻辑上讲，最前面会有一个终端，后面会有一个长链接接入层，在线有几亿的管理连接部分。 底层上，因为数据比较敏感而且数据量比较大，所以我们的存储并没有基于开源来搭建，而是自己开发了一整套存储，这也是迭代比较多的部分。 2011年，用的是第一代存储。早期的微信与QQ不同，它更像是一个邮箱。 后来逐渐完善，包括内部安全、管理等。 目前，最关注的有两个方面： 第一是，高可用。微信作为国民级应用，对高可用有着极高的要求，是不可以有服务暂停的。早期的微信迭代速度很快，几乎每两周一个版本，还包括大量的变更。 第二是，敏捷开发的一些问题。例如Coredump、内存泄露等等。 微信后台系统主要面临的挑战 微信的用户规模已达10亿，每天的微信消息达1000+亿，朋友圈每日发表和点赞数达10+亿，每日浏览数达100+亿，开放平台，微信支付等业务活跃度持续增长。 系统方面主要面临4大挑战： 1.海量存储。需要一个能容错、容灾的高可用存储与计算的框架。 2.数据强一致性。保障10亿用户数据不会出现问题。 3.突发洪峰流量。春节、元旦、以及突发热点事件。 4.数据存取压力大。后台数据服务节点，每分钟超过百亿次数据存取服务。 微信后台对高可用的定义 在高可用方面，我们先了解相关定义如下图所示： 最下面的2个9，是指一年故障时间不超过3.65天；最上面5个9 ，是指金融应用，一年故障时间不超过5分钟。 微信是一个什么样的应用场景？微信其实有金融应用，也就是大家常用的微信支付。 那么我们希望达到怎样的目标呢？有2大点： 1、机器故障是常态，微信希望提供连续无间断的服务能力 业界数据可用性，通常通过Paxos租约、RAFT等来实现数据复制。机器故障时，系统会进入等待租约过期并重新选主的状态，即会产生30秒级别的服务中断，这对于我们来讲也是不能接收的。 2、相对于传统的基于故障转移的系统设计，我们需要构建一个多主同时服务的系统，系统始终在多个数据中心中运行，数据中心之间自适应地移动负载，透明地处理不同规模的中断。 微信系统高可用的关键设计 最初，微信是异步复制，接着是选主同步复制，然后是多主可用。 基于故障切换的系统。包括两个主要的协议，Raft协议和基于租约Paxos Log。来保证数据的一致性，但对服务的可用性有一定影响。 基于多主的系统。是在可用性方面做的最彻底的系统，它是基于非租约Paxos Log，Google MegaStore以及微信PaxosStore。 多主系统有很多的难点，第一， 海量Paxos Log管理，对存储引擎的要求很高。第二，代码假设在一个cas环境中运行。要做到服务随时可用，对cache和热点处理的要求很高。同时它对于追流水/恢复流程有时效性的要求。 目前微信的核心数据存储服务可用性达6个9。整个系统有一个创新的技术点，具体细节我们发表在： /pvldb/vol10/p1730-lin.pdf 论文相关示例代码开源：/tencent/paxosstore。 早期大家对Paxos算法都是认为很难实现的，近两年逐渐有一些公司开始对这方面有一些分享。上面提到的这个论文是微信PaxosStore的一点创新，贡献出了一些简洁的算法实现流程，大家可以很轻松的去理解和实现。 PaxosStore整体架构 PaxosStore整体架构，如下图。中间我们会把PaxosStore共识层和计算层、存储层分离起来，PaxosStore其实是一整套框架，它可以容纳不同的共识算法和存储。 下面是一个存储引擎。微信的存储引擎包括很多种，最早是Bitcask模型，现在广泛使用的是LSM，它可以支持比较多的业务。 最下面是迁移系统、备份系统、路由中心。PaxosStore支持类SQL的filter，format，limit，groupby等能力，单表可以支持亿行记录。下一步，我们可能会根据业