我们知道同时期其实在后端的开发是有很多的竞品的。

比如说Java开发平台.Net的开发平台还有曾经昙花一现的什么Perl和PHP还有现在的go这些都能用来开发后端。

但唯独JavaEE是持续时间最长最成熟产品最多选择性最多从业人员也是最多的一个开发平台。

其实这一切在JavaEEJava一开始出现的时候30年前就已经决定了。

它走了跟其它的东西完全不同的一条道路它建立的不是一个产品或者是一种语言Java建立的是一个生态一个市场让很多的企业能参与到生态里头来在市场上竞争从而形成百花齐放优胜劣汰这样才会使得Java的市场慢慢的一步一步的发展到今天成为占比最大的一个后端的开发市场。

以生态市场来说没有任何一个后端的开发生态市场比Java更加的成熟。

Java其实曾经有三个版本——JavaSE、JavaEE、JavaME。

就是我们最熟悉的JavaSE这是Java最基本的语言版本每一个版本中间增加不同的特性。

在JavaSE的基础上头为了开发服务器端的应用或者我们称之为企业级的应用它有JavaEEJavaEE其实不是一个产品它是一系列的规范我们后面会讲从一开始它就是一个规范而不是像Java那样的是一个产品这个规范其实包含了开发后端应用的所有所需要的技术当然它不是一开始就这么大的是随着后端的开发的技术不断的发展JavaEE的规范也在不断的扩充和修改从而形成了今天庞大的JavaEE的这样一个规范。

它还有一个是它试图占领移动端但是这个是不成功的我们知道移动端今天基本上是安卓和ios的天下ios就是封闭系统跟Java没关系是吧安卓还是基于Java的但是它不是基于JavaME的而是就是基于Java的这样的一个结构。

在JavaME的移动版来说今天已经销声匿迹了今天我们所能看到的主要也就是JavaSE和JavaEEJavaSE的每一个新版本的发布也紧跟着会有一个新的JavaEE的发布因为它会用到JavaSE中间的一些新特性从而产生一个新版本的JavaEE基本上是这样的一个特征。

我们从最开始的起源开始JavaEE起源于99年当时的Sun公司大家知道Java是Sun公司的但是Sun公司倒闭了Sun公司被Oracle公司收购了所以现在是Oracle公司的Java。

Sun公司提出了一个新的成员就是它要在企业级应用上头去定一个规范这个规范是什么规范企业级的应用要以容器和组件的方式来提供服务的。

我们知道之前我们写程序的时候你是写个程序这个程序放到机器上运行就好了。

但对于企业级的这个东西来说其实它要管的事情太多了它要管网络通讯要管安全要管多线程并发等等这些事情。

所以你要在企业级的应用环境中间去写一个程序你要把这事情都管了其实是挺困难的。

Sun公司当时提出的想法就是把一些共性的东西用容器去管个性化的东西比如说每个企业自己的业务由组件去管然后容器和组件一起构成我们最终的企业级的服务来提供我们企业级的应用这是它的最基本的想法

就是把企业级的后端应用把它分成了容器和组件容器管共性的东西组件管个性化企业的这些业务需求为了让这个东西能形成一个生态它定义了一系列的规范就是容器该怎么做做什么组件该怎么做做什么容器和组件之间该怎样连接到一起它定义了一系列的规范把这个规范称之为JavaEE的规范。

所以JavaEE从一开始出现它不是首先出现了一个产品而是出现了一个设计这个设计就是服务器端的应用是分为容器和组件的然后容器有一系列的规范组件有一系列的规范只要你符合规范的组件和容器就能够合起来构成我们企业的应用这就是最开始出现的J2EE的概念。

容器所面对的其实是开发商很多的开发商都可以按照JavaEE的规范去开发各种各样的容器。

比如大家所熟悉的Tomcat就是一个容器同样符合规范的容器还有很多比如说Jetty也是符合JavaEE的容器。

对于开发者来说你开发的程序是组件我开发的程序是在Tomcat容器里去跑的因为Tomcat容器和Jetty容器都符合容器的规范所以我开发的组件是既可以在Tomcat跑也可以在Jetty中间跑这就使得这不是一个单一产品的市场而是它定义的一个规范在每一个规范下面都是有很多的产品可以做出来然后这些产品可以竞争然后从而优胜劣汰最后整个市场会往前发展这就是JavaEE的最开始的这样的一个思路。

从99年的12月份开始出现了第一个版本的JavaEE的这样的一个规范这样的一个规范把后端的服务分成了容器和组件定义了一个清晰的架构和全景明确了说组件应该做什么容器应该做什么而且对于Sun公司来说它并不是说这个容器只能由Sun公司来做这个容器它可以把规范公开了以后可以让所有的厂商只要你有兴趣就来做这样的一个容器。

