app服務器

http://heipark.iteye.com/blog/1847421
http://heipark.iteye.com/blog/1847421
http://wenku.baidu.com/view/f761cc1f55270722192ef769.html


服務框架:
一、servlet
二、netty
協議：
一、http 1.0
二、http 1.1
db：
mysql就能夠了
ORM框架：
mybatis
緩存：
redis

技術：
網絡通訊: tcp，http等；
Web服務：servlet, cgi腳本，asp等；
系統調度：多線程，併發等；

框架：
對應不一樣的web服務技術，採用的編程語言不一樣；
對應不一樣的網絡通訊協議，採用的框架也不一樣，netty->tcp，servlet等web服務框架->http等；
對應系統調度，有不一樣的多線程，多進程通訊框架等；
對應提供不一樣的服務接口，有web service和restful兩大類，前者基於soap協議，後者基於http協議，對應的框架就不少，不一一敘述；

你能夠找本講android的書看看，我記得不少國內的書都會在最後講幾個實戰項目，涉及到服務器開發，最後建議你Java服務器開發框架能夠用jfinal，實際上手機服務器開發就是作網站，輸出的內容通常採用json

常見的服務器端編程技術有.net Java php python 等等
既然題主提到Android App，你不如去學習Java服務器端編程。
先系統的學習一下Servlet，安裝運行Servlet的容量Tomcat
還得學習一下數據庫，推薦MySql，練習簡單的增刪查改語句
學習Java鏈接數據庫的方法JDBC
服務器與App交互數據推薦使用JSON


應該沒有所謂的主流吧 - - 我只知道instagram使用了nginx、django、Gunicorn。。。
像instagram這麼多用戶的應用後臺絕對不是這麼簡單。What Powers Instagram: Hundreds of Instances, Dozens of Technologies這篇文章是他們公佈的架構，可供參考，另外網上也有一些逼人翻譯與分析的文章。

最後說下個人用法：
目前使用nginx+uWSGI+flask
flask是python的一個輕量級框架，上面有介紹。
nginx主要是處理靜態的請求，動態的交給uWSGI。
uWSGI是一個服務器，使用它能夠很方便的部署python應用，並且處理速度也比較快。
網上能夠找到不少關於nginx+uWSGI+flask的配置介紹。



三、數據庫
數據庫有Mysql、Oracle、SQL server等這些都是關係型數據庫，還有非關係型數據庫：memcached、mongodb、redis等。建議瞭解各類數據庫的特色，根據本身的業務模型，選擇最優的搭配。

四、開發語言
開發語言有不少python、php、perl、c++、java...基本上大部分語言均可以開發後臺。每種語言都有本身的特色與框架，像這些語言都有不少公司用。
據我所知，使用python做爲後臺開發的有知乎、豆瓣、quora，並且如今大部分的新型互聯網公司都傾向於使用python做爲後臺的開發語言。
python做爲後臺開發主要是能夠實現快速的開發，同時可供選擇的開發框架也有不少，好比：flask、django、tornado、bottle等。建議瞭解這些框架的特色。

六、數據交換格式
protobuf、json、xml。。。
這裏面最節約空間與速度最快的是protobuf，通常使用json就行了，json的在空間與速度上都優於xml。若是是特別追求節約空間與速度就使用protobuf。
...


http://uwsgi-docs.readthedocs.org/en/latest/



某手機公司應用商店App（客戶端、服務器端
具體要求：
一、須要有Coin金幣中心；有帳戶系統，充值系統（voucher充值）；
二、應用商城還須要包含（含壁紙，視頻，主題）；
三、網頁版本（可選）。
4：服務端安裝（新加坡亞馬遜雲），後臺系統維護（中英文界面）；
5：金幣對CP提供計費SDK。
6：app含新聞，新聞爲從當地主要網站抓取。新聞含網盟代碼；
7：app帶消息推送，自動更新功能；
8：支持平板電腦；
9：另增長手機第一次開機上報功能，後臺數據導出功能。
十、消息推送（採用第三方平臺）
十一、二維碼掃描功能。
開發商要求：
一、        成熟的App開發經驗，最好具備app market開發經驗。
二、        具有公司資質。


