app 后端技术
一直以来工作的方向是web server，对app server没有什么了解。虽然没有接触过移动app开发，但对app后端技术还是挺有探索欲望的，app应用和web应用在前端的用户习惯不同，相信后端也会有很多不太一样的地方。开此文记录一些网上收集到的app后端技术体系，以备了解。
下面就app server在业务设计上通常需要考虑的几个方面：
1、api风格
如何设计一套合理且优雅的api接口集，可以参考Restful分格：
- api采用http(s)协议与前端通信；
- 每个uri代表一种资源（resource），对于资源的操作类型，由HTTP方法表示（如GET、POST、PUT等）。例如：
GET /zoos： 列出所有动物园POST /zoos： 新建一个动物园GET /zoos/ID： 获取某个指定动物园的信息PUT /zoos/ID： 更新某个指定动物园的信息（提供该动物园的全部信息）DELETE /zoos/ID： 删除某个动物园GET /zoos/ID/animals： 列出某个指定动物园的所有动物DELETE /zoos/ID/animals/ID： 删除某个指定动物园的指定动物
- 通过参数过滤结果，例如
?limit=10： 指定返回记录的数量?offset=10： 指定返回记录的开始位置。?sortby=name&order=asc： 指定返回结果按照哪个属性排序，以及排序顺序。?animal_type_id=1： 指定筛选条件
- 服务器返回的数据格式尽量采用json；
- API身份认证key采用OAuth 2.0框架；
- 返回错误码和错误消息，方便前端进行错误处理和异常保护；
2、聊天服务
聊天服务端选用openfile，这是一个基于xmpp协议的聊天服务器。
xmpp除了提供聊天服务外，还可以充当消息服务器。
3、短信、邮件、推送服务
首先，各种消息推送一定要放在队列中处理，不然会严重影响api的响应时间。
手机短信方面：
通常要使用一些第三方短信服务平台提供的接口，这个没什么好说的；
email方面：
要考虑邮件发送失败的重发问题，所以不再在服务器上搭建sendmail服务发送，选择了邮件服务商mailgun。mailgun还提供每个账号每月1万封邮件的免费额度，很适合创业团队。
消息推送方面：
1、apns是iphone推送的不二选择。但如果自身开发apns的服务，会遇到无效token而需要重发，这样需要维护一个队列并建立重发机制。
当用户在iphone上卸载了app后，device token会失效，所以应该定期访问苹果的feedback服务器，把无效的token去掉。
2、android方面，有google的C2DM平台，但C2DM服务器在国外，国内用起来好像不太可用；
4、LBS
在LBS的应用中，一个基本的需求是查找附近的用户（或商户），现在有两种做法：
1. 使用mysql的空间数据库，具体做法参考：http://blog.sina.com.cn/s/blog_a48af8c001018q1p.html 。
2. 使用geohash编码。
关于geohash编码，它把球面上的经纬度转换成一个值，简单点来说就是把二维坐标转换成一维坐标。查找附近的时候，非常方便，用SQL中，LIKE ‘w23yr3%’可查询附近的所有地点。
当检索数据量特别大的时候，采用 coreseek+redis+mysql 可以解决查询慢的问题；
PS：coreseek是一个基于Sphinx的全文检索引擎。
5、动态通知
通常很多app的右上角能看到一个小红圈，圈里面有一个数字，表示有多少条新消息到达，借此唤醒用户的打开欲望。
在app端，怎么才能知道有多少条新通知呢？实现的技术有两种：
1. polling：app定时查询
2. push：服务器实时推送给app
相对来说，push的方式更高效，避免app频繁去查询服务器，既增加了服务器的压力，又多消耗了自己的流量和电量。
6、数据增量更新
7、安全性
用户和后端服务器通信的数据不要采用明文传输，尤其是涉及用户的帐号、密码这些敏感信息。
比如用户登录过程可以使用ssl 协议交换数据。
之前我自己在港交所的行情接收项目中采用过 Diffie-Hellman 算法，就是一种不错的密钥交换算法：
参考文档：
1、曾健生, 《app后端》
2、阮一峰，《RESTful API设计指南》
3、《查找附近的xxx 球面距离以及Geohash方案探讨》
4、《XMPP协议实现原理介绍》