我们来看一下在99年12月份的第一版的JavaEE那时候叫做J2EE的结构是什么样的

它的容器分成两种容器一种叫做Web容器一种叫做EJB容器为什么分成两种容器

它跟当时的技术是有一定的关系的当时我们在做企业级应用的时候主要是两种架构一种是B/S的架构

B/S的架构叫什么叫做浏览器Browser/Server的架构就是基于网页的浏览器这样的一个架构C/S的架构是什么是Client/Server架构就是前端是一个应用程序后端是这个服务器这样的一个架构。

它分成两个容器主要是针对于B/S架构因为当时99年那个时候上网还是很奢侈的事情但是从技术界来说已经认识到说B/S的架构会成为未来的主流

所以它在做JavaEE的架构的时候你可以看到它就考虑的是B/S的架构对于B/S的架构它有一个问题就是服务器往前端丢的是什么呢是HTML是吧浏览器看到是HTML所有的界面和结果都是用HTML来呈现的因为我们是一个应用程序而不是一个死页面这个HTML会根据你的业务逻辑HTML的内容和你的业务逻辑不断的变化所以HTML的产生是动态的而不是静态的不是一个死文件你填的内容包括长什么样子都其实根据你的业务逻辑在不断的变这个HTML势必是由服务器产生的因为逻辑在服务器上是吧而不是在前端在浏览器里头是肯定是没有逻辑的逻辑在服务器上所以只能由服务器根据业务逻辑算出来的结果来渲染形成HTML然后送给前端前端其实很简单就是拿到HTML把它展现出来就好了这是当时的这样的一个架构。

所以它把服务器里头就分成了两个容器一个容器负责渲染生成HTML一个容器负责去做业务逻辑。

这么做的主要的原因它因为我们在体系结构中间有一个MVC的这样的一个分层的架构在面向对象中间会讲它其实就是基于这样的一个思想MVC的分层的架构提出的一个J2EE的最初的体系结构前面的Web

Container就是其中的V叫做View层EJB的Container就是后面的模型层Model用来负责做业务逻辑。

但是在技术架构上面你可以看到这两个容器的规范里头是有很多相同的地方当然也有不同的地方下面这一部分都是相同的它都支持比如说JDBC大家应该知道JDBC就是J2EE中间的最早就存在的一个规范访问数据库的规范不同的数据库厂商会按照J2EE的JDBC的规范去开发JDBC的我们叫做Driver

JDBC的驱动程序只要你符合JDBC的规范我们在上面写代码的时候其实都是基于JDBC去访问的而不是基于关于数据库的厂商的逻辑去做的那个规格去做的所以JDBC是大家熟悉的这就是个J2EE的规范。

支持这个事务的规范就是JTA支持这个消息驱动的规范JMS支持如何发邮件的规范Java

Mail以及说它中间有一个相互互联的规范叫做RMI-IIOP这是Web

Container和EJB

Container负责做逻辑所以它之间要相互调用会产生这一切的规范这些规范都是一样的不同的地方在于说在Web

Container中间主要是用Servlet和JSP来形成渲染的HTML而在EJB的Container中间是靠的EJB来实现我们的业务逻辑就是用EJB的Bean来实现我们的业务逻辑。

Container主要负责HTML的渲染而EJB这个容器主要负责业务逻辑然后它们之间是可以相互访问的访问的方式是通过我们在中间看到的RMI-IIOP规范来实现相互的访问。

对于这两个容器来说它都通过JDBC可以去访问数据库所以从技术上来说你在Web

Container中间也可以通过JDBC去访问数据库也可以在EJB中间通过JDBC去访问数据库不过它推荐的做法来说是Web

Container只负责HTML的渲染而EJB的容器负责业务逻辑去访问数据库之类的。

对于前端来说我们刚才说到它分为B/S的前端和C/S的前端C/S前端就是基于JavaSE的在JavaSE上头你依然可以使用JDBC的规范。

就是JDBC的规范不一定是要用到容器里的容器当然支持JDBC的规范可以为容器的组件提供JDBC之类的这些东西但是大多数JavaEE的规范都可以直接在JavaSE的用只不过是说这时候并没有一个容器的存在而你需要自己去把这些比如JDBC的驱动这些东西自己Load起来。

如果是在服务器端在容器里头你其实根本不用去管这些东西是怎样被Load起来的它的管理都是由容器去负责管理的但是在前端虽然没有容器但是你可以直接去使用。

