app用什麼伺服器

❶ APP伺服器如何選擇

不同的應用對於伺服器有不同需求，APP選擇伺服器時需要注意幾個方面：
一、根據規模的大小，來選擇合適的配置與帶寬，比如說新開發的APP，前期訪問量小，可以用一個普通配置的雲伺服器就能滿足需求，但如果是較大規模或者數據量比較多的APP，則需要用較高的配置和帶寬。
二、根據用戶分布區域來選擇機房線路，大多APP是面向全國各地的用戶，所以在伺服器線路方面，推薦用多線或者BGP線路。
三、後期擴展性。如果你選擇的是雲伺服器，基本上都是支持中途升級高配置的，但如果是選擇的物理伺服器，就需要考慮後期升級的便利性，畢竟隨著APP規模的提升，後期升級配置以及帶寬也是很常見的操作。
四、服務商的資質以及服務，APP是需要全天不間斷運行的，所以選擇一個有信譽，資質齊全，服務有保障的IDC服務商，在伺服器出現問題時能第一時間響應並解決，非常重要。

❷ 開發一個APP，選擇什麼樣的伺服器最合適

網路時代中，手機對我們每個人的影響越來越大，無論工作還是生活都已經離不開手機，尤其是智能手機的普及，更加大了這一影響。我們哪個人手機上沒有幾個APP，支付的，聊天的，拍照的，視頻的等等。
APP軟體開發商也非常重視用戶體驗度，畢竟競爭壓力大，除了APP功能，畫面排版外，APP軟體打開速度，是否卡頓等等也是影響用戶體驗度的重要因素。如果APP不穩定，經常卡，連不上伺服器等，用戶會卸載APP的。因為APP軟體伺服器顯得尤為重要，是APP的基礎。那麼壹基比小喻就來教你們怎麼選擇伺服器吧

我們開發一款APP時，首先需要提供的就是數據交換，數據存儲以及數據處理等，這些都是需要伺服器來完成的。一台好的伺服器能承受更高的用戶承載量，提升用戶體驗度。既然伺服器這么重要，我們該怎麼選擇伺服器呢？

1.一定要正規的服務商
很多用戶在選擇時貪小便宜選擇個人渠道，這樣的價格可能會便宜些，但是售後是沒有保障的。一個人無法提供24小時售後支持這是其一。二，個人是什麼客戶都接，安全性低，易受到其他用戶的影響。三，一旦出現問題，個人跑路是很常見的，經常遇到用戶拿著ip來問是不是我們家的ip，因為他聯系不到服務商了，有的甚至到期了沒人通知機器下架的，數據全部丟失，損失是非常大的。

2.伺服器配置
現在伺服器配置都是很好選擇的，剛開始業務量不大選擇一款一般配置的機型就可以，現在伺服器基礎上都支持硬體升級，後期可以根據實際需求升級硬體配置。一般配置的機器幾百塊就搞定了，如果APP軟體硬體配置需要大的話，幾千上萬的都有，根據實際使用情況選擇就好。

❸ 手機APP開發用什麼伺服器

APP開發的第一個難點是數據通信，要把命令發送到控制器，由控制器發送命令來控制智能設備，這是一種方式。也有一部分沒有通過控制器直接控制職能設備的，但是就兩者而言他們的實現方式都大相徑庭。推薦用友有信，0成本，能提供：即時通訊、消息推送、簡訊服務、落地電話、視頻會議。

❹ 一般手機app開發，使用什麼類型的伺服器

看你要開發哪種類型的。要是社交類，建議租用雲伺服器比較好點。要是只是手機app開發，買個空間就可以了

❺ 開發APP伺服器選什麼好

伺服器肯定是linux啊 app用的是java吧 java默認的環境最好就是在linux下運行

❻ 開發APP,什麼伺服器比較好

開發app不用伺服器，app只是客戶端，和app交互信息的後台放在伺服器上。

❼ 手機app一般用什麼配置的伺服器

手機APP軟體下載量都會比較大的，選用伺服器最好是不限制流量的，還有就是要大帶寬，這樣多用戶下載時就不會擁堵，所以你選用伺服器時首先就是要求帶寬要大 。具體選擇什麼樣的配要根據具體情況選擇

❽ 手機app 一般採用什麼服務端軟體

你可以找本講android的書看看，我記得很多國內的書都會在最後講幾個實戰項目，涉及到伺服器開發，最後建議你Java伺服器開發框架可以用jfinal，實際上手機伺服器開發就是做網站，輸出的內容一般採用json,可以用httpService的形式，請求和響應，返回json給客戶端。

❾ 什麼是APP伺服器

