web服务器类型介绍？

web应用的运营都是基于web服务器的存在才能实现的。今天我们就一起来了解一下，目前比较常见的一些web服务器都有哪些类型。

1、Tomcat服务器

目前非常流行的Tomcat服务器是Apache-Jarkarta开源项目中的一个子项目，是一个小型、轻量级的支持JSP和Servlet技术的Web服务器，也是初学者学习开发JSP应用的选。

2、Resin服务器

Resin是Caucho公司的产品，是一个非常流行的支持Servlet和JSP的服务器，速度非常快。Resin本身包含了一个支持HTML的Web服务器，这使它不仅可以显示动态内容，而且显示静态内容的能力也毫不逊色，因此许多网站都是使用Resin服务器构建

3、JBoss服务器

JBoss是一个种遵从JavaEE规范的、开放源代码的、纯Java的EJB服务器，对于J2EE有很好的支持。JBoss采用JMLAPI实现软件模块的集成与管理，其核心服务又是提供EJB服务器，不包含Servlet和JSP的Web容器，不过它可以和Tomcat完美结合

4、WebSphere服务器

WebSphere是IBM公司的产品，可进一步细分为WebSpherePerformancePack、CacheManager和WebSphereApplicationServer等系列，其中WebSphereApplicationServer是基于Java的应用环境，可以运行于SunSolaris、WindowsNT等多种操作系统平台，用于建立、部署和管理Internet和IntranetWeb应用程序。

5、WebLogic服务器

WebLogic是BEA公司的产品(现在已经被Oracle收购)，可进一步细分为WebLogicServer、WebLogicEnterprise和WebLogicPortal等系列，其中WebLogicServer的功能特别强大。WebLogic支持企业级的、多层次的和完全分布式的Web应用，并且服务器的配置简单、界面友好。南邵java课程培训机构认为对于那些正在寻求能够提供Java平台所拥有的一切应用服务器的用户来说，WebLogic是一个十分理想的选择。

在Tomcat中部署Java Web应用程序有两种方式：静态部署和动态部署。

一、静态部署

静态部署指的是我们在服务器启动之前部署我们的程序，只有当服务器启动之后，我们的Web应用程序才能访问。以下3中方式都可以部署：

1、将PetWeb目录拷贝到$CATALINA_HOME\webapps下，然后启动服务器就可以了。这种方式比较简单，访问地址如下：http://localhost:8080/PetWeb/

2、这种方式可以不必将PetWeb目录拷贝到webapps下，直接在F:\部署。方法如下，更改$CATALINA_HOME\conf\serverxml文件，在<host>标签内添加<Context>标签，内容如下：

<Context docBase="F:/PetWeb" reloadable="false" path="/Pet"/>

其中reloadable="false"表示当应用程序中的内容发生更改之后服务器不会自动加载，这个属性在开发阶段通常都设为true，方便开发，在发布阶段应该设置为false，提高应用程序的访问速度。docBase为路径，可以使用绝对路径，也可以使用相对路径，相对路径相对于webapps。path属性的值是访问时的根地址。访问地址如下：http://localhost:8080/Pet/ 。

3、这种方式和第二种方式差不多，但是不是在Serverxml文件中添加Context标签，而是在$CATALINA_HOME\conf\Catalina\localhost中添加一个xml文件，如Petxml，内容如下：

<Context

docBase="F:/PetWeb" reloadable="false"

/>大家可能发现和第二种方式差不多，但是缺少了path属性，这种方式服务器会使用xml的名字作为path属性的值。访问地址如

下：http://localhost:8080/Pet/ 。

我们刚才是将PetWeb文件夹部署在了服务器中，我们知道可以将Web应用程序的内容打成war包，然后在部署在服务器上。

部署Petwar文件非常简单，将刚才有docBase="F:\PetWeb"更改为docBase="F:\Petwar"或者直接将其拷贝到

webapps下也可以。重新启动服务器就可以将Petwar部署为一个Web应用程序了。如果你够细心的话你会发现，服务器将Petwar文件解开，并且在webapps下面又生成了一个Pet文件夹，然后把Petwar的内容拷贝到里面去了。我们可以通过以下方式取消自动解包，配置方式如下：

<Context

docBase="F:/PetWeb" reloadable="false" unpackWAR="false"/> 。

JavaWeb Tomcat服务器配置过程如下：

Tomcat服务器端口的配置

　　Tomcat的所有配置都放在conf文件夹之中，里面的serverxml文件是配置的核心文件。如果想修改Tomcat服务器的启动端口，则可以在serverxml配置文件中的Connector节点进行的端口修改

例如：将Tomcat服务器的启动端口由默认的8080改成8081端口

Tomcat服务器启动端口默认配置

1 <Connector port="8080" protocol="HTTP/11"

2                connectionTimeout="20000"

3                redirectPort="8443" />