Java在最开始的时候支持在HTML中间插入一个Applet去运行Java的程序因为最开始的HTML是不具备任何逻辑功能的是纯粹就是用来显示界面的当然我们在前端会有很多的比如说动态的要求那个时候还没有JavaScript所以Java在那个时候提供了一个Applet的这样的一个小插件插在前面的浏览器里头可以运行Java程序从而具备Java程序所提供的一些动态的特性包括去访问后端的东西等等这些特性当然这个东西死亡了死亡的原因是因为后来出现了——JavaScript那个东西就不依赖于任何东西由浏览器原生的支持JavaScript去运行所以它的性能和效率它的效率会比通过

Applet的去进行Java程序的效率会更高但是作为历史我们知道它的沿革是这么来的这是最早的版本。

第一个版本的J2EE的规范规范里头就已经出现了我们所说的两个非常核心的概念服务器端的部分是由容器和组件构成的。

容器是由厂商提供的按照规范可以提供各种各样的容器只要这些容器是符合J2EE规范的你按照这个规范所写的组件就能在这个容器里去跑所以这样的组件和容器的体系结构的划分以及用技术规范去规范容器和组件的开发创造了一直到今天为止依然非常繁荣的JavaEE的这个生态链的存在这是最早的版本。

2001年的3月份J2EE1.3增加的主要是什么增加的就是XML。

基本上就跟着当时技术的潮流在1999年时候XML其实还并不是大家广泛接受的一个东西服务器服务器之间的调用还是通过一些二进制的协议比如说RMI-IIOP来做的所以在2001年3月份的1.3版本中间它主要修改的就是RMI-IIOP这是它最大的一个改进。

全部改成了基于XML的这样一种通讯的方式所以它也衍生了XML的一系列的这些规范比如说怎么去读写XML同时在这个时代JavaEE出现了以后订立了容器和组件的这样一个结构订立了规范去发展。

在2002年10月份Rod

它这本书的中心的想法是什么它觉得在这个结构里头你可以看到它在服务器端分成了Web

Container和EJB

Container中间也全部可以做它在提出一个问题为什么需要EJB

Container我们不要这个EJB

Container是否能开发出一个应用出来所以它以这样的一个想法写了这么一本书。

《J2EE

Container它完整的开发出了一个在线的订座系统为了开发在线订座系统它使用了大量的面向对象的设计的方法设计了一个底层的框架这个框架里头第一次支持了两个东西

一个叫做依赖注入一个叫做AOP这两个东西当时在J2EE中间都是没有的就在J2EE规范中间没有关于IOC的定义和AOP的定义。

至于什么是IoC什么是AOP一两句话讲不清楚我们在之后的课中间再讲因为这是Spring框架两个最核心的思想一开始就出现了这个思想而这两个思想又跟面向对象的设计息息相关也就是我们要完整的讲完面向对象的设计以后你才会知道IoC起什么作用AOP起什么作用然后再到Spring框架中间去看说Spring框架是怎样来实现IoC和AOP的。

在书中他展示了如何在不使用EJB的情况下构建高质量可扩展的在线座位预定程序。

为了构建这个程序他编写了超过30000行的基础结构代码牛逼《Expert

One-on-One

Container的规范然后加上了在J2EE的规范中间没有的IoC的特性和AOP的特性形成了一个在线订座系统这本书的出版其实让当时大家觉得眼光一亮因为J2EE的规范这时候已经相对来说有二三十条规范了所以在J2EE上去开发东西会相对比较繁琐比较累而这本书的出现其实给大家开了一条新的路子就是我们可以不要J2EE的整套东西我只选择其中的一小部分东西甚至很少的一部分东西我就能开发出一个系统来虽然这个系统可能在某些方面不如在重量级的J2EE的结构上的开发出来的系统那么强大但是这个系统它其实有它自己的这样的一个特点这本书出版了以后其实已经起了很大的反响。

Caroff这个人在那本书下面写了一个书评说这本书里头所写的内容是令人激动的它创造了一个新的时代很长大概中心的意思是这样的意思为什么要把他的书评拿出来。

Hoeller和Yann

Johnson跟他说你这个东西做得太有意思了我们把这本书里头的一部分代码把它拿出来做成一个独立的框架这个框架的名字就叫做Spring这个名字就是Yann

Rod

Johnson的书以非常详尽翔实和实用的方式介绍了J2EE的最佳实践。

从编码标准陈规bean实体单元测试设计决策持久性缓存EJBmodel-2表示层视图验证技术还有性能等方面都有翔实的论述。

书中案例是带领大家做个java项目开发的绝佳之旅从开发现状、制约因子风险及至最佳决策。

它不光是一本教科书还是一个Java开发的知识库。

2003年6月Spring

1.0版发布。

实际上在1.0发布之前Spring就已经得到开发人员的广泛使用。

2004年8月Rod

JohnsonJuergen

