孙玄58同城典型技术架构演变O2O核心技术介绍.pdf

58 同城典型技术架构演变及O2O核心技术 介绍 在UPYUN主办的 “UPYUN Open Talk ”第三期北京站上，58同城系统架构师孙 玄向参会的各位知名企业及创业团队的开发者们详细介绍了58同城的商家（移 动）管理平台的技术架构及演变历程，并就企业的核心O2O技术进行了专题的分 享。 我们都知道，58同城是一个分类信息网站，涵盖房产、二手车、招聘、黄页等 内容，在每一个类别里都能看到方便用户交流沟通的58帮帮。58帮帮分为IM 部分和非IM的业务处理部分，目前，整个帮帮系统每天要处理10亿次+的发消 息，加好友等传 IM请求，和30亿+的业务线操作，总请求到达40亿次+。帮 帮同时在线用户量也突破了100万，这给我们带来了很大的挑战。 系统起步：传统IM 说到挑战，58帮帮从诞生到现在，曾经面对过很多。最开始时，它只是一个传 统的IM，主要用来满足用户沟通和传递信息的功能。针对这样的业务场景，我 们设计了如下的结构： 整个架构分为四层：接入层、逻辑层、路由层、数据层。 1）接入层 直接面对 PC、移动、网页海量客户端的连接请求，整合成少数的长连接，并将 请求转发至逻辑层。 2）逻辑层 主要是一些业务逻辑的处理（例如权限校验、添加好友、发送消息等）。 ）路由层 主要处理和用户一次登录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. 服务端长连接（push) 这是目前的主流实现方式，实时性好，且电量消耗低。 2、不同平台的实现方案 基本上目前的推送技术都是结合这 3 个方面展开的，但对于不同的终端平台， 又有各自不一样的实现，这里简单介绍一下 IOS 和 android 上的具体实现 方案。 2.1 IOS平台 对于 IOS 来说比较简单，你没有别的选择，因为 IOS 中的应用是不允许后 台常驻的，所以你没有办法通过开发自己的 pushservice 来完成推送下发， 只能通过苹果APNS 渠道来完成推送，大致流程如下： 2.2Android 平台 在 android 平台上，由于没有 IOS 那样的限制，可选的方案就多一些。你 可以通过谷歌官方的。 C2DM 完成推送，可以借助开源的推送协议 （例如 XMPP）实现，也可以借助市 面上的各种推送产品完成推送。 谷歌 C2DM 的主要流程如下： C2DM 和 APNS 流程类似，但其最大的问题是服务器在国外，很容易被屏蔽， 而且由于 android 社区分裂比较严重，很多厂商可能直接就把 C2DM