从0到1：微信后台系统的演进之路.pdfVIP

2016/1/16 从0到1：微信后台系统的演进之路 从0到1 微信后台系统的演进之路 原创 2016-01-14 张文瑞 InfoQ 2个月的开发时间，微信后台系统经历了从0到1的过程。从小步慢跑到快速成 “ 长，经历了平台化到走 国门，微信交 的这份优异答卷，解题思路是怎样 的？本文由张文瑞，微信后台团队 品。 从无到有 2011.1.21 微信正式发布。这一天距离微信项目启动日约为2个月。就在这2个月里，微信从 无到有，大家可能会好奇这期间微信后台做的最重要的事情是什么？ 我想应该是以下三件事 1 确定了微信的消息模型 微信起初定位是一个通讯工具，作为通讯工具最核心的功能是收发消息。微信团队源于广硏 团队，消息模型跟邮箱的邮件模型也很有渊源，都是存储转发。 图 1 微信消息模型 图1展示了这一消息模型，消息被发 后，会先在后台临时存储；为使接收者能更快接收到 消息，会推送消息通知给接收者；最后客户端主动到服务器收取消息。 2 制定了数据同步协议 由于用户的帐户、联系人和消息等数据都在服务器存储，如何将数据同步到客户端就成了很 关键的问题。为简化协议，我们决定通过一个统一的数据同步协议来同步用户所有的基础数 据。 最初的方案是客户端记录一个本地数据的快照(Snapshot) ，需要同步数据时，将Snapshot带 /s?__biz MjM5MDE0Mjc4MA mid 402340325idx 1sn 5b7bf6025b1a83a0e529e630fc95ae28scene 2srcid 0114lydqve… 1/20 2016/1/16 从0到1：微信后台系统的演进之路 到服务器，服务器通过计算Snapshot与服务器数据的差异，将差异数据发给客户端，客户 端再保存差异数据完成同步。不过这个方案有两个问题 一是Snapshot会随着客户端数据 的增多变得越来越大，同步时流量开销大；二是客户端每次同步都要计算Snapshot ，会带 来额外的性能开销和实现复杂度。 几经讨论后，方案改为由服务计算Snapshot ，在客户端同步数据时跟随数据一起下发给客 户端，客户端无需理解Snapshot ，只需存储起来，在下次数据同步数据时带上即可。同 时，Snapshot被设计得非常精简，是若干个Key-Value的组合，Key代表数据的类型，Value 代表给到客户端的数据的最新版本号。Key有三个，分别代表 帐户数据、联系人和消息。 这个同步协议的一个额外好处是客户端同步完数据后，不需要额外的ACK协议来确认数据收 取成功，同样可以保证不会丢数据 只要客户端拿最新的Snapshot到服务器做数据同步， 服务器即可确认上次数据已经成功同步完成，可以执行后续操作，例如清除暂存在服务的消 息等等。 此后，精简方案、减少流量开销、尽量由服务器完成较复杂的业务逻辑、降低客户端实现的 复杂度就作为重要的指导原则，持续影响着后续的微信设计开发。记得有个比较经典的案例 是 我们在微信1.2版实现了群聊功能，但为了保证新旧版客户端间的群聊体验，我们通过 服务器适配，让1.0版客户端也能参与群聊。 3 定型了后台架构 /s?__biz MjM5MDE0Mjc4MA mid 402340325idx 1sn 5b7bf6025b1a83a0e529e630fc95ae28scene 2srcid 0114lydqve… 2/20 2016/1/16 从0到1：微信后台系统的演进之路 图 2 微信后台系统架构 微信后台使用三层架构 接入层、逻辑层和存储层。 1. 接入层提供接入服务，包括长连接入服务和短连接入服务。长连接入 服务同时支持客户端主动发起请求和服务器主动发起推送；短连接入 服务则只支持客户端主动发起请求。 2. 逻辑层包括业务逻辑服务和基础逻辑服务。业务逻辑服务封装了业务 逻辑，是后台提供给微信客户端调用的API。基础逻辑服务则抽象了 更底层和通用的业务逻辑，提供给业务逻辑服务访问。