Sampaleanu共同创立了interface21一家专注于Spring咨询培训和支持的公司。

Yann

Johnson也在2012年离开了Spring团队。

Juergen

JavaEE发展历程2003-2007

三个人就开始着手来写这个框架与此同时J2EE的框架推出了1.4版本也就是在2003年的11月份推出了1.4版本。

在这个版本中间它其实首次加入了Web

Service第一次出现在J2EE的框架中间大家知道2003年是互联网刚刚出现的年代第一次互联网的浪潮破灭了然后开始复兴的这个年代那个时候Web的网页大家还没有玩溜J2EE的标准里头已经开始出现了Web

Service也就是我们现在的Web服务的这样的一些相关的规范只有这些规范出现以后才会有不同的厂商上面去开发出相应的产品然后大家在这部分上去用这个产品才发现这个东西有什么样的好处才会往后发展所以这是在2003年11月份的事情其实它们没有发现它的最大的竞争对手已经产生了。

也就是在2004年3月份一年的时间内三个人开发出了一个框架叫做Spring1.0版本发布Spring的框架与J2EE的框架最大的区分在于什么

Container的这部分的规范除了这个以外它还加入了它两大核心的特性。

这是在J2EE中间没有的就是AOP和IoC

因为AOP和IoC这两个会要讲很多的时间所以我们知道这两个非常重要特性这两个特性的加入会使它的程序开发变得异常的简单很多原来需要管的事情就通过AOP和IoC把它简化了。

除了这两个以外它的另外一个改进就是我们上面写的它用XML配置Bean对象。

就是配置组件Bean对象其实是我们说的组件在之前的J2EE的标准中间所有的配置需要靠用代码来写就在这个1.4版本的时候它是所有的配置需要靠代码来写的那个时候就要写一个简单的hello程序大家知道入门一个框架或者入门一个程序语言第一个程序都写的是hello是吧你简简单单在打出一个hello在J2EE的1.4版本中间需要写100多行代码其中99行代码都是用来写配置我们配置这个容器配置组件能在这个容器里跑出来然后组件跑起来以后就打了一行hello出来所以虽然这些代码在之后在做其它的工程时候是可以重用的但是J2EE的一个臭名昭着的地方就是它起步慢你要打个hello先要搞清楚那100行代码是怎么回事你才能把个hello打出来。

JavaScript

所以Spring框架首先改变这一点就是它不再用代码去写这个配置而是用文件去写配置。

当时用的就是XML文件文件去写配置的好处在于什么配置在运行的时候是可以改的我代码写好了以后如果我想修改配置我不需要重新编译打包这个东西而仅仅去修改它的XML文件就可以了当然这是一个很大的特性当然后来它发现这也是一个很大的弊病。

因为它会有安全性的问题我的代码部署上去以后如果安全没控制好别人把你的XML一改了你整个系统就完蛋了所以后来它也慢慢的收回了这样一个特性但在当时这是一个革命性的进步加上它的AOP和IoC大家觉得Spring的推出真的是耳目一新。

Spring的其它部分来说它同样支持了我们在J2EE中间的相应的规范比如说访问数据库的JDBC这个是一定要的比如说Web部分的一些的HTTP

Request的一部分的规范它都是支持的也就是我们在前端Web

Container的规范它选择性的支持了一部分这是第一版的Spring。

第一版的Spring发布了以后大家会发现在Spring的结构上去开发一个应用比在J2EE上的去开发一个应用要简单很多而且工作量也要小很多所以J2EE就意识到这个问题来了

原来是没有竞争者原来是我定规范然后大家都在我的规范底下去开发东西现在有人只选择我一部分规范还有一部分规范不遵循我的还推出了一些新的概念来跟我竞争怎么办我就开始改规范人家好的我就来学。

它首先做的一件事情就是跟Spring一样改成配置的方式来配置组件也就是它的EJB的3.0这样的话它就在配置的部分来说跟Spring是完全一样的。

但是这时候它还没有把它的IOC和AOP引进进来。

但是它提出了一些新的概念。

比如说我们在SpringSpring框架中间大家可以看到它有支持ORM的框架比如说Hibernate

MyBatis那这个时候基本上你的程序要是写的是Hibernate或者写的是MyBatis就是跟绑死了的所以J2EE说我是定义规范的我就定一个新的规范叫做JPA。

这个JPA的规范所有的ORM都通过JPA的方式去访问这样的话你无论是用Hibernate还是用MyBatis只要遵循JPA的规范你的代码就都可以去跑MyBatis还没完全支持JPA这就是规范的力量。

Web

Service部分在之前一直是J2EE走在了Spring的前面Spring这时候还在做它内源性的东西还没有关注Web

