后端程序员都干些什么

转自：微信公众号码农翻身

这个问题来自于QQ网友，一句两句说不清楚，索性写个文章。

我刚开始做Web开发的时候，根本没有前端，后端之说。

原因很简单，那个时候服务器端的代码就是一切：接受浏览器的请求，实现业务逻辑，访问数据库，用JSP生成HTML，然后发送给浏览器。

即使后来Javascript在浏览器中添加了一些AJAX的效果，那也是锦上添花，绝对不敢造次。因为页面的HTML主要还是用所谓“套模板”的方式生成：美工生成HTML模板，程序员用JSP,Veloctiy,FreeMaker等技术把动态的内容添加上去，仅此而已。

那个时候最流行的图是这个样子：

在最初的J2EE体系中，这个表示层可不仅仅是浏览器中运行的页面，还包括Java写的桌面端，只是Java在桌面端太不争气，没有发展起来。

每个程序员都是所谓“全栈”工程师，不仅要搞定HTML, JavaScript, CSS，还要实现业务逻辑，编写访问数据库的代码。等到部署的时候，就把所有的代码打成一个WAR包，往Tomcat指定的目录一扔，测试一下没问题，收工回家！

不差钱的公司会把程序部署到Weblogic，Websphere这样的应用服务器中，还会用上高大上的EJB。

虽然看起来生活“简单”又“惬意”，但实际上也需要实现那些多变的、不讲逻辑的业务需求，苦逼的本质并没有改变。

1前后端的分离

随着大家对浏览器页面的视觉和交互要求越来越高，“套模板”的方式渐渐无法满足要求，这个所谓的表示层慢慢地迁移到浏览器当中去了，一大批像Angular, ReactJS之类的框架崛起，前后端分离了！

后端的工程师只负责提供接口和数据，专注于业务逻辑的实现，前端取到数据后在浏览器中展示，各司其职。

像Java这样的语言很适合去实现复杂的业务逻辑，尤其是一些MIS系统，行业软件如税务、电力、烟草、金融，通信等等。所以剥离表示层，只做后端挺合适的。

但是如果仅仅是实现业务逻辑，那后端也不会需要这么多技术了，搞定SSH/SSM就行了。

2后端技术

互联网，尤其是移动互联网开始兴起以后，海量的用户呼啸而来，一个单机部署的小小War包肯定是撑不住了，必须得做分布式。

原来的单个Tomcat得变成Tomcat的集群，前边弄个Web服务器做请求的负载均衡，不仅如此，还得考虑状态问题，session的一致性。

（老刘注：参见文章《小白科普：分布式和集群》）

业务越来越复杂，我们不得不把某些业务放到一个机器（或集群）上，把另外一部分业务放到另外一个机器（或集群）上，虽然系统的计算能力，处理能力大大增强，但是这些系统之间的通信就变成了头疼的问题，消息队列（MQ)，RPC框架（如Dubbo）应运而生，为了提高通信效率，各种序列化的工具(如Protobuf)也争先空后地问世。

单个数据库也撑不住了，那就做数据库的读写分离，如果还不行，就做分库和分表，把原有的数据库垂直地切一切，或者水平地切一切，但不管怎么切，都会让应用程序的访问非常麻烦，因为数据要跨库做Join/排序，还需要事务，为了解决这个问题，又有各种各样“数据访问中间件”的工具和产品诞生。

为了最大程度地提高性能，缓存肯定少不了，可以在本机做缓存(如Ehcache)，也可以做分布式缓存(如Redis)，如何搞数据分片，数据迁移，失效转移，这又是一个超级大的主题了。

互联网用户喜欢上传图片和文件，还得搞一个分布式的文件系统（如FastDFS），要求高可用，高可靠。

数据量大了，搜索的需求就自然而然地浮出水面，你得弄一个支持全文索引的搜索引擎(如Elasticsearch ,Solr)出来。

林子大了，什么鸟都有，必须得考虑安全，数据的加密/解密，签名、证书，防止SQL注入，XSS/CSRF等各种攻击。

3“大后端”

前面提到了这么多的系统，还都是分布式的，每次上线，运维的同学说：把这么多系统协调好，把老子都累死了。

得把持续集成做好，能自动化地部署，自动化测试（其实前端也是如此），后来出现了一个革命化的技术docker，能够让开发、测试、生成环境保持一致，系统原来只是在环境（如Ngnix, JVM,Tomcat,MySQL等）上部署代码，现在把代码和环境一并打包，运维的工作一下子就简化了。

公司自己购买服务器比较贵，维护也很麻烦，又难于弹性地增长，那就搞点虚拟的服务器吧，硬盘、内存都可以动态扩展（反正是虚拟的），访问量大的时候多用点，没啥访问量了就释放一点，按需分配，很方便，这就是云计算的一个场景。

随着时间的推移，各个公司和系统收集的数据越来越多，都堆成一座大山了，难道就放在那里白白地浪费硬盘空间吗？

有人就惊奇地发现，咦，我们利用这些数据搞点事情啊，比如把数据好好分析一下，预测一下这个用户的购买/阅读/浏览习惯，给他推荐一点东西嘛。

可是这么多数据，用传统的方式计算好几天甚至好几个月才能出个结果，到时候黄花菜都凉了，所以也得利用分布式的技术，想办法把计算分到各个计算机去，然后再把计算结果收回来，时势造英雄，Hadoop及其生态系统就应运而生了。

之前听说过一个大前端的概念，把移动端和网页端都归结为“前端”，我这里造个词“大后端”，把那些用户直接接触不到的、发生在服务器端的都归结进来。

4怎么学？

现在无论是前端还是后端，技术领域多如牛毛，都严重地细分了，所以我认为真正的全栈工程师根本不存在，因为一个人精力有限，不可能搞定这么多技术领域，太难了。

培训机构所说的“全栈”，我认为就是前后端还在拉拉扯扯，藕断丝连，没有彻底分离的时候的“全栈”工程师。

那么问题来了，后端这么多东西，我该怎么学？

之前写过一篇文章叫做《上天还是入地》，说了学习的广度和深度，在这里也是相通的。

往深度挖掘，可以成为某个技术领域的专家，如搜索方面的专家、安全方面的专家，分布式文件的专家等等，不管是哪个领域，重点都不是学会使用某个工具和框架，而是保证你可以自己的知识和技术去搞定这个领域的顶尖问题。

往广度发展，各个技术领域都要了解，对于某种需求，能够选取合适的软件和技术架构来实现它，把需求转化成合适的技术组件，让这些组件以合适的方式连接、部署、运行，这也需要持续地学习和不断的经验积累。

最后，以一张漫画来结束吧！

（完）

我为什么对后端编程情有独钟？

转自：老刘码农翻身 2017-05-10

这几年前端很热闹，发展也很快， Angular, React, Vue ... 等各种各样的新技术层出不穷，并且不断地抢后端的饭碗。比如说著名的Model - View -Controller , 原来前端只负责View层，展示数据，现在前后端分离，前端把控制层Controller 也给抢走了，可怜的后端程序猿只剩下RESTful服务提供的数据了，再加上Node.js趁火打劫，入侵服务器端，有木有危机感？

