那些对数据实时性要求高的APP后端是怎么做的

我们团队目前主要的工作只能就是一套网关系统，围绕网关或者是接入层系统来说，是存在一套通用解决方案的。

我们目前的系统做的并不是很好，也还有很大一部分的进步空间，围绕做好一套接入层系统或是网关系统，可以围绕下面要说的几件事展开。

我们可以脑补下，信息更多，吞吐更大，一致性要求更高的微信会怎么做。

第一件事 ：消息通信模型

作为一款以通讯为核心的产品，做好消息收发通信的模式是首先需要确认的。

而且我们知道微信最早的团队资源是张小龙从自己的微信邮箱团队演化而来的，所以相信早期的消息模型应该是类似于邮件模型的，类似于消息的存储和转发。

也就是说，消息发送者发送消息之后，先发送到微信后台，作为临时存储。为了让消息接收者可以及时接收到消息，会给消息接收者发送一条相关推送，之后消息接收者进行主动的拉取以获取消息。

第二件事 ： 如果做好基础数据同步

在确认了消息同步的模型之后，下一阶段要做的事情就是做好基础数据的同步了，什么是基础数据呢？

比如个人账户信息，联系人列表，群组列表等其他系统级别信息。因为每次产品版本升级都会涉及到类似的一些信息的变更，不管是数据信息还是数据类型的变更都需要做好向后兼容。

首先想到的解决方案就是客户端和服务端确认一种类似基础数据同步的协议，围绕这个协议实现统一的用户基础数据同步。

第一种方案是客户端记录一个本地数据快照，在需要进行数据同步时，将快照信息发送到服务端，服务端完成快照计算，算出快照和服务端数据之间的差异，将差异数据增量的同步到客户端，客户端在进行差异数据处理。

但是这个方案存在以下问题：

1. 快照会随着客户端数据增多而变得越来越大，为解决此类数据同步，未来造成的同步流量开销会越来越大
2. 客户端每次同步都需要提前计算快照，为客户端带来额外的性能开销和复杂度，比如消耗cpu，需要做好进程杀死的数据一致性问题

于是我们有了第二种方案。

第二种方案是围绕服务端实现而建设的，在每次数据同步时，会将快照信息同步到客户端，这样客户端就无需计算快照，只需要存储起来即可。

接下来针对快照进行一定简化设计，由若干个key-value组合而成，key代表数据类型，value代表给到客户端数据的最新版本号。

比如key可以代表账户数据，联系人和消息，客户端。

客户端每次拿快照到服务端进行数据同步，服务端就可以认为上次数据同步已经成功完成了，而无需一次ack机制进行数据确认。

为减少流量开销，和精简方案，后期可以确定一系列原则，即由服务端完成较为复杂的业务逻辑，降低客户端实现的复杂度。

第三件事 ： 确认后台架构

由于我不是客户端开发方面的专家，在相关架构和技术前瞻性上也没什么发言权，所以这一部分围绕后端架构演进而来。

先以一个简单的通用的架构来看。

参考我们的交易网关服务而言，主要分为：接入层，逻辑层，存储层。

• 接入层：主要提供服务接入，包括长链接服务，短链接服务。长链接服务同时支持客户端主动发起请求和服务端主动发起推送；短链接服务只支持客户端主动发起的请求。
• 逻辑层：包括业务逻辑服务和基础逻辑服务。业务逻辑服务封装了业务逻辑，是后台提供给微信客户端调用的API。基础逻辑服务抽象底层通用业务逻辑，提供业务逻辑服务访问。
• 存储层：包括数据访问服务和数据存储服务。数据存储服务通过MySQL，Redis，Tair等k-v数据存储实现数据持久化存储。数据访问服务适配并路由数据访问请求到不同底层数据存储服务，面向逻辑层提供结构化数据服务。比如就即时通讯场景来说存储不同类型的数据，采用单独的数据访问服务和数据存储服务，比如账户相关，消息相关，文件相关，联系人相关等都是互相独立的。

第四件事 ：高性能内部服务通信

确认了后台架构之后，接下来的事情就是纯后台相关的事情了。

各服务化系统采用微服务架构，各微服务之间采用自研RPC服务完成服务调用和数据通信。

RPC服务可以基于Netty自研，也可以直接用Thrift或GRpc框架，由于业务场景特点，每日几十亿调用次数完全没有问题。

第五件事 ：运营支撑系统

作为一套网关系统，需要对请求的流量和数据负责，围绕各种数据可以建立一套运营支撑系统。

比如做业务数据统计。由于未来可能会衔接一部分开发平台职能，可以围绕具体的开放平台特点做一些更细化的业务监控，页面监控，数据曲线，注册数据等。

数据采集可以从统计库实时而来，或者采用日志埋点，定时脚本统计实现，这部分就不展开了，相信各位专门搞大数据处理的大佬们各有各的方案吧。

第六件事 ： 系统融合，数据同步

在互联网下半场红利消失背景下，为实现企业降本提效的目的，需要对核心业务进行沉淀以支持更好的业务创新，这个新组织就是业务中台，围绕其需要建立一套技术中台，最终实现裁人的目的。

好吧，戏虐了下目前比较火的中台，现实的中台推进过程中必将大量涉及到组织架构调整和系统融合，以及数据同步。

说到这里我不禁想到，在那个微信一夜爆发之后，小马哥决定将用户同样过亿的QQ数据好友信息同步到微信，那么他应该是怎么做的呢？

为打通腾讯微博私信，群聊，工作邮箱，QQ好友列表，邮箱好友列表。内部可以通过异步MQ实现解耦。

因为涉及到了不同部门对接，不同系统的SLA要求不同，可以通过MQ进行削峰解耦，消息发到群里后，可以通过异步队列异步完成消息的扩散写能力。

即时通信消息群聊信息是写扩散的，就是说消息发到群里的一条消息会给群里每个人都存一份（消息索引）。

这里可能会有同学问：为什么不采用读扩散呢？

1. 如果群里人数不多，一个群50人，扩散成本不是很大，不像微博，几千，上万，太阳女神都是上亿的粉丝，发一条微博，每个粉丝都存一份效率太低，存储成本也太大了。
2. 消息扩散写入到每个人的收件箱存储后，接收者到后台同步数据时，只需要检查自己收件箱即可，同步逻辑跟单聊消息是一致的，这样可以统一数据同步流程，实现起来也会更轻量级一些。

异步队列是后台数据交互的一种重要模式，和RPC同步服务调用形成了互补，在内部信息通信过程中都大量使用。