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进行交互。这些进程服务规模很小,高度离散,聚焦在一个很小的任务上,使用模块化方式来构建系统”。

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

微服务具备弹性和伸缩性。微服务不只依赖单个服务器和部署,它们可以被发布到多个机器上,或者多个数据中心及其它任何可用的区域。如果一个服务失效,可以启动另外一个。因为整个应用被分解成了微服务(小型服务),可以很容易地对其中某些热门的服务进行横向扩展。

如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等,那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器,并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包,以及各种组件包,因为服务器资源太过昂贵,要尽可能地物尽其用。不过从最近几年的发展情况来看,之前的方式有些落伍。操作系统服务器一直在变化,虚拟资源可以被当成组件发布,比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势,硬件、云技术、多核CPU和虚拟技术也在发展,所以我们要改变以前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM,Docker只不过是一个进程,但它可以表现得像一个操作系统一样。Docker运行在云端的操作系统上,而云端的操作系统运行在虚拟机里,虚拟机运行在Linux服务器上。这些服务器不是归谁所有,而是被很多互不相识的人共享。如果出现流量高峰怎么办?很简单,使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里,而不是Java EE容器或servlet容器。

微服务一般会提供基于HTTP/JSON的API端点。这样可以很容易地与其它服务(开源或闭源的)集成,只要这些服务提供了HTTP/JSON接口。服务可以通过更有意义的方式被消费、被组合。EC2、S3及其它来自Amazon(或其它公司)的服务就是最好的例子。基础设施会成为应用程序的一部分,而且它们是可编程的。

使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进,而不会影响到整个应用。如果所有的组件都提供了可编程的API,那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。

随着微服务逐渐流行起来,很多厂商开始尝试把他们的JavaEE Web服务转成微服务,这样他们就可以继续卖他们的过时产品,API Gateway就是这些厂商中的一个。

Jason Bloomberg是Intellyx的主席,他在一篇文章里指出了传统Web服务和微服务的区别,并对把传统Web服务转成微服务的趋势提出了质疑。

微服务不是企业服务总线里的Web服务,也不是传统的面向服务架构,尽管它沿袭了SOA的一些基本概念。从根本上来说,微服务跟SOA是不一样的,因为整个环境已经发生了彻底的转变。

微服务架构的环境是没有边界的:端到端,基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化,DevOps为IT基础设施提供框架,帮助自动化开发、部署和管理环境。

虽然容器对微服务来说不是必需的,不过微服务可以很容易地运行在容器里。况且,把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其它容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发,让集成测试变得更简单。

容器有助于微服务开发,但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进,不过微服务包含的东西远比容器多!

结论

应用开发的风格这几年一直在变化,而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用,这些小型应用被部署在云端的容器里。开源微服务框架Light Java为这些运行在容器里的微服务提供了很多特性,它支持设计驱动,开发者只需要把注意力专注在业务逻辑上,剩下的事情可以由框架和DevOps流程来处理。