将Tomcat服务器启动端口修改成8081端口

1 <Connector port="8081" protocol="HTTP/11"

2                connectionTimeout="20000"

3                redirectPort="8443" />

　　这样就把原来默认Tomcat默认的的8080端口改成了8081端口了，需要注意的是，一旦服务器中的xml文件改变了，则Tomcat服务器就必须重新启动，重新启动之后将重新读取新的配置信息。因为已经在serverxml文件中将Tomcat的启动端口修改成了8081，所以Tomcat服务器启动时就以8081端口启动了，如下图所示：

1、首先打开eclipse程序，在下端工具栏内，找到server按钮

2、点击打开server界面，可以看到所要部署的Tomcat工程服务

3、选择对于的服务，点击右键选择open，或者直接双击，打开overview详情配置页面

4、在overview界面可以看到相关的服务配置信息，查看Server Location，其中有两个路径信息，一个server path是Tomact服务路径，一个是Deploy path发布路径，根据Tomcat服务路径和发布路径，可以找到工程发布的位置

web应用服务器是互联网时代最为重要之一的底层支持。它处理相应的应用访问请求，并为前端提供相应的展示数据。

不同的web应用服务器实现性能不同，大型网站服务器可以每秒处理几万到几十万的应用请求，中小型网站服务器可能会因为每秒几千次请求停机。

从架构的角度上而言，web-server的升级是一个迭代的过程，只有现在的应用服务器无法满足网站的访问量，才会在此之上进行优化。对于一名好的架构师而言，落地和防灾、可扩展是优先需要考虑的相关事宜。

首先要说的是软件开发是一个确定性的事件， 有章可循，有理可溯 ，任何现象都是可以被解释的，这是入门级程序员和高级程序员的区别之处。

我们以这种思路自顶向下去分析解决问题。

以主流的JavaEE为例，传统的应用开发两个较为核心的工作内容是：

这可能会涉及持续化集成、自动化测试、测试驱动开发概念。

在这之后，可能还会存在的工作是：

在这个过程中，可能会涉及封装、基类、工具类、反射、泛型的概念。

从上面可以看出，软件开发是一件团队合作的事情。应该由 不同的人员去从事不同的事情 。传统项目的分工基本如下（基于个人主观猜测）：

目前比较主流的web应用框架是以spring-boot为主的微服务框架。对于上面说的三个事情而言，重要的是 把其中任何一件事情当作一个工程去做，赋予一个合适的时间周期。 这部分内容在预研过程中非常关键，前期未考虑到的因素后期再修改代价可能为 指数级 。

以spring-boot为主，结合mysql搭建web应用服务器的例子github上有很多，在这里不再赘述。

从客户端传递到服务器，响应时间由以下三个部分组成：

当出现应用响应时间过高这个问题时，对于相关人员，首先需要做的是：

对上面三个部分进行测试，分析它们分别所消耗的时间，然后再对此进行优化。 做到有的放矢，不要四处放枪 。

当我们开发完应用程序之后，该如何进行应用的部署呢？怎样的部署才能够保证服务器的处理时间较短？

下面我们讨论单个tomcatweb应用服务器和多个tomcatweb应用服务器。

通过spring boot 创建web应用有两种方式：war包与jar包。在本文中以war包为例。

servlet解析web请求过程：

tomcat作为servlet容器的一种，管理着部署的多个web应用。tomcat运行架构图如下：

从上图中可以看出：

所以由于每个web应用只创建了一个servlet实例，所以需要线程安全问题。（即servlet中包含静态变量和成员变量的时候会出现线程安全的问题。应该使用局部变量。）

tomcat 并发模型

从单个tomcat运行web应用中可以看出：

java web通过封装servlet屏蔽了服务细节，使web开发人员专注与业务逻辑的实现。这是j2ee能在web开发中有一定地位的原因。

然而，由于servlet的创建和tomcat 多线程的并发处理全部交由tomcat来做，在这一个层次程序员无法做太多的事情，只能对tomcat和jvm进行调优。

万幸的是cpu不是系统性能的瓶颈。但是目前有很多的游戏已经使用goroutine来实现了。因为golang的协程可以开上万个，非常适合多线程的处理。

在一些大型网站中，对这部分性能调优的解决方案有：

第二种方案就引入了多tomcat web应用服务器。它的思路是：

在云计算尚未出现时，负载均衡及容器的维护往往由内部的技术部自行实现，在云计算时代，由于K8S和Docker的出现，使这类问题解决更为容易。

K8S的弹性伸缩，把容器进行拷贝复制，并自动负责负载均衡，可以大大简化其流程。

ps：在K8S上运行的多个tomcat容器是相同的拷贝。

淘宝的例子

从传统的意义上讲，系统的性能瓶颈并不存在于cpu的计算能力，而在于I/O。

所以大型网站架构上通常在思考如何降低I/O的时间。

