MicroProfile 对微服务框架的影响 | InfoQ 圆桌

本文要点

• 从 2018 年开始，Java 社区出现了多个微服务框架，包括 Micronaut、Helidon 和 Quarkus，它们对基于微服务和云原生应用的开发产生了一定的影响。

• MicroProfile 社区和规范的创立是为了让企业级 Java 开发人员更加高效地交付微服务。这一努力已经影响了当前开发人员设计和构建应用程序的方式。

• MicroProfile 将会继续演化，当前的 API 将会发生一些变化，也很可能创建新的 API。

• 开发人员应该熟悉 Heroku 的“十二要素应用”，这是一套适用于任何语言或框架的指导原则，其目标是为了创建云就绪的应用。

• 当需要决定采用微服务还是单体风格构建应用的时候，在选择要使用的工具和架构之前，开发人员要分析业务需求和技术背景。

2016 年年中，作为对 Oracle 在发布 Java EE 8 方面停滞不前的直接回应，社区发起了两个新的倡议，也就是MicroProfile和 Java EE Guardians（现在被称为Jakarta EE Ambassadors）。Java 社区认为，随着用于构建微服务应用的 web 服务技术的出现，企业级 Java 已经落后于时代了。

MicroProfile 倡议是在2016年6月27日Red Hat的DevNation会议上发起的，它是由 IBM、Red Hat、Tomitribe、Payara 等厂商协作创建的，旨在为企业级 Java 提供微服务。MicroProfile 1.0的发布是在 JavaOne 2016 上宣布的，它包含了三个基于 JSR 的 API，这些 API 被视为创建微服务的最低限度要求，即JSR-346：上下文和依赖注入（CDI）、JSR-353：JSON 处理的 Java API（JSON-P）以及JSR-339：RESTful Web 服务的 Java API（JAX-RS）。

到 2018 年 2 月MicroProfile 1.3发布的时候，已经创建了八个基于社区的 API，以补充最初的三个基于 JSR 的 API，用来构建更加健壮的基于微服务的应用。随着MicroProfile 2.0的发布，增加了第四个基于 JSR 的 API，即JSR-367：JSON 绑定的 Java API（JSON-B）。

原定于 2020 年 6 月发布的 MicroProfile 4.0被推迟了，以便于按照 Eclipse 基金会的授权成立MicroProfile工作组。该工作组定义了MicroProfile规范流程和正式的指导委员会，该委员会由各组织和 Java 用户组（Java User Group，JUG）组成，即亚特兰大JUG、IBM, Jelastic、Red Hat和Tomitribe。预计其他的组织和 JUG 会在 2021 年加入。MicroProfile 工作组在 2020 年 12 月 23 日发布了 MicroProfile 4.0，其特性是对12个核心API进行更新并与Jakarta EE 8保持一致。

MicroProfile 的创始厂商提供了自己的微服务框架，分别是Open Liberty（IBM）、WildFly Swarm/Thorntail（Red Hat）、TomEE（Tomitribe 和Payara Micro（Payara），它们最终都支持了 MicroProfile 倡议。

在 2018 年的年中，Red Hat 将 WildFly Swarm（这是 Red Hat 的核心应用服务器WildFly的扩展）重命名为Thorntail，从而为它的微服务框架提供自己的标识。但是，不到一年之后，Red Hat 发布了Quarkus，这是一个“为 OpenJDK HotSpot 和 GraalVM 量身定做的 Kubernetes 原生 Java 栈，基于最优秀的 Java 库和标准精心打造”。Quarkus 被称为“超音速亚原子的 Java”，在 Java 社区迅速流行了起来，以至于 Red Hat宣布Thorntail在2020年7月寿终正寝。Quarkus 加入了相对较新的框架Micronaut和Helidon的行列，这两个框架都是在此之前不到一年前引入 Java 社区的。除了 Micronaut 之外，所有这些基于微服务的框架都支持 MicroProfile 倡议。

本次虚拟座谈会的核心主题分为三部分：首先，讨论 MicroProfile 倡议如何影响微服务框架和云原生应用的构建。其次，探讨使用微服务和单体架构构建云原生应用的方式，以及最近重新回归基于单体架构的应用开发趋势。第三，讨论构建基于微服务和云原生应用的几项最佳实践。

专家列表

• Cesar Hernandez：Tomitribe 的高级软件工程师

• Emily Jiang：IBM 公司 Liberty 微服务框架的架构师和倡导者

