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]，满足每天百亿量级的吞吐量，并通过动态组合和扩展的方式，结合离线的移动推送数据分析，不同手机使用不同的推送策略，针对性的优化，从而提升到达率。