最常用的降低I/O时间是使用reddis和memcached做缓存，关于这块前辈的经验摘引如下:

安全内容博大精深，关于安全方面相关的一些基本的认知链接如下：

web application security

另外，如果对于java 而言，可以使用一个apache的安全框架

shiro

此外还有一些诸如分布式文件存储、加快服务器脚本运算速度、页面组件分离等都是提高服务器响应的方法。

在web开发中，cookie和seesion经常用到。接下来进行简单的说明。cookie和session主要是用来保存数据及状态。

cookie 和session 的区别：

建议：

cookie和session可以解决跨页面传递数据的问题。

前端跨页面传递数据是一个比较繁琐的问题，依赖于浏览器的架构和实现。cookie和session是一种通用的解决方案。

一、静态部署

1、直接将web项目文件件拷贝到webapps 目录中

Tomcat的Webapps目录是Tomcat默认的应用目录，当服务器启动时，会加载所有这个目录下的应用。所以可以将JSP程序打包成一个 war包放在目录下，服务器会自动解开这个war包，并在这个目录下生成一个同名的文件夹。一个war包就是有特性格式的jar包，它是将一个web程序的所有内容进行压缩得到。具体如何打包，可以使用许多开发工具的IDE环境，如Eclipse等。也可以用 cmd 命令：jar -cvf mywarwar myweb

webapps这个默认的应用目录也是可以改变。打开Tomcat的conf目录下的serverxml文件，找到下面内容：

<Host name="localhost" appBase="webapps"

unpackWARs="true" autoDeploy="true"

xmlValidation="false" xmlNamespaceAware="false">

将appBase修改即可。

2、在serverxml中指定

在Tomcat的配置文件中，一个Web应用就是一个特定的Context，可以通过在serverxml中新建Context里部署一个JSP应用程序。打开serverxml文件，在Host标签内建一个Context，内容如下。

在tomcat中的conf目录中，在serverxml中的，<host/>节点中添加：

<Context path="/hello" docBase="D:\ workspace\hello\WebRoot" debug="0" privileged="true">

</Context>

或者

<Context path="/myapp" reloadable="true" docBase="D:\myapp" workDir="D:\myapp\work"/>

或者

<Context path="/sms4" docBase="D:\workspace\sms4\WebRoot"/>

说明：

path是虚拟路径；

docBase 是应用程序的物理路径；

workDir 是这个应用的工作目录，存放运行时生成的与这个应用相关的文件；

debug 则是设定debug level, 0表示提供最少的信息，9表示提供最多的信息

privileged设置为true的时候，才允许Tomcat的Web应用使用容器内的Servlet

reloadable 如果为true，则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化，自动装载新的应用程序，可以在不重起tomcat的情况下改变应用程序，实现热部署

antiResourceLocking和antiJARLocking 热部署是需要配置的参数，默认false避免更新了某个webapp，有时候Tomcat并不能把旧的webapp完全删除，通常会留下WEB-INF/lib下的某个jar包，必须关闭Tomcat才能删除，这就导致自动部署失败。设置为true，Tomcat在运行对应的webapp时，会把相应的源文件和jar文件复制到一个临时目录里。

3、创建一个Context文件

在conf目录中，新建 Catalina＼localhost目录，在该目录中新建一个xml文件，名字不可以随意取，要和path后的那个名字一致，按照下边这个path的配置，xml的名字应该就应该是hello（helloxml），该xml文件的内容为：

<Context path="/hello" docBase="E:\workspace\hello\WebRoot" debug="0" privileged="true"></Context>

tomcat自带例子如下：

<Context docBase="${catalinahome}/server/webapps/host-manager"

privileged="true" antiResourceLocking="false" antiJARLocking="false">

</Context>

这个例子是tomcat自带的，编辑的内容实际上和第二种方式是一样的，其中这xml文件名字就是访问路径，这样可以隐藏应用的真实名字。

4、注意：

删除一个Web应用同时也要删除webapps下相应的文件夹和serverxml中相应的Context，还要将Tomcat的conf\catalina\localhost目录下相应的xml文件删除，否则Tomcat仍会去配置并加载。。。

二 动态部署

登陆tomcat管理控制台：http://localhost:8080/，输入用户名和密码后便可管理应用并动态发布。

在Context Path(option):中输入/yourwebname ，这代表你的应用的访问地址。

XML Configration file URL中要指定一个xml文件，比如我们在F:\下建立一个hmcxxml文件，内容如下： <Context reloadable="false" />其中docBase不用写了，因为在下一个文本框中填入。或者更简单点，这个文本框什么都不填，在WAR or Directory URL:中键入F:\hmcx即可，然后点击Deploy按钮，上面就可以看到了web应用程序，名字就Context Path(option):中的名字。

如果部署war文件还有更加简单的方式，下面还有个Select WAR file uploae点击浏览选择war文件，然后点击Deploy也可以。