2006年10月份Spring的框架发布了第二个版本第二个版本它把XML的配置进行了大幅度的简化也就是最开始的XML。

它没有最开始的是用DDT来配置的很麻烦。

所以在2006年的10月份的第二个版本的Spring框架中间用了Schema来配置XML这就是XML的进步所以Spring也跟它进步了。

除了这个特性以外大家可以看到它引入了很多在JavaEE中间的规范原来没有JPAJavaEE做了JPA这个挺好的我Spring也支持JPA是吧所以它就它选择性的认为在JavaEE中间好的规范我就拿进来这样的话我在Spring框架中间可以用JPA去写代码就无需要关注你是MyBatis还是Hibernate了。

当然它在表现层增加了更多的插件这些东西其实有一些是J2EE的规范比如说JSF和JSP这是在J2EE中间做前端表现层的规范。

它也有很多不是J2EE的规范比如说像Struts

Spring其实比J2EE的规范提供了更大的灵活性在当时我们称这个Spring框架叫做SSH——就是StrutsSpringHibernate

SSH构成一个最简单的构成应用的这样的一个架构我们可以看到Spring的框架其实是在JavaEE的规范之外提供了另外一种可能当然它也在不断的吸收JavaEE的这些好的东西这是在06年的10月份。

07年的11月份Spring的框架有了一次决定性的改变这不是一个大版本数而是一个小版本数2.5但我们为什么把它提出来讲是因为从此Spring的框架引入了注解配置注解配置的来源是来自于我们之前的JavaSE

5因为JavaEE5和JavaSE5是同步发行的就是JavaSE每一次升级之后就会跟着会有一次JavaEE的升级JavaSE5的一个重大的升级就是引入了注解就是我们在类前面用去标志注解方法前面用去标注注解在JavaSE5之前是没有的。

标注注解引入到了JavaSE的库里头Spring框架看见了觉得这个东西非常有用

它可以用来写我们的配置之前的配置是用XML写的大家知道XML很麻烦XML有一个是一对一对的而且XML那一对里头还要写有意义的东西所以往往XML会弄到好大一串这样的一个东西其实看起来是很麻烦的写起来也很麻烦改成注解来写的话我想配哪个类

我想配哪个方法在类前面和方法前面直接写。

而且配置和代码合成了一体它的好处就在于说如果我的代码改变了我看我的配置是不是会受到影响如果我的配置改变了我的代码是不是会受到影响从程序员的维护来说提供了极大的便利性如果是分开的你把代码改了如果改配置你还去找那个XML在什么地方很麻烦这是一个革命性的改变。

我们知道在Java的库里头Java的代码中间如果加了注解的话Java的类在Load的时候在装载的时候是可以把注解读出来的因为Java是具有反射机制的是吧这种语言所以它可以支持自动扫描也就是我不再需要去配置说这个东西在什么地方了我只要配置说这个东西可能在某个好了在整个项目的根目录底下它会自动去扫描说什么类有加了这样的一个注解我就把它作为我们的配置读进来这样的话会使得什么会使得我们的配置又变得更少了很多东西我们不需要写只要告诉它说你去扫找到了那就有没找到就没有这个配置。

所以用注解和用自动扫描的方式的引入使得Spring的配置大幅度的减少。

减少了70%以上剩下的部分就基本上靠注解和自动扫描去完成除了这个以外它还引入了测试框架因为我们知道任何一个东西如果不能测试的话这个东西不是一个成熟的东西它在Spring框架中间引入了我们称为单元测试的JUnit的框架和TestNG的框架这是Spring框架的一次脱胎换骨的变化。

它的IoC和AOP一直是领先于JavaEE的规范的引入了这样的一个机制以后它在配置的是大幅度的优于JavaEE的框架。

JavaEE发展历程2009-至今

Spring干什么我就学什么所以在JavaEE的6版本中间它把Spring框架的两大法宝——IoC和AOP我学过来定了两个规范叫做CDI和DI。

我们有时候叫做IoC有时候叫做DependentInjection叫做依赖注入或者说控制反转是Spring发明的依赖注入是Java发明的两个东西是同一个事。

是因为它不能表现出来我从抄过来的所以它发明了一个新的词叫做DI其实是一码事就把它的AOP和IoC把它抄过来了变成了JavaEE的规范不仅仅是在这里在JavaEE的这个版本中间其实它有加入了我们在后面看到的Restful风格的API也是基于JSON的Restful

在面向服务的这一个部分来说JavaEE永远是走在前面的走在Spring的前面的Spring在不断的跟JavaEE规范中间关于Web

但是在内源性上头比如说配置IoCAOP这些东西Spring是走在JavaEE前面的所以JavaEE在跟着Spring来学这些内源性的东西AOP和IoC被JavaEE学去了。

