@levinzhang 2021-03-02T23:42:31.000000Z 字数 9747 阅读 798

虚拟座谈会：MicroProfile对微服务框架的影响

Michael Redlich, Cesar Hernandez, Emily Jiang, Otavio Santana, Erin Schnabel

摘要：

在2016年年中，MicroProfile作为一个厂商协作的项目而启动，它的目标是为企业级Java提供微服务。InfoQ最近就MicroProfile如何影响当今开发人员构建基于微服务的应用、新的微服务框架的出现以及重新回归基于单体的应用开发等问题咨询了专家从业者的观点。

核心要点

从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”来了解反应式操作符的工作原理。