标签:android style blog http color os 使用 ar strong
一直以来工作的方向是web server,对app server没有什么了解。虽然没有接触过移动app开发,但对app后端技术还是挺有探索欲望的,app应用和web应用在前端的用户习惯不同,相信后端也会有很多不太一样的地方。开此文记录一些网上收集到的app后端技术体系,以备了解。
下面就app server在业务设计上通常需要考虑的几个方面:
如何设计一套合理且优雅的api接口集,可以参考Restful分格:
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: 指定筛选条件
聊天服务端选用openfile,这是一个基于xmpp协议的聊天服务器。
xmpp除了提供聊天服务外,还可以充当消息服务器。
首先,各种消息推送一定要放在队列中处理,不然会严重影响api的响应时间。
手机短信方面:
通常要使用一些第三方短信服务平台提供的接口,这个没什么好说的;
email方面:
要考虑邮件发送失败的重发问题,所以不再在服务器上搭建sendmail服务发送,选择了邮件服务商mailgun。mailgun还提供每个账号每月1万封邮件的免费额度,很适合创业团队。
消息推送方面:
1、apns是iphone推送的不二选择。但如果自身开发apns的服务,会遇到无效token而需要重发,这样需要维护一个队列并建立重发机制。
当用户在iphone上卸载了app后,device token会失效,所以应该定期访问苹果的feedback服务器,把无效的token去掉。
2、android方面,有google的C2DM平台,但C2DM服务器在国外,国内用起来好像不太可用;
在LBS的应用中,一个基本的需求是查找附近的用户(或商户),现在有两种做法:
1. 使用mysql的空间数据库,具体做法参考:http://blog.sina.com.cn/s/blog_a48af8c001018q1p.html 。
2. 使用geohash编码。
关于geohash编码,它把球面上的经纬度转换成一个值,简单点来说就是把二维坐标转换成一维坐标。查找附近的时候,非常方便,用SQL中,LIKE ‘w23yr3%’可查询附近的所有地点。
当检索数据量特别大的时候,采用 coreseek+redis+mysql 可以解决查询慢的问题;
PS:coreseek是一个基于Sphinx的全文检索引擎。
通常很多app的右上角能看到一个小红圈,圈里面有一个数字,表示有多少条新消息到达,借此唤醒用户的打开欲望。
在app端,怎么才能知道有多少条新通知呢?实现的技术有两种:
1. polling:app定时查询
2. push:服务器实时推送给app
相对来说,push的方式更高效,避免app频繁去查询服务器,既增加了服务器的压力,又多消耗了自己的流量和电量。
用户和后端服务器通信的数据不要采用明文传输,尤其是涉及用户的帐号、密码这些敏感信息。
比如用户登录过程可以使用ssl 协议交换数据。
之前我自己在港交所的行情接收项目中采用过 Diffie-Hellman 算法,就是一种不错的密钥交换算法:
参考文档:
1、曾健生, 《app后端》 http://blog.csdn.net/newjueqi/article/category/1743543
2、阮一峰,《RESTful API设计指南》 http://www.ruanyifeng.com/blog/2014/05/restful_api.html
3、《查找附近的xxx 球面距离以及Geohash方案探讨》 http://www.wubiao.info/372
4、《XMPP协议实现原理介绍》 http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378956.html
标签:android style blog http color os 使用 ar strong
原文地址:http://www.cnblogs.com/chenny7/p/3991925.html