Jetty 服务器架构分析(中)

喜欢ヅ旅行 2022-09-29 04:14 217阅读 0赞

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

![0_12984479401W4N.gif][]

这里可以看到 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 开始的，我们来看一下服务器真正的启动过程。

![0_1298448028K0pz.gif][]

从上图中我们能大概看出服务器启动过程，先是由用户设置好需要的核心组件，然后调用 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 为例 )

![0_1298448174O1GG.gif][]

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); \}

![0_1298448271hk3v.gif][]

最后再分配 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 启动过程

![0_12984484141BXx.gif][]

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

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

[0_12984479401W4N.gif]: /images/20220708/645db5f2d8014d338ea6c5477ec60b07.png
[0_1298448028K0pz.gif]: /images/20220708/755af873c8cf466e8bce9fdb884a19eb.png
[0_1298448174O1GG.gif]: /images/20220708/fad9dded5c694e2baa4ddebfd2dc0d25.png
[0_1298448271hk3v.gif]: /images/20220708/639df65aa6a04a1a80e9fd50f45b26a6.png
[0_12984484141BXx.gif]: /images/20220708/a232ee1d11504f4c8ccaac715a04a3bd.png