• Otavio Santana：Platform.sh 的开发者关系工程师

• Erin Schnabel：Red Hat 的高级首席软件工程师

InfoQ：2016 年首次引入的 MicroProfile 倡议是如何影响现在的开发人员构建基于微服务和云原生的应用的呢？

Hernandez：MicroProfile 一直致力于让 Java 开发人员在创建新的分布式应用的过程中提升他们的效率，同时也让他们能够改善其现有的 Jakarta EE（以前被称为 Java EE）架构。

Jiang：得益于 MicroProfile 发布的 API，使用 MicroProfile 的云原生应用变得轻便和可移植。有了这些标准的 API，云原生应用的开发人员可以聚焦于他们的业务逻辑，因此他们的生产率得到了明显提升。云原生应用不仅可以在最初开发所用的运行时上运行，还可以在支持 MicroProfile 的不同运行时上运行，如 Open Liberty、Quarkus、Helidon、Payara 以及 TomEE 等。开发人员只需要学习一次 API，不需要再担心为了达到相同的目标而重新学习另外一套完整的 API。

Santana：云原生这个词仍然是一个很大的灰色地带，它的概念依然处于讨论之中。例如，如果你阅读十篇关于该主题的文章和书籍，所有的这些材料都会描述不同的概念。然而，这些概念的相同点在于它们的共同目标，那就是在云计算模式下获取技术的最大效益。MicroProfile 普及了这一讨论，并为公司和社区提供了一个地方，让他们来提供成功的和不成功的案例。除此之外，它还通过 API 推广良好的实践，比如 MicroProfile Config 和十二要素应用中的第三要素。

Schnabel：MicroProfile 倡议为 Java 开发人员，尤其是习惯于 Java EE 理念的开发人员，提供了一条前进的道路。具体的规范，比如 Config、Rest Client 和 Fault Tolerance，定义了对微服务应用至关重要的 API。这是一件好事儿。

InfoQ：从 2018 年开始，Java 社区中出现了 Micronaut、Helidon 和 Quarkus。你们认为这种趋势会持续下去吗？随着我们的发展，会不会有新的微服务框架出现呢？

Hernandez：是的，我认为新的框架和平台有助于协同，从而能够在生态系统中产生创新。随着时间的推移，这些创新可以引发新标准的产生。

Jiang：我很高兴地看到不同的框架不断出现以帮助 Java 开发人员来开发微服务。显然，这意味着 Java 依然具有吸引力，仍然是开发微服务的首选。我看到的另外一个趋势就是，新出现的框架都采用 MicroProfile 作为开箱即用的方案，实现云原生应用的开发，比如 Quarkus、Helidon 等。从个人来讲，我认为会有更多的微服务框架出现。同时，我也预测它们会比较明智地采用 MicroProfile 作为它们的云原生方案。

Santana：是的，我坚信这种类型的框架将会是一个大的趋势，尤其是探索 AOT 编译和应用冷启动所带来的收益方面。

框架对反射的使用有其自己的权衡。例如，在应用的启动和内存消耗方面，框架通常会调用Class.java中的内部类ReflectionData。它会以SoftReference进行实例化，这需要一定的时间才能释放内存。所以，我觉得未来有些框架会使用反射来生成元数据，而有些框架则会在编译期生成这类信息，比如使用Annotation Processing API或类似的技术。举例来说，我们已经在CDI Lite中看到了这种演变。

这种框架的另外一个趋势就是借助GraalVM支持原生镜像。这种方式在与无服务器协作时非常有意思，毕竟如果你的代码只运行一次的话，那么像 JIT 和垃圾收集器这样的代码改进就没有意义了。

Schnabel：我并不认为这种趋势会停止。随着微服务变得更加专业化，有很大的空间来思考应用中应该包含什么。我们将会继续推动微服务去除不必要的依赖，减少应用的大小和内存占用，这将会推动新 Java 框架的产生，或者导致其他语言的微服务的出现，毕竟其他语言的库中不用承载 20 多年的约定。

InfoQ：现在 MicroProfile 有了 12 个完善的核心 API，你认为还需要更多的 API（除了独立的 API 之外）来进一步完善构建更健壮的基于微服务和云原生的应用吗？

Hernandez：最终，我们需要的不仅仅是 12 个核心 API。生态系统不仅局限于 MicroProfile 和 Java，工具、基础设施和其他的利益相关者会极大地影响新 API 的创建。

