在旅途 2019-11-04
转自:码农翻身(微信号: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, 图片) ,我们这里心无旁骛地执地执行“不讲逻辑的”业务逻辑,访问数据库,然后生成页面返回。
日子过得波澜不惊,我一度认为,这个世界就将这么运行下去。
应用程序越开发越多,出现了一些通用的需求,比如安全,事务,分布式等等,这些需求应用程序不愿意处理,想丢给操作系统,操作系统也不愿意处理, 那怎么办?
不知道是谁提了一个叫做中间件的概念: 你们不愿意做的,我们中间件来做。
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也被封装隐藏起来了。 我估计真正具有钻研精神的程序员才愿意去研究他吧。