但我还是对后端编程情有独钟，原因很简单，相比GUI编程，我更喜欢API编程，有点费解？听我慢慢道来。

1 单机时代的GUI

最早的时候我其实也是挺喜欢GUI编程的，谁愿意只在命令行下折腾呢？

作为“初恋”的C语言，虽然功能强大、效率高，但是只能在命令行窗口写点小程序，很无趣。

后来遇到VB, 不由的眼前一亮：哇塞，还能这么写程序！创建一个窗体，把各种各样的控件拖动上去，摆好位置，设好属性，然后双击，在onClick方法中写下代码就ok了。

号称VB杀手的Delphi 也类似，都是所谓的RAD(Rapid Application Development) 。

当时的控件多如牛毛，上了年纪的程序员应该还记得CSDN出的《程序员大本营》，里边有张光盘，全是程序猿们开发的VB控件，你想发送邮件，拖动一个不可见的SMTP控件过来，设定邮箱服务器和端口，直接就可以发信，非常简单。你想用一个定时器功能，没问题，那里有个定时器控件，可以直接使用，这才是真正的组件化开发。

由于开发出来的应用只能在PC上，在Windows上运行，不会出现如今手机端各种各样的适配问题，垄断在某些时候也是好处啊。

虽然这些桌面应用程序不像Web页面那样美轮美奂，但对于我这个缺乏艺术细胞的人来说，这是GUI编程的黄金时代。

2 Web GUI

好景不长，技术变迁很快， Web时代来临了。

于是开始学HTML, CSS, Javascript，忙着折腾个人主页，做了没多久就意识到，用HTML产生页面布局怎么这么麻烦，当时CSS还不普及 , 页面布局全靠一个表格套一个表格来做，如果没有Dreamweaver, Frontpage 这样的软件帮忙，这些<tr><td>标签绝对会把人淹死。

光有布局还不行，还得弄图片，调颜色，我在大学还学了photoshop ，想着自己设计。后来看到一本书上的例子，在photoshop中不使用任何外界图片，从零开始做出一个可口可乐易拉罐出来，那光影效果当时就把我震撼了，立刻意识到自己不是搞艺术的这块料，还是老老实实的回去写程序去吧。

个人主页怎么办？我就Copy了一个别人的网站，改了改，变成了这个样子（图片没有显示）：

忘了Copy谁的网站了，向原作者表示歉意，当时是学生，知识产权意识不够，搁现在肯定得掏钱去买。

现在一般的开发团队都配有美工，可以设计界面，设计完还能“切图”，形成漂亮的html+css的静态页面，接下来的问题就是怎么把静态的网页变成动态的网页，这就八仙过海，各显神通了。

传统的方式就是在服务器端完成，利用各种各样的模板技术，在静态页面中加上动态内容，直接生成HTML UI元素。

最近流行的就是让浏览器来负责，通过js 调用后端API，把数据变成HTML UI元素后展示出来。

不管是那种方式， CSS都是不可或缺的。因为它控制了页面的布局结构，又是布局，快逃！

3 Java GUI

上了Java的贼船以后，也做了一些GUI的工作，相比于VB/Delphi拖放控件的便捷，用Java写界面简直就是地狱！

虽然也有图形化的界面编辑器，也可以拖放控件，但是自动生成的代码那叫一个惨不忍睹。更悲催的是，稍微手工改动一下，那个界面编辑器就可能不认了。绝大多数情况下还是直接写代码来生成界面。 (再次大声疾呼：不要再Swing和AWT上浪费精力，用的极少。 )

这里必须说一下Java和VB在界面编程的区别， Java 的界面全是用代码来生成的，就是说你需要写代码创建一个按钮，写代码把这个按钮放到什么地方去，所以即使是GUI程序，最终的表现形式也只是Java 文件而已。

VB则不同，它专门有个.frm文件，里边存储所有界面控件和布局的信息，最终也需要把.frm打包发布。所以在编辑界面这一点， VB和Dephi 是非常方便的。

程序员们这么痛苦，那些大牛肯定会来解救我们的，比方说能不能用XML来描述界面啊，在XML中把各个控件及其布局关系都给描述好，由系统读取，创建界面，就像原来的.frm文件一样。 Android 不就是这么干的吗？

但是XML文件读起来也够痛苦的，为了灵活性，这个XML文件还不能隐藏起来，有时候还要手工去改，改完还不容易看到真正的效果，唉，想想就头大。

更不用说Android的适配问题了，不同屏幕尺寸，不同的分辨率，不同的像素密度给程序员带来了极大的工作量。

（每个矩形代表一种设备）

4 后端编程

啰嗦了这么多，其实就想表达一个中心思想：我是有点害怕GUI编程。而Web 前端和App前端都是在和GUI打交道。

我甚至想，这可能和内向的性格有关系，擅长和机器打交道，不擅长和人打交道。前端需要琢磨用户的心理、使用习惯、用户体验，这不是我的优势。

在软件编程领域，与其费力不讨好的补上短板，不如把自己的长处发挥到极致。

既然如此，那就呆在后端编程吧，这里没有GUI, 只有API。悄悄地躲在电脑的背后，给Web前端和App前端提供服务，让他们调用。

有人会说：前端把Controller和View都拿走了，后端就是个API的提供者，能折腾啥啊。

别小看后端编程，后端是非常有技术含量的，像什么高并发、缓存、负载均衡、分布式、消息队列、安全、搜索、数据复制.... 每个方向都值得静下心来去深挖。

不管前端技术怎么变化，作为提供服务的后端总是要存在的，这是一大优势。

后端编程还有一个优势就是相对稳定，比起大爆炸的前端，后端技术的变化要缓慢一些，心思不会那么浮躁，有很多知识可以慢慢的沉淀。

对于那些不喜欢做GUI的同学，不妨考虑下后端编程。

J2EE到底是何方神圣

一、J2EE历史

前言：

昨天下午有同学问我Java EE是干什么用的，能开发什么系统，我在QQ中敲了很多字，掰扯了半天，终于给他整明白了。

我突然意识在其实很多初学者对Java EE的来龙去脉并去清楚，大家并不知道为什么会出现这个技术，要解决什么问题。所以就写了这篇文章介绍下Java EE的历史。

-----------------------------------------------------------------------

先把时间扯的远一点， 94年我上高中的时候，见过亲戚家有过电脑，很好奇，虽然上面都是一些单机桌面程序，根本上不了网，但是一个小小的扫雷程序就足以吸引很多眼球了。

后来上了大学，接触电脑越来越多，局域网已经普及，互联网开始抬头，这时候C/S (Client-Server )结构的程序开始出现了，例如QQ, 棋牌类游戏，还有著名的PowerBuilder 开发的MIS（管理信息系统），都是典型的客户端-服务器结构, 程序运行在个人的电脑上，和服务器通信。

C/S 软件界面可以整的很漂亮，用户体验很好，但是缺点也很明显，就是用户必须要安装客户端，并且需要升级客户端来用新功能，这样就带来两个问题

