CSDN首页> 云计算 孙玄：解析58同城典型技术架构及演变
转：http://www.csdn.net/article/2015-04-09/2824437
在UPYUN主办的“UPYUN Open Talk ”第三期北京站上，58同城系统架构师孙玄详细介绍了58同城的商家（移动）管理平台的技术架构及演变历程，并就企业的核心O2O技术进行了专题的分享。
孙玄表示，58同城是一个分类信息网站，涵盖房产、二手车、招聘、黄页等内容，在每一个类别里都能看到方便用户交流沟通的58帮帮。58帮帮分为IM部分和非IM的业务处理部分，目前，整个帮帮系统每天要处理10亿次+的发消息，加好友等传统IM请求，和30亿+的业务线操作，总请求到达40亿次+。帮帮同时在线用户量也突破了100万，给基础设施带来了严峻挑战。
58同城帮帮技术架构
系统起步：传统IM
而说到挑战，58帮帮从诞生到现在，曾经面对过很多。最开始时，它只是一个传统的IM，主要用来满足用户沟通和传递信息的功能。针对这样的业务场景，架构设计如下：
整个架构分为四层：接入层、逻辑层、路由层、数据层。
接入层。直接面对 PC、移动、网页海量客户端的连接请求，整合成少数的长连接，并将请求转发至逻辑层。
逻辑层。主要是一些业务逻辑的处理（例如权限校验、添加好友、发送消息等）。
路由层。主要处理和用户一次登录session相关的数据（比如：用户在线状态，登录IP等），这部分涉及的数据变化非常快，没必要固化，-直接存储在内存中。
数据层。严格来讲是数据中间件，屏蔽了底层RDBMS和NoSQL的区别和复杂性，较容易完成关键数据的存储。
系统发展：第三方业务接入
随着业务的不断变化，58帮帮不再局限于传统的IM，而是一个逐步向一个商家综合移动管理平台演进，例如接入房产、招聘等业务，提供商家管理功能，进行发帖、刷新、置顶帖子等操作。很多功能，比如招聘、房产等需要在客户端完成操作和展示。针对这些需求，在原有IM的架构上了调整，主要变化在客户端APP。
第三方业务接入，由于和IM业务类型不一样，对长连接没有依赖，因此没必须使用长连接，可以直接在APP通过http调用第三方服务，垂直划分后，开发效率非常高，第三方业务可以快速介入，但由于客户端与第三方业务耦合太紧，带来很多兼容性的困难，一旦第三方业务接口发生变动，客户端就要随之更新来适配变化，客户端升级代价非常大，而且不能做到实时更新，比如需要升级时，用户可以选择不升级，这些都会带来很大的麻烦。
系统成熟：客户端轻量化
为解决这个问题，在此基础上又做了些调整，形成了目前的框架：
加入一层帮帮WebService服务。通过这层业务，较少客户端与第三方的耦合，即使第三方服务发生变化，客户端也不受影响。
O2O核心技术解析
对于移动O2O，长连接、移动LBS、推送技术都比较重要。
1. 推送的主要途径
推送方面，主要通过以下三个方式来做：
1.1 客户端轮询（pull）
客户端定期发起查询请求，来达到推送的目的。pull的优点和缺点都很明显，架构简单但实时性差，想提高实时性，只能加快查询频率，但这会造成电量消耗过高。
1.2 短信推送
通过短信发送推送消息，并在客户端置入短信拦截模块，将接收到的短信拦截，并解析后转发给应用处理。这个方案实时性好、到达率高，但成本很高。
1.3 服务端长连接（push)
这是目前的主流实现方式，实时性好，且电量消耗低。
2. 不同平台的实现方案
基本上目前的推送技术都是结合这 3 个方面展开的，但对于不同的终端平台，又有各自不一样的实现，这里简单介绍一下 IOS 和 android 上的具体实现方案。
2.1 IOS 平台
对于 IOS 来说比较简单，你没有别的选择，因为 IOS 中的应用是不允许后台常驻的，所以你没有办法通过开发自己的 push service 来完成推送下发，只能通过苹果 APNS 渠道来完成推送，大致流程如下：
2.2 Android 平台
在 android 平台上，由于没有 IOS 那样的限制，可选的方案就多一些。你可以通过谷歌官方的。
C2DM 完成推送，可以借助开源的推送协议（例如 XMPP）实现，也可以借助市面上的各种推送产品完成推送。
谷歌 C2DM 的主要流程如下：
C2DM 和 APNS 流程类似，但其最大的问题是服务器在国外，很容易被屏蔽，而且由于 android 社区分裂比较严重，很多厂商可能直接就把 C2DM 模块给去掉了，所以在国内这个方案极不可靠。
对于开源推送协议，常见的有 XMPP 等，事实上谷歌的 C2DM 底层就是基于 XMPP 实现的，通过调用和测试，主要遇到了两个问题：1. 没有ACK 机制，消息不可靠。2. 请求量大时会不稳定。
最后就是一些市面上的第三方推送产品了，使用这些产品需要面对几个问题：
首先是到达率。虽然都宣传到达率能到 90%及以上，但实际使用起来，发现远远不到。
其次是实时性。第三方推送产品的推送通道是共用的，会面向多个客户，如果某一个客户推送量特别大，你的推送实时性可能就会受到影响，这些都是你不可控的。
曾经，58同城也有考虑过自己去实现一套推送方案，如果自己来做的话，要先解决几个难点。首先是服务端海量长连接的管理，然后是客户端常驻 sevice 的稳定性，手机在内存不足的时候，系统会杀掉你的 service，甚至有些系统比较强势，它不允许你的 service 常驻，如何在这些复杂场景下处理好，非常麻烦。
综合上面的一些考虑，58 帮帮目前的推送方案没有过多的使用自建方案，主要结合多家第三方推送来实现。针对到达率的提升，什么手机上使用什么推送产品，这需要去做一些数据分析，然后再做针对性优化。
