本文整理自许家滔老师在 "第十届中国系统架构师大会 SACC2018)" 的演讲内容整理而成, 以下是正文:
01
微信发展主要的技术里程碑
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 / ----
来源: https://www.qcloud.com/developer/article/1601025