Jetty 服务器架构分析(中)【转】

接上一篇，说到XmlConfiguration ,XmlConfiguration 利用自己实现的 IOC 组装 Server 的全过程如下图所示：

这里可以看到 3 个关键的配置文件， jetty.xml 、 jetty-deploy.xml 、以及 contexts/xxx.xml

 

l  Jetty.xml 文件中定义了入口类 Server, 以及其所需要的线程池、 Connector 、 Handler 。

l  Jetty-deploy.xml 中则定义了部署 web 应用用到部署工具，在其中指定了部署 web 应用的两种方式，类似于 tomcat, 如果采用 webappProvider ，则表示将 web 应用放在 webapp 下即可生效，如果采用 ContextProvider ，则需要定义 Contexts 目录所在位置，只要在该目录下放置任何应用的 context 配置文件就可以生效。

l  Xxx.xml 这是一个用户自定义文件，表示采用 ContextProvider 时，在其中定义一个 WebAppContext 的 handler, 它指定了我们应用所在的位置，便于加载。

 

XmlConfiguration 解析装配完毕之后，就开始启动服务， Jetty 的启动是从 Server 开始的，我们来看一下服务器真正的启动过程。

从上图中我们能大概看出服务器启动过程，先是由用户设置好需要的核心组件，然后调用 Server.start() 开始启动服务，其中会首先启动 handler 处理器，之后启动用户自定义组件，这个自定义组件需要实现 LifeCyle 接口，最后才启动 Connector 接受请求。可以想到，关闭过程恰好是反过来，首先关闭接受请求的 connector ，然后再关闭用户自定义组件，最后关闭 handler.

         我们再来详细看一下 Server 源代码的核心实现过程，当调用 start 方法时，其实是调用其祖先类 AbstractLifeCycle 中方法，该方法在这里有一个模板实现，如下：

public
 
final
 
void
 start() 
throws
 Exception
   {
       synchronized
 (_lock)
       {
           try
           {
               if
 (_state == __STARTED || _state == __STARTING)
                   return
;
               setStarting();
               doStart();
               setStarted();
           }
           catch
 (Exception e)
           {
               setFailed(e);
               throw
 e;
           }
           catch
 (Error e)
           {
               setFailed(e);
               throw
 e;
           }
       }

• Connector 启动过程

 

看下 Connector 的详细启动过程： ( 以 NIO 为例 )

NIOConnector 启动过程中，先创建了多个 SelectSet 对象，每个 SelectSet 负责一个 NIO 的 Selector ，专门用于监听 read 事件 ( 这里利用的多线程 Reactor 模式， http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf ) ，当然这里仅仅是创建了对象，并没有启动，后面会提到。

SelectorManager ：

 

然后再调用 open 创建了一个 blocking 的阻塞 channel ，专门用于接受用户的新连接，我们看下：

public
 
void
 open() throws IOException
   {
       synchronized(this
)
       {
           if
 (_acceptChannel == 
null
)
           {
               // Create a new server socket
               _acceptChannel = ServerSocketChannel.open();
               // Set to blocking mode
               _acceptChannel.configureBlocking(true
);
               // Bind the server socket to the local host and port
               _acceptChannel.socket().setReuseAddress(getReuseAddress());
               InetSocketAddress addr = getHost()==null
?
new
 InetSocketAddress(getPort()):
new
 InetSocketAddress(getHost(),getPort());
         _acceptChannel.socket().bind(addr,getAcceptQueueSize());
               _localPort=_acceptChannel.socket().getLocalPort();
               if
 (_localPort<=0)
                   throw
 
new
 IOException(
"Server channel not bound"
);
           }
       }

 

随后从线程池中分配了 N 个 ( 可以在配置文件中配置 ) 线程用于启动 SelectSet 监听 read 事件。

synchronized (
this
)
        {
            _acceptorThread = new
 Thread[getAcceptors()];
            for
 (
int
 i = 0; i < _acceptorThread.length; i++)
                _threadPool.dispatch(new
 Acceptor(i));
            if
 (_threadPool.isLowOnThreads())
                Log.warn("insufficient threads configured for {}"
,
this
);
        }

最后再分配 1 个线程用于 accept 用户的新连接，新连接来之后，会将其设置为 nonblocking 模式，之后就将其 Register 给某个 SelectSet 去监听 read 事件，然后又返回来继续监听新连接：

_manager.dispatch(
new
 Runnable()
        {
            public
 
void
 run()
            {
                final ServerSocketChannel server=_acceptChannel;
                while
 (isRunning() && _acceptChannel==server && server.isOpen())
                {
                    try
                    {
                        SocketChannel channel = server.accept();
                        channel.configureBlocking(false
);
                        Socket socket = channel.socket();
                        configure(socket);
                        _manager.register(channel);
                    }
                    catch
(IOException e)
                    {
                        Log.ignore(e);
                    }
                }
            }
        });

• Handler 启动过程

 

Jetty 将所有的真正处理请求的动作都抽象成了 Handler ，因此做事情的组件都是实现了这个接口的，包括上图所示的 WebAppContext 等等，需要做什么样的工作，那么就添加什么样的 Handler ，这里 SessionHandler 不是必须的，但是默认是创建好的。 ServletHandler 主要负责处理 web 应用的 Servlet 、 Filter 等工作，最后将请求直接交给 Servlet 、 Filter 都是在这里完成。

   这里展示的 Handler 的启动过程其实是在准备 web 应用环境，例如解析 web 应用的 web.xml 等等工作，做好一切准备工作。