微服务：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 被一路追捧，人们几乎把它跟 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 的支持正在走下坡路。

随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个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 访问的微服务）。

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

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

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

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

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

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

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

结论

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

查看英文原文： Java EE is dead

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。