Java EE即将死去,毫无疑问!

  在Java问世之初,包括IBM、BEA、Oracle在内的一些巨头公司看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢?答案就是使用这门语言构建复杂无比的服务器,让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了Java EE规范、JSR规范,以及WebLogic、WebSphere等服务器中间件。

  在这些服务器上面部署了大型的程序包,它们运行缓慢,消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦,作为对他们的补偿,他们从雇主那里获得了丰厚的报酬。

  因为耗资巨大,几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站,你必须支付一大笔费用来运行这些服务器,哪怕你只用到了Servlet容器。在很长一段时间里,Java被用在企业和公司里,因为只有这些大公司能够负担得起数百万美元的服务器费用,并为那些企业级开发人员支付高额的薪水。

  Rod Johnson在2003年发布了Spring框架,Spring提供了IoC和对POJO的支持,帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升,大量开发人员转向Spring,把EJB丢在一边。应用服务器开发商看到了这一点,他们在Java EE 5里提供了一些可以减轻开发人员负担的特性。可惜的是,Spring被一路追捧,人们几乎把它跟JavaEE容器混为一谈,它仍然运行在Java EE的Servlet容器里,这些容器沿用的是十年前的设计,并没有考虑到多核CPU和NIO。

  在这期间,PHP奋起直追。PHP使用更少的内存和资源,得到很多公司的支持。一些CMS平台,比如WordPress、Drupal等都是基于PHP构建的,这些平台吸引了大批PHP开发人员。不过,虽然PHP仍然是现今最流行的编程语言,但它也有自己的短板。它运行速度不是很快,而且难以横向扩展。

  2009年,Ryan Dahl启动了Node.js项目,它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当,Node.js可以极大地提升响应速度,单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Node.js是一个很好的作品,但它也有自己的局限性。Node.js难以扩展,也难以与遗留的系统集成。

  2014年,Undertow出现了,它是一个基于Java的非阻塞Web服务器。从techempower.com的测试结果来看,在一个价值8000美金的戴尔服务器上,它可以每秒钟处理几百万个请求,而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的,它的核心部分只需要1M内存,它还包含了一个内嵌的服务器,这个服务器使用不到4M的堆内存。

  基于Undertow Core构建的Light Java Framework是一个微服务容器,它支持设计驱动及生成代码,并支持运行时安全和运行时验证。

  Java EE厂商

  多年前,Java EE厂商,比如Oracle和IBM,他们花费数亿美元开发应用服务器(WebLogic和WebSphere),这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了,因为JBoss迅速抢占了市场份额,Oracle对Java EE的支持正在走下坡路。

  随着微服务越来越多地受到关注,这些应用服务器很难有好的销量,因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用,为了在WebLogic上测试一行代码改动,居然用了45分钟时间。

  Java EE客户

  从客户角度来看,耗费巨资购买这些服务器是不值得的,因为Java EE所承若的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上,所以你需要花更多的钱去升级服务器,因为厂商可能不再支持旧版的服务器,而这样的更新会花费你数百万美元。

  于是一些聪明人不禁要问,为什么我们要把应用部署在这些庞然大物上?为什么我们要把应用打包成一个ear包或war包,而不是jar包?为什么我们不能把大型的应用拆分成更小的块,让它们可以独立部署和扩展?

  微服务

  微服务是这些问题的解药。Wikipedia把微服务定义为“……一种软件架构风格,复杂的应用由一些独立的进程组成,这些进程使用与语言无关的API进行交互。这些进程服务规模很小,高度离散,聚焦在一个很小的任务上,使用模块化方式来构建系统”。

  微服务架构让构建应用变得更加容易,而且应用被拆分成单独的服务,这些服务可以被任意组合。每个服务可以被独立部署,也可以被组合成一个应用。这些服务还可能会被其它应用依赖。它加快了服务的开发速度,因为只要定义好接口,服务可以并行开发。