2016 年会成为 Java EE 微服务年吗？

进入 2016 年时间还不是很长，让我们回顾下去年年底的一个预言。去年 12 月，来自 C2B2 的 Steve Millidge预测，2016 年将会成为Java EE微服务年。在一定程度上，这是基于 Steve 在 JavaOne 上的演讲，他在演讲中详细地讨论了这个主题。此外，Steve 还是 Payara 的联合创始人，Payara 的目标用户也是对微服务感兴趣的 Java EE 开发人员。Steve 还认为，SOA 和微服务之间的差别很小，这种观点我们以前听说并且报道过。他在视频中指出：

“微服务与 SOA 没什么不同。它还是关于 SOA”。

当然，现在还存在争论，因为他的背景和当前的工作重心，Steve 可能会发现自己很难保持客观的态度。不过，早在 2014 年，微服务还处于起步阶段，Adam Bien 就描述了理想的 Java EE 微服务：

[…] 理想的 Java EE 微服务是一个单 [实体控制边界] 组件，在一个 WAR 包中，部署在单台服务器 / 域中。在这种情况下，开发人员可以单独地发布和重新部署单个组件（又称微服务）。WAR 包之间不可能直接调用方法，因此，WAR 包将不得不使用比如 JAX-RS 来彼此通信。

我们在去年年底就微服务、DevOps 和 Java EE 相关内容采访了Markus Eisele ，他详细论述了自己为什么认为 Java EE 将会在微服务生态圈的发展中扮演重要的角色。还有一些其他使用 Java EE 编写微服务的方法，包括 TomEE 和 WildFly 。 KumuluzEE 是 JavaOne 2015 Duke 选择奖的其中一个获奖者，该框架是一个 Java EE 微服务框架。该框架的联合创建者 Matjaz Juric 解释说：

KumuluzEE 是第一个使用标准 Java API 的微服务框架。微服务架构的重点是将应用程序开发成服务并将这些服务单独部署；没有一个框架提供自动化部署和配置，是不可能使用 Java EE 实现真正的微服务架构的。

让我们看一些人们如何看待微服务和 Java EE 的其他例子，这会非常有趣，因为有些人严格来讲并不属于传统的 Java EE 领域。例如，早在 2014 年，Alex Soto 就论述了为什么 Java EE 和 RxJava 是一个很棒的方案。不过，并不是每个人都认可使用 Java EE 能使开发人员采用微服务。正如 Rick Hightower 所说的那样：

如果你将一个 WAR 文件部署到一个 Java EE 容器，那么你很可能不是在做微服务开发。如果你在一个容器或 EAR 文件中包含超过一个 WAR 文件，那么你肯定不是在做微服务开发。如果你将服务部署为 AMI 或 Docker 容器，而且你的微服务有一个 main 方法，那么你可能是在编写微服务。

而且，Rick 也不认为微服务与 SOA 相同：

事实上，它们在许多方面是完全相反的。例如，SOA 往往采用 WSDL，后者是一种非常严格的、强类型的服务端点定义方式。WSDL 和 XML 模式中所有的未知量都来自 XML。

当然，我们已经多次讨论过， SOA 和 Web Service 常常没有关系。不过，Rick 及其他一些人确信，Java EE 太过臃肿或者说笨拙，以其为基础构建微服务并不合适。 Jeppe Cramon 认为，Java EE 之所以是一个糟糕的基础还有更为根本的原因：

如果我们将两路（同步）通信与小 / 微服务结合使用，并根据比如“1 个类 =1 个服务”的原则，那么我们实际上回到了使用 Corba、J2EE 和分布式对象的 20 世纪 90 年代。遗憾的是，新生代的开发人员没有使用分布式对象的经验，因此也就没有认识到这个主意多么糟糕，他们正试图重复历史，只是这次使用了新技术，比如用 HTTP 取代了 RMI 或 IIOP。

如果微服务和 SOA 密切相关，那么可能会有一种观点，就是微服务可以像 SOA 那样采用一种技术无关的方式。你认为呢？2016 年会成为Java EE 微服务年吗？如果有的话，Java EE 会在微服务中扮演什么角色？

查看英文原文： Java EE and Microservices in 2016?