Jiang：MicroProfile 社区会自我调整并保持敏捷。它会与底层的框架或云基础设施一起转型。例如，由于新成立的 CNCF 项目OpenTelemetry（OpenTracing + OpenCensus），MicroProfile 需要将 MicroProfile Open Tracing 向 OpenTelemetry 进行整合。与之类似，之前所采用的技术可能不再是主流技术，MicroProfile 需要与新的趋势保持一致。例如，被广泛采用的度量框架Micrometer，它为最流行的监控系统提供了一个带有 instrumentation 客户端的简单门面，MicroProfile 社区有意愿和 Micrometer 进行写作。

我认为 MicroProfile 可以改进的另外一个领域就是提供一些指南，比如如何实现日志记录，要求所有的 MicroProfile 支持者提供 CORS 功能等。如果读者有任何建议的话，请在 MicroProfile Google Group中开启对话。我个人希望在 2021 年初能够就 MicroProfile 应该关注的新倡议和各方的一些偏差展开对话。

Santana：是的，另外现有的 API 也有需要进行改善的地方。很多事情需要和 Jakarta EE 团队一些协作。第一点，就是在 API 中更多地拥抱十二元素应用的理念。例如，通过 MicroProfile Config API，使得需要凭证（如用户名和密码）的应用更加便捷。同样的例子也适用于 JPA 和 JMS。

另外一点就是如何集成 CDI 事件和事件驱动设计（Event-Driven Design），并探索数据库和微服务中的功能领域。

Schnabel：在反应式编程领域，还有很多演变的机会。我们都理解 REST，但是随着流式功能发展所带来的压力，即便是这个领域也在发生着一些变化。我认为，在跟踪和监控方面，随着行业实践的变化，这方面有一些工作需要做，另外，随着过去由应用服务器提供的功能转移到基础设施中，无论是原始的 Kubernetes、无服务器的 PaaS 式环境，还是接下来我们试图让 Kubernetes 变得更加友好所产生的其他方案，都会持续发生一些变化。

InfoQ：如果不采用微服务的话，构建云原生应用会有什么不同吗？例如，构建基于单体的云原生应用会不会更困难呢？

Hernandez：当我们移除云原生等式中的微服务时，我马上就会想到单体的 uber-jars 部署。我感觉基于容器基础设施的早期采用者通过使用 SOAP 架构发挥了云原生特性的优势，而不是基于 JAX-RS 的微服务。

Jiang：我觉得构建云原生应用和微服务并没有太大的区别。云原生应用包括模块化单体和微服务。微服务通常会比较小，而单体应用按传统会比较大。MicroProfile API 既可以用于单体应用，也可以用于微服务。重要的一点在于，云原生应用可能会包含多个模块，它们共享同样的发布节奏，并且互相关联。云原生应用应该有其专门的数据库。

Santana：所以，正如 Java 没有消亡一样，单体应用也不会很快消亡。我们今天在云原生环境中针对微服务所采用的很多最佳实践，都可以用于单体应用。值得记住的是，十二要素应用是基于《企业应用架构模式》一书的，这本书出版于 2003 年，而云环境的普及则主要发生于 2006 年的 Amazon AWS。

整体而言，构建微服务架构所需要的最佳实践，在单体环境下是依然需要的。比如，CI/CD、测试覆盖率、十二要素应用等。

鉴于单体应用需要更少的物理层，通常只需要作为数据库和应用的两层或三层即可，因此在云环境中它们往往更加易于配置、监控和部署。唯一需要注意的就是，它的可扩展性是垂直的，这往往会导致超出云供应商所能提供的限制。

Schnabel：我认为，云原生应用的核心特征是部署的灵活性和频率：只要你的应用没有依赖它的特定环境（比如，它具有注入后端服务的凭据信息，并且避免了特殊的代码路径），那么你的状态就没有问题。如果你的单体应用能够频繁且持续地构建、测试和部署（别忘了自动化），那么你就没有问题。

InfoQ：尽管微服务取得了成功，但是最近的有些公开信息一直在讨论微服务的陷阱，并推荐重新回归基于单体的应用开发。你们对这个话题有什么看法呢？开发者是否应该严肃地考虑重回基于单体的应用开发呢？

Hernandez：在选择要使用的工具和架构之前，开发人员应该先分析业务需求和技术背景。

作为开发人员，我们会因为能够测试新的框架和工具而感到兴奋。不过，我们还需要理解和分析特定场景的架构。然后，挑战就会变成在采用新技术或重回现有架构的利弊之间找到一个平衡。