移動APP服務端API設計應該考慮到的問題
2014年，移動APP的熱度絲毫沒有減退，並無像桌面軟件被WEB網站那樣所取代，
不但如此，愈來愈多的傳統應用、網站也都開始製做本身的移動APP，也就是咱們常說的IOS客戶端、android客戶端。
這彷彿又回到了多年前的CS架構，那時候咱們用VB、VC、Delphi在Windows平臺上快速開發各類應用程序。
不一樣的是，現在的移動端APP基本上都是聯網從服務器端獲取各類數據，客戶端只是一個簡單的表現層的工具。

不只僅是移動APP，包括面向服務的SOA架構，都須要制定一套統1、規範的接口，
那麼，作這樣的後端接口須要注意哪些問題呢？

一、跨平臺性
所謂跨平臺是指咱們的接口要可以支持不一樣的終端，好比android、ios、windowsphone以及桌面軟件、網站等，
一套接口，支持多端，就像當年Java的口號同樣「Write Once,Run Anywhere」。
固然從本質上講，服務器端的接口跟終端是沒有太大關係的，只是接口應該考慮到不一樣端的接入成本，
採用通用的解決方案，好比通訊協議就採用最經常使用的HTTP協議，若是是即時通訊，能夠採用開放的XMPP協議，
作遊戲的能夠採用可靠的TCP協議，除非TCP不夠用了，再採用定製的UDP協議。
數據交換採用xml或者json格式等等。
總之，要達到的目標就是讓不一樣的端可以很方便的使用你的接口。

二、良好的響應速度
若是要用一個指標來衡量接口的性能的話，那麼我想最重要的就是響應速度了。
接口應該以最快的速度將數據返回給請求者。
試想，當咱們打開一個頁面，若是「努力加載中」之類的提示超過三五秒鐘的話，
咱們確定會變得不耐煩，移動app原本大部分就是用戶在碎片化時間來使用的，
在有限的時間內，用戶巴不得得到的信息越多越好，即便你的app界面設計的再好，用戶也不會買帳。

提升響應速度又是個老生常談的問題，大致上應該按照如下步驟來作：
初期，以功能爲主，要保證功能完整，知足業務需求，這階段可使用動態的語言，好比java、php、asp.net等，
配合設計良好的數據庫結構和索引，能知足必定的需求；
其次，隨着用戶的增多，能夠考慮一些緩存方案，緩存是解決性能問題的萬金油，一般能起到立竿見影的效果。
最經常使用的靜態文件緩存，memcached內存緩存等。
而後，單臺機器的吞吐率不行了，經過負載均衡多加幾臺機器就好了。七八臺機器，支持天天千萬級的接口調用是可行的。
或者，直接採用CDN的解決方案，將絕大多數的靜態資源交給CDN去處理。

總之，要達到的目標就是快，一個頁面，秒開最好，超過三秒就須要找找緣由了。

三、接口要爲移動客戶端考慮

接口不只僅是提供數據和功能就完事了，更應該充分考慮移動端的特性，爲移動端提供更加方便、快捷的接口。
好比，在移動端裏，下拉刷新和上拉加載更可能是很常見的功能，若是接口仍然按照傳統的web思路，
只提供按頁讀取的話，就會形成移動端的額外的數據請求和計算。 這時，接口就應該針對這兩種類型的操做提供額外的支持。

再好比，對於一個新聞閱讀類的app來講，最新的新聞列表裏的文章，特別是前幾條，用戶很容易點擊進去看，
然後面的老的文章列表，一來用戶下滑加載好幾頁的狀況較少，二來過期的新聞用戶也不多點。
若是，接口在返回新聞列表時，對於最新的列表，能夠直接把文章的正文（或者部分正文，好比一屏的內容）信息一塊兒傳給客戶端，
這樣，用戶在打開新聞詳情頁的時候，就不用再從服務器端獲取了，天然能夠作到秒開。

好比訪問第一頁時，接口能夠返回文章內容，以下所示 ，content=1表示加載文章內容
newslist?page=1&pagesize=20&content=1
其餘頁時，newslist?page=5&pagesize=20&content=0 ,不用加載文章內容。

固然，客戶端要跟接口作好配合，搭配好，才能最大化的提升性能。
好比，移動端都有左右滑動來看上一篇、下一篇文章或者圖片的功能，
若是，當用戶請求某篇文章的時候，服務器端順便也把下一篇文章的內容返回回來了，