(1) 服务器端发生变化，一定要能兼容很多客户端版本，要不然有的客户端软件就运行不了了，因为客户不一定升级。

(2) 可能会出现DLL 地狱问题 -- 自己百度下啥是DLL 地狱。

再后来Web大发展，速度快了，带宽也够了，大家发现， Web页面也能做的很漂亮了，把程序放到服务器端，用浏览器访问多好，用户也不用安装，所有功能都是即时更新。

但是html只是静态的，怎么才能变成动态的，可交互的呢？

CGI 技术出现了， CGI 允许web服务器调用外部的程序，并把结果输出到Web浏览器，这样就能根据用户的操作生产不同的动态页面了。

在我读大学的年代， CGI 最常见的就是实现一个计数器，看着自己的主页访问量慢慢的增长，那种感觉是很爽的。

当然，使用CGI 最苦逼的就是需要用程序输出html , 那可是整个网页的html , 不是其中的一个片段！

换句话说，程序员只能在代码里写html, 而不能在html里写代码。你可以想象一下用C 语言或者Perl 写CGI脚本的程序员那种咬牙切齿的感觉。

举个例子，通过浏览器提交了用户名/ 密码, cgi 会这么做：

if (name=="liuxin" and password == "xxxx" ) {

println ("<html>");

println ("<head>");

println ("<title>欢迎</title>");

println ("</title>");

println("<body>")

println("<table>")

println("<tr><td>") ..... 我实在是写不下去了，太崩溃了，这是伪码，不要和我较劲...............

println("</td></tr>")

println("</table>")

println("</body>")

print("</html>")

}

这个时候我们赖以糊口的Java 在干嘛？

Java是Sun 发明的，当然Sun 现在已经被Oracle 收购了。

Java 其实是依靠Applet ,依靠互联网才起家发达的，大家在简陋的页面上突然看到当时极为炫目的Applet 小动画，立刻就震惊了。

但悲剧的是大家发现Applet 除了用来演示以外，似乎没有找到真正的用武之地。

浏览器还必须得装个java 插件，后来微软为了阻止Java 还在自己浏览器IE中使坏 :-) ，这个插件运行一直不太稳定。

Java 看到CGI 技术发展的不错，自己也搞一个类似的吧，这就是Servlet , 由于提供了一个request, response, session等支持, 用起来比CGI方便多了。

但是输出html这一块没有任何改进，还得程序员一句一句的输出html.

06年我进IBM的时候发现有个项目是在用servlet 输出页面html ,完全没用jsp，我也就见怪不怪了，这肯定是个90年代的遗留应用。

最后大家都受不了这种极为痛苦的输出方式，于是Sun 就弄了个JSP , 微软也不甘示弱，出了个ASP。

这下子Web开发出现了跃进，因为不管是JSP还是ASP, 都是所谓的 Server Page , 也就是说程序员终于可以把逻辑代码和html混在一起了！在也不用一行一行的输出纯html了。

当然现在老师教导你， jsp中不要有逻辑代码，但在当时，这可是了不起的突破。

我们可以先让美工把页面设计好，然后把程序嵌入进去就行了。

再后来出现了Struts, 使用MVC解决了职责划分问题， Web 应用迈向了新的台阶，开始飞速发展，对于这种应用，我们称为 B/S 结构, 即Browser(浏览器)-Server (服务器) 。

C/S结构的程序当然不会消亡，因为像聊天，视频，游戏等对性能，界面，用户体验要求很高，天然适合桌面程序实现。

为了支持更大，更复杂的应用开发，微软为ASP 添加了实现业务逻辑的COM, COM+ ，访问数据库的ADO 等技术。

而Sun和Java 社区有更大的野心，他们提出了一套更大的，不同于传统应用开发的架构，专门用于满足企业级开发的需求。

这些需求包括数据库，邮件，消息，事务处理， Java 对这些通用的需求做了抽象，形成了一些规范和标准，除了Servelt 和 JSP ,还有EJB, JMS , JDBC 等等。

这些东西，Sun 把他们称为J2EE 。

为啥不是Java EE ? 那个2是怎么回事？

这完全是一种市场策略，原来Java 的版本是1.1 ，从1.2开始， Sun 称之为为Java 2 平台，以便告诉大家，这是一个突破性的技术平台。实际上也确实有所突破， Java 被分成了 J2SE (标准版) ， J2EE(企业版) 和J2ME(移动版) ，当然移动版在手机上一直没有发展起来，直到Android的出现--这是后话了。

到了2005年， Sun 又取消了那个 “2” ，于是就变成了 Java SE, Java EE, Java ME 了。

J2EE需要运行在一个叫应用服务器的东西里，这就是Weblogic, websphere , jboss, 也称为应用中间件。

J2EE发展的非常迅猛，迅速统治了Web应用开发市场，微软的ASP只能偏居一隅了，后来推出.NET 才算扳回一城。

我们走了漫长的路，终于来到你的面前，现在你知道Java EE 是干啥的了吧 :-)

在后来的故事估计很多人都听过了，Java EE远远没有宣传的那么美好， EJB，尤其是Entity Bean 极为难用，对业务代码侵入性极强，在大家想抛弃而又没有替代品的时候，有一位大牛Rod Johnson如约而至，他说我们不要这种臃肿，低效，脱离现实的J2EE, 我们要灵活，轻便，轻量级的框架，这就是Spring，我们就有了依赖注入,AOP....

有位叫Gavin King的澳大利亚小伙子也是在忍受不了EJB的O/R Mapping , 自己整了一个Hibernate 。

再加上更早出现的Struts, 我们Java 程序员终于过起了幸福的SSH生活。

二、J2EE入门指南

前言

这是写给零基础小白的一系列文章。

为啥叫生存指南呢，因为Java发展了20年，现在已经不仅仅是一个单纯的语言了，而是一套完整的生态系统，其中的术语像 HTML, XML, CSS, Javascript , AJAX, JQuery,Prototype, HTTP, Tomcat, JBoss, Nginx , Memecached , Redis, MVC ,Servlet, JSP, Struts, Hibernate, myBatis , Spring, JFinal, MySql, JDBC, EJB, JMS, Swing , AWT, Reflection, OSGi... 铺面而来，搞的你头晕脑胀，无所适从，很容易就Lost了。

所以写这个文章的目的就是帮助小白能在Java 的汪洋大海里生存，时不时的能冒出水面喘口气，看看空中的生存指南，把握自己的方向继续向前。

-------------------------------------------------------------

先回答一个问题？为什么要学习Java ?

我想原因无非有这么几点

1. 我周围的人都在学，所以我也学

2. Java 好找工作啊，确实是，在中国，软件行业还处于模仿、学习美国鬼子的阶段，做系统级编程的不是没有，像BAT就会用到。不过绝大部分公司还都是搞应用级程序的开发，所以Java, 尤其是Java EE 工作机会是非常多的。

3. Java 看起来挺简单的。

Java 语言本身看起来确实挺简单的，不像C语言，一个指针就把你搞迷糊了；

也不像C++，语法复杂而诡异， new 了一个对象以后还得记住释放内存，确实是挺悲催的；

