共计 2967 个字符，预计需要花费 8 分钟才能阅读完成。
转自：码农翻身（微信号：coderising）
我是 Servlet，由于很多框架把我深深地隐藏了起来，我变得似乎无关紧要了，很多人也选择性的把我给遗忘了。其实，我还活得好好的呢，只不过是从前台明星慢慢退居幕后而已。
好基友 Servlet + JSP
想当年我刚刚诞生的时候，无数人对我趋之若鹜。
因为那个时候 Web 服务器只能处理静态的 HTML 页面，图片，JavaScript 这样的东西，比如 Apache 这个著名的 Web 服务器。
人类想要看一点动态的内容，比如什么留言板，购物网站等，还得靠极为难用的 CGI。
我一出生，他们就欢呼着把 CGI 给抛弃，纷纷改用 Java 写 Servlet 程序，再后来我的好兄弟 JSP 问世，我们简直形成了绝配。
我负责控制，JSP 负责视图，再加上负责数据的 Java Bean，MVC 三驾马车正式形成，风靡一时，想当年，著名的开源论坛软件 Jive 就是我们的巅峰之作。
说起 JSP，这小子有时候还不太服我，经常振振有词地说：“你 Servlet 没什么了不起的，我也可以当 Controller！”
JSP 确实可以当 Controller，早些年我还真的见过，一个长达 6000 多行的 JSP，行使着 Controller 的职责，每当程序员要改这些代码就胆颤心惊，叫苦不迭。
其实 JSP 不知道，它本质上也就是 Servlet，JSP 只不过穿了一件漂亮的外衣，给了程序员们一个轻松写动态页面的工具而已，实际运行的时候会被编译成 Servlet 类，本质上我们是一样的。
我和 JSP 都生活在 Servlet Container 当中，Container 这个词有点高大上，但是说白了，无非就是能执行 Servlet 和 JSP 的一个东西，比如说 Tomcat, 比如说 Jetty。
但是无论是我还是 JSP，我们能处理的只是 HTTP 请求，必须得有人把 HTTP 请求转发给我们才可以。
这件事情只有让 Tomcat, Jetty 他们来做了，他们自己可以接收 HTTP 请求，然后转发给我们；
他们也可以从别人，例如 Apache 那里接收 HTTP 请求，然后发给我们处理，处理完了再转发给 Apache，Apache 再发给人类的浏览器。
虽然有点麻烦，但是这种方式确实非常灵活，各司其职，扩展性比较好，比如，一个 Apache 可以把请求分发给后台多个 Tomcat 中的一个。
Apache，Nginx 他们专心致志地去处理静态内容(HTML, JS, 图片），我们这里心无旁骛地执地执行“不讲逻辑的”业务逻辑，访问数据库，然后生成页面返回。
Application Server
日子过得波澜不惊，我一度认为，这个世界就将这么运行下去。
应用程序越开发越多，出现了一些通用的需求，比如安全，事务，分布式等等，这些需求应用程序不愿意处理，想丢给操作系统，操作系统也不愿意处理，那怎么办？
不知道是谁提了一个叫做中间件的概念：你们不愿意做的，我们中间件来做。
Java 世界也不敢怠慢，也搞出了一大堆的规范，像什么 EJB,JMS，JTA 等等，把我和 JSP 也合并到其中，形成一个大“杂烩”，叫做 J2EE。
其中最春风得意的就是 EJB 这家伙，独自生活在 EJB Container 中（又是 Container！），号称能支持真正地分布式计算：一个 EJB 可以有多个实例，分布到多个服务器中，应对用户的请求，听起来很高深的技术。
他们把 Servlet Container 称为 Web Container , 和 EJB Container 一起，还有其他的一些东西，被合并到一个叫做 Application Server 当中去了。最知名的几个 Application Server 就是 Weblogic , WebSphere , JBoss。
国内的金蝶也实现过一个，叫做 Apusic，虽然影响力不如前面那几位，但值得赞赏。
退居幕后
我和 JSP 都没有料到，EJB 抢了我们的风头，成了系统的中心，让我们极为不爽。
我和 JSP 岂能善罢甘休？我们决定抓住 EJB 的弱点进行反击，我们和人类一个叫做 Rod Johnson 的联合，让他出面，列举出 EJB 的 36 大罪状，昭告天下，这些罪状包括但不限于：笨重，性能低下，难于测试，昂贵…
EJB 确实是个扶不起的阿斗，很快就被人批得体无完肤，大家纷纷投入 Rod Johnson 创建的 Spring 的怀抱。
我松了一口气，可是很快就发现事情不对劲，大家纷纷用起了框架！比如 Struts, SpringMVC…
在这些框架中，我虽然处于一个非常重要的角色，但是通常情况下只要配置一下 web.xml，就可以把我扔到一边了。
Container 照例把 HTTP 请求传递给我，但是我却不能亲手处理，我需要传递给框架，框架分派给 Controller，没我什么事了！
那些程序员们要做的事情就是写 Controller, Service , DAO 这些和我八班杆子打不着的东西。
我恨框架，但是看到程序员们写代码写得那么高兴，又无话可说，毕竟框架极大地减少了他们的工作量：
之前对于每个 HTTP 请求，程序员得手工地去解析 URL，调用相关的 Java Bean。
现在只需要用个配置文件或者注解就可以把 URL 给映射到一个 Java 类。
之前对于 HTTP 请求中的参数，程序员也得手工解析和验证。
现在也可以直接映射到 Java 对象或者变量
…
用起来这么简单，他们不用才怪。
更让人生气的是，Rod 他们后来倒腾出来一个叫做 Spring Boot 的东西，彻底地把我给隐藏起来了！
尤其是对于一个新手来说，甚至完全不知道我的存在。
Tomcat 和 Jetty 这样的 Servlet Container 也很悲催，他们竟然被内嵌到了 Spring Boot 中！程序员开发出的 Web 应用，就像一个普通的 Java 程序一样，从 main 函数开始运行。
我们彻底地退居幕后了！
不过我有义务提醒一下学习后端编程的同学，不要一上来就学习框架，不要被框架迷住你的双眼！
还是应该好好看看最基本的 Java Web，就是我和我的兄弟 JSP。
一键生成基于 SSH 框架的功能代码
威胁来临
虽然是退居幕后，但是我的核心地位依然稳固，是 Java Web 应用的中坚力量，我生活在 Servlet Container 中，专门处理 HTTP 请求，这么多年难逢敌手。
直到有一天，有个叫做 Netty 的家伙上门挑战。
这个 Netty 居然完全不用 Servlet Container，或者换句话说，人家自己就是一个“Container”，这对我来说绝对是釜底抽薪的攻击，我引以为傲的 Servlet 规范，Servlet API 统统不管用了。
我只能处理 HTTP，可是这个 Netty 支持各种各样的协议：HTTP, FTP, UDP, 它还支持实现各种各样自定义的协议！这就意味着程序员完全可以自定义一套自己应用的 RPC 协议，然后放到 Netty 上运行。
它的底层是 Java NIO，又封装了 Java NIO 那些复杂的底层细节，可以轻松实现高性能、高可靠的网络服务器, 这实在是太可怕了。
我似乎看到了一个可怕的场景：用 Netty 开发的服务器端，运行着众多的 Web 服务，他们之间使用私有的协议在互相调用，效率极高，性能极高，根本没有 Servlet, HTTP, Tomcat 什么事。
让我稍感安慰的是，直接使用 Netty 的程序员们还不多，虽说有不少人在使用基于 Netty 的 Dubbo, 但是 Netty 也被封装隐藏起来了。我估计真正具有钻研精神的程序员才愿意去研究他吧。