Jiang：单体并不是邪恶的。有时候，模块化单体的表现并不逊色于微服务。微服务并不是云原生方案的唯一选择。至于选择单体还是微服务，取决于公司团队的结构和文化。如果你有一个小的团队，而且所有的应用都以相同的节奏发布，那么单体是正确的选择。而另一方面，如果你有一个分布式的团队，而且他们是独立运行的，那么微服务就适合这样的团队结构和文化。

如果转向微服务会导致团队行动变慢的话，那么重回基于单体的应用是明智的。

总之，没有默认的答案。你必须要基于公司的环境和文化做出自己的选择。要选择最适合公司的方案。你不应该根据是否采用微服务或者微服务的数量来衡量成功与否。

Santana：作为开发人员，我们需要明白，任何架构中都没有银弹。所有的方案都有其对应的权衡。这里的问题是羊群效应，这导致社区认为如果不采用微服务就是错误的。在技术方面，这不是第一个，也不是最后一个充斥整个技术社区的流行语。

整体而言，我认为这是一件很好的事情，我认为社区已经足够成熟，能够理解微服务不能适用于所有可能的事情，也就是说，常识和实用主义仍然是开发者/架构师最好的工具。

Schnabel：我同意这样的一个观点：没有必要从微服务开始，尤其是你在做一些新东西的时候。我发现，新的应用在开始的时候是很不稳定的。最初你认为要构建的东西往往与你最后所需要的大相径庭。在这个初始阶段使用单体的方式可以节省很多的精力：在应用程序的早期，协调许多服务的开发和部署是比较复杂的，而且没有一个令人信服的理由确定从哪里开始。在单体内部进行健全的软件实践可以为以后应用稳定下来重构成微服务做好准备。我发现，明显的候选方案很自然地就出现了。

InfoQ：在构建基于微服务的和云原生应用方面，你们有哪些推荐的最佳实践呢？

Hernandez：首先要分析要解决的问题是否适合微服务的方式，以及特定项目所具有的限制和机会。云原生方式的所有收益都取决于你对基础架构的应用程度。

Jiang：构建基于微服务和云原生应用的最佳实践是十二要素应用，它能够确保你的应用能够在云端有好的表现。请参考我在 QCon 伦敦 2020 上关于十二要素应用的演讲，在这个演讲中我介绍了如何使用 MicroProfile 和 Kubernetes 开发云原生应用。这里有一个忠告，那就是为你的云应用采取一个开放且被广泛采用的标准，这样你就可以放心地让它们在云中运行了。

Santana：除了实践，包括流行的DDD和十二要素应用，我认为要有良好的意识，做一个务实、专业和优秀的从业者。简单的东西只要符合需求和业务就不要怕应用它，所以要逃离技术的羊群效应。我最近在读一本书97 Things Every Cloud Engineer Should Know: Collective Wisdom from the Experts，在众多的技巧中，我引用其中的两个：

• 第一个是如果你不用 Kubernetes 也没有问题，就像我提到的，当不需要一项技术的时候，不要因为不使用它而感到沮丧。

• 第二个是使用能增加抽象性并降低实现类似云 PaaS、DBaaS 风险的服务。重要的是要明白，这种类型的服务带来了云提供商的整个技术诀窍，使备份/恢复、更新数据库服务等运维操作变得更加简单。例如，我可以以Platform.sh为例，它能够直接采用以GitOps为中心的方式部署云原生应用。

Schnabel：避免使用特殊的代码路径。它们很难进行测试，而且可能更难调试。无论你的应用程序运行在什么环境中，都要确保特定环境的依赖关系（主机、端口、支持服务的凭证）以一致的方式注入。

如果你要使用微服务的话，请坚定地使用微服务。要理解它们是完全解耦的独立实体，有自己的演化生命周期。API 和契约测试应该是你要关注的。尽最大努力了解微服务的后果：如果你试图确保所有的东西都能在一个 staging 环境中一起工作，然后部署一组一起工作的版本化服务，那么这就重新回到了单体部署模型。如果你必须持续地同时发布两个或更多的服务，因为它们相互依赖，那么你所面对的是一个具有不必要移动部件的单体结构。

预先考虑应用安全问题。每暴露一个 API 都是一个风险。你构建的每一个容器都需要进行维护，以降低已发现漏洞的风险。为此要做好计划。当迁移到云原生环境时，你应该抛弃“让一个应用程序工作，然后忘记它，使其永远运行”的想法，要确保你有持续维护的工具。

