位置:编程技术网 > 物联网 > 正文 >

微信架构总监:微信10亿日活场景下,后台系统微服务架构实践!

2020年03月26日 07:03来源:未知手机版

机智的卷纸,李玟图片,张杨果

微信架构总监:微信10亿日活场景下,后台系统微服务架构实践! 2020-03-25 08:59:16 Java架构技术

作者| 许家滔 编辑| 老K

作者介绍:许家滔,微信技术架构部后台总监,专家工程师,多年来伴随QQ邮箱和微信后台成长,历经系统从0到10亿级用户的过程。目前负责微信后台工作,包括消息,资料与关系链,后台基础设施等内容。

本文整理自,许家滔老师在“第十届中国系统架构师大会SACC2018)”的演讲内容整理而成,以下是正文:

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

本文地址:http://www.reviewcode.cn/wulianwang/125581.html 转载请注明出处!

今日热点资讯