app server的前身是middleware（中間件），歷史要長的多。早在上世紀六七十年代就已經開始在IBM大型機系統上廣泛應用了，叫做TP Monitor，比較著名的是BEA的Tuxedo和IBM的CICS，運行在Terminal/Server模式的Server端，其功能主要是分離商業邏輯，進行分布式計算的，可以自動管理事務、資源和容錯等等。因為發展的時間很長，所以技術非常成熟。middleware最早是用cobol編寫的，現在還可以偶爾看到cobol的中間件的舊系統，再後來middleware改用C++來實現，著名中間件的有IBM的CICS，BEA的Tuexdo，仍然廣泛的應用在高端系統中，特別是銀行系統。

然而在面向對象的技術出現和廣泛的應用之後，TP Monitor由於不是面向對象的，而是面向過程的調用，因此TP Monitor管理的商業邏輯並沒有分布式對象系統中的商業組件那樣的可擴展性、可重用性，表現出來很大的局限。

不過像PHP這樣主要還是面向過程調用的函數式的語言來說，TP Monitor仍然可以支持的非常完美，由於有了TP Monitor的支持，PHP也可以應用在企業的環境中了。

我所知道的eachnet用的是：

1
Linux+Apache+PHP+Tuxedo+Oracle

eachnet在上海好幾個ISP那裡放了伺服器，以保證服務不因某個ISP的問題而無法訪問。我曾經見過eachnet在上海熱線機房的伺服器，說出來，大家可能不信，eachnet竟然用的是自己攢的兼容機，世紀之星的機箱，估計不比我們大家自己買的兼容機強到哪裡去。大概有六七台機器的樣子，來負載均衡。

對象請求代理（Object Request Brokers）是另一種用的很多的中間件，支持分布式對象的調用。然而它的問題是僅僅是一個代理（Broker），系統級的功能需要自己來實現，這包括管理並發性、事務、資源管理和容錯機制等等，而且不同的廠商提供的ORB之間也存在互操作的兼容性問題。

於是一種綜合了TP Monitor和ORB功能的新的伺服器出現了，叫做CTM（Component Transaction Monitor）組件事務監控器。用在我們特定的管理應用程序的環境中就是App Server。

在1997年開始，CTM市場發生了巨大的變化，因為這一年Sun的J2EE標准正式發布，從此除了微軟之外，所有的CTM廠商都用Java來改寫自己的產品，例如Sybase原來有一個叫做Jagus CTS的東西，現在已經變成了純Java實現的EAServer，Borland的公司app server也是這樣來的。這樣一來，除了微軟之外，就剩下基於Java的app server了。

App Server可以自動管理並發性、事務、對象分布、負載均衡、安全性和資源管理等等系統級功能。簡單的來說就是App Server是管理服務端組件的，它給服務端組件提供了一個全功能可靠的運行環境。

打個比方來說，資料庫系統是管理數據的，它也給數據提供了一個受監控和管理的運行環境，提供了事務、安全性、負載均衡，並發性等等系統級功能，對於使用者來說，你不需要自己處理資料庫表的並發鎖定問題，自己處理SQL語句的解析、自己處理索引的優化等等系統級功能，同樣對於服務端組件的調用者來說也不需要自己處理並發請求、對象創建、銷毀、緩存，控制組件事務等等系統級功能。

App Server對服務端組件的的關系就是資料庫系統對數據的關系。App Server完全是一個類似資料庫系統這樣一個非常復雜的服務端軟體，所不同之處就是資料庫系統（RDBMS）是管理數據的，而App Server是管理對象的。這也是我研究Weblogic Server之後的切身感受。

Microsoft是最早發布App Server的廠商，叫做Microsoft Transaction Server（MTS）。其他還有很多基於不同技術的App Server，不過隨著EJB規范的發布，主流的App Server基本上都是基於J2EE的了。目前看來，App Server市場主要就是實現J2EE規范的Java應用伺服器和Microsoft的.Net應用伺服器這兩大主流。

Tuxedo等基於過程傳統的中間件會繼續在特定的場合發揮巨大的作用，像那些需要極高的響應性能和基於特定平台C/C++的場合，還是具有不可替代的作用。

App Server提供的服務端組件模型並沒有解決所有的問題，基於不同技術實現的服務端組件之間不能互相調用和數據共享，比如EJB組件和COM組件之間不能之間交換數據，所以基於SOAP協議的Web Services試圖解決這個問題，想把互聯網上所有的不同技術實現的組件服務都統一成單一的Web Services。這也是Web Services熱門的原因之一，標準的統一對大家都有好處。

❿ app後端選擇什麼伺服器

作為伺服器主要的作用是處理客戶端發過來的請求然後拿出請求所需要的數據在傳給客戶端，app也算是一種客戶端，用什麼伺服器性質沒什麼區別，甚至用什麼語言都不需要在乎，因為socket使用的協議tcp或者udp或者http等在任何語言裡面都是一樣的。還有伺服器還需要考慮高並發，也就是能同時處理很多個客戶端的請求，這是C/S或者B/S系統的關鍵。