app伺服器包括什麼

⑴ web server與app server有什麼不同

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

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

3、提供的服務不同

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

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

⑵ 伺服器APP伺服器與WEB伺服器有什麼區別

場景不一樣唄。web就是提供一種服務就行了。 app伺服器需要提供多種服務模式。

⑶ 短視頻app伺服器要哪些配置

短視頻APP應用在選擇伺服器時，怎麼挑選配置呢？短視頻是近幾年一直都比較流行的。目前抖音視頻的用戶量也是在逐年不斷增加的，除了抖音以外，火山小視頻、快手等都是比較火熱的應用。由於人們對手機休閑娛樂的需求還是比較大的，所以目前做短視頻應用的用戶也是特別多的。

無論是視頻網站還是直播的平台還是短視頻應用，在伺服器配置上的需求都是差不多的，大多的IDC運營商都有專門針對於這類行業專用的伺服器配置進行推薦。大部分的配置選擇都是可以常規選擇進行選擇的，由於短視頻類APP伺服器需要具備儲存、高速緩存。還需要有多種視頻專用的軟硬體功能的設備，來去應對媒體數據的壓縮、傳輸、存儲等功能。面對這些需求，帶寬的大小對一款短視頻APP應用的影響還是比較大的。
通常單個在線觀眾需要流暢的觀看高清視頻，大概是需要350K左右的帶寬流量的。由於伺服器所需要的帶寬是按照可以承載的最高並發流量來計算的。所以如果同時在線觀看的人數是10個人的情況下，根據換算，為了保證10人均能穩定流暢的觀看視頻，則需要20M以上的帶寬。
當然對於短視頻類APP本身對帶寬的需求就是特別大的，用戶可能會存在下載和上傳視頻的操作。無論是上傳還是下載都是需要帶寬支撐的。所以在短視頻伺服器配置的選擇上選擇比較好的帶寬，其他配置依照常規的視頻網站的規則去選擇即可。

⑷ 開發一款新的APP,需要用到伺服器嗎

開發APP需要伺服器嗎？這個答案當然是一定的。那麼像APP伺服器需要什麼配置比較好呢？哪一家的伺服器租用比較可靠呢？
一般來說，新開發的APP伺服器不需要太高的配置，前期只需要用來測試即可。但如果說我們本身就對這個app很熟悉，未來是靠這個來賺錢的話，我們應該一開始就選擇品牌雲伺服器如阿里雲，給用戶以更好的體驗，留住大部分用戶;而且雲伺服器租用也不是說沒有區分，也是隨著價格的不同而不同，一般來說普通配置的伺服器是雙核2G伺服器，中等配置的伺服器是四核4G，高端伺服器的配置的話是八核8G，這個租用什麼配置的話還是要看使用我們app的人數，使用人數越多，同時在線人數越多，對伺服器的配置要求也越高。
App伺服器租用的帶寬也是跟使用人數有關系，前期的話建議5M獨享的帶寬，等到後期如果用戶數足夠大的話可以選擇10M獨享或是100M獨享等等，反正一切是以用戶體驗良好為前提。
海河雲平台為客戶提供豐富的IT基礎資源,包括雲伺服器、雲資料庫、負載均衡、專有網路、彈性公網IP以及雲監控等多款雲產品。通過友好的可視化UI界面輕松管理雲資源。

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

⑺ 什麼叫CTI伺服器，APP伺服器

CTI伺服器
CTI伺服器是整個Call Center的核心，它將電話交換系統和計算機系統有機地結合起來，充分利用交換機話路交換功能和計算機系統數據處理功能。不僅可以接收來自交換機的呼叫信息(如呼叫電話號碼等)，同時可以通過計算機有效地控制交換機的呼叫處理，包括呼叫轉移、呼叫中止、智能呼出等服務。

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

⑻ APP開發需要用到伺服器嗎伺服器都有什麼用途

APP開發需要用到伺服器啊，一般是台式的伺服器，即我們日常最常見的電腦主機，不過高配置一點。但是伺服器類型很多：家用的主機電腦、機房運營商提供的伺服器，就我們家裡的電腦主機就是伺服器的一種。開發是在伺服器上面進行的，但是除非是對外APP已經上線要全國測試或者說是直接使用，一般開發都是公司裡面直接本地用主機電腦就可以進行了。騰正科技，嘉輝上

⑼ 什麼是應用伺服器