结论

在这个虚拟座谈会中，我们请专家从业者讨论了 MicroProfile 和微服务框架。我们甚至询问了他们对最近重回基于单体的应用开发的趋势的看法。

我们的专家一致认为，MicroProfile 已经影响了开发人员构建基于微服务和云原生应用的方式。Java 社区应该期待新的微服务框架的出现，MicroProfile 本身也会随着新的 API 或对现有 API 的改变而不断发展。

我们的专家成员还建议所有开发人员应该熟悉 Heroku 的 “十二要素应用”，这是一套指导原则，可以应用于任何语言或框架，以创建云就绪的应用程序。

随着微服务的出现，基于单体的应用开发似乎已经被定性为“邪恶的”。然而，我们的专家警告说，不要认同这样的定性。除了描述利弊之外，他们还解释了在哪些情况下，基于单体的应用程序开发会比基于微服务的应用程序开发更有利。现在具有挑战性的部分是你要把这些智慧应用到你的特定环境和一系列挑战中。

嘉宾简介

Cesar Hernandez 是 Tomitribe 的高级软件工程师，在企业 Java 应用方面拥有超过 14 年的经验。他是 Java Champion、Duke's Choice 获得者、Oracle Groundbreaker 大使、开源倡导者、Apache 和 Eclipse 提交者、教师和公开演讲者。当 Cesar 远离电脑时，他喜欢和家人在一起、旅行，并与 Java 社区乐队The Null Pointers一起玩儿音乐。请在Twitter上关注Cesar。

Emily Jiang 是一位 Java Champion，她是 Liberty 微服务的架构师和倡导者、IBM 的高级技术人员（STSM），常驻英国 Hursley 实验室。Emily 是 MicroProfile 专家，从 2016 年开始从事 MicroProfile 相关的工作，并主导 MicroProfile Config、Fault Tolerance 和 Service Mesh 的规范。她是 CDI 专家组成员。她对 MicroProfile 和 Jakarta EE 充满热情。她经常在会议上发言，如 Code One、DevNexus、JAX London、Voxxed、Devoxx、EclipseCon、QCon、GeeCon、JFokus 等。读者可以在Twitter和LinkedIn上与 Emily 联系。

致力于赋能全球开发者，让他们在云端更快、更可扩展地交付更好的软件。

Otavio Santana 是一位充满激情的软件工程师，专注于云和 Java 技术。他主要在金融、社交媒体和电子商务领域的多语言持久性和高性能应用方面具有丰富的经验。Otavio 是多个 JSR 和 JCP 执行委员会的专家组成员和专家组长。他正在参与多个 Apache 和 Eclipse 基金会的项目，如 Apache Tamaya、MicroProfile、Jakarta EE，他领导了 Jakarta EE 的第一个规范和 Jakarta NoSQL。他是 JUG 的领导者，也是 JavaOne 和 Devoxx 会议的全球演讲者。Otavio 因其对 OSS 贡献而获得认可，如 JCP 杰出奖、年度成员和创新 JSR、Duke's Choice 奖和 Java Champion 等。

Erin Schnabel（@ebullientworks）是 Red Hat 的高级首席软件工程师。她是一名 Java Champion，拥有 20 年的经验，是一名开发者、技术领导者、架构师和布道者，她强烈地喜欢在代码中忙碌。Erin 通过编写有趣的代码来学习（和教学），比如“Monster Combat”（这是一个让怪物互相打斗以探索应用指标的应用程序）、“Game On!”（这是一个微服务的文本冒险游戏），还有一个反应式工作坊，通过“The Jabberwocky”来了解反应式操作符的工作原理。

参考资源

Microservices: What They Are and Why Use Them by Laura Mauersberger (August 14, 2017)

To Microservices and Back Again - Why Segment Went Back to a Monolith by InfoQ (April 27, 2020)

This Week in Programming: Forget Microservices, Monoliths Are the Way Forward by Mike Melanson (February 1, 2020)

Goodbye Microservices: From 100s of Problem Children to 1 Superstar by Alexandra Noonan (July 10, 2018)

You Don't Need Microservices by Elder Moraes (August 2020)

Istio as an Example of When Not to Do Microservices by Christian Posta (January 8, 2020)

Monolith vs. Microservices tweet thread by Oliver Drotbohm (July 2, 2020)

原文链接：

[Virtual Panel: The MicroProfile Influence on Microservices Frameworks](