文章转载自 开源中国社区 [http://www.oschina.net]

时间: 2024-09-08 16:24:31

Java EE 即将死去,毫无疑问!的相关文章

主流Java EE应用服务器横向对比分析

在开源Java应用服务器领域,像JBoss.Tomcat及Apache的Geronimo,他们不仅仅是商 业领域的领跑者,同时是技术领域的先行者.当然,所有的Java EE应用服务器的实现不 尽相同,但其很多方面具有一定程度的可比性.本文对JBoss4.2.Geronimo 2及Tomcat 6 三种开源的Java EE应用服务器,就他们的特性.部署及性能等方面进行一一比较. 一.前言 当企业级的Java应用程序需要真正的应用部署时,Java EE应用服务器是必不可少的工 具.研究表明,除了商业

将Java EE单体应用打造成微服务

本文讲的是将Java EE单体应用打造成微服务[编者的话]如何将单体应用拆分成微服务相信是很多人共同的疑问,本文作者就技术和组织结构等方面为我们提供了一个思路,一起来看看吧~ 紧接着上篇为什么微服务应该是事件驱动的介绍博客,我还想再花一些文章和篇幅就这块为我即将参加的一些演讲做些准备(与你相约jBCNconf及在旧金山的Red Hat峰会).你可以通过在twitter上关注我@christianposta来跟进这个项目的最新进展.在本文里,我们将讨论第一部分,即如何拆分一个单体应用. 这些文章里

JAVA EE一年工作经验面试问题

问题描述 有Java EE 一年开发经验的面试时一般会问到哪些问题啊?这一年我主要负责项目里的后台数据处理的,前台的那些经验不多,会有影响吗? 解决方案 前台没什么,主要问你框架,我给你提供点面试题: JAVA面试题0.1如何处理并发?单例 ---共享对象 还有就是 在执行算法和存储结构的方法前加锁 一.Java基础知识1.Java有那些基本数据类型,String是不是基本数据类型,他们有何区别.区别:首字母大写就可以看出他是个类,string和8种基本类型都属于类.2.字符串的操作: 写一个方

调查显示,Java EE 用户需要更多的 REST

自世纪初以来,Java企业版(Java EE)一直是许多企业以 Web 为中心,面向服务,支持云计算组件的核心.不过最近有许多用户,包括它的死忠粉也一直在问,它的框架是否已经过时,并正在被更轻量.更敏捷和更简单的设置,如容器.云服务或 API 取代. 为了回应 Java EE 现在面临的问题,Oracle 的 Java EE 开发团队在社区对 Java EE 的用户进行了一次调查,以了解该框架后续该为其企业基础服务的方向.共有1693个 Java EE 社区成员参与了调查,这些发现将有助于确定哪

甲骨文展示Java平台企业版(Java EE)发展的最新成果

在旧金山举行的2011年JavaOne大会上,甲骨文公司展示了其推动Java 平台企业版(Java EE)发展的最新成果. Java EE 继续大受欢迎,并有越来越多的http://www.aliyun.com/zixun/aggregation/7155.html">开发人员采用,包括Oracle GlassFish Server在内的Java EE组件获得了4000万次下载. 自2009年12月推出以来,6个主要IT厂商已经推出了经过认证.开源和商业实施的Java EE 6,使其成为迄

Oracle:将继续支持Java EE

从2015年秋天开始,Oracle将开发资源转移到其它项目,服务端Java应用企业框架Java EE的开发事实上已经停止了.然而该公司发言人Mike Moeller却称甲骨文承诺会继续支持Java和Java EE. 据悉,即将发布的最新版本为Java EE 8,目前Oracle正在与Java社区的关键伙伴密切合作新版工具,具体细节将在今年9月的JavaOne会议上与Java社区分享. 但这一消息却着实让Java社区的开发者有些"蒙圈",因为前后不一致的表述会让人摸不着头脑.不过既然甲骨

甲骨文将推出Java EE 7版本扩展对HTML 5的支持

甲骨文全球大会,2012 年 10 月 2 日--在2012 JavaOne大会上,甲骨文展示了 Java平台企业版 (Java Platform, Enterprise http://www.aliyun.com/zixun/aggregation/29806.html">Edition,Java EE) 的最新开发进展,并针对即将推出的Java EE 7 版本进行了讨论. 越来越多的开发者采用Java EE,而且超过5000万用户下载了Java EE组件,从而使其成为最受开发人员欢迎的

方便 Ajax 与 Java EE 的集成

随着 Ajax 的兴起,对于消解这个热门技术的谜团并有针对性地处理在它的使用中出现的问题的需求出现了.高级 IT 专家 Patrick Gan 利用这个机会,研究了在 Java EE Web 应用程序中引入 Ajax 对整个开发生命周期可能产生的影响.对采纳 Ajax 基于异步通信的模式会存在的问题保持清醒,有助于踏上有效集成 Ajax 的正确道路. Asynchronous JavaScript + XML (Ajax)是个相当新的术语(有些人说它是旧酒装新瓶),在不同的 Web 开发社区中,

图片-java ee中的EJB出现错误:

问题描述 java ee中的EJB出现错误: 解决方案 看异常貌似是jdbc/MysqlDB_pm 这个数据源配置的问题