中间件（英语：middleware）是提供系统软件和应用软件之间连接的软件，以便于软件各部件之间的沟通。中间件处在操作系统和更高一级应用程序之间。他充当的功能是：将应用程序运行环境与操作系统隔离，从而实现应用程序开发者不必为更多系统问题忧虑，而直接关注该应用程序在解决问题上的能力 。容器就是中间件的一种。
也就是说，关于中间件，我们可以理解为：是一类能够为一种或多种应用程序合作互通、资源共享，同时还能够为该应用程序提供相关的服务的软件。（注意：中间件是一类软件的总称，不是单独的一个软件）
我们经常管web中间件叫做web服务器或者web容器
正常情况下一次web的访问顺序是：web浏览器---服务器(硬件)---web容器---web应用服务器---数据库服务器。
tomcat
tomcat 是apache 软件基金会（apache software foundation）的jakarta 项目中的一个核心项目，由apache、sun 和其他一些公司及个人共同开发而成。因为tomcat 技术先进、性能稳定，而且免费，因而深受java 爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的java web 应用服务器(servlet 容器)。实际上tomcat 部分是apache 服务器的扩展，但它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与apache 独立的进程单独运行的。tomcat 服务器是一个免费的开放源代码的web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试jsp 程序的首选。tomcat默认使用 8080 号端口
weblogic 是美国oracle公司出品的一个application server，确切的说是一个基于javaee架构的中间件，weblogic是用于开发、集成、部署和管理大型分布式web应用、网络应用和数据库应用的java应用服务器。将java的动态功能和java enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。weblogic默认端口是 7001。
jboss 是一个基于java ee的开放源代码的应用服务器。 它不但是servlet容器，而且也是ejb容器，从而受到企业级开发人员的欢迎，从而弥补了tomcat只是一个servlet容器的缺憾。jboss是一个管理ejb的容器和服务器。但jboss核心服务不包括支持 servlet/jsp 的web容器，一般与 tomcat 或 jetty 绑定使用。jboss默认端口号是8080。
jetty 是一个开源的servlet容器，它为基于java的web容器，例如jsp和servlet提供运行环境。jetty是使用java编写的，它的api以一组jar包的形式发布。开发人员可以将jetty容器实例化成一个对象，可以迅速为一些独立运行（stand-alone）的java应用提供网络和web连接。
webshere 是 ibm 的软件平台。它包含了编写、运行和监视全天候的工业强度的随需应变 web 应用程序和跨平台、跨产品ag真人游戏的解决方案所需要的整个中间件基础设施，如服务器、服务和工具。websphere 提供了可靠、灵活和健壮的软件。websphere 是一个模块化的平台，基于业界支持的开放标准。可以通过受信任和持久的接口，将现有资产插入 websphere，可以继续扩展环境。websphere 可以在许多平台上运行，包括 intel、linux 和 z/os。webshere默认端口号是 9080。
glassfish 是一款强健的商业兼容应用服务器，达到产品级质量，可免费用于开发、部署和重新分发。开发者可以免费获得源代码，还可以对代码进行更改。
3.1tomcat
3.1.1概念
tomcat 服务器是一个开源的轻量级web应用服务器，在中小型系统和并发量小的场合下被普遍使用，是开发和调试servlet、jsp 程序的首选。
3.1.2 原理
tomcat结构图：
tomcat主要组件：服务器server，服务service，连接器connector、容器container。连接器connector和容器container是tomcat的核心。
一个container容器和一个或多个connector组合在一起，加上其他一些支持的组件共同组成一个service服务，有了service服务便可以对外提供能力了，但是service服务的生存需要一个环境，这个环境便是server，server组件为service服务的正常使用提供了生存环境，server组件可以同时管理一个或多个service服务。
3.1.3两大组件
1、connector
一个connecter将在某个指定的端口上侦听客户请求，接收浏览器的发过来的 tcp 连接请求，创建一个 request 和 response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 request 和 response 对象传给处理engine(container中的一部分)，从engine出获得响应并返回客户。
tomcat中有两个经典的connector，一个直接侦听来自browser的http请求，另外一个来自其他的webserver请求。http/1.1 connector在端口8080处侦听来自客户browser的http请求，ajp/1.3 connector在端口8009处侦听其他web server（其他的http服务器）的servlet/jsp请求。
connector 最重要的功能就是接收连接请求然后分配线程让 container 来处理这个请求，所以这必然是多线程的，多线程的处理是 connector 设计的核心。
2、container
container是容器的父接口，该容器的设计用的是典型的责任链的设计模式，它由四个自容器组件构成，分别是engine、host、context、wrapper。这四个组件是负责关系，存在包含关系。通常一个servlet class对应一个wrapper，如果有多个servlet定义多个wrapper，如果有多个wrapper就要定义一个更高的container，如context。
context 还可以定义在父容器 host 中，host 不是必须的，但是要运行 war 程序，就必须要 host，因为 war 中必有 web.xml 文件，这个文件的解析就需要 host 了，如果要有多个 host 就要定义一个 top 容器 engine 了。而 engine 没有父容器了，一个 engine 代表一个完整的 servlet 引擎。
- engine 容器
engine 容器比较简单，它只定义了一些基本的关联关系 - host 容器
host 是 engine 的子容器，一个 host 在 engine 中代表一个虚拟主机，这个虚拟主机的作用就是运行多个应用，它负责安装和展开这些应用，并且标识这个应用以便能够区分它们。它的子容器通常是 context，它除了关联子容器外，还有就是保存一个主机应该有的信息。 - context 容器
context 代表 servlet 的 context，它具备了 servlet 运行的基本环境，理论上只要有 context 就能运行 servlet 了。简单的 tomcat 可以没有 engine 和 host。context 最重要的功能就是管理它里面的 servlet 实例，servlet 实例在 context 中是以 wrapper 出现的，还有一点就是 context 如何才能找到正确的 servlet 来执行它呢？ tomcat5 以前是通过一个 mapper 类来管理的，tomcat5 以后这个功能被移到了 request 中，在前面的时序图中就可以发现获取子容器都是通过 request 来分配的。 - wrapper 容器
wrapper 代表一个 servlet，它负责管理一个 servlet，包括的 servlet 的装载、初始化、执行以及资源回收。wrapper 是最底层的容器，它没有子容器了，所以调用它的 addchild 将会报错。
wrapper 的实现类是 standardwrapper，standardwrapper 还实现了拥有一个 servlet 初始化信息的 servletconfig，由此看出 standardwrapper 将直接和 servlet 的各种信息打交道。
3、其他组件
tomcat 还有其它重要的组件，如安全组件 security、logger 日志组件、session、mbeans、naming 等其它组件。这些组件共同为 connector 和 container 提供必要的服务。
3.1.4 http请求过程
tomcat server处理一个http请求的过程
1、用户点击网页内容，请求被发送到本机端口8080，被在那里监听的coyote http/1.1 connector获得。
2、connector把该请求交给它所在的service的engine来处理，并等待engine的回应。
3、engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机host。
4、engine匹配到名为localhost的host（即使匹配不到也把请求交给该host处理，因为该host被定义为该engine的默认主机），名为localhost的host获得请求/test/index.jsp，匹配它所拥有的所有的context。host匹配到路径为/test的context（如果匹配不到就把该请求交给路径名为“ ”的context去处理）。
5、path=“/test”的context获得请求/index.jsp，在它的mapping table中寻找出对应的servlet。context匹配到url pattern为*.jsp的servlet,对应于jspservlet类。
6、构造httpservletrequest对象和httpservletresponse对象，作为参数调用jspservlet的doget（）或dopost（）.执行业务逻辑、数据存储等程序。
7、context把执行完之后的httpservletresponse对象返回给host。
8、host把httpservletresponse对象返回给engine。
9、engine把httpservletresponse对象返回connector。
10、connector把httpservletresponse对象返回给客户browser。
3.2 jetty
3.2.1 什么是jetty?
简单来讲jetty就是一个开源http服务器和servlet引擎，它可以为jsp和servlet提供运行时环境。比如java web应用最常用的servlet容器和tomcat。由于其轻量、灵活的特性，jetty也被应用于一些知名产品中，例如activemq、maven、spark、gooleappengine、eclipse、hadoop等。
3.2.2 为什么使用jetty？
1.异步的servlet，支持更高的并发量。
2.模块化的设计，更灵活，更容易定制，也意味着更高的资源利用率。
3.在面对大量长连接的业务场景下，jetty默认采用的nio模型是更好的选择。
将jetty嵌入到应用中，使一个普通应用可以快速支持http服务。
3.2.3 与tomcat的对比
jetty比较容易贴合第三方框架，比如你可以直接用spring配置一个jetty服务器
直接将jetty作为提供http服务的组件，嵌入到应用中
jetty是面向handler的架构，而tomcat是面向容器的架构
jetty默认采用nio技术，而tomcat默认是bio
jetty高度模块化，可以很灵活的管理拓展组件，而tomcat对其他组件的管理则相对困难
3.2.4 jetty的基本架构
3.2.5 jetty的项目结构
3.3 nginx
3.3.1代理服务器
nginx就是反向代理服务器。
首先我们先来看看什么是代理服务器，代理服务器一般是指局域网内部的机器通过代理服务发送请求到互联网上的服务器，代理服务器一般作用于客户端。比如goagent，fq神器。
一个完整的代理请求过程为：客户端首先与代理服务器创建连接，然后根据代理服务器所使用的代理协议，请求对目标服务器创建连接、或则获得目标服务器的指定资源。web代理服务器是网络的中间实体。代理位于web客户端和web服务器之间，扮演“中间人”的角色。
http的代理服务器既是web服务器又是web客户端。
代理服务器是介于客户端和web服务器之间的另一台服务器，有了它之后，浏览器不是直接到web服务器去取回网页，而是通过向代理服务器发送请求，信号会先送到代理服务器，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。
正向代理是一个位于客户端和原始服务器之间的服务器，为了从原始服务器取的内容，客户端向代理发送一个请求并指定目标（原始服务器），然后代理向原始服务器转交请求并将获得的内容返回给客户端，客户端必须要进行一些特别的设置才能使用正向代理。
反向代理服务器：在服务器端接收客户端的请求，然后把请求分发给具体的服务器进行处理，然后再将服务器的响应结果反馈给客户端。nginx就是其中的一种反向代理服务器软件。
nginx：nginx（“engine x”），nginx是俄罗斯人igor sysoev(塞索耶夫)编写的一款高性能的 http 和反向代理服务器。也是一个imap/pop3/smtp代理服务器，也就是说，nginx本身就可以托管网站，进行http服务处理，也可以作为反向代理服务器使用。
正向代理客户端必须设置正向代理服务器，当然前提是要知道正向代理服务器的ip地址，还有代理程序的端口。
反向代理正好与正向代理相反，对于客户端而言代理服务器就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间中的内容发送普通请求，接着反向代理将判断向哪个原始服务器转交请求，并将获得的内容返回给客户端。
用户a始终认为它访问的是原始服务器b而不是代理服务器z，但实际上反向代理服务器接受用户a的应答，
从原始资源服务器b中取得用户a的需求资源，然后发送给用户a。由于防火墙的作用，只允许代理服务器z访问原始资源服务器b。尽管在这个虚拟的环境下，防火墙和反向代理的共同作用保护了原始资源服务器b，但用户a并不知情。
简单的说：
正向代理：客户端知道服务器端，通过代理端连接服务器端。代理端代理的是服务器端。
反向代理：所谓反向，是对正向而言的。服务器端知道客户端，客户端不知道服务器端，通过代理端连接服务器端。代理端代理的是客户端。代理对象刚好相反，所以叫反向代理。
3.3.2.nginx的应用现状
nginx 已经在俄罗斯最大的门户网站── rambler media（www.rambler.ru）上运行了很多年，同时俄罗斯超过20%的虚拟主机平台采用nginx作为反向代理服务器。
在国内，已经有 淘宝、新浪博客、新浪播客、网易新闻、六间房、56.com、discuz!、水木社区、豆瓣、yupoo、海内、迅雷在线 等多家网站使用 nginx 作为web服务器或反向代理服务器。
3.3.3.nginx的特点
（1）跨平台：nginx 可以在大多数 unix like os编译运行，而且也有windows的移植版本。
（2）配置异常简单，非常容易上手。配置风格跟程序开发一样，神一般的配置
（3）非阻塞、高并发连接：数据复制时，磁盘i/o的第一阶段是非阻塞的。官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数.(这得益于nginx使用了最新的epoll模型)
（4）事件驱动：通信机制采用epoll模型，支持更大的并发连接。
（5）master/worker结构：一个master进程，生成一个或多个worker进程
（6）内存消耗小：处理大并发的请求内存消耗非常小。在3万并发连接下，开启的10个nginx 进程才消耗150m内存（15m*10=150m）
（7）成本低廉：nginx为开源软件，可以免费使用。而购买f5 big-ip、netscaler等硬件负载均衡交换机则需要十多万至几十万人民币
（8）内置的健康检查功能：如果 nginx proxy 后端的某台 web 服务器宕机了，不会影响前端访问。
（9）节省带宽：支持 gzip 压缩，可以添加浏览器本地缓存的 header 头。
（10）稳定性高：用于反向代理，宕机的概率微乎其微
如何使用事件驱动呢？
nginx的事件处理机制：
对于一个基本的web服务器来说，事件通常有三种类型，网络事件、信号、定时器。
首先看一个请求的基本过程：建立连接---接收数据---发送数据 。
再次看系统底层的操作 ：上述过程（建立连接---接收数据---发送数据）在系统底层就是读写事件。
1）如果采用阻塞调用的方式，当读写事件没有准备好时，必然不能够进行读写事件，那么久只好等待，等事件准备好了，才能进行读写事件。那么请求就会被耽搁 。阻塞调用会进入内核等待，cpu就会让出去给别人用了，对单线程的worker来说，显然不合适，当网络事 件越多时，大家都在等待呢，cpu空闲下来没人用，cpu利用率自然上不去了，更别谈高并发了 。
2）既然没有准备好阻塞调用不行，那么采用非阻塞方式。非阻塞就是，事件，马上返回eagain，告诉你，事件还没准备好呢，你慌什么，过会再来吧。好吧，你过一会，再来检查一下事件，直到事件准备好了为止，在这期间，你就可以先去做其它事情，然后再来看看事 件好了没。虽然不阻塞了，但你得不时地过来检查一下事件的状态，你可以做更多的事情了，但带来的开销也是不小的
小结：非阻塞通过不断检查事件的状态来判断是否进行读写操作，这样带来的开销很大。
3）因此才有了异步非阻塞的事件处理机制。具体到系统调用就是像select/poll/epoll/kqueue这样的系统调用。他们提供了一种机制，让你可以同时监控多个事件，调用他们是阻塞的，但可以设置超时时间，在超时时间之内，如果有事件准备好了，就返回。这种机制解决了我们上面两个问题。
以epoll为例：当事件没有准备好时，就放入epoll(队列)里面。如果有事件准备好了，那么就去处理；如果事件返回的是eagain，那么继续将其放入epoll里面。从而，只要有事件准备好了，我们就去处理她，只有当所有时间都没有准备好时，才在epoll里面等着。这样 ，我们就可以并发处理大量的并发了，当然，这里的并发请求，是指未处理完的请求，线程只有一个，所以同时能处理的请求当然只有一个了，只是在请求间进行不断地切换而已，切换也是因为异步事件未准备好，而主动让出的。这里的切换是没有任何代价，你可以理 解为循环处理多个准备好的事件，事实上就是这样的。
4）与多线程的比较：
与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费（上下文切换）。
小结：通过异步非阻塞的事件处理机制，nginx实现由进程循环处理多个准备好的事件，从而实现高并发和轻量级。
3.3.4.nginx的不为人知的特点
（1）nginx代理和后端web服务器间无需长连接；
（2）接收用户请求是异步的，即先将用户请求全部接收下来，再一次性发送后后端web服务器，极大的减轻后端web服务器的压力
（3）发送响应报文时，是边接收来自后端web服务器的数据，边发送给客户端的
（4）网络依赖型低。nginx对网络的依赖程度非常低，理论上讲，只要能够ping通就可以实施负载均衡，而且可以有效区分内网和外网流量
（5）支持服务器检测。nginx能够根据应用服务器处理页面返回的状态码、超时信息等检测服务器是否出现故障，并及时返回错误的请求重新提交到其它节点上
3.3.5.nginx的内部(进程)模型
nginx是以多进程的方式来工作的，当然nginx也是支持多线程的方式的,只是我们主流的方式还是多进程的方式，也是nginx的默认方式。nginx采用多进程的方式有诸多好处 .
(1) nginx在启动后，会有一个master进程和多个worker进程。master进程主要用来管理worker进程，包含：接收来自外界的信号，向各worker进程发送信号，监控 worker进程的运行状态,当worker进程退出后(异常情况下)，会自动重新启动新的worker进程。而基本的网 络事件，则是放在worker进程中来处理了 。多个worker进程之间是对等的，他们同等竞争来自客户端的请求，各进程互相之间是独立的 。一个请求，只可能在一个worker进程中处理，一个worker进程，不可能处理其它进程的请求。 worker进程的个数是可以设置的，一般我们会设置与机器cpu核数一致，这里面的原因与nginx的进程模型以及事件处理模型是分不开的 。
(2)master接收到信号以后怎样进行处理（./nginx -s reload ）?首先master进程在接到信号后，会先重新加载配置文件，然后再启动新的进程，并向所有老的进程发送信号，告诉他们可以光荣退休了。新的进程在启动后，就开始接收新的请求，而老的进程在收到来自 master的信号后，就不再接收新的请求，并且在当前进程中的所有未处理完的请求处理完成后，再退出 .
(3) worker进程又是如何处理请求的呢？我们前面有提到，worker进程之间是平等的，每个进程，处理请求的机会也是一样的。当我们提供80端口的http服务时，一个连接请求过来，每个进程都有可能处理这个连接，怎么做到的呢？首先，每个worker进程都是从master 进程fork(分配)过来，在master进程里面，先建立好需要listen的socket之后，然后再fork出多个worker进程，这样每个worker进程都可以去accept这个socket(当然不是同一个socket，只是每个进程的这个socket会监控在同一个ip地址与端口，这个在网络协议里面是允许的)。一般来说，当一个连接进来后，所有在accept在这个socket上面的进程，都会收到通知，而只有一个进程可以accept这个连接，其它的则accept失败，这是所谓的惊群现象。当然，nginx也不会视而不见，所以nginx提供了一个accept_mutex这个东西，从名字上，我们可以看这是一个加在accept上的一把共享锁。有了这把锁之后，同一时刻，就只会有一个进程在accpet连接，这样就不会有惊群问题了。accept_mutex是一个可控选项，我们可以显示地关掉，默认是打开的。当一个worker进程在accept这个连接之后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完整的请求就是这样的了。我们可以看到，一个请求，完全由worker进程来处理，而且只在一个worker进程中处理。
(4)nginx采用这种进程模型有什么好处呢？采用独立的进程，可以让互相之间不会影响，一个进程退出后，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。当然，worker进程的异常退出，肯定是程序有bug了，异常退出，会导致当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。当然，好处还有很多，大家可以慢慢体会。
(5)有人可能要问了，nginx采用多worker的方式来处理请求，每个worker里面只有一个主线程，那能够处理的并发数很有限啊，多少个worker就能处理多少个并发，何来高并发呢？非也，这就是nginx的高明之处，nginx采用了异步非阻塞的方式来处理请求，也就是说，nginx是可以同时处理成千上万个请求的 .对于iis服务器每个请求会独占一个工作线程，当并发数上到几千时，就同时有几千的线程在处理请求了。这对操作系统来说，是个不小的挑战，线程带来的内存占用非常大，线程的上下文切换带来的cpu开销很大，自然性能就上不去了，而这些开销完全是没有意义的。我们之前说过，推荐设置worker的个数为cpu的核数，在这里就很容易理解了，更多的worker数，只会导致进程来竞争cpu资源了，从而带来不必要的上下文切换。而且，nginx为了更好的利用多核特性，提供了cpu亲缘性的绑定选项，我们可以将某一个进程绑定在某一个核上，这样就不会因为进程的切换带来cache的失效
3.3.6.nginx是如何处理一个请求
首先，nginx在启动时，会解析配置文件，得到需要监听的端口与ip地址，然后在nginx的master进程里面，先初始化好这个监控的socket(创建socket，设置addrreuse等选项，绑定到指定的ip地址端口，再listen)，然后再fork(一个现有进程可以调用fork函数创建一个 新进程。由fork创建的新进程被称为子进程 )出多个子进程出来，然后子进程会竞争accept新的连接。此时，客户端就可以向nginx发起连接了。当客户端与nginx进行三次握手，与nginx建立好一个连接后，此时，某一个子进程会accept成功，得到这个建立好的连接的 socket，然后创建nginx对连接的封装，即ngx_connection_t结构体。接着，设置读写事件处理函数并添加读写事件来与客户端进行数据的交换。最后，nginx或客户端来主动关掉连接，到此，一个连接就寿终正寝了。
当然，nginx也是可以作为客户端来请求其它server的数据的（如upstream模块），此时，与其它server创建的连接，也封装在ngx_connection_t中。作为客户端，nginx先获取一个ngx_connection_t结构体，然后创建socket，并设置socket的属性（ 比如非阻塞）。然后再通过添加读写事件，调用connect/read/write来调用连接，最后关掉连接，并释放ngx_connection_t。
nginx在实现时，是通过一个连接池来管理的，每个worker进程都有一个独立的连接池，连接池的大小是worker_connections。这里的连接池里面保存的其实不是真实的连接，它只是一个worker_connections大小的一个ngx_connection_t结构的数组。并且，nginx会通过一个链表free_connections来保存所有的空闲ngx_connection_t，每次获取一个连接时，就从空闲连接链表中获取一个，用完后，再放回空闲连接链表里面。
在这里，很多人会误解worker_connections这个参数的意思，认为这个值就是nginx所能建立连接的最大值。其实不然，这个值是表示每个worker进程所能建立连接的最大值，所以，一个nginx能建立的最大连接数，应该是worker_connections * worker_processes。当然 ，这里说的是最大连接数，对于http请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes，而如果是http作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。