fasionchan

读万卷书,行万里路,品万味肴,撸万行码。

手游数据平台

手游app在玩家登陆前,有不少高价值的数据需要搜集,包括:用户行为数据以及推广渠道效果数据等等。 收集并分析这部分数据,对于完善app操作体验以及优化游戏推广策略意义非凡。 然而,由于玩家未登录,难以通过游戏数据通道进行上传。 因此,需要设计一套不依赖游戏逻辑的通用数据收集方案,这就是手游数据平台

架构

数据提交采用最通用的HTTP协议,以此实现比较高的适应性。 数据提交后,最终由分布式计算集群处理,包括:StormSpark等。 因此,平台需要提供一些HTTP服务器,完成数据的接收并实时推送给后端计算集群。 整个数据平台最终框架如下:

HTTP 服务器

HTTP是核心接收逻辑所在,负责高效处理HTTP请求,校验数据并按照业务逻辑要求格式化数据并发送到Kafka消息队列集群。

由于玩家未完成登录验证,接收服务不能完全信任一个请求。 为此,我设计了一个简单的数据校验方案:手游SDK将待提交数据几个关键字段以及一个key组装起来算一个哈希签名。 服务端接到数据后,按照同样的算法,对比验证。 由于key保存在SDK中,因此无法应对逆向破解(反编译)。

Kafka

在接收服务和计算服务之间,有一个Kafka集群承接逻辑上的解耦。 这意味着,就算后端计算机群需要进行维护操作,也不影响接收服务正常服务。 另外,消息队列的引入也完成了负载调节,负载峰值到达时,数据可以暂时在消息队列中停留,等待后续处理。

Kafka采用集群式部署,由Zookeeper进行集群状态管理。 消息以topic进行划分,为了提高单个topic的吞吐,Kafka进一步将topic划分成多个partition。 每个partition可以配置多个副本,分散在集群不同机器上,这样可靠性也得到保障。

LVS 高可用/负载均衡

HTTP服务器需要实现可靠和可扩展,多机器部署不可避免。 在HTTP服务器之前,使用LVS作为高可用负载均衡方案。 LVS节点负责对HTTP服务进行健康检查,将请求转发到可用的HTTP服务器上。

与其他方案相比,采用LVS有以下优势:

  • 内核转发,降低用户/内核态切换开销;
  • HTTP服务器直接回包,减轻LVS节点压力;

DNS 负载均衡

由于LVS单节点处理能力也存在上限(如千兆网卡),而且单点无法应对机房网络异常这样大粒度的故障。 这时候,需要提供多套服务,多个接入IP,最好是跨机房的(异地多活)。 由于计算机群只部署在数据中心机房,需要一个数据同步模块Syncer从其他机房的消息队列同步数据。

如上架构图,LVS-HTTP-Kafka服务部署了两套,在两个不同的机房,提供两个不同的接入IP。 通过DNS,将服务随机解析到接入IP上,以此实现水平扩展。 在某个机房服务不可用时,可以通过修改DNS配置,快速完成服务接入切换(由于DNS缓存有小段时间不可用)。

此外,还可以用该架构实现类似CDN的服务接入效果。 例如,在美国aws上部署一套服务,将美国地区的DNS解析过去,这样美国用户提交数据就更可靠快捷了。 Syncer在通过跨国公网往国内同步数据时,还可以通过数据压缩等方式进行优化。

Comments