以IM为例看58同城典型技术架构演变

以IM为例看58同城典型技术架构演变

58同城作为中国最大的生活服务平台,涵盖了房产、招聘、二手、二手车、黄页等业务,在每一个业务类别里都能看到方便用户交流沟通的58帮帮。本文选取了58帮帮作为58同城典型技术架构的代表,详细讲述了58帮帮自上线以来,随着用户量、数据量以及产品方向的发展,58帮帮在技术架构上持续的演变。58帮帮由即时通讯(IM)部分和非IM的业务处理部分构成,目前,整个帮帮系统每天要处理10亿次+的发消息、加好友等传统IM请求,以及30亿+的非IM业务请求操作,总请求到达40亿次+。帮帮同时在线也突破了100万,如此多的请求量和在线用户量对我们带来的挑战非常之大。

本文详细讲述58帮帮技术架构演变的四个阶段:阶段一:传统的IM架构我们如何设计?如何满足千万在线的性能需求?阶段二:从传统IM到商家管理平台,58帮帮的架构如何演变?阶段三:从商家管理平台到移动营销工具,58帮帮的架构又如何演变?阶段四:如何打造满足58帮帮的移动推送系统

阶段一:传统IM

最早58帮帮只是一个传统的IM,主要满足58用户与58商户沟通以及传递信息,核心功能包括添加好友、用户关系、收发消息等。在客户端产品形态分为PC桌面客户端、WEB网页客户端,其中PC桌面客户端主要服务于58商户,58用户使用WEB网页客户端和58商户沟通。针对阶段一的传统IM使用业务场景,我们设计了入如下的技术架构[图1]:

图1 58帮帮技术架构一

传统IM服务端的整个技术架构分为五层:

接入层(ENTRY)

作为客户端和服务端的接口子系统,此层直接面对PC桌面客户端、WEB网页客户端、移动APPS客户端的海量长连接请求,负责建立与客户端通信的加密通道,整合成内部少量有限的长连接,对通信数据进行压缩与解压,并将相应请求转发至逻辑层(LOGIC)。除此之外,接入层实施初步的攻防策略,用来抵御非逻辑层面的攻击,监控某些数据(连接频率、发包频率、发包速率等),对IP/UID等指标实施封禁,IM在某些紧急情况下,必须能够迅速实施封禁,所以需要实时授权IP/UID等黑白名单,使得白名单动态生效、黑名单自动解封。

逻辑层(LOGIC)

逻辑子系统主要是负责整个58帮帮业务逻辑的处理,包括用户相关(用户登录登出、用户信息设置查询)、好友相关(添加好友、获取好友、删除好友、修改好友信息等)、消息相关(收发好友消息、收发陌生人消息、消息确认、通用消息处理、离线消息等)等复杂逻辑处理。

路由层(ROUTER)

路由子系统主要处理和用户一次登录session相关的数据(比如:用户在线状态[在线、离开、隐身],登录IP等),这部分涉及的数据变化非常快,没必要固化,直接存储在内存中。并记录用户登录接入层的路由信息,支持向指定UIDS通信的功能。

数据层(DATA ACCESS)

统一数据访问子系统屏蔽了底层的存储引擎,上层不用关心实际的存储是RDBMS或者NoSQL或者其他的KV存储引擎,对上层提供友好、统一的访问接口,封装原子逻辑。并通过CURD接口的抽象封装,增加新的数据操作只需要增加配置,不用变动数据层代码,较容易完成关键数据的存储。

数据存储层(DATA STORAGE)

数据存储层是58帮帮数据的固化存储系统,根据数据的特点使用了RDBMS(MySQL)、NoSQL(MongoDB)等持久化存储,并通过分布式缓存(Memcached、Redis等)加速查询。

阶段一的传统IM架构是分层低耦合,在每层中我们采用了无状态的设计,每层的子系统可以自由动态扩展,以满足请求量增长需求。在每层中我们通过子系统冗余部署,消除单点,保证了系统的高可用性。每层之间的调用设计成了动态负载均衡方式,当被调用下层某台子系统故障时,上层子系统调用自动动态切换到可用服务节点,继续完成用户请求操作。单机线上支持50W+的同时在线用户,单机线上达到了3w+QPS,以满足千万级用户同时在线的需求。

阶段二:从传统IM到商家管理平台

随着产品的不断发展变化,58帮帮不再局限于传统的IM,而是一个逐步向商家管理平台演进,不断接入房产、招聘等分类信息业务,提供商家管理功能,进行发帖、帖子刷新、置顶帖子等操作。更多的功能,比如招聘简历推荐、房产发布等需要在客户端完成操作和展示。针对这些变化,在传统IM的架构上做了调整,主要变化体现在客户端。技术架构[图2]如下:

图2 58帮帮技术架构二

