本文要点
微软提供了构建无服务器应用程序所需的所有工具和持续部署工具。目前,Azure DevOps 和 GitHub Actions 都提供了支持。
除了 Spring Boot 之外,Azure 还提供了对 Quarkus 和 Microaut 的支持。JHipster 为直接部署到 Azure 提供了开箱即用的支持。
借助这种“lift-and-shift”的方式,我们可以很容易地将一个部署在 Tomcat 上的 Spring Boot 应用程序转换为一个“无服务器”的 Azure 应用程序。MVC 控制器需要进行重写,复杂的部分在 DB 端,需要额外的工作量来获得类似的行为。
Azure 为 Java 8 和 Java 11 提供了适当的支持。
只要谨慎地选择所使用的工具,就可以确保无压力地从 Azure 迁移到另一个云平台。
微软似乎一次又一次地证明了它对云计算和 Java 生态系统的关注成了一种新的常态。Java 已经是 Azure 函数所支持的语言之一,而 Julien Dubois 进一步对 Spring Boot 和 Azure 进行了实验,看看这种组合对于 Azure 的无服务器计算意味着什么。InfoQ 采访了 Julien Dubois,进一步探讨了他在 Azure 上部署 Spring Boot 应用程序的经验。
InfoQ:感谢你花时间回答读者的一些问题。我们可以先请你做一下自我介绍并描述一下你在微软的日常工作吗?
Julien Dubois:我在 Java 社区工作了 20 多年,是JHipster的作者和 Java Champion。在专业方面,是微软 Java 云开发者倡导团队的负责人。我的团队的职责是与 Java 开发者保持接触,让 Azure 成为他们选择的平台。这意味着我们要与各种 Java 社区和合作伙伴一起收集反馈、改进文档,并与工程团队一起改进我们的产品和服务。
InfoQ:微软似乎正在成为 Java 开发者背后的一股强大的力量。是什么原因让你加入微软?
Julien Dubois:到目前为止,微软聘请了 11 位 Java Champion。我们为 Java 提供了很好的支持并制定了一些很好地计划。此外,微软不仅仅有 Azure:我们还有很多在 LinkedIn 或 Minecraft 工作的 Java 开发人员!
我加入微软,首先是因为当我还是个孩子的时候,它给了我梦想,因为我想为美国公司工作。我喜欢这家公司的价值观和精神,作为一个热爱科技的人,它是成长和学习的最佳场所之一。
InfoQ:你加入微软对于 JHipster 来说意味着什么?给它带来了什么影响吗?
Julien Dubois:作为 JHipster 的作者对于我加入微软来说绝对是个优势,然后,我在微软的职业生涯给 JHipster 的开源带来了非常大的变化。显然,现在我花在 JHipster 上的工作时间更少了,但这并不完全是因为我在微软所承担的角色。去年我有了第四个孩子,而由于新冠病毒,我没有太多的空闲时间。JHipster 的伟大之处在于它可以让社区里的其他人一起成长,从而让项目变得更强大、更稳定。
InfoQ:微软似乎正在成为 Java 和云生态系统的一等公民,是这样吗?
Julien Dubois:我相信已经是这样了。微软的很多产品都使用了 Java,包括 Azure。我们的 PaaS 产品 Azure App Service 支持 Java,在 Azure 函数 s 中也支持 Java,而我们的无服务器产品 Azure 函数 s 也支持 Java。我深入参与了 Azure Spring Cloud 项目,这是一款与 Spring 相关的产品,由我们和来自 VMware 的 Spring 团队共同开发。所以说我们已经在深度使用 Java,在不久的将来,它将变得更加强大。
InfoQ:无服务器运动的势头正猛,你觉得怎么样?它离生产就绪还有多远的路要走?
Julien Dubois:我们已经有很多客户在生产环境中使用 Azure 函数 s,包括一些运行 Java 工作负载的大型客户。我看到了在这个领域发生的一些非常令人兴奋的事情,但我相信这只是开始。最开始,Java 并不是非常适用于无服务器函数,将来还可以做很多改进来降低无服务器函数的成本,减少它们的冷启动时间,更好地监控它们以及更好地扩展它们。我很喜欢与负责 Azure 无服务器的工程团队一起工作。
InfoQ:为了进入这个领域,微软开发了哪些工具?你们需要其他云供应商提供的工具吗?是否有可能与其他供应商集成?
Julien Dubois:我们有运行时、特定于语言的 Worker(例如Java Worker)、一个 CLI 以及 IDE 插件。它们都是开源的。它们与 Azure App Service 一样,都是构建在相同的基础之上。Azure App Service 是我们的 PaaS 产品,它提供了很多经过生产验证的特性,不过也存在一些限制:我们因此能够很快进入这个领域,并提供了非常完整的功能,可能会让其他云供应商感到惊讶。我们与其他供应商的主要区别是我们的函数可以被不同的客户端同时调用:可以使用多线程,就像传统的应用程序一样。这样可以大大提高性能,但成本也很高,对于使用 Java 的人来说,这通常是件好事,因为 Java 的冷启动时间很长。
关于与其他云供应商的互操作性,我可以从一个 Spring 老用户的角度来聊一聊。我们与 Spring 团队密切合作,因此可以使用 Spring Cloud Function 部署工作负载。不同的供应商之间有一些非常小的差异,事实上,我目前正在修复一个问题,但基本上使用这个抽象应该能够在任意云供应商平台上运行相同的 Spring Boot 代码。Spring 做了与 J2EE 时代一样的事情:一个抽象,让你在不修改代码的情况下更换实现。
InfoQ:除了 Azure,你们使用过其他供应商吗?相比之下,感觉如何?
Julien Dubois:在我过去作为顾问的职业生涯中,我用过很多供应商。最明显的自然是 AWS、GCP 和 Heroku,但我花了很多时间与提供简单虚拟机和网络解决方案的小型供应商打交道。
首先,我推崇 PaaS:我不喜欢维护虚拟机、Kubernetes 集群或 SQL 数据库。我相信现在有很好的 PaaS 解决方案,而且价格很便宜。人工参与是在浪费时间,而且是一个糟糕的选择。你无法与大型云服务供应商相竞争。现在,所有的大型云服务供应商都有自己的优势,我在 Azure 的竞争对手那里积累了很多经验。因为 GCP 在一开始为我们提供赞助,所以JHipster Online运行在 GCP 上。大多数 JHipster 用户通常会先用 Heroku,因为他们的免费层对他们来说已经足够好了,这要感谢 Heroku 团队对其进行了优化。这些都是很好的选择,幸运的是 Java 能在这么多不同的平台上良好运行。
InfoQ:Azure 函数文档表明,HTTP 原生编程语言将支持 Azure 函数。这对于 Java 来说意味着什么?要写一个 Java Azure 函数需要做哪些事情?
Julien Dubois:实际上,我们有两种在 Azure 上运行 Java 函数的方法。一种是传统的方式:我们有一个官方提供的 Java Worker,它有很棒的文档和 API。这是大多数人都在使用的工具,也是我推荐的工具,因为你还可以获得 JDK 的支持和更好的监控。它的冷启动性能也相当不错,因为我们使用了一些技巧来改进它,包括预热一些机器。
另一种是非官方的方式,就是你在谈及 HTTP 时提到的那种,它提供了一个叫作“Azure 函数自定义处理器”的新特性。使用这种方法,我们的 HTTP 代理只知道它与 HTTP 服务器通信,不知道你的应用程序:这消除了我们这边进行调优和监控的可能性,但它允许你按照自己想要的方式开发应用程序。现在,包括我在内的所有人都在尝试使用 GraalVM 原生镜像构建 Java 函数。这在很多情况下都可以很好地工作,包括使用 Spring Cloud Function。在将其安全地投入生产之前还有很长的路要走,但如果你喜欢使用最好的新技术,当然可以尝试一下。
InfoQ: Java 8 也是 Azure 函数支持的一门编程语言。它的使用体验是怎样的?
Julien Dubois:我们已经在使用 Java 11 了,因为它是最新的 LTS 版本。我个人而言,我想支持 Java 14,但是现在大多数客户仍然在使用 Java 8,所以我们并不急于这样做。我们在这方面最大的改进是支持 Linux。这有点令人感到惊讶,但是我们有一些客户正在做调优,需要在 Linux 上使用 Java,由于历史原因,我们最初只在 Windows 上提供 Java 支持。
另外,请注意,我们与 Azul 系统合作是为了得到 JDK 的支持和补丁,这对于我们的客户和我们自己来说是非常重要的,因为我们非常重视安全问题。
InfoQ:你们成功地在 Azure 上部署了一个无服务器 Spring Boot 应用程序。你能给我们描述一下你的经历吗?
Julien Dubois:实际上我用了两种不同的方法。首先,我使用 Spring Cloud Function 的官方方法,将 Spring Boot 应用部署到 Azure 函数 s。这段代码已经成为Azure的官方示例应用程序。这个解决方案还可以继续改进,因为我们需要为此提供一个特定的配置类,我目前正在与 Azure 工程团队和 Spring Boot 团队一起来改进它。
其次,我尝试使用新的“Azure 函数自定义处理器”来构建相同的函数(基于 GraalVM)。在 Spring 和 GraalVM 团队的帮助下,我做到了,而且效果很好。请注意,我没有在生产环境中广泛使用它,所以如果你想运行很重的工作负载,我不推荐使用它。然后,这让我发现了 Azure 函数中一些奇怪的行为,我已经在内部报告了这些问题,我们正在积极地修复它们。
InfoQ:它是开箱即用的吗,还是需要额外的工作量?
Julien Dubois:对于官方受支持的方法,在使用 Spring Cloud Function 时,需要注意一个特定于 Azure 的配置文件,但总的来说,并不需要太多的工作量。
如果是基于 GraalVM,则是另一回事,因为之前没有人这么做过。大部分工作已经由 Spring 和 GraalVM 团队完成了,不过我还是花了几天时间才让一切顺利运行起来。当然,现在你可以使用我的 GitHub 代码库里的东西,它提供了完整的文档,你应该可以更快地获得相同的结果。
InfoQ:看来微软现在已经拥有了整个持续部署流程所需的东西,是这样吗?
Julien Dubois:实际上,微软提供了两种选择。目前的主要产品是 Azure DevOps,它完整且强大,所以我们会推荐给所有人。我们在 JHipster 上用了它几个月,因为它为 OSS 项目提供了一个免费层,非常成功。当然,它也被集成到 Azure 和整个微软技术栈中。
然后,你可能知道 GitHub 有一个叫作 GitHub Actions 的新服务。由于 GitHub 的每个用户都在使用它,这款应用程序的增长速度非常惊人。虽然它目前仍然不如 Azure DevOps 强大,但它的发展速度非常快,而且因为与 GitHub 集成,它有很大的优势。这就是我们将 JHipster CI/CD 管道迁移到 GitHub 的主要原因:我们有大量的贡献者,有很多权限,而且作为组织管理员,这对我来说要容易得多。而且,对于我们的应用场景来说,它完全足够了,我们对这个解决方案感到非常满意。
InfoQ:这看起来很像 Quarkus 和 Amazon Lambda。你有机会尝试一下这种组合吗?它们与 Spring Boot 和 Azure 相比的话表现如何?
Julien Dubois:我没有在 Lambda 上尝试过 Quarkus,但在 Azure 上尝试过 Quarkus!事实上,我们与 Spring、Quarkus 和 Micronaut 团队合作,因此这三个主要的 Java 框架在我们的服务上得到了同等的支持。现在,它们在 JVM 上的运行方式很相似,体验应该也非常接近。目前,主要的实验是在 Azure 函数上运行基于 GraalVM 的框架。这肯定会改变游戏规则,那么 JVM 提供的支持级别就真的很复杂了,这意味着开发者在短期内将承担更多的责任。例如,我们为 JVM 用户提供了托管的操作系统和 JVM,如果 JVM 出现了安全问题,我们将提供补丁,用户将不会注感知到任何问题。而如果我们使用来自 Azul 的 JVM 版本,我们甚至可能可以在安全问题暴露之前打好补丁。相反,如果你想基于 GraalVM 做同样的事情,你就得自己做了:升级和修补二进制文件就是你自己的事情,因为我们在 Azure 端看到的都是二进制文件。
InfoQ:Azure 无服务器应用最适合的场景是什么?如果你现在需要从头开始创建一些应用,你会使用它吗?为什么?
Julien Dubois:我们目前有很多不同的客户,他们有不同的应用场景,并且都有成功的经验,所以很难说出一个“最佳”场景,但至少我可以谈谈我们的一个大而有趣的用例。这是一家非常著名的法国公司,它提供的服务被很多人使用,确切地说,有数千万人使用。不过在不同的时间使用情况有很大的不同。通常,人们会在晚上大量使用该服务,并且当出现一些公共活动或公告时,该服务的使用量会大幅增长。我在新冠疫情发生之前有幸拜访了他们,因为他们的办公室离我们的办公室很近。在高峰时间,他们服务的使用量令人难以置信。他们在 Azure 函数 s 上运行 Java 和 Spring,他们的实例池会根据使用情况自动增长或减少,不需要进行任何维护。他们可以专注于代码和业务特性,一切都能正常运行,他们不用做任何事情就能处理负载,所以这绝对是一个很棒的场景。我相信这为他们省去了很多麻烦,也让他们赚了很多钱。
InfoQ:将一个生产就绪的应用程序迁移到无服务器 Azure 会有多复杂?
Julien Dubois:因为我有 Java 背景,所以我们假设有一个运行在 Tomcat 上的经典 Spring Boot 应用程序,这是一个非常常见的场景。有两种方法可以将其迁移到无服务器:一个是所谓的“lift-and-shift”,一个是重构所有东西。
如果采用“lift-and-shift”的方式,你将会遇到的一个麻烦,你需要将所有 Spring MVC 控制器移植成 Spring Cloud Function。这个可以通过一些方法和技巧来实现,不过会有一些限制,但这应该花不了太多钱。此外,你不需要过多地修改业务代码,因此不会破坏任何重要的代码。
Azure 函数与经典的 Spring Boot 应用程序的运行方式非常不一样:你仍然可以享受 Hibernate 二级缓存或数据库连接池的好处,但很显然,它们不会很高效,因为它们的生存周期会短得多。这个时候使用分布式缓存将是一个巨大的麻烦。另外,与单节点 Tomcat 服务器不同,你的函数会伸缩,所以数据库可能不会像以前那样,因为它不是为那样的负载而设计的。你可以使用像 CosmosDB 这样的数据库,或者像 Redis 这样的缓存解决方案,这是 Azure 上广泛使用的两个选项。这需要做很多工作,但这是获取无服务器平台好处的唯一方法。这就是我们所说的“重构”,为了充分利用云平台,需要转换整个应用程序及其服务。
InfoQ:那从另一家云供应商迁移呢?
Julien Dubois:我在这里主要说一下 Amazon Lambda,不过我相信其他很多无服务器供应商也是一样的。Azure 函数和 Amazon Lambda 之间有一个巨大的区别:使用 Azure,你的应用程序启动并运行了几分钟,在这段时间内,多个客户端可以访问它,它的后台线程照常工作。在 Amazon Lambda 上,每个客户端都会执行一次,后台线程可能不能很好地工作。所以,在使用 Azure 时,你看到是一个“正常”的应用程序,只是它不会运行很长时间。这意味着大多数现有的应用程序是一样的,它们只运行几分钟(而不是几天或几周),不过这不应该是一个大问题。这就是为什么“lift-and-shift”方式在 Azure 上运行得很好,而其他云供应商可能会要求你对应用程序进行全面的重构。不过,即使是 Azure,重构也是迁移大多数无服务器应用程序的唯一方法,因此在这方面没有什么神奇的解决方案。
InfoQ:将你的应用程序迁移到另一个供应商有多容易?在 Azure 上开发应用程序是否意味着供应商锁定?
Julien Dubois:这取决于你使用的服务和框架!关于框架,正如我们前面所讨论的,有一些解决方案,如 Spring Cloud Function、Quarkus 和 Micronaut,它们提供了云供应商抽象。对于 Java,你可能会使用其中一个框架,这意味着你的大部分代码可以在所有平台上运行。对于服务,如果你使用 CosmosDB(这是一种优秀的但只适用于微软的解决方案),那么迁移到其他云供应商会有点麻烦。这就是为什么当我用 JHipster 做演示时,我使用的是 MySQL,因为它可以在任何地方运行。如果我要使用 CosmosDB,我会使用它的 MongoDB API:这样我就可以很容易地迁移到另一个支持 MongoDB 的云供应商。
想要不被供应商锁定会对你造成很大限制,你可能无法使用云供应商提供的很多高级特性。这就像人们在使用数据库时只使用标准 SQL。你会损失很多:迁移成本不在于使用另一个 API,而在于将所有数据从一个服务移动到另一个服务。
InfoQ:让我们来分析一下你参与的两个项目:是否有可能将 JHipster 和 Azure 混合在一起?你是怎么想的?
Julien Dubois:我们已经支持将 JHipster 部署到 Azure!我们已经正式支持 Azure Spring Cloud 和 Azure App Service。JHipster Kubernetes 可以运行在 Azure Kubernetes Service 上,不需要我们做任何事情。当然,我还想更进一步,我想让 JHipster 更好地支持 Terraform:这样就可以在 Azure 上生成更复杂的基础设施。
InfoQ:对于那些刚刚开始使用 Azure 函数的人,你有什么建议吗?
Julien Dubois:我建议先构建一个简单的无服务器应用程序,就像Azure静态Web应用程序那样。目前这只适用于 JavaScript,但它是免费的,使用起来很简单,所以可以用它来测试和学习。另外,微软学习网站上也有一些很棒的文档。
这里最复杂的是概念,然后将其应用到另一种语言应该不是什么大问题。
嘉宾介绍:
Julien Dubois,微软 Java 开发者倡导团队经理,他一直在尝试 Spring Boot 和 Azure 的结合,看看这种组合对 Azure 的无服务器计算意味着什么。Julien Dubois 是 JHipster 项目的创建者和首席开发人员,也是 Java Champion。在过去的 20 年里,他主要以架构师和顾问的身份从事 Java 和 Spring 技术工作,为各行各业的很多不同客户工作。Julien Dubois 写了一本关于 Spring 框架的书,并在 100 多个国际会议上发表演讲,并创建了几个流行的开源项目。
原文链接:
Azure + Spring Boot = Serverless - Q&A with Julien Dubois
评论