smart-servlet 是一款实现了Servlet 3.1规范，支持多应用隔离部署的的 Web 容器。除此之外，smart-servlet 还是一款插件化容器，基于内置的沙箱环境确保 smart-servlet 拥有最精简的运行能力，用户还可以通过自定义插件扩展容器的服务能力。
![]()
开发这个项目的过程中会听到一些疑惑的声音：为什么要去开发 servlet 容器？现在还有人用 servlet 吗？
的确，都2021年了，10年前还是香饽饽的技术如今看上去有些过时了。但我认为这只是表象，至少目前几乎绝大多数的 Java 服务都还运行在 Tomcat、Undertow 等服务器上，依托的还是Servlet技术。只是这些服务器的性能瓶颈比较明显，以致于很多场景下被其他语言的解决方案所替代。
而 smart-servlet 要做的就是突破这一瓶颈，成为一款低延迟又具备高并发能力的服务器。
更新内容
本次发布的版本在功能方面相较之前没有太多变化，更多的在于对这个项目发展方向作了一些思考，同时代码设计进行相应的调整。
1. 关于插件的思考
![]()
曾经在做业务线开发时，经常出现其他团队提供的 api 包所依赖的三方包与自身系统冲突的情况。即使让对方在pom.xml中加一个简单的<scope>provided</scope>都是一种奢望，更无法期待有某位架构师能站出来统一公司的三方包管理。不得不埋头逐个排除，这种“不痛不痒”的小问题会持续困扰着一线开发。
最近花了一周时间去思考 Plugins 模块该如何设计。当未来更多的人参与进来提供丰富的插件包，smart-servlet 如何进行统筹管理，确保这些插件相互之间不干扰，毕竟包冲突是所有大型系统难解的痛。
为了避免这类问题发生在 smart-servlet 中，后续我们会用类加载器完全隔离插件之间的依赖。先后调研了 sofaark 和 springboot loader 的 fat jar 隔离机制，最终决定选择后者。
2. 关于架构的调整
这个版本的架构图较之前版本有了一些调整，原先的 ContainerRuntime 变成了ApplicationRuntime，ServletHTTPServlet 调整成了 ContainerRuntime。这不是简单的重命名，更多的是考虑定义的合理性，架构关系的设计和命名是否是相契合的。
除此之外，我理想中的 smart-servlet 应该是更具包容性。用户可以自由选择哪些请求走 Servlet 容器，哪些请求直接由 smart-http 作处理（如下代码）。彻底告别用 nginx 作反向代理的架构设计，这样的开发体验不香吗。
new HttpHandle() {
@Override
public void doHandle(HttpRequest request, HttpResponse response) {
if(isStaticRequest(request)){
//加载本地资源文件
...
}else{
//处理Servlet请求
containerRuntime.doHandle(request, response);
}
}
}
3. 其他更新内容
1、新增支持加载 HttpSessionListener 监听器。
2、将路由匹配算法定义为工具类 PathMatcherUtil；修复默认 ServletContext 空路径场景下的路由匹配 bug。
3、调整过滤器的执行逻辑。
4、优化输出流缓冲区设计，性能快到不敢相信。
5、优化资源文件加载策略，路径查找失败时尝试从classpath中获取。
6、优化类加载器的使用，Servlet 容器最不好伺候的大爷。
最后
最后祝大家新年快乐吧，并希望这个项目在 2021 年有个好的发展。开源不易，且行且珍惜！