那麼當用戶看下一篇的時候，是否是就很快了呢。

固然這種preload的方案也不能濫用，若是預加載數據的命中率較低的話，也不行，白白浪費了不少的流量。

四、考慮移動端的網絡狀況和耗電量

若是讓咱們說出哪類app比較好，可能還不大好說，可是若是讓咱們說出哪些app不好，
咱們確定會說出那些 體積很大、佔用內存多、界面很卡、費電的app很差。

對於移動APP開發者來講， 網絡流量和電池電量是不得不考慮的問題。
不過，您也許會說，這些跟接口沒啥關係吧，服務器端的接口還能管得了客戶端的網絡流量和電量？

對於網絡狀況，接口應該具有爲不一樣的網絡提供不一樣的內容的能力，
一般，移動端的上網方式無非是2G（GSM、GPRS、EDGE）、3G（CDMA、TDSCDMA、WCDMA）、WIFI，
設想一下，若是用戶在流量須要花錢的狀況下，你的app給用戶展現了視頻、音頻、大量的圖片而沒有通知用戶的狀況下，
用戶會怎麼想，畢竟國內的流量費用仍是很貴的。
還以上面的新聞列表接口爲例，若是咱們可以知道用戶的網絡狀況，只有在wifi的狀況下才給用戶傳輸封面圖、縮略圖之類的，
是否是能夠幫用戶節省不少流量呢。
newslist?page=1&pagesize=20&content=1&network=wifi

對於電量，首先咱們要弄清楚，app的哪些方面會消耗電量？
好比app有大量的計算、有很炫的視覺畫面都會消耗電量， 另外，不斷的移動網絡連接也會消耗大量的電量，
咱們都知道移動網絡是經過無線電波來通信的，那麼發射裝置就須要消耗必定的電量來發射和接收無線信號。
特別的是，頻繁的連接會不斷的切換網絡設備與移動基站之間鏈接狀態，這都會消耗一部分電量。

因此，對於接口而言，儘可能用少的連接傳輸多的數據，
好比，對於關於咱們、版本更新以及一些系統配置信息，徹底能夠經過一次連接所有返回給客戶端。

五、通用的數據交換格式

目前，對於接口和客戶端的數據交換格式，基本上就是兩種，xml和json，而如今使用json的應該佔大多數。
交換的數據包括兩種，一種是客戶端請求服務器端接口時傳遞的一些參數，一種是服務器端返回給客戶端的數據。

對於客戶端的請求參數，如今也愈來愈多的接口要求採用json的格式，而不是以往最多見的key_value對了。
好比，接口須要username和password兩個參數
key_value pair的方式是：
username=hutuseng&password=hutusengpwd
而後經過GET或者POST方式傳送。
而經過json方式交換數據的話，格式以下，直接POST到服務器端。
{
'username':'hutuseng',
'password':'hutusengpwd'
}

對於服務器端返回的json數據格式，須要注意兩個問題：
一是漢字編碼問題，由於json（javascript）內部支持Unicode編碼，會將漢字等轉換成unicode編碼保存，
因此在返回結果中，對於中文，能夠直接輸出中文，也能夠輸出中文的unicode編碼，
json解析器都會很好的解析。
好比下面兩種方式都是能夠的。
{"code":"208","data":"\u53c2\u6570\u4e0d\u5b8c\u6574"}
{
"code": "208",
"data": "參數不完整"
}
二是字段的數據類型，特別是數字類型的，json中儘可能轉成數字格式，
好比
{
'userid':128
}
不要寫成
{
'userid':'128'
}

六、接口統計功能

在作PC端網站的時候，咱們都會給咱們的網站加上個統計功能，要麼本身寫統計系統，要麼使用第三方的好比GA、百度等。
移動端接口API則須要咱們本身實現統計功能，
這時就須要咱們儘量多的收集客戶端的信息，除了傳統的IP、User-Agent以外，還應該收集一些移動相關的信息，
好比
手機操做系統，是android仍是ios，都是什麼版本，
用戶使用的網絡情況，是2G、3G、4G仍是WIFI
客戶端APP是什麼版本信息。

這樣，有助於咱們更好的瞭解咱們用戶的使用狀況。

七、客戶端與服務端的肥瘦平衡