Java 即使加上了面向对象（封装，继承，多态），也是简单的令人发指，不用上大学，高中生，甚至初中生都能看明白。

可是你会发现学了基本的Java 以后，除了能写个水仙花数，九九乘法表，还是啥也干不了，更别说月薪过万了。

人家公司至少要求精通SSH，AJAX,JQuery ，CSS,mysql , 这条路走起来就不那么容易了。

再看第二个问题： Java 到底能干什么？

一句话， Java 最擅长的就是Web 应用开发(通俗的讲就是网站开发)，不善长桌面应用开发。

你想想你开发一个Java 桌面应用，还得让用户下载一个Java 虚拟机，甚至要设置环境变量，一般人是搞不定的。此外Java 内置的Swing ,AWT确实不怎么样，开发出来的界面距离操作系统原生界面差了很远，所以除了特殊情况，奉劝那些还在孜孜不倦的研究Java 界面编程(Swing, AWT)的同学还是不要浪费精力了，不要硬逼着Java***不擅长也不不愿意做的事情。

所以咱们就聊聊Java Web 开发中用到的那些技术和术语。

先来说说HTML, 咱们想象一个场景，互联网还没有出现，你是个球迷＋程序员，电脑里有很多的记录足球的文件例如足球.txt, 巴塞罗那.txt ，曼联.txt .....

其中足球.txt 中有一个词"巴萨罗那" ，为了方便，你想点这4个字就打开另外一个文件“巴赛罗那.txt” 立刻就能看看球队的介绍，这该怎么办？

你冥思苦想，终于顿悟了，可以这么干：　定义一个协议　<a href ="巴塞罗那.txt">巴塞罗那 </a> 　，　然后开发一个软件, 把所有的文本都管理起来，遇到像<a href ...>这样的东西，软件就认为这是一个链接，点击后就打开另外一个文件！

这的确是个好主意，其实在1989年，万维网的发明人蒂姆·伯纳斯·李也是这么干的，你看你要是早出生20年，估计也是WWW的发明人了。

加了链接以后，文本就不是不同的文本了，而升级为超文本 (Hypertext)了　！

但是如果你的“足球.txt”还有“广州恒大”几个字，但是广州恒大的介绍是在你哥们的电脑上，而他也想把他的文本能链接到你的电脑文件上，这怎么办？

一个单机运行的软件就不行的，必须得有网络，有网络还不够，你得解决通信的问题。

你就想：既然上面的文本是超文本，并且需要把你好哥们的文本传输到你的电脑上才能看，那通信方法就叫做超文本传输协议吧 HyperText Transfer Protocol ，简称Http。

于是你又扩展上一个程序，不但把你的文本文件都管理起来，还允许通过网络访问，别人要想通过网络看你的文件，得发个这样的命令给你的软件：

http://192.168.0.10/football/巴萨罗那.txt 。你的程序就会找到football 目录下的巴萨罗那.txt , 读出内容，发给对方, 并且给他说： 200 成功

如果找不到，软件就告诉他： 404 对不起，找不到。

如果你的软件在处理过程中出了错，软件就说： 500　唉，服务器出错了。

这个软件功能强大，专门在网络上别人服务，就叫网络服务器吧，可以起个名字叫Apache 。

可是只看文字太不爽了，你还想看表格，列表，图片，甚至视频。干脆自己定义一个描述界面的语言吧，像这样：

<table> ---表示表格

<li> --- 表示列表

<image> -- 表示图片。

这些都称为标记(markup) , 所以现在你的超文本就更加丰富了，这个语言就叫做 Hyper Text Markup Language ，简称为 HTML。

原来的软件只能显示文本和处理链接，现在还需要能处理这些标签，遇到不同的标签，就显示相应的内容。

现在你把你的文本全部用html改写了一遍，放到了Apache 服务器中，你的哥们也把他的html放到了他的Apache服务器上，当然你们的html之间还保持着链接。然后你们就可以用新的软件对这些html进行浏览了，对了，可以把这个软件称为浏览器。

由于方便，快捷，能发布图文并茂的信息，更关键的是可以把散布在全世界各个角落中的计算机连接在一起， HTML ， HTTP, 网络服务器，浏览器迅速普及，人们上网在也不用使用那些难用的telnet , ftp 了。网络就变成了这样：

下面的文字来源于百度百科：

因为在互联网技术上的杰出贡献，伯纳斯·李被业界公认为“互联网之父”。他的发明改变了全球信息化的传统模式，带来了一个信息交流的全新时代。然而比他的发明更伟大的是，伯纳斯·李并没有像其他人那样为“WWW”申请专利或限制它的使用，而是无偿的向全世界开放。伯纳斯·李本来可以在金钱上与盖茨一比高低，但他的这一举措却为互联网的全球化普及翻开了里程碑式的篇章，让所有人都有机会接触到互联网，也圆了那些。com公司创建者们的富翁梦。即便如此，伯纳斯·李仍然十分谦虚，总是以一种平静的口气回应：“我想，我没有发明互联网，我只是找到了一种更好的方法。”

互联网之父伯纳斯·李

接上篇《给小白的Java EE生存指南》，你可以通过公共号的消息历史中查看。今天继续聊Web的事情。

上次说到你发明了html , http, 浏览器， web服务器，这下子把整个世界的信息都链接成了一个了一个大网： world wide web

可是你注意到一个问题没有，这些html都是静态的，也就是说你除了浏览你的网站和别人的网站之外，什么都做不成。用你发明的HTTP术语来讲，就是现在的互联网，只支持 “GET”

比如说，你看了哥们的网站，知道广州恒大夺得了2015亚冠冠军，想给他留个言表示一下兴奋之情，这就做不到了。

这是不能令你满意的，对互联网做扩展吧

先扩展HTML ，加上一堆新标签像<form>了， <input>了什么type=text, radio, textarea,checkbox 。。。这样你就可以在html中支持输入各式各样的信息了。

你还得扩展HTTP协议，引入一个“POST”这样可以把数据发到Web服务器。

Web 服务器当然也得扩展，接收到POST过来的留言数据以后，肯定得想办法处理啊，怎么处理?　

无非就是新生成一个html , 除了把原有的数据保留以外，还要把新的留言相关的数据“动态”的加上去，这就是所谓的动态页面。

必须得有程序来办这件事情，你马上就面临两个问题：

(1) 用什么语言来写，毕竟有那么多语言像C, Perl , Python, 甚至Java 都在虎视眈眈呢

(2) 这个程序怎么和 Web 服务器交互

解决方法也很简单，你弄了了一个叫做 Common Gateway Interface (简称CGI) 的东西，定义了标准的输入(STDIN)和输出(STDOUT)，所有的程序都可以从STDIN 读入数据，处理后形成html, 然后向STDOUT 输出。

这下子任何语言都可以写cgi程序了，网页也变成了“可交互式”的，整个互联网又向前推进了一大步，各种各样的商业网站如雨后春笋一般发展起来。

