最近，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，但效果并不理想。所以，我希望字节码的变更不会太频繁。