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）是一个让用户接收从一个远端网络存取服务器上的象征密， 其促使一个用户 码改变的工具。