微服务:Java EE的拯救者还是掘墓人?

有人认为,微服务的大行其道是在给Java EE下达死刑判决书。也有人认为,Java EE已死的论调可笑至极。的读者朋友,你们怎么看?
引言
有人说,Java确实过于臃肿,经常“小题大做”。但PHP、Node.js扩展方面短板太明显,做小应用可以,大型应用就玩不转了。另外,Java EE领域有太多优秀框架可以解决开发效率的问题,事实上借用Spring等框架,开发的效率丝毫不亚于PHP。
互联网时代的Java开发者,很多都不是基于Servlet和EJB来开发Web应用,而且WebLogic、WebSphere也只会存在于大公司的存量系统中,互联网公司的Java都是Tomcat的世界。
那么,微服务能完全弥补Java EE的短板吗?对于Jave 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被一路追捧,人们几乎把它跟Java EE容器混为一谈,它仍然运行在Java EE的Servlet容器里,这些容器沿用的是十年前的设计,并没有考虑到多核CPU和NIO。
在这期间,PHP奋起直追。PHP使用更少的内存和资源,得到很多公司的支持。一些CMS平台,比如WordPress、Drupal等都是基于PHP构建的,这些平台吸引了大批PHP开发人员。不过,虽然PHP仍然是现今最流行的编程语言,但它也有自己的短板。它运行速度不是很快,而且难以横向扩展。
2009年,Ryan Dahl启动了Node.js项目,它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当,Node.js可以极大地提升响应速度,单个服务器的吞吐量可以媲美一个Java EE服务器集群。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的支持正在走下坡路:
https://developers.slashdot.org/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-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容器。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值