技术管理篇5一技术演变史(8)

上一篇我们聊了Web服务器到应用服务器的发展历程，今天以JavaEE的发展历程为代表，聊一下应用服务器的演变。

假设我们从头搭建一个Java的应用服务器。首先，我们得先实现网络接入部分，我们管这一层叫网络层。JDK封装了几个操作系统的网络模型，可以帮助到我们。尤其是NIO包，提供了高性能的网络支持。

通过网络层，我们接收的数据还是字节序列。我们还需要根据支持的网络协议，把字节数据翻译成应用能理解的数据。比如Http协议，我们要解析出哪些是Header数据，哪些是参数数据，哪些是上传的文件等等。我们管这一层叫协议层。

网络层和协议层相互独立，这样我们就可以灵活的在两个方面进行扩展，比如支持Http2等其他协议，再比如网络层也可以支持更高效的网络模型。

经过协议层之后，我们就得到了应用可理解的协议对象信息。我们可以理解为Request对象。下一步就是传递给业务处理层。作为一个服务器，我们应该把请求传递给谁呢。

服务器应该是可以同时运行多个应用程序的，每个应用程序可以对应不同的域名。我们怎么来区分呢？我们得有一套接口规则来区分服务器代码和业务代码，这有点像CGI。业务代码怎么被服务器加载进来呢，业务代码中哪些代码对应哪个请求呢，这都得有一个规范来描述。我们管这一层叫业务代码层，在JavaEE中就是War包的规范。

War包就是一个zip压缩包，他通过一系列约定，定义了一个可被加载的业务代码包。比如web.xml文件放在哪个目录下，class文件放在哪，jar包放在哪等等。

通过这个规范，服务器就能知道你这个业务代码怎么加载。不同的代码包之间是需要隔离的，这个怎么来做呢。我们得让不同的War文件可以加载到不同的命名空间下，这样才能做到互相之间的隔离。我们就需要为服务器设计单独的Class Loader体系了。

首先，服务器的公用代码是在父加载空间中的，这样可以保证各个业务包代码可以复用服务器的公用代码。然后，服务器为每个War包提供不同的加载器，这样就保证了不同War包之间的隔离。

在一个War包中，代码也会分为两部分。一部分是我们自己写的代码，一部分是引用的第三方的Jar包。为了避免第三方代码覆盖了我们自己的代码，War加载器会先加载class目录下我们自己的代码，然后再加载lib目录下第三方的代码。

解决了代码的隔离和覆盖问题，我们还得看一个请求到达后，怎么去路由处理。因为一个War包会对应很多请求Path，到底哪个Path执行哪段代码，我们得需要描述清楚。Web.xml文件中就清晰的描述了这个对应关系。

在Web.xml中，我们把请求Path映射到不同的Servlet上。当这个Path的请求到达后，服务器通过网络层和协议层，将请求的数据封装成Request对象。然后，通过域名和War包的对应关系描述，找到对应的War包，再通过War包里的Web.xml文件，找到对应的Servlet，最终运行执行。

有时候，我们需要在某些Path请求达到后，在Servlet处理之前做一些拦截处理，这就是Filter的概念。同样在Web.xml中，我们描述了各种Filter和Path的对应关系。

总结一下，我们把应用服务器分拆为网络层、协议层、业务代码层，逐层来简化服务器的设计，让服务器独立出来，开发者可以自由的编写自己的业务逻辑。