在之前C/S、B/S架構時，咱們就已屢次討論過這個問題，客戶端是瘦點好仍是肥點好，固然也沒有固定答案，須要本身根據實際狀況去作權衡。
可是，在移動開發中，因爲客戶端的修改會很費時費力，特別是IOS應用還要通過Apple審覈，
另外，當前IOS開發人員、Android開發人員的人工成本廣泛較高，人才緊缺，
基於這兩點，能在服務器端實現的功能就不要放在客戶端，畢竟服務器端程序的修改要比客戶端方便、靈活、快捷的多。

八、隱式用戶與顯式用戶

顯式用戶和隱式用戶，我不知道這兩個詞用的是否確切。
顯式用戶指的是，APP程序中有用戶系統，一個username、password正確的合法用戶，稱之爲顯式的用戶，
一般顯式用戶都須要註冊，登陸之後能完成一些我的相關的操做。

隱式用戶指的是，APP程序自己就沒有用戶系統，或者一個在沒有登陸的狀況下，使用咱們APP的用戶。
在這種狀況下，能夠經過客戶端生成的UDID來標識一個用戶。

有了用戶信息，咱們就可以瞭解不一樣用戶的使用習慣，而不只僅是全體用戶的一個總體的統計信息，
有了這些個體的信息以後，就能夠作一些用戶分羣、個性化推薦之類的事情。

九、安全問題

網絡安全已經從桌面互聯網轉到了移動互聯網，從客戶端蔓延到了接口API中。

傳統固若金湯的網站，極可能由於接口的一點疏忽而遭受入侵。如今，在不少白帽子或者黑客的入侵思路中，

先看看移動端接口是否存在漏洞，再看網站是否有漏洞。
客戶端APP與接口的通訊很容易被獲得，只要在中間路由上嗅探一下就行，
whireshark、tcpdump這類工具使得這項工做變得簡單無比。

因此，接口的安全工做不能馬虎，暴力破解啊、SQL Injection啊、僞造請求和數據啊、重複提交啊也要考慮到,
若是數據特別敏感，能夠考慮採用SSL/TLS等加密傳輸，或者客戶端、服務器端約定一個加密算法和密鑰，對來往傳輸的數據進行加密、解密
若是不採用RESTful API，能夠採用基於WSDL和SOAP的Web Service的安全措施。


十、良好的接口說明文檔和測試程序

接口文檔有時候是項目初期就定下來的，先後端開發人員按照接口規範開發，
有的是接口開發完成後寫的。
接口文檔要清晰、明瞭，包含多少個接口，每一個接口的地址、參數、請求方式、數據交換格式、返回值等都要寫清楚。

接口測試程序，有條件的話，也能夠提供，方便先後端的調試。



十一、版本的維護

隨着業務的變化，客戶端APP和服務器端API都會發生變化，增長新的功能，修改已有的功能，
增長功能還好說， 若是是接口須要修改，那麼就面臨着同一個接口要同時爲不一樣版本的客戶端服務的問題。
所以，服務器端接口也要作好相應的版本維護。









 App server 與 Web server之間的區別
2009-12-17 12:02 1315人閱讀 評論(0) 收藏 舉報
serverwebweb服務服務器html瀏覽器

原文： http://www.javaworld.com/javaqa/2002-08/01-qa-0823-appvswebserver.html

 

app服務器和web服務器的區別是什麼呢？

 

簡單來講，web服務器提供頁面給瀏覽器，而app服務器提供客戶端能夠調用的接口。具體而言，咱們能夠說：

 

         Web服務器處理HTTP請求，而app服務器基於多種不一樣的協議，處理應用程序的邏輯問題。

 

如下將詳細介紹它們之間的區別。

 

 

Web服務器

 

web服務器處理HTTP協議。當收到一個HTTP請求以後，web服務器會返回一個HTTP響應，好比一個HTML頁面。爲了處理請求，它可能響應一個靜態的HTML頁面、圖片、重定向，或者代理（delegate）其餘動態響應。這些動態響應能夠由其餘程序生成，包括CGI腳本，JSPs，servlets，ASPs，服務器端的Javascript，或者其餘服務器端技術。而這些服務器端程序響應，大多數時候都表現爲HTML頁面，供瀏覽器訪問。

 