第三方业务(招聘、房产、二手车等)接入,和IM业务类型不一样,从技术角度分析,为了满足对应的产品功能,对长连接没有依赖,可以使用更加优雅的实现方式,因此没必须继续使用长连接,我们采用了在客户端通过HTTP的方式调用第三方服务,开发效率非常高,第三方业务可以快速接入,但由于客户端与第三方业务耦合紧密,带来很多兼容性的困难,一旦第三方业务策略发生变化、接口发生变动,客户端就要随之更新以适配变化,客户端升级代价非常大,而且不能做到实时更新,比如需要升级时,用户可以选择不升级,这些都会带来很大的麻烦。

为了解决客户端通过HTTP方式“简单粗暴”调用问题,在阶段一传统技术架构基础继续演变,形成了如下的架构[图3]:

图3 58帮帮技术架构三

以上演变的技术架构,我们发现客户端调用第三方业务由HTTP直接调用方式演变为通过58帮帮服务端中转调用的方式。客户端不再和第三方业务直接“接触”,所有第三方请求都会通过58帮帮服务端中转,58帮帮服务端继续调用第三方业务接口,即使下游服务策略变动、业务变动,我们只需要58帮帮服务端做相应的调整,对58帮帮客户端完全透明,从而避免了客户端升级代价大的问题。然而此技术架构存在的问题也比较明显:第一、一次用户请求要经过5个子系统(CLIENT->ENTRY->LOGIC->EXTLOGIC->TRANSIT->DESTSERVICE),5次网络交换,交互路径比较长,响应延迟较高。第二、线上出现问题,定位问题需要查看至少5个子系统日志,增加了快速分析和解决问题困难,成本较高。第三、客户端通过58帮帮服务端调用第三方业务,仍然采用的是TCP长连接的方式,随着移动化到来,移动网络相对不够稳定,试想正在使用58帮帮刷新二手帖子,进入电梯后,网络不稳定,刷新功能不再能够使用,提示你用户已经掉线,请重新登录后使用,这样的用户体现一定很糟糕。

阶段三:从商家管理平台到移动营销工具

随着业务发展以及产品的变化,我们从商家管理平台演变成商家随身的移动营销工具,定位为商家移动生意平台,满足招聘、房产、二手车、黄页等分类业务商家。58帮帮技术架构[图4]持续演变如下:

图表4 58帮帮技术架构四

从产品层面看,我们接入了更多的分类业务,这部分业务在技术架构上我们采用了更加轻量化的WebService服务,客户端使用HTTP的方式调用58帮帮WebService服务,WebService服务再调用下游服务,通过这样的架构,第一:我们解决了第三方服务变动对客户端升级的影响;第二:减少了对TCP长连接的依赖,稳定性和用户体验更好;第三;一次用户只需要2次网络交互,响应延迟提高;第四:用户请求调用路径变短,我们定位和分析线上问题,更加快速效率更高效。

通过上述的技术架构可以看到,58帮帮最终架构分为两个部分:IM相关(用户、好友、消息等)我们在技术架构上采用了TCP长连接的方式,保证了消息的及时到达;第三方业务部分我们采用HTTP短连接方式,在技术层面减少对长连接的依赖,在满足产品功能的同时,用户体验更好。

阶段四:如何打造满足58帮帮的移动推送系统

随着58帮帮移动化的深入,我们需要打造自己的移动推送系统,以解决移动环境下网络不稳定、APP应用无法触达的问题,从而把Message、Operation、Alert等类型消息推送给用户。

移动推送主要的三种实现方式:

客户端轮询(pull)

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

短信推送

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

服务端长连接(push)

这是目前的主流实现方式,实时性好,且电量消耗低,技术架构复杂度较高。

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

iOS平台

对于iOS来说相对简单,你没有别的选择,iOS中的应用是不允许后台常驻,所以你没有办法通过开发自己的 push service 来完成推送下发,只能通过苹果 APNS 渠道来完成推送,推送流程[图5]如下:

图5 iOS移动推送流程

Android平台

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

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

谷歌 C2DM[图6]的主要流程如下:

图6 C2DM推送流程

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

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

除此之外海域一些市面上的第三方推送产品供选择,使用这些产品需要面对几个问题:

1.到达率

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

2.实时性

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

我们曾经考虑实现一套完整的移动推送平台方案,如果从零开始来做,需要解决几个难点:首先是服务端对移动客户端海量长连接的管理、维持;然后是客户端常驻Service稳定性;第三手机在内存不足的时候,系统会杀掉你的Service,甚至有些系统比较强势,它不允许第三方Service常驻;如何在这些复杂场景下处理好,非常麻烦。

图7 58移动推送系统技术架构

综合考虑,58 推送方案没有选择从零开始的自建方案,我们采用了第三方移动推送平台和自主研发高性能Provider的方案[图7],满足每天百亿量级的吞吐量,并通过动态组合和扩展的方式,结合离线的移动推送数据分析,不同手机使用不同的推送策略,针对性的优化,从而提升到达率。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,324评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,303评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,192评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,555评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,569评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,566评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,927评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,583评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,827评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,590评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,669评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,365评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,941评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,928评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,159评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,880评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,399评论 2 342

推荐阅读更多精彩内容