最近，IBM发布了Open Liberty—WebSphere Liberty的开源实现—进一步体现了IBM为开源社区所做出的贡献。这一版本支持基于Eclipse MicroProfile和Java EE API构建微服务和云原生应用。

WebSphere Liberty于2012年问世，是一个轻量级的小型应用服务器，用于在Docker、Kunernetes或Cloud Foundry上部署符合Java EE 7规范的应用程序。IBM网站上对其进行了描述：

眺望未来，我们相信Java、开放标准和开源的组合是构建卓越应用程序的最佳方式。因此，我们在去年联合了Red Hat、Payara、Tomitribe和其他一些公司一起致力于推动使用Java来开发微服务，我们还为我们的MicroProfile和Java EE运行时创建了开源版本。

这并非这些公司之间唯一的一次合作。除了OpenLiberty，IBM还发布了他们的开源JVM Eclipse Open J9。在今年早些时候，IBM还与Google及Lyft一起开发了开源项目Istio—一个用于监控微服务的服务网格。

Open Liberty与Open J9及Istio组合而成的技术栈可以用于开发Java微服务和云原生应用。开发人员还可以使用Open Liberty Tools—一系列轻量级的工具，用于开发、组装和部署应用程序到Open Liberty。Open Liberty的代码库可以在GitHub上找到。

InfoQ采访了IBM WebSpere和Liberty运行时架构师Alasdair Nottingham，谈论了Open Liberty相关话题。

InfoQ：Eclipse Open J9和Istio服务网格是怎样被集成到Open Liberty中的？

Alasdair Nottingham：Open Liberty与符合TCK标准的任何一种JVM兼容。不过目前Liberty还不能完全兼容Java SE 9，而Eclipse Open J9只能运行Java SE 9的字节码。这是我们需要去解决的一个问题。因为Eclipse Open J9是基于IBM JVM开发的，所以如果它与Open Liberty能够支持相同版本的Java SE，那么它们的结合就是天衣无缝的。从我们的经验来看，相比在Hotspot上运行Open Liberty，J9在内存占用和启动速度方面更具优势。

Istio意欲在Docker或Kubernetes环境中支持多种语言运行时，它通过在运行时与外部环境中间扮演协调者角色来实现这一目的。这也意味着，用户可以在不修改应用程序代码的情况下，在发生故障时使用服务选择、服务超时、重试和回路断路器功能。

在这种架构下，Open Liberty可以很容易地与Istio运行在一起。Open Liberty也支持Eclipse MicroProfile Fault Tolerance规范，为应用程序提供了类似的容错API，开发人员可以选择使用Istio或自己编写Java代码来处理这些问题。如果Istio已经配置了这些容错模式，那么就可以停用Open Liberty中的这些功能，因为没有必要让应用程序和Istio做相同的事情。

InfoQ：MicroProfile和Java EE 8之间的相互影响程度是怎样的？

Nottingham：Java EE 8是一个非常重要但也很有限的更新版本，而Eclipse MicroProfile正在探索新的API，用于增强Java EE的实际应用。

Eclipse MicroProfile对Java EE的未来已经产生了重大影响，Eclipse软件基金在这方面的进展速度惊人。最新的EE4J章程显示，随着Java EE移交给Eclipse，MicroProfile将会对Java EE的发展产生主要影响。

InfoQ：在过去的一年中，为了加快Java在微服务方面的应用，你都与Red Hat、Payara和Tomitribe做了哪些工作？会继续和他们合作下去吗？

Nottingham：这是一次非常有成效的合作。虽然过渡到Eclipse对每一个人来说都是一个巨大挑战，但我们在MicroProfile 1.2上所取得的进展很让人感到欣慰。每个人都使出浑身解数，希望在JavaOne上有所斩获。不管是观众还是参与者，都能从中体会到乐趣。

我们的合作当然会继续下去。这对于Eclipse MicroProfile的成功和Eclipse Enterprise for Java（EE4J）的成功来说都是至关重要的。

InfoQ：Java每六个月的发布周期对Open Liberty的开发和后续的发布有什么影响吗？

Nottingham：是否对Open Liberty的发布周期产生影响要看JVM发生了哪些变更。从我们的经验来看，更新到新版本字节码会占用比较多的时间。

Java EE重度使用了字节码操作，所以更新到新版本字节码需要做大量的工作。如果每次发布新版的Java时都伴随字节码的更新，那么我们就很难跟上步伐。从过去的经验看，我们使用了差不多六个月时间更新到新版的Java，但效果并不理想。所以，我希望字节码的变更不会太频繁。

InfoQ：是什么让Open Liberty有别于其他的应用服务器？

Nottingham：Open Liberty与其他应用程序有一些不同之处。首先是配置的简易性。我们努力让配置变得简单易用，配置文件可以被提交到版本控制系统里，这对于DevOps来说是一个好消息，因为配置文件可以和代码放在一起了。另一方面，我们的应用服务器可以为应用程序提供它们所需要的功能。

Open Liberty从一开始就被设计成可以为应用程序提供必要功能的应用服务器，我们把它们叫作功能单元。我们为Java EE和MicroProfile提供了所有功能，而如果你只需要其中的一小部分功能，那么就可以得到一个小型而快速的服务器运行时。

InfoQ：关于Open Liberty，还有其他什么可以分享的吗？

Nottingham：从功能方面来看，我们要支持Java EE 8。从GitHub上可以看出，我们正在开发Servlet 4、JAX-RS 2.1、JPA 2.2、JSON-B和JSON-P。其他特性也会陆续添加进来。

Open Liberty还支持Eclipse MicroProfile 1.2。我们的开发团队还参与了新的EE4J项目，所以我很期待我们到时候能够提供一个实现版本，并支持Java SE 9。

Holly Cummins是IBM Bluemix Garage London的技术组长，也是WebSphere Liberty Profile的前任交付经理，她也分享了她在OpenLiberty方面的经验：

我个人对我们在Liberty上所做的工作感到非常自豪，看到它在GitHub上开源也感到很激动。Open Liberty有一些非常棒的模块化和动态特性。运行在本地时，它支持热部署，可以在无需重新启动的情况下增加、移除或重配置整个服务器。运行在云端时，它的模块化特性可以让未使用的功能不占用任何磁盘或内存。另外，我也很喜欢它那清晰且统一的配置方式。

有趣的是，Liberty是第一个可以运行在Raspberry Pi上的应用服务器（我们随后也让它运行在Android设别上）。而Liberty这种适合小型部署的特点却也让它成为大规模云原生应用的最佳选择，这不得不说是一种悖论。