一直以來工做的方向是web server,對app server沒有什麼瞭解。雖然沒有接觸過移動app開發,但對app後端技術仍是挺有探索慾望的,app應用和web應用在前端的用戶習慣不一樣,相信後端也會有不少不太同樣的地方。開此文記錄一些網上收集到的app後端技術體系,以備瞭解。html
下面就app server在業務設計上一般須要考慮的幾個方面:前端
如何設計一套合理且優雅的api接口集,能夠參考Restful分格:mysql
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除了提供聊天服務外,還能夠充當消息服務器。android
首先,各類消息推送必定要放在隊列中處理,否則會嚴重影響api的響應時間。web
手機短信方面:redis
一般要使用一些第三方短信服務平臺提供的接口,這個沒什麼好說的;算法
email方面:sql
要考慮郵件發送失敗的重發問題,因此再也不在服務器上搭建sendmail服務發送,選擇了郵件服務商mailgun。mailgun還提供每一個帳號每個月1萬封郵件的免費額度,很適合創業團隊。數據庫
消息推送方面:json
一、apns是iphone推送的不二選擇。但若是自身開發apns的服務,會遇到無效token而須要重發,這樣須要維護一個隊列並創建重發機制。
當用戶在iphone上卸載了app後,device token會失效,因此應該按期訪問蘋果的feedback服務器,把無效的token去掉。
二、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 算法,就是一種不錯的密鑰交換算法:
參考文檔:
一、曾健生, 《app後端》 http://blog.csdn.net/newjueqi/article/category/1743543
二、阮一峯,《RESTful API設計指南》 http://www.ruanyifeng.com/blog/2014/05/restful_api.html
三、《查找附近的xxx 球面距離以及Geohash方案探討》 http://www.wubiao.info/372
四、《XMPP協議實現原理介紹》 http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378956.html