APP后台开发运维与架构实践 9 : App后端架构剖析

9.1 聊天App后台架构

    移动互联网的网络特性：弱网络性和对流量敏感。    

    针对弱网络环境，开发者在设计协议时必须考虑尽量减少数据往返的次数。长连接时可能会出现忽然中断的情况。这叫TCP half-open，有效的解决方法是使用应用层心跳机制：在App和服务器保持连接的过程中，App在规定时间间隔内向服务器发送一个数据。服务器收到这个数据知道这个连接是有效的。

     如果建立上万的连接定时器，会消耗大量的系统资源，可用时间轮片。

     协议：常用的聊天协议，如XMPP（比较成熟），MQTT、类ActivitySync（微信实现的协议）

     短时内实现聊天功能，最好选择XMPP协议，有两个著名开源聊天服务器，Ejobberd和Openfire。

     如果必须使用自定义的通信协议，...

      聊天还有一个常见的功能：发送图片、声音等文件。笔者建议是在采用纯文本的方案发送这些数据。流程如下：

     采用纯文本的好处：只处理文本比较简单和可以统一优化文件的性能（如CDN）

     整体架构：

     参考资料：《高可用即时通信架构》

9.2 社交App后台架构

     类似于微博的场景，用户与用户之间有关注和粉丝这两种关系。社交的核心功能是Feed。指用户通过关注功能，聚合了被关注用户的最新的内容以供自己浏览的信息服务。

     基本表结构：常用的Feed架构是把数据存储在MySQL，热点数据（一般最近3天）存储在缓存。

     推拉模式：

     数据库架构的演进：

     缓存架构的演进：

9.3 LBS App后台架构

     App端建议直接使用地图SDK提供的获取地理坐标的方法来获取地理坐标。需要注意坐标的偏移问题。因为系统底层函数获取的是国际坐标系。

     查找附近的人：数据库的用户信息中有一个地理坐标字段，MySQL的空间数据库、geohash编码、MongoDB。

     基于MongoDB的LBS后台架构演进：

9.4 推送服务器后台架构

   现在推送服务主要分两块：Android推送和iOS推送。

9.5 获取更改App后台架构资料

    InfoQ

     http://www.devstore.cn/

     http://apistore.baidu.com/