app伺服器都有什麼

A. 大家做一個APP需要什麼樣的伺服器

app不需要伺服器，做數據傳輸的時候才需要。操作系統常用的是linux或者windows。視伺服器語言選擇伺服器類型，如java後端就是用tomcat居多，php在windows用apache，nginx，IIS都可以，在linux就用apache或nginx。python類腳本語言可以自成伺服器，做守護進程監聽網路連接。

B. 什麼是APP伺服器租用，對伺服器帶寬有什麼要求

伺服器能做的應用很多，比如做網站、app、資料庫、下載站、採集站等等。做app的話就叫app伺服器，做網站就叫網站伺服器。
每個人的應用都是不一樣的，對伺服器配置需求還看自己的具體情況，具體要多大帶寬沒人能夠說得清楚。建議前期選擇基礎的配置，包括cpu、內存、硬碟、帶寬等，這些都是可以隨時補差價升級的，後期不夠用再根據實際情況升級就好了。
耀磊數據為您解答

C. 什麼是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熱門的原因之一，標準的統一對大家都有好處。

D. web server與app server有什麼不同

1、處理問題不同
Web伺服器處理HTTP請求，而app伺服器基於多種不同的協議，處理應用程序的邏輯問題

2、功能不同
當web伺服器接收到一個請求，它只是簡單的將請求交給處理該請求的最優程序。除了為伺服器程序簡單的提供一個運行環境之外，web伺服器不提供任何功能。不同於web伺服器主要發送用來展示在瀏覽器上的HTML頁面，app伺服器為客戶端程序處理應用邏輯方面問題。

3、提供的服務不同

web伺服器一般會提供諸如容錯機制，負載均衡、緩存、集群等。app伺服器通過元件API，比如基於j2ee app伺服器的EJB，來提供應用邏輯。而更多的情況下，app伺服器自己管理自己的資源。這些責任（gate-keeping）包括安全、進程交互、資源池、消息分發等。

(4)app伺服器都有什麼擴展閱讀

主要web server產品

1、kangle

kangleweb伺服器（簡稱：kangle）是一款跨平台、功能強大、安全穩定、易操作的高性能web伺服器和反向代理伺服器軟體。除此：kangle也是一款專為做虛擬主機研發的web伺服器。實現虛擬主機獨立進程、獨立身份運行。

用戶之間安全隔離，一個用戶出問題不影響其他用戶。安全支持php、asp、net、java、ruby等多種動態開發語言。

2、nginx

Nginx（發音同 engine x）是一款輕量級的Web伺服器/反向代理伺服器及電子郵（IMAP/POP3）代理伺服器，並在一個BSD-like 協議下發行。由俄羅斯的程序設計師Igor Sysoev所開發，供俄國大型的入口網站及搜索引擎Rambler（俄文：Рамблер）使用。

其特點是佔有內存少，並發能力強，事實上nginx的並發能力確實在同類型的網頁伺服器中表現較好，中國大陸使用nginx網站用戶有：新浪、網易、騰訊等。

3、apache

Apache是世界使用排名第一的Web伺服器軟體。它可以運行在幾乎所有廣泛使用的計算機平台上，由於其跨平台和安全性被廣泛使用，是最流行的Web伺服器端軟體之一。

同時Apache音譯為阿帕奇，是北美印第安人的一個部落，叫阿帕奇族，在美國的西南部。也是一個基金會的名稱、一種武裝直升機等等。

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伺服器處理業務邏輯。

E. app伺服器開發需要學習哪些知識

這個問題有些籠統，一個完整的app有簡單有復雜，不同的app應用功能的差異也導致不同的技術實現或者演算法模型。大體來說，一個app從設計到最終實現需要懂得以下幾個必要方面：
1、前期需求規劃與信息、交互設計——需要制定出一個完整的需求文檔，功能文檔，流程圖，時序圖。
2、交互設計、UI設計——設計出基本且完善的原型圖和app基礎的交互設計效果，之後再根據這些設計出完整的UI界面並學會切圖，一些需要做自適應的素材圖片需要做點9patch。 這里還需要懂得px，pt和dp之間的換算，屏幕密度的換算和相互之間的系數，以便app能完美適應不同解析度設備。其中交互設計需要懂得很多人機操作的技巧經驗，掌握Axure等交互工具的使用，UI設計需要掌握Photoshop和Illustrator等操作。
3、使用ADT之類的開發環境進行app開發，最基本的也得掌握java語言，熟悉android環境和機制，這裡面涉及面廣，請根據項目自行學習相關知識。
4、如果不是單機版的app，需要用到伺服器，那還得掌握WebService相關知識和開發語言，常用的有ASP.Net，PHP，JSP等。
5、熟悉並能開發資料庫。
6、某些功能需要做演算法，這還需要一定得專業知識，尤其是數學基礎。
7、熟悉API介面開發，這里包括自行開發API的能力以及調用第三方API的經驗。
8、熟悉TCP/IP，socket等網路協議和相關知識。
9、熟練掌握App發布的流程，真機調試技巧，證書，打包，上架。
App開發其實不一定適合一個人搞，太費勁，除非是一個單機版的小應用，或者利用現成的api開發簡單的第三方應用，否則還是讓一個團隊來完成各自擅長的領域。

F. APP伺服器如何選擇

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

G. app後台租哪種伺服器比較好

主要看你APP的規模大小以及訪問量.如果是新做的APP.其實前期可以不用伺服器,用一個普通配置的雲主機足矣,另外APP軟體一般是面向各個地區不同線路的用戶使用的.所以機房的話推薦用BGP多線,這樣能保證各種不同線路用戶的訪問速度.

H. 開發一個APP需要什麼的伺服器好

可以容納2-5萬人,是同時迸發,還是,還是一共就這么多人.

同時迸發量5萬人,那要求高了.建議內存16G以上 CPU8核以上 寬頻300M以上 年付估計3萬以上.
一天5萬人,建議內存8G以上,CPU6核以上 寬頻100M 以上

除了伺服器外如果想更穩定,建議數庫分離. 你須要一個域名並且備案,如果要支付功能還須要去申請介面,SSL證書,及蘋果應用證書. 如果你APP要國產及蘋果的支持,可能須要二台伺服器. 當然你要是網站打包成APP就不用二台了.

I. 利用java開發的app後台伺服器框架有哪些

java開發的app後台伺服器框架有：
spring+springmv+mybatis是主流。

伺服器框架基本上有長鏈接短鏈接兩種。
手機APP的後台服務建議還是JSON-over-HTTP(s)的，因為網路狀況一般不穩定。
Java的HTTP開發框架，跟做網站一樣。

J. 面試題 什麼是應用伺服器，簡要介紹幾種常用的app service

應用程序伺服器提供訪問商業邏輯的途徑以供客戶端應用程序使用。它不僅像傳統中間件一樣，提供對應用邏輯層的支持，更明顯的特點是本身也提供對表現層的支持。這個特點也是與其Web特性不可分的，比如表現層外的client可能如下：Web Browser, Email, Smart Phone, PDA等。