转自：码农翻身（微信号：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。
威胁来临
虽然是退居幕后，但是我的核心地位依然稳固，是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也被封装隐藏起来了。 我估计真正具有钻研精神的程序员才愿意去研究他吧。