Spring

Spring又放了一个大招就是它在2009年的12月份引入了一种新的配置方式叫做Java配置。

用程序来写配置我们说在JavaEE的最开始的时候就是用程序写配置那时候被人诟病说我写一个hello要写100多行代码所以Spring框架改用XML来做配置是用注解来做配置大幅度减少了配置的方式然后JavaEE把它学过去了。

这时候它又发现Spring又返回来又开始用代码来写配置了为什么要用代码来写配置因为它会发现默认配置是有问题的就是我加了注解加了自动扫描以后它其实是一个默认配置我会去默认扫描说有注解的那些东西来作为我的配置但是有些时候我不能用默认配置就是我一定要告诉它说我虽然那里有这个东西但我不能用它那怎么办

传统方式它之前的方式是要用XML来写的用XML来写XML的弊病始终是在那就是它写起来麻烦而且它的安全性不好把它程序做好以后人家是可以去改XML的。

所以从3.0开始加入了一个新的特性——就是它用Java代码来写最原始的方式。

但是这时候它并不是用Java代码去写所有的东西因为Java代码去写就必须要显式声明的。

就是我不能用默认的这些东西我改用Java代码去写这样的好处在于说

第一你写配置时不容易出错因为Java代码是要编译的第二它编译完了以后配置是不能改的所以它的安全性等等这方面会更好。

当然它在内源性的部分来说会增加更多的东西比如说它把AOP上面把AOP的特性从原来的单纯的AOP改成了AspectJ也可以支持所以它把AOP分成了两个——AOP和Aspects在类的加载上头加了——Instrumentation这使得在Java类被加载的时候可以做一些桩来做一些额外的这些工作当然我们其实用的比较少。

Language使得它可以用描述语言去定义一些更复杂的配置信息等等。

还有它最下面加了一个Test2.5开始有了Test所以3.0的结构上最下面是Test然后是Core然后是Core上面支持的Core上面支持的IoC然后AOP然后是访问数据的一块和做Web的这一块这是3.0的版本。

13年6月份的时候发布的7里头增加了一个现在为止影响很深的变化JavaEE7支持HTML5,

这是在2013年——10年前JavaEE已经加入了响应式编程的规范支持HTML5所以大家可以看到在这一块Web

Service响应式编程这一块JavaEE的规范永远是走得非常的前卫的。

Spring这个部分来说它在4.0版本其实做的改变不大你可以看到从结构上来说没有太大的改变支持了条件化配置但是我们把4.0提出来中间是因为4.0中间的有一个小版本做了一个革命性的变化大概是4.2还是4.3它引入了SpringBoot。

SpringBoot的引入使得——Spring项目的配置再大幅度的减少。

也就是说原来是用注解自动扫描加上Java的代码你还需要写一些的配置包括说你的依赖因为我们知道Java代码的最讨厌的地方就是说你要依赖很多Jar包原来的管理方式来说是有一定的问题的因为我要引入一个Jar包这个Jar包还要依赖其它的Jar包那要一堆出来然后这些Jar包还会相互打架等等这些问题依赖的引入配置的这些问题。

在SpringBoot中间通通一键性的解决了SpringBoot用一种默认的方式去管理这些依赖以及这些依赖的这些配置这是在Spring4.3引入的SpringBoot的工程放进来了从此Spring就跟SpringBoot一起了这再没有人有了SpringBoot以后再没有人想直接用Spring而是通过SpringBoot去管理Spring的工程所以就把Spring和SpringBoot画上了等号。

JavaEE的8的版本我们可以看到它引入了更多的JSON的这些特性这个版本引入了响应式编程这个版本是一个划时代的意义它的化时代的意义在于JavaEE的版本号永远停在了JavaEE8。

因为这时候发生了什么发生了Sun公司被Oracle公司收购了然后Oracle公司发现Java这个东西是一个不赚钱的东西为什么不赚钱因为它是规范而不是产品我辛辛苦苦定义了一堆的规范然后让一堆的公司去开发它们的产品然后它们产品在卖钱规范也不卖钱是吧所以这就是为什么Sun公司最后会被Oracle公司收购了。

Oracle公司做了一个决定既然你是个规范我是一个商业公司我的商业公司好像不适合于全力去支持这样的一个规范它就把这个东西交给了阿帕奇的基金会大家知道阿帕奇是一个开源的基金由它去维护这样的一个规范而Oracle公司作为一个商业公司着力去在规范上面去开发自己的产品去赚钱是吧所以JavaEE的版本停留在了8。