( ps : 现在CGI 技术已经过时了， ASP, JSP, PHP等技术是主流。

在Java的世界里，把Apache ,Ngnix 这样的服务器称为静态内容服务器，主要处理像图片/文件件这样不变的，只读的静态资源，性能非常好；把Tomcat, JBoss ，Websphere, Weblogic等称为动态内容服务器，主要产生动态内容。

一般的设计会把Apache/Ngnix 放的前边，接收所有的Http 请求，如果是静态资源，就直接处理掉，如果是动态资源，就转发到Tomcat/Jboss 去处理。 )

等等，还有个小问题，我的留言我能看到，别人的留言我也想看到改怎么办？很明显，每个人通过浏览器提交的留言都需要保存起来，在生成页面的时候动态的读取他们，形成html 。

可以把所有的用户留言都存放到一个文件当中，读取文件形成html没有任何压力，但是你要非常小心处理同步的问题：你提交留言的时候，别人也在提交，可不能相互覆盖啊！

这也是为什么Web程序都有一个数据库的原因，数据库帮我们解决了这些乱七八糟的同步问题，我们只需要向数据库发出 Select, Insert, Upate ,Delete 就好了。数据库的历史要比WWW久远的多，早在大机时代就出现了，现在已经发展的非常成熟，直接拿过来用就可以了。

解决了用户留言的问题，你接下来要写一个网上售票的应用，让大家在网上买球票，买票的时候需要一个购物车，大家可以把票暂时放到购物车里。

开发购物车的时候发现了你设计的HTTP一个非常严重的缺陷：没有状态，因为用户往购物车里加了一个球票，一刷新页面购物车就空了，里边的所有东西都丢失了。

假设用户A在操作，用户B也在操作，你的Apache服务器实际上根本区分不出来谁是用户A, 谁是用户B, 只是看到了一个个毫无关联的GET和POST 。根本记录不下来同一个用户在过去一段时间内做了什么事情。

你想改一下HTTP协议，可是悲催的是数以亿计的网站已经在用了，你想改都改不了了。

于是你想了个办法， HTTP 协议不是有个header吗，在里边做做手脚：

浏览器A第一次给服务器发送请求时，服务器通过header告诉它一个编号number_a，浏览器A需要记住这个编号，然后下次请求的时候（以及后续所有请求的时候）也通过header 把number_a 发给服务器。这样服务器一看，奥，原来你是浏览器A 啊，就可以把浏览器A相关的购物车数据从内存中取出来，形成html 发回浏览器A了。

浏览器A和服务器的这个通过这个编号来交互，这个过程就称为： session

用了这一个小伎俩，这样服务器就把各个浏览器（各个用户）给区分开了。

到目前为止，构建一个Web系统最基础的工作可以说已经完成了，我想起来高中时物理老师说的一句话：牛顿三定律出来以后，经典物理学的大厦已经建立起来了，后人的工作无非是刷刷墙，装饰装饰而已。

对于互联网也是： HTTP + HTML +　Web服务器 + 数据库就是WWW的基石，后续的工作都是为了提高生产率做的包装和装饰。

最后简单做一个总结：其实发明创造并没有那么难，马云说过，哪里有抱怨，哪里就有机会，所以找一找现在你感觉最不爽的地方，也许能发明下一代互联网呢。

前两篇文章《给小白的Java EE生存指南(1)》和《给小白的Java EE生存指南(2)》（注：回复关键字“小白”即可查看）基本上把Web编程所依赖的基础技术（HTTP,HTML, WEB服务器，浏览器）的来龙去脉介绍完了，从这篇开始，正式开始进入应用程序的开发领域。

其实Web应用程序开发也有个极为常见的技术： XML . 很多小白在问，为什么有XML, 要XML干嘛？不是有HTML了吗？晕倒

对一项技术我的风格是喜欢刨根问底，不但要知道how, 还要知道why , 了解了一个技术的成因，才能真正掌握。

假设你用Java 写了一个很棒的Web应用，这个程序可以在线购书，在互联网刚起步的时代这个应用火的一塌糊涂，后来有个出版社看到了机遇，就想和你搞合作：我这儿也有个Web应用，可以给你提供很多书籍的资源，你能不能开发个程序把这些书的信息读出来，放到你的网站上？

这没啥难的，首先得定义一下你的应用和出版社的应用中间怎么进行数据交换，你要定义一个格式，像这样：

[isbn|书名|作者|简介|价格]

例如： [978-7-229-03093-3|三体|刘慈欣|中国最牛的科幻书|38.00]

数据虽然紧凑，但是每个字段是什么含义，不好理解，你想起了HTML的标签好像不错，不如学习HTML改进一下：

<book>

<introduction>中国最牛的科幻书</introduction>

</book>

由于HTML的标签<head>,<title>,<tr><td>...... 是有限的，而你的标签确实可以随意扩展的，想写什么写什么所以你就把它称为 Extensible Markup Language, 简称XML

现在每个字段的含义很明确，人读起来也很爽了，但是毕竟是程序在处理出版社发过来的数据，万一他们的数据里少了一些重要字段该怎么办，能不能自动的检测出来？

所以你需要设计一套校验规则，能让程序自动校验一段xml 文本是不是你期望的，这个规则可以像这样：

<!ELEMENT book (isbn, name, author, introduction, price)>

