微服务：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包，以及各类组件包，由于服务器资源太过昂贵，要尽量地物尽其用。

不过从最近几年的发展状况来看，以前的方式有些落伍。操做系统服务器一直在变化，虚拟资源能够被当成组件发布，好比EC二、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，因此咱们要改变之前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。如今咱们能够在Docker里运行JVM，Docker只不过是一个进程，但它能够表现得像一个操做系统同样。Docker运行在云端的操做系统上，而云端的操做系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁全部，而是被不少互不相识的人共享。若是出现流量高峰怎么办？很简单，使用更多的服务器实例。这就是为何要把Java微服务运行在一个单独的进程里，而不是Java EE容器或servlet容器。

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

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

随着微服务逐渐流行起来，不少厂商开始尝试把他们的Java EE Web服务转成微服务，这样他们就能够继续卖他们的过期产品，API Gateway就是这些厂商中的一个。

Jason Bloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web

服务转成微服务的趋势提出了质疑：

http://techbeacon.com/dangers-microservices-washing-get-value-strip-away-hype

微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来讲，微服务跟SOA是不同的，由于整个环境已经发生了完全的转变。

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

虽然容器对微服务来讲不是必需的，不过微服务能够很容易地运行在容器里。何况，把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其余容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。

Docker简化了微服务的开发，让集成测试变得更简单。

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

当前微服务很热，你们都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是否是发展趋势？想必这些是不少程序员共同的疑惑，若是你也有一样的疑惑，想要深刻了解、熟练掌握微服务架构，能够加个人架构交流群：650385180，我会在群里分享我从业多年总结出来的的经验，也会在群里分享这些技术知识点供你们学习免费下载。

结论

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