为什么因为JavaEE是Sun公司的注册商标它没把商标转给阿帕奇基金会它只把规范转给它了所以阿帕奇的基金会不能再使用JavaEE来标识后续的产品它们就做了一个投票投票的结果是它把这个名字改成了JakartaEE所以JakartaEE也有JakartaEE8JakartaEE8就是JavaEE8只不过是JavaEE8被移交给了这个阿帕奇基金会被改成了JakartaEE8后来JakartaEE9包括9.1都有后续的版本出现。

Spring的框架在这个JavaEE停止了以后又发布了一个新的版本5.0就是跟着JavaEE去学了响应式编程。

因为响应式编程是高并发大负载的一个非常有效的解决的方案。

响应式编程我们在面向对象的课里头有提到过它其实是用的函数式编程就是函数式编程的方式这意味着它跟我们传统的命令式编程的方式是完全不同的设计方法和编程的方式传统的整个链的Spring的框架里头的东西通通都不能用了Spring框架5.0开始大家可以看到Spring的框架被切成了两半

全套的东西都是不同的从最上面到最下面都完全不同唯一相同的就是上面看到那个SpringBoot是一样因为SpringBoot是没内容的SpringBoot就是负责去管理依赖管理配置信息的所以它跟具体的技术的特征是没有什么太大的关系但是下面的所有东西全部都不同因为它是两种完全不同的编程的方式。

Stack我们要讲Reactive

Stack因为这个是在近5年来会越来越成为一种主流的不是主流的会成为一种有影响力的编程的方式它到目前为止还没有撼动Servlet

Stack这一条线的应用。

因为作为函数式编程来说我们其实在设计方法上头并没有像我们在命令式编程的设计方法中间那么成熟就换句话说我们知道所有的东西你基本上用命令式的编程方式是能够把它做出来的但是它用函数式编程是不是能做出来数学上说是可以万事万物都可以函数化是不是万事万物都是函数的转换都是从输入的值域转成这个转成输出的域是吧。

但是实际上你再去用函数的编程去解决问题的时候还有很多事情我们从来没做过所以是发展的趋势但是它是不是能解决所有的问题我们现在还在探索中。

JavaEE的后续的这个介绍的话它依然在不断的来扩展这个新的功能我们就不仔细讲了因为它已经转换到这个阿帕奇的基金会了转换到阿帕奇基金会以后其实阿帕奇基金会还需要一段时间来稳定所以说它们在后续的8和9版本中间并没有做出一些革命性的变化也就是它最后一次革命性变化是把响应式的编程引入到了

JavaEE的规范中间到目前为止9版本中间并没有什么特别大的这样一个东西所以我们就不讲。

第一把XML的配置彻底成为过去式。

因为我们可以看到它的发展的过程来说慢慢的用注解替代XML减少XML的使用显式的还会用XML做然后用Java的程序来替代XML的使用。

第二个是它会全面支持JakartaEE

9提出的一些规范在Spring6.0中间可能会有选择的吸收进来。

第三是它会支持云原生的SpringBoot3.0因为我们刚才说了SpringBoot是一个管理配置和管理依赖的所谓支持云原生的SpringBoot3.0意味着说它会全面微服务化。

因为我们刚才说了云原生的这样的一个结构无论是我们在设计上头和实现上头都得要考虑微服务化和容器化就是Docker化这样的一个考量这样的话才会根据你的负载的差异来动态的弹性调整在服务器端的应用的配置。

我们把两条线把它画了出来大家可以看到Spring和JavaEE其实是相生相克的。

两产品线在JavaEE的规范中间在JavaEE的市场中间其实是两条平行线但是中间大家在不断的吸收对方的一些东西然后放到自己的产品里头来又不断的提出新的东西去对对手产生这样的一个竞争的优势我们希望JavaEE的规范被移交给阿帕奇基金会以后还能提出一些革命性的这些东西出来那同样Spring的框架从一开始所提出的轻量化设计的这样一个想法在今天的云原生的这样一个架构上其实是有优势的因为云原生会更加讲究每一个单独的这样的服务的轻量化你才可以很方便的在服务器架构上的去弹性化的部署所以这样的一个发展我们可以看到已经精彩了差不多接近30年未来的话有两个产品线在这么不断的竞争我们希望看到说在未来的几十年里头我们还能看到Java像今天这样在整个后端服务器市场中占有差不多半壁以上的江山。

当然我们今天有很多新的语言在跟它竞争大家知道目前它面对最大的竞争是哪种语言——Go语言goroutine语言跟

