58同城:商家(移动)管理平台技术架构解析 | UPYUN Open Talk NO.3

孙玄 58同城系统架构师

我们都知道,58同城是一个分类信息网站,涵盖房产、二手车、招聘、黄页等内容,在每一个类别里都能看到方便用户交流沟通的58帮帮。58帮帮分为IM部分和非IM的业务处理部分,目前,整个帮帮系统每天要处理10亿次+的发消息,加好友等传统IM请求,和30亿+的业务线操作,总请求到达40亿次+。帮帮同时在线用户量也突破了100万,这给我们带来了很大的挑战。

系统起步:传统IM

说到挑战,58帮帮从诞生到现在,曾经面对过很多。最开始时,它只是一个传统的IM,主要用来满足用户沟通和传递信息的功能。针对这样的业务场景,我们设计了如下的结构:

图片描述

整个架构分为四层:接入层、逻辑层、路由层、数据层。

1)接入层
直接面对 PC、移动、网页海量客户端的连接请求,整合成少数的长连接,并将请求转发至逻辑层。

2)逻辑层
主要是一些业务逻辑的处理(例如权限校验、添加好友、发送消息等)。

3)路由层
主要处理和用户一次登录session相关的数据(比如:用户在线状态,登录IP等),这部分涉及的数据变化非常快,没必要固化,-直接存储在内存中。

4)数据层
严格来讲是数据中间件,屏蔽了底层RDBMS和NoSQL的区别和复杂性,较容易完成关键数据的存储。

系统发展:第三方业务接入

随着业务的不断变化,58帮帮不再局限于传统的IM,而是一个逐步向一个商家综合移动管理平台演进,例如接入房产、招聘等业务,提供商家管理功能,进行发帖、刷新、置顶帖子等操作。很多功能,比如招聘、房产等需要在客户端完成操作和展示。针对这些需求,在原有IM的架构上了调整,主要变化在客户端APP。

图片描述

第三方业务接入,由于和IM业务类型不一样,对长连接没有依赖,因此没必须使用长连接,可以直接在APP通过http调用第三方服务,垂直划分后,开发效率非常高,第三方业务可以快速介入,但由于客户端与第三方业务耦合太紧,带来很多兼容性的困难,一旦第三方业务接口发生变动,客户端就要随之更新来适配变化,客户端升级代价非常大,而且不能做到实时更新,比如需要升级时,用户可以选择不升级,这些都会带来很大的麻烦。

系统成熟:客户端轻量化

为解决这个问题,在此基础上又做了些调整,形成了目前的框架:

图片描述

主要调整是将客户端轻量化,将容易变化的部分迁移至服务端,在APP和第三方业务中间加入一层帮帮WebService服务。通过这层业务,较少客户端与第三方的耦合,即使第三方服务发生变化,客户端也不受影响。

O2O核心技术解析

对于移动O2O,长连接、移动LBS、推送技术都比较重要。

1、推送的主要途径

推送方面,我们主要通过以下三个方式来做:

1.1客户端轮询(pull)
客户端定期发起查询请求,来达到推送的目的。pull的优点和缺点都很明显,架构简单但实时性差,想提高实时性,只能加快查询频率,但这会造成电量消耗过高。

1.2短信推送
通过短信发送推送消息,并在客户端置入短信拦截模块,将接收到的短信拦截,并解析后转发给应用处理。这个方案实时性好、到达率高,但成本很高。

1.3服务端长连接(push)
这是目前的主流实现方式,实时性好,且电量消耗低。

2、不同平台的实现方案

基本上目前的推送技术都是结合这 3 个方面展开的,但对于不同的终端平台,又有各自不一样的实现,这里简单介绍一下 IOS 和 android 上的具体实现方案。

2.1 IOS平台
对于 IOS 来说比较简单,你没有别的选择,因为 IOS 中的应用是不允许后台常驻的,所以你没有办法通过开发自己的 pushservice 来完成推送下发,只能通过苹果APNS 渠道来完成推送,大致流程如下:

图片描述

2.2Android 平台
在 android 平台上,由于没有 IOS 那样的限制,可选的方案就多一些。你可以通过谷歌官方的。

C2DM 完成推送,可以借助开源的推送协议(例如 XMPP)实现,也可以借助市面上的各种推送产品完成推送。

谷歌 C2DM 的主要流程如下:

图片描述

C2DM 和 APNS 流程类似,但其最大的问题是服务器在国外,很容易被屏蔽,而且由于 android 社区分裂比较严重,很多厂商可能直接就把 C2DM 模块给去掉了,所以在国内这个方案极不可靠。

对于开源推送协议,常见的有XMPP 等, 事实上谷歌的 C2DM 底层就是基于 XMPP 实现的,我们通过调用和测试,主要遇到了两个问题:1. 没有ACK 机制,消息不可靠。2. 请求量大时会不稳定。

最后就是一些市面上的第三方推送产品了,使用这些产品需要面对几个问题:

首先是到达率。虽然都宣传到达率能到 90%及以上,但实际使用起来,发现远远不到。

其次是实时性。第三方推送产品的推送通道是共用的,会面向多个客户,如果某一个客户推送量特别大,你的推送实时性可能就会受到影响,这些都是你不可控的。

我们曾经有考虑过自己去实现一套推送方案,如果自己来做的话,要先解决几个难点。首先是服务端海量长连接的管理,然后是客户端常驻 sevice 的稳定性,手机在内存不足的时候,系统会杀掉你的 service,甚至有些系统比较强势,它不允许你的 service 常驻,如何在这些复杂场景下处理好,非常麻烦。

综合上面的一些考虑,58 帮帮目前的推送方案没有过多的使用自建方案,主要结合多家第三方推送来实现。针对到达率的提升,什么手机上使用什么推送产品,这需要去做一些数据分析,然后再做针对性优化。

你可能感兴趣的:(58同城,技术架构,移动应用开发,o2o)