應用伺服器
應用伺服器是指通過各種協議把商業邏輯曝露給客戶端的程序。它提供了訪問商業邏輯的途徑以供客戶端應用程序使用。應用伺服器使用此商業邏輯就像調用對象的一個方法一樣。
基本信息
中文名
應用伺服器
提供
訪問商業邏輯的途徑
實現
動態網頁技術
目錄
定義
隨著Internet的發展壯大,「主機/終端」或「客戶機/伺服器」的傳統的應用系統模式已經不能適應新的環境,於是就產生了新的分布式應用系統,相應地,新的開發模式也應運而生，即所謂的「瀏覽器/伺服器」結構、「瘦客戶機」模式。應用伺服器便是一種實現這種模式核心技術。[1]
Web應用程序駐留在應用伺服器(Application Server)上。應用伺服器為Web應用程序提供一種簡單的和可管理的對系統資源的訪問機制。它也提供低級的服務，如HTTP協議的實現和資料庫連接管理。Servlet容器僅僅是應用伺服器的一部分。除了Servlet容器外，應用伺服器還可能提供其他的Java EE(Enterprise Edition)組件，如EJB容器，JNDI伺服器以及JMS伺服器等。
市場上可以得到多種應用伺服器，其中包括Apache的Tomcat、IBM的WebSphere Application Server、Caucho Technology的Resin、Macromedia的JRun、NEC WebOTX Application Server、JBoss Application Server、Oracle(並購了BEA)的WebLogic等。其中有些如NEC WebOTX Application Server、WebLogic、WebSphere不僅僅是Servlet容器，它們也提供對EJB(Enterprise JavaBeans)、JMS(Java Message Service)以及其他Java EE技術的支持。每種類型的應用伺服器都有自己的優點、局限性和適用性。
分類
通常，根據確定文檔內容的時間，所有文檔可以劃分為如下三類。
靜態
靜態：靜態Web 文檔是一個存儲於Web伺服器的文件。靜態文檔的作者在寫作的時候確定文檔的內容。由於文檔內容不會變化，所以對靜態文檔的每次訪問都返回相同結果。
動態
動態：動態web文檔不是以一個預先定義的格式存在，而是在瀏覽器訪問web伺服器時創建。當一個請求到達時，web伺服器運行一個應用程序創建動態文檔（dynamic documents），伺服器返回程序的輸出作為應答。由於每次訪問都要創建新的文檔，動態文檔的內容是變化的。
活動
活動：一個活動文檔不完全由伺服器一端說明，而是包括一個計算並顯示值的程序。當瀏覽器訪問活動文檔時，伺服器返回一個瀏覽器可以本地執行的程序。當該程序運行時，它可以和用戶交互執行並不停地改變顯示。這樣，活動文檔的內容是不固定的-只要用戶讓程序保持運行，它總是在不停地變化。靜態文檔的主要優點在於它的簡單、可靠性和性能。由於靜態文檔是直接指定格式。它可以由不懂編程的人創建。更重要的是，在已經創建和測試之後，靜態文檔永遠是正確的。最後，瀏覽器可以快速存取文檔，同時通過把文檔放在本地盤上的緩沖區內以加快以後對這些文檔的訪問速度。 靜態文檔的主要缺點是不靈活-當信息變化時文檔必須重新設計。另外，改變是很耗費時間的，因為它需要人工修改文件。因此，靜態文檔不適合頻繁變化的報告信息。動態文檔的主要優點是它報告當前信息的能力。例如，一個動態文檔可以用來報告股市行情、天氣預報或音樂會售票情況等內容。當瀏覽器申請信息的時候，伺服器運行一個應用程序，訪問所需要的信息，並創建一個文檔，伺服器於是將該文檔返回給瀏覽器。動態文檔把任務放在伺服器一端，瀏覽器採用和靜態文檔同樣的方法訪問動態文檔。實際上，從瀏覽器的角度來看。動態文檔和靜態文檔是無區別的。由於動態文檔和靜態文檔都採用H T M L 編寫，瀏覽器不知道伺服器是從一個磁碟文件還是計算機程序中取得文檔。動態文檔的主要缺點是增加成本和不能顯示變化的信息。和靜態文檔類似，動態文檔在瀏覽器取得文檔後不會再改變。因此在信息發送給瀏覽器之後，文檔就開始過時。例如一個報告股市信息的動態文檔，由於股市信息變化迅速，當用戶訪問時文檔很快就過時。動態文檔的創建和訪問成本比靜態文檔昂貴。創建動態文檔的代價較高，因為動態文檔的創建者必須懂得如何寫程序。另外，程序必須仔細編寫和廣泛測試，以保證輸出的合法性。驗證這樣一個程序的正確性是很困難的，因為輸入可以包含不同來源的多種數據。動態文檔除了創建成本高，所需的硬體成本也較高，因為伺服器端需要更強大的計算機。最後取出動態文檔需要的時間稍多些，因為伺服器需要額外的時間去運行程序創建文檔。盡管在申請到達時動態文檔才創建，但信息可能很快過時，活動文檔相對於動態文檔的主要優點在於它持續更改信息的能力。例如，只有活動文檔能夠快速改變顯示以顯示動畫。更重要的是，活動文檔能夠直接訪問信息源並連續更改顯示。例如，一個顯示股市行情的活動文檔可以連續讀取股市信息，並且不需要用戶干預而自動修改顯示。活動文檔的主要缺點是創建和運行這種文檔所需的額外費用，同時缺少安全性。首先，活動文檔的顯示需要更復雜的瀏覽器軟體和一個強有力的計算機運行瀏覽器。另外，寫正確的活動文檔比寫其他畫面需要更多的編程技巧，所得到的結果文檔更難於測試。而且，由於活動文檔必須運行在客戶端而不是伺服器端，程序必須解決在不同客戶上的兼容性問題，最後，活動文檔存在著潛在的安全性問題，因為文檔既輸入信息又輸出信息。

⑽ APP伺服器的介紹

APP伺服器1（APP Server）是一個讓用戶接收從一個遠端網路存取伺服器上的象徵密， 其促使一個用戶 碼改變的工具。