理解一個web服務器的代理模型(delegate model)相對比較簡單。當web服務器接收到一個請求，它只是簡單的將請求交給處理該請求的最優程序。除了爲服務器程序簡單的提供一個運行環境（服務器程序能夠在其中運行，而且返回生成的響應）以外，web服務器不提供任何功能。服務器程序通常本身處理交換(transaction)、數據庫鏈接、消息分發等。

 

雖然web服務器不提供以上的服務，可是它通常會提供諸如容錯機制，負載均衡、緩存、集羣等的可擴展性。然後者，通常來講不該該部署在web服務器上，而應該在app服務器上！

 

 

App服務器

 

根據咱們的定義，app服務器能夠基於各類不一樣的協議（可能包含HTTP協議），爲客戶端程序提供應用邏輯的處理。不一樣於web服務器主要發送用來展現在瀏覽器上的HTML頁面，app服務器爲客戶端程序處理應用邏輯方面問題。應用程序使用這些邏輯，就如同調用一個對象的方法（或者面向過程編程中的函數）同樣簡單。

 

這些應用程序可能包含PC機上運行的GUI進程，web服務器，甚至其餘的app服務器。app服務器和客戶端之間的通訊並不侷限於簡單的顯示標記，而是能夠由程序邏輯，好比數據表單、方法調用，而非靜態的HTML，這樣，客戶端程序就能夠按需去用了！

 

在大多數狀況下，app服務器經過元件API，好比基於j2ee app服務器的EJB，來提供應用邏輯。而更多的狀況下，app服務器本身管理本身的資源。這些責任（gate-keeping）包括安全、進程交互、資源池、消息分發等。同web服務器同樣，app服務器也可能須要各類可擴展性和容錯機制。

 

一個例子
以一個提供實時價格和相關信息的在線商店爲例，它極有可能提供了一個表單，用戶能夠選擇不一樣的產品並查詢。它會查找，並經過HTML網頁展現結果。這個網站可能有多種方式來實現這個功能，下面咱們將舉兩個相反的例子，一個不使用app服務器，而另外一個使用。經過這兩個例子，能夠幫助你理解app服務器的功能。

 

場景1：web服務器，而非app服務器
在這個場景裏，web服務器獨自提供在線商店的功能。它接受用戶的請求，交給服務器端程序處理。該服務器端程序經過數據庫，或者純文本，查找到價格信息，而後生成HTML響應，經過web服務器返回給用戶的瀏覽器。
總結來講，web服務器僅須要接受HTTP請求，並響應HTML網頁。
 

場景2： web服務器 + app服務器
同場景1同樣，web服務器仍然代理腳本生成的響應。可是你能夠把業務邏輯部署在app服務器上。這樣，腳本就不須要去關注怎樣查詢和生成響應，而僅須要調用app服務器提供查詢服務，從而利用其生成它的HTML響應。

在這個例子中，app服務器提供了價格查詢的業務邏輯。這個邏輯不該該包含怎樣去展現，或者強迫客戶端使用這些數據。相反的是，客戶端和app服務器進行交互，只有當客戶端調用了app服務器的價格查詢服務的時候，該服務才查找到信息並返回。

同HTML代碼生成分離開後，價格查詢邏輯的複用性提升了。另一個客戶端，好比收銀機，一樣能夠調用這個接口。而場景1裏，價格查詢服務就很難被重用，由於它和HTML頁面緊密聯繫。

總結來講，第二個場景中，web服務器處理HTTP請求，並返回HTML頁面，而app服務器處理業務邏輯。


注意事項
近來，XML web服務器模糊了app服務器和web服務器的界限。發送一個XML請求給web服務器，web服務器能夠像過去的app服務器同樣，處理數據並返回響應。
另外，不少app服務器包含web服務器，這就意味着你能夠把web服務器看作app服務器的一個子集。雖然app服務器包含web服務器的功能，可是開發者仍是不多以此身份發佈app服務器。若是須要的話，他們一般將web服務器和app服務器分離開。這樣的目的是，性能（簡單的web請求不會影響到app服務器的性能）、發佈配置（專用的web服務器，集羣等）、更好的廠商選擇。

About the author
Tony Sintes is an independent consultant and founder of First Class Consulting, a consulting firm that specializes in bridging disparate enterprise systems and training. Outside of First Class Consulting, Tony is an active freelance writer, as well as author of Sams Teach Yourself Object-Oriented Programming in 21 Days (Sams, 2001; ISBN: 0672321092).