Java语言最大的优势就是在它是完全基于云来设计的云原生的这样的一个应用我们可以看到因为Java无论是JavaEE还是Spring承载了太长的历史今天在云原生的架构上头Go语言对于Java语言来说是有一定的优势的但是我们相信Spring已经首先做出了反应也就是它会在SpringBoot中间完全支持云原生的这样一个结构JavaEE我想也会做出反应来因为这是反应了这个市场之所以会精彩了30年就是因为这个市场给很多的不同的产品提供了机会让这些产品去竞争相互促进才会发展成为今天这个样子所以这是我们花点时间来简要的讲了一下JavaEE的规范和Spring发展的历史。

我们可以看到随着几十年的发展JavaEE规范已经非常的庞大了到最后一个官方版本就是JavaEE8的官方版本来说已经达到了40个规范。

到今天就是Spring5.0里头它仅支持40个规范中间的9个它有选择性的支持了其中的一小部分特别是它前面在Web

Container那里头的那些规范EJB里头的EJB的规范它基本上把它大幅度的给它抛弃掉了支持这些小部分的规范加上它自己的特性Spring的框架从来没有在说我所有东西都要遵循JavaEE的规范它相信它自己做出来的东西终究会成为JavaEE的规范过去的30年已经有看到JavaEE的规范中间有学了很多Spring框架的东西当然Spring的框架东西也在某些部分来说超前于JavaEE的规范我们希望这两个东西包括未来的go语言三个东西会相互促进一起向前发展。

从体系结构上来说我们最早期的体系结构是这样的我们把这个应用是部署在服务器上的按照JavaEE的规范来说它的服务器是分为Web服务器和应用服务器Web服务器就是我们说的Web容器的服务器而应用服务器就是EJB的服务器Web容器负责渲染我们的HTML而EJB的服务器是应用服务器负责我们的应用逻辑所以它是这么取名的。

用Spring的框架来说它往往会把Web服务器和应用服务器合一因为它没有后面的EJB的容器所以说如果采用Spring框架来说其实这两个服务器会合成一个变成一个更简单的架构但随着Web技术的发展我们知道Web技术的发展中间有一个重要的事件——就是AJAX。

我们后面会提到它也就是在HTML上面加上了JavaScript加上了JavaScript以后HTML不再需要由服务器去渲染产生了你可以把HTML写成死文件

HTML仅是用来描述格式的里头的内容靠什么——靠JavaScript。

其实不是JavaEE的标准但是这是我们知道在Web发生了一个重大的改变这样的一种方式就使得说

我们可以把HTML和JavaScript把它放到浏览器里头。

然后在浏览器里头运行JavaScript去访问我们的服务器。

服务器去做我们的应用逻辑得到数据把数据送给前面的浏览器。

前面浏览器用JavaScript去解析这些数据再来决定这些数据如何在界面上去显示。

靠浏览器的JavaScript去完成服务器已经完全脱离了界面层的任何职责这时候你会发现JavaEE的Web

Container就没什么用了是吧因为它不需要在服务器端生成HTML的网页了服务器端就是做应用逻辑的事情接收前端发来的请求去做业务逻辑把得到的结果用数据我们现在数据的格式是JSON的方式送回前端。

所以今天的结构在Spring架构上又形成了我们看到了这样的一个结构只不过是此时的Web服务器不是彼时的Web服务器了此时的Web服务器是个单纯的Web服务器就是单纯用来存

JavaScript的代码和HTML的一个单纯的文件服务器就是死服务器没有任何动态的东西它的作用就是当客户端来访问的时候把HTML和JavaScript传到前面的浏览器上去然后前面浏览器再去访问这个应用服务器去拿到逻辑和数据而这时的应用服务器其实是用JavaEE的标准的Web

Spring

JavaEE的标准到今天我们看到最新的9的版本中间还是有EJB的Container这就是死不改悔拖了30年一直被Spring来刺说你EJB没有任何意义但是它就坚持了30年还在做这个东西当然可能坚持有坚持的好处。

这是这样的一个结构我们说到当负载大的时候当负载大的时候大家想到了一个解决方案就是把服务器增加——无论是Web服务器还是应用服务器都增加。

但这个简单的方式会带来成本的增加所以从成本的核算来说弹性增加才是更好的而且弹性增加增加的其实并不是给所有的应用都平等的分服务器而是我们把其中高负载大并发的那部分应用分给更多的计算资源给它而那些平时不是负载很大的东西分更少的资源给它这才是一个更好的使用这样的服务器资源的方式。

所以在分布式应用的这样的一个前提下在云原生的情况下头我们要把应用做到如何让服务器能够弹性的给它分配资源这就是我们所说的云原生的结构。

考虑你的代码将来是会被弹性的分配的你如果不这么写代码是没办法做到弹性分配的以后如果去到互联网公司去就业的话它们基本上在高并发大负载的时候都是弹性分配的这样的一个云原生的架构来写代码这是我们总体的这样的一个结构。