<!ELEMENT price (#PCDATA)>

<!ELEMENT name (#PCDATA)>

<!ELEMENT isbn (#PCDATA)>

<!ELEMENT introduction (#PCDATA)>

<!ELEMENT author (#PCDATA)>

其中第一行的意思是 xml 需要有个 book 标签（元素），它包含了几个子标签，并且这几个标签必须都得有，并且按次序出现。

其他行表示每个标签都是文本就可以了。

你把这个东西起名为文档类型定义 Document Type Definition, 简称DTD 。

这样就不怕出版社使坏了，对他们发过来的数据, 在真正的处理之前，你写了个程序，调用用DTD一验证就知道是不是合法的，少了个字段什么的一下子就能查出来，巨爽。

后来又有人发明了DTD的改进版XML Schema ，那就是后话了。

慢慢的你就发现，XML极为灵活，描述一个东西非常方便，除了应用之间交互数据之外，用来描述你的系统的配置信息也大有永无之地。

原来你为了让代码有可移植性（说白了就是在别人的机器上安装时不用费那么大劲），把数据库的ip , 用户名，密码都写在了一个文本文件中，这样就可以只改配置而不用改动代码了

ip=192.168.0.1

name=test

user=liuxin

password=liuxin

但是碰到复杂的，尤其是层次化的配置用文本文件就捉襟见肘了，例如：

form1.name=login

form1.class=com.test.login

form1.property1.name=ok

form1.property1.type=java.lang.String

form1.property2.name=failure

form1.property2.type=java.lang.String

form2.name=logout

form2.class=com.test.logout

form2.property1.name=ok

form2.property1.type=java.lang.String

form2.property2.name=failure

form2.property2.type=java.lang.String

是不是看的头大？

改成xml 描述看看，是不是就容易理解多了:

</form>

</form>

其实不光是你，现在绝大多数Java 应用程序的配置文件都是xml , 已经成为事实的标准了。

总结：XML主要用于程序之间的数据交换，以及描述程序的配置信息。

历史知识：

早在1969年，IBM公司就开发了一种文档描述语言GML用来解决不同系统中文档格式不同的问题,这个语言在1986年演变成一个国际标准（ISO8879），并被称为SGML，SGML是很多大型组织，比如飞机、汽车公司和军队的文档标准，它是语言无关的、结构化的、可扩展的语言，这些特点使它在很多公司受到欢迎，被用来创建、处理和发布大量的文本信息。

在1989年，在CERN欧洲粒子物理研究中心的研究人员开发了基于SGML的超文本版本，被称为HTML。HTML继承了SGML的许多重要的特点，比如结构化、实现独立和可描述性，但是同时它也存在很多缺陷：比如它只能使用固定的有限的标记，而且它只侧重于对内容的显示。

同时随着Web上数据的增多，这些HTML存在的缺点就变的不可被忽略。W3C提供了HTML的几个扩展用来解决这些问题，最后，它决定开发一个新的SGML的子集，称为XML。

本文是给小白的Java EE生存指南的第4篇，讲一下几乎100%Java 开发人员都要用的 Tomcat。

为什么有Tomcat ？其实需要从Servlet 说起。

记得《给小白的Java EE生存指南(2)》 (回复“小白”查看)　提到的动态网页吗？　常见的实现动态网页的技术就是CGI。

但是作为Java 的发明人， Sun肯定要搞一个超越CGI的技术出来，之前Sun 通过Applet出了一个超级大风头，让整个世界一下子认识了Java ，不过很快发现悲催的Applet其实用途不大，眼看着互联网开始起势，一定要搭上千载难逢的快车啊。

于是Servlet 就应运而生了， Servlet 其实就是Sun为了让Java 能实现动态的可交互的网页，从而进入Web编程的领域而定义的一套标准。

这套标准说了：

你想用Java 开发动态网页，可以定义一个自己的"Servlet"（名字很怪，不知道怎么翻译） , 但一定要是实现我的HttpServlet接口，然后重载doGet(), doPost()等方法。

用户从浏览器GET的时候，调用doGet()方法，从浏览器向服务器发送表单数据的时候，调用doPost()方法。

（参见《给小白的Java EE生存指南(1)》，回复“小白”查看）。

如果你想访问用户从浏览器传递过来的参数，没问题，用HttpServletRequest 对象就好了，里边有getParameter() ，getQueryString()方法。

如果你处理完了，想向浏览器返回数据，用HttpServletResponse 调用getPrintWriter() 就可以输出数据了。

如果你想实现一个购物车，需要session, 很简单，从HttpServletRequest 调用getSession() 就好了。

你写了一个"Servlet"，接下来要运行，你就发现没法通过java 直接运行了，你需要一个能够运行Servlet的容器，这个容器Sun 最早实现了一个，叫Java Web Server, 1999年捐给了Apache Software foundation , 就改名叫Tomcat 。

所以Tomcat 就是一个Servlet容器，能接收用户从浏览器发来的请求，然后转发给Servlet处理，把处理完的响应数据发回浏览器。

但是Servlet 输出html ,还是采用了老的CGI 方式，是一句一句输出，所以，编写和修改 HTML 非常不方便。

于是 Java Server Pages(JSP) 就来救急了，JSP 并没有增加任何本质上不能用 Servlet 实现的功能。

实际上JSP在运行之前，需要先编译成servlet , 然后才执行的。

但是，在 JSP 中编写静态HTML 更加方便，不必再用 println语句来输出每一行 HTML 代码。更重要的是，借助内容和外观的分离，页面制作中不同性质的任务可以方便地分开：比如，由页面设计者进行 HTML设计，同时留出供 Java 程序员插入动态内容的空间。

Tomcat 能运行Servlet, 当然运行JSP肯定也是易如反掌。

既然是Web 服务器， Tomcat除了能运行Servlet和JSP之外，也能像Apache/nginx 那样，支持静态html, 图片，文档的访问，只是性能要差一些，在实际的应用中，一般是这么使用他们的：

Nginx 作为负载均衡服务器和静态资源服务器放在最前端，后面是tomcat组成的集群。

如果用户请求的是静态资源， Nginx直接搞定，不用麻烦后面的tomcat了。

如果是动态资源（如xxx.jsp） , Nginix 就会按照一定的算法转发到某个Tomcat上，达到负载均衡的目的。

本文是给小白的Java EE生存指南的第5篇，讲一下前端工程师必备的AJAX的来龙去脉。

回到2001年，当时的老刘还是小刘，在计算所跟着老板和四川的一个公司合作，做一个类似于OA(办公自动化)的项目。

当时小刘刚毕业，写过一些asp的程序，在小刘的意识当中，还是觉得只要你通过浏览器向服务器发出请求，服务器处理以后，需要刷新整个网页才能看到服务器处理的结果。

但是有一天我突然看到项目中大牛写的一个页面，这个页面上面是菜单，中间是一个树形结构，代表了一个公司的各个部门。

点击了菜单以后，整个页面没有刷新，神奇的是那个部门的树形机构竟然发生了变化！也就是说整个页面没有刷新，只是页面的局部发生了刷新。

太不可思议了！我赶紧打开那个普通的asp程序，看看到底是什么情况。

原来点了菜单以后，执行了一段javascript，其中创建了一个叫XMLHttpRequest的东西;

var xhr;

if (window.XMLHttpRequest){

xhr=new XMLHttpRequest(); //非IE浏览器

}else{

xhr=new ActiveXObject("Microsoft.XMLHTTP"); //IE 浏览器

}

//放置一个回调函数： state_change，当http的状态发生变化时会调用

xhr.onreadystatechange=state_change

xhr.open("GET","http://xxxxxx.xxx/xxx.asp",true); // true 表示异步调用

xhr.send(); //这是一个耗时的操作

//具体的回调函数定义

function state_change()

{

if (xmlhttp.readyState==4 && xmlhttp.status==200){

//获取到服务器返回的xml

xmlRes = xhr.responseXML;

//对xml进行处理，更新部门的树形结构，代码略

document.getElementById('deptTree').innerHTML = xxxxxxx

}

//其他代码，略

你可以想象我第一次看到这样的处理时那种震惊的表情。原来页面可以这么写， javascript 可以这么用！

其实这里体现的思想有两点：

1. 异步调用

异步的意思是说，调用一个耗时的函数（上例中的xhr.send()）以后，不等到它返回，就直接执行后续的代码了。

当然在调用它之前会放置一个回调的函数callback（上例中的state_change），等到这个耗时的函数完成以后，再来调用callback 。

为什么要这么做呢？主要是网络操作太耗时了，你在浏览器中的一个点击可能访问是地球那一边的服务器，如果是同步操作，即等待网络操作完成以后再进行下一步，就可能阻塞当前线程，甚至会导致浏览器卡死的情况。

异步调用在编程中是个非常常用的手段，后来服务器端的javascript Node.js 几乎全是基于事件的异步调用。

2. 用XML做浏览器端和服务器端的数据交换

这点毋庸解释，参见《给小白的Java EE指南(3): XML》，看看xml 的作用。

3. 局部刷新

Javascript 取到从服务器端返回的XML以后，解析该XML, 然后通过DOM对象只更新整个页面html的一部分，例如更新一个table, 一个div ....

document.getElementById('deptTree').innerHTML = xxxxxxx

异步的JavaScript和XML(Asynchronous Javascript And XML）就简称AJAX, 你看这些缩写其实没什么神秘的。

AJAX这个词2005才出现，之前已经出现了大量的“AJAX”Web应用，我认为其中最著名的就是Google Maps 它使用XMLHttpRequest异步调用服务器端来获取数据，并将数据应用在客户端，实现了无刷新的效果，极好的用户体验让Google Maps获取了巨大的成功。

【XML VS JSON】

但是在javascript中使用XML有两个问题：

1. XML 要求有开始标签和结束标签，如<name>liuxin</name> ,name出现了两次，这在网络传输中其实是一种冗余浪费。

2. javascript 需要解析xml , 然后展示到浏览器中。

第二点尤其不爽，所以就有人发展了一个叫JSON(JavaScript Object Notation) 的一个轻量级的数据格式。 JSON其实就是javascript 语法的子集，就是javascript中的对象和数组。

对象在js中表示为“{}”括起来的内容，数据结构为 {key：value,key：value,...}的键值对的结构。

数组在js中是中括号“[]”括起来的内容，数据结构为 ["java","javascript","vb",...]。

这两种结构虽然很简单，但是递归组合起来能表达任意的数据结构，这就是简单的力量，下面就是一个例子：

{

"programmers":

[{

"firstName": "Brett",

"lastName": "McLaughlin",

"email": "aaaa"

}, {

"firstName": "Jason",

"lastName": "Hunter",

"email": "bbbb"

}],

"authors":

[{

"firstName": "Isaac",

"lastName": "Asimov",

"genre": "sciencefiction"

}, {

"firstName": "Tad",

"lastName": "Williams",

"genre": "fantasy"

}],

"musicians":

[{

"firstName": "Eric",

"lastName": "Clapton",

"instrument": "guitar"

}, {

"firstName": "Sergei",

"lastName": "Rachmaninoff",

"instrument": "piano"

}]

}

由于JSON本身就是Javascript 语法的一部分， javascipt代码可以直接把他们当成对象来处理，根本不用解析XML了。

再加上JSON结构很紧凑，很快就流行开来了，现在AJAX 基本上都是在用JSON来传递数据了。

题外话：第一次看到AJAX这个词的时候，作为球迷的我脑海里第一反应是荷兰的阿贾克斯足球俱乐部，在90年代，阿贾克斯足球号称青年近卫军，一帮小孩在欧冠决赛中把如日中天的AC米兰都搞定了，后来由于《博斯曼法案》的实施，球员可以自由转会，阿贾克斯就没落了。

本文是给小白的Java EE生存指南的第6篇，讲点稍微有深度的：反射。

这里不定义什么叫反射，先来看个例子，假设我给你一个Java 类：

package com.example;

public class HelloWorld {

public HelloWorld(){

}

public void sayHello(){

System.out.println("hello world!");

}

现在要求:

(1) 你不能使用 HelloWorld hw = new HelloWorld() ，但是要构建一个HelloWorld的实例来.

(2) 调用sayHello() 方法，但是不能直接用 HelloWorld实例的 hw.sayHello()方法，说起来怪拗口的 :-)

用Java的反射功能，可以很轻松的完成上面的要求：

//第一步，先把HelloWorld的类装载进来

Class cls = Class.forName("com.example.HelloWorld");

//第二步，创建一个HelloWorld的实例，注意，这里并没有用强制转型把obj转成HelloWorld

Object obj = cls.newInstance();

//第三步，得到这个类的方法，注意，一个类的方法也是对象啊

Method m = cls.getDeclaredMethod("sayHello");

//第四部，方法调用，输出"hello world"

m.invoke(obj);

可能有人要问了，为什么不直接new 出来呢？通过反射来创建对象，调用方法多费劲啊？

这是个好问题，关键点就是：　很多时候我们并不能事先知道要new 什么对象，相反，我们可能只知道一个类的名称和方法名，很多时候这些名称都是写在XML配置当中的。

为了更好的说明问题，来看看几个SSH的例子：

【Struts的例子】

1. 在XML配置文件中定义Action

<result>/hello.jsp</result>

</action>

2. 定义Java 类

public class HelloWorld extends ExampleSupport {

public String execute() throws Exception {

......

return SUCCESS;

}

.......

}

Struts 框架的作者事先肯定不知道你会配置一个HelloWorld的Action 。

不过他可以这么做， Struts 在启动以后，解析你配置XML配置文件，发现名称为HelloWorld的Action, 找到相对于的类名example.HelloWorld, 然后就可以通过反射去实例化这个类。等到有人调用这个action 的时候，可以通过反射来调用HelloWorld的execute() 方法。

【Hibernate的例子】

1. 定义Java类和表之间映射，类名叫Event, 对应的表名是EVENTS 。

<hibernate-mapping package="org.hibernate.tutorial.hbm">

</id>

</class>

</hibernate-mapping>

2. 定义Event 类，如下所示：

public class Event {

private Long id;

private String title;

private Date date;

...... 为了节省篇幅，每个属性的getter /setter 方法略...

}

3. 查询，你可以用Hibernate 这么查询表中的数据了：

List result = session.createQuery( "from Event" ).list();

for ( Event event : (List<Event>) result ) {

System.out.println( "Event (" + event.getDate() + ") : " + event.getTitle() );

}

Struts 的作者事先也不知道你会配置一个叫Event的类。

不过他会这么处理：类名(Event)-> 数据库表名(EVENTS) -> 发出SELECT查询表数据 -> 通过反射创建Event的实例 -> 通过反射调用实例的setter方法把数据库的值设置进去

【Spring的例子】

1. 配置一个Bean

<beanid="helloWorld"class="example.HelloWorld">

<propertyname="message"value="Hello World!"/>

</bean>

2. 写一个Java 文件

public class HelloWorld

{

private String message;

public void setMessage(String message){

this.message = message;

}

public void getMessage(){

System.out.println("My Message : "+ message);

}

3. 调用

ApplicationContext context =newClassPathXmlApplicationContext("Beans.xml");

HelloWorld hw=(HelloWorld) context.getBean("helloWorld");

hw.getMessage();

我都懒得解释了，无非是根据类的名称通过反射创建一个类HelloWorld的实例，然后再通过反射调用setMessage方法，这样当你getMessage就有值了。

所以反射是很重要的，在Java EE世界里，反射最大的用途就是支持以声明式的方法（在XML中）来描述应用的行为，是Struts, Hibernate , Spring 的最核心的技术之一。

简单的来讲，反射能让你在运行时而不是编程时做下面的事情：

(1) 获取一个类的内部结构信息（或者成为元数据），包括包名，类名，类所有的方法，

(2) 运行时对一个Java对象进行操作，包括创建这个类的实例，设置一个属性的值，调用这个类的方法等等。

这篇文章只是介绍了反射的一点皮毛和用途，具体的细节还是等待你自己去发掘吧。

三、J2EE要死了？

最近有人问我说：欣哥，我们现在都用Spring， Hibernate, SpringMVC了，这Java EE是不是已经死掉了？

这个问题让我哭笑不得，因为他似乎还没有搞清楚Java EE到底是怎么回事，就给Java EE判了死刑。

Java EE是什么呢？　

简单来讲Java EE 就是一个技术规范的集合，一些核心的技术规范包括：JDBC, Servlet, JSP, JNDI, EJB, RMI, XML , JMS , JTA, JPA,JavaMail 等等。这些规范的目标很美好，就是帮助程序员开发大规模的、分布式的、高可用的“企业级”应用，只是实际的效果可能就没那么美好了。

我们先来看一看这些核心的技术规范都是干嘛的，然后再来评判Java EE是不是快要死掉了。

JDBC ： Java程序访问数据库的核心技术，不管是使用Hibernate , MyBatis, EJB, 还是自己写类库，只要你访问数据库， JDBC是绕不过去的，我还没见过在Java 中用其他技术读取数据库的案例。

（参见文章：《JDBC的诞生》）

Servlet : 简单地说，Servlet就是Web应用让外界访问的入口。当然现在直接写Servlet的越来越少，因为在框架的包装下，应用程序只需要直接写Action 或者 Controller就可以了，但这并不能否定Servlet的核心和基石地位。

JSP & JSTL：由于前后端的分离和其他更优秀的替代技术，现在用JSP当做视图层也是凤毛麟角了，更多的是在遗留系统中在使用， JSP确实在走向没落。

JSTL 是JSP Standard Tag Library, 一套标准的标签库， JSP不受人待见，JSTL就更不行了。

（扩展阅读：《JSP:一个装配工的没落》）

EJB ：曾经最为热门的技术，寄托了大家最美好的期望，但事实证明EJB 1.x 2.x 简直就是灾难， EJB3.x 虽然吸收了Hibernate的很多优秀特性，奈何大家使用轻量级类库和框架的习惯已经养成，无法翻身了。

更要命的是使用EJB需要昂贵、复杂、笨重的应用服务器（如Weblogic, Websphere等），这也是使用它的巨大障碍，再加上Spring 这个轻量级框架的崛起， EJB被彻底打入冷宫。

a.EJB实现原理：就是把原来放到客户端实现的代码放到服务器端，并依靠RMI进行通信。

b.RMI实现原理：就是通过Java对象可序列化机制实现分布计算。

RMI ：远程方法调用，让Java程序可以像访问本地对象一样来访问远程对象的方法，早期和EJB搭配用的最多，因为EJB会被部署在分布式的应用服务器中，一个机器上的程序需要访问远程的EJB，RMI是个基础的技术。随着EJB的失宠， RMI似乎也用的很少了。

RMI应该是RPC的一种实现，只能在Java 世界中使用，相对于被广泛使用的基于Web、基于HTTP的RPC调用， RMI更不受待见。

（参见文章《我是一个函数》）

JNDI：这是一个基础性的技术，可以把名称和对象进行绑定，最常见的就是通过一个名称来访问数据源，而不用关心这个数据源到底在什么地方。依然在广泛使用。

JAXP： XML在Java 中无处不在，Java EE 通过Java API for XML Processing(JAXP)来读取/解析XML文件，只是这个接口实在是不太好用，学院派气息过浓，所以现在大家都用民间开源的JDOM,DOM4J 了。

等到JSON开始流行， “悲剧”又重演了，大家都在用民间的fastjson, jackson ，似乎选择性的忘记了官方的 Java API for JSON Processing。

官方的不如民间的，也是Java世界的一大特色。

JMS： Java世界访问消息队列的标准方式，各大消息队列产品都支持，没有理由不用它。

（扩展阅读《Java帝国之JMS的诞生》）

JavaMail ：在Java中发送邮件，又一个基础性的技术。

JTA： Java Transaction API，主要是为了在多个数据源之间实现分布式事务，但是JTA在在高并发和高性能的场景下表现不佳，很多时候并没有用JTA，而是用异步的方式来解决问题。

（扩展阅读：《Java帝国之宫廷内斗（上）》《Java帝国之宫廷内斗（下）》）

除了上面列举的，Java EE还有很多规范

Java API for WebSocket

Java Persistence

Concurrency Utilities for Java EE

Java EE Connector Architecture

Java API for RESTful Web Services (JAX-RS)

Java API for XML-Based RPC (JAX-RPC)

Java Management Extensions (JMX)

JavaBeans Activation Framework (JAF)

......

这些规范在日常的Web开发中可能用的更少，SSH/SSM 中也可以找到对应物，给大家的感觉就是这Java EE的规范没用了，要死掉了。

我倒是觉得应该是Websphere , Weblogic这些应用服务器不行了，从上面的描述中可以看到，活得最滋润的几个是JDBC, Servlet, JMS, 最不如意的就是EJB了，而EJB恰恰是昂贵的商业应用服务器Weblogic , Websphere 的一个核心功能。

在云计算的环境下，在容器技术、微服务当道的情况下，那种集中式的、繁琐的、笨重的部署注定要走向消失。现在很多后端开发，用Tomcat这种主要支持Servlet/JSP的Web服务器，再配上轻量级的SSH,或者SSM就足够了。

说了这么多，可能有人想到这个问题：这些规范是怎么制定的的呢？

答案是JCP(Java Community Process)，在这个组织中，一些特定的成员（Full Memeber）如果想把某个技术如JDBC变成Java 规范，就需要发起一个叫做Java Specification Request (JSR) 东西，公开让大家进行评判，最后由执行委员会投票，决定是否可以发布成为正式规范。

理论上每个人都能够成为JCP的成员，但是有发言权的，能上桌玩牌的还是一些巨头，如Oracle, Google, IBM, SAP等等，所以有很多人认为JCP制定出来的Java EE规范只是考虑大厂商的利益，不顾普罗大众的死活，这种脱离人民群众的规范是没人用的，是要死掉的。

这么说确实有一定的道理，我个人觉得Java EE规范中有一些精华会保留下来，被一直使用，直到Java退出历史舞台。至于其他的Java EE规范，就让他们自生自灭去吧。

（完）

更多内容请关注微信公众号【Java技术江湖】

一位阿里 Java 工程师的技术小站。作者黄小斜，专注 Java 相关技术：SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程，偶尔讲点Docker、ELK，同时也分享技术干货和学习经验，致力于Java全栈开发！（关注公众号后回复”Java“即可领取 Java基础、进阶、项目和架构师等免费学习资料，更有数据库、分布式、微服务等热门技术学习视频，内容丰富，兼顾原理和实践，另外也将赠送作者原创的Java学习指南、Java程序员面试指南等干货资源）

走进JavaWeb技术世界1：Web后端与J2EE的由来

后端程序员都干些什么

我为什么对后端编程情有独钟？

J2EE到底是何方神圣

一、J2EE历史

二、J2EE入门指南

三、J2EE要死了？