在Azure Functions上运行Spring Boot是否具有成本效益？

As I'm currently writing the official "Spring Boot on Azure Functions" documentation on the 一种zure documentation website, I published a sample application and received quite a lot of comments about the performance and associated cost that we can expect from such a setup.

结果，我做了一些相当广泛的测试，在这里我将尝试总结一下。 请注意，Azure Functions的定价模型在这里非常重要，因此，如果要使用最具成本效益的解决方案，则应首先详细研究此模型，并据此计划应用程序部署。

I will update this blog post once my "Spring Boot on Azure Functions" documentation is published on the official documentation website.

Introduction to Azure Functions

一种zure Functions is the "serverless" solution provided by 一种zure, so basically it runs your code on-demand, responding to an event, without you having to provision or set up anything.

它具有不同的定价模型，包括一些“高级”定价模型，但是这里的经典用例是用一组功能替换一个简单的应用程序，以获取相关的运营成本。

当我们谈论Spring Boot时，此博客文章将重点介绍Web应用程序，但是请注意，Azure Functions不限于Web应用程序：它们只是一种Azure函数，碰巧是由HTTP调用触发的。 其他几种类型的事件通常可以在执行批处理或IoT时触发Azure功能。

Introduction to Spring Cloud Functions

小号pring Cloud Function is an official Pivotal project, that aims to run Spring Boot on serverless providers. It includes a specific Azure provider, so you can easily run a Spring Boot application as an Azure Function.

Cold start issues

为了承载功能而无需任何前期费用，无服务器提供程序在不使用这些功能时将其置于“睡眠”状态。 调用函数时，无服务器提供程序随后需要唤醒该函数：它找到可用于运行该服务器的服务器，挂载其文件系统，然后执行该函数。

这本质上需要时间，并且通常有两种方法可以解决该问题：

• 某些人使用某种cron作业来定期唤醒其功能：这很hacky（因为您永远不知道何时该功能将变为非活动状态），并且实际上并没有遵循无服务器功能的理念。如果您使用的是Azure，请购买“高级”版本的Azure Functions，在该版本中您可以拥有“永远温暖”的功能。 当然，这将花费更多的钱，并消除了大多数问题。

Now, how long is a "cold start"? There is no official number here, and Azure Functions is constantly improving, so it's hard to tell, but it will take a few seconds. Also, launching a simple Spring Boot application like my sample application will take about 4 seconds, and that does not depend on the cloud provider.

这是示例应用程序开始的日志：

切换到另一个JVM框架可能对这里没有多大帮助：删除Spring可能会赢得几秒钟，但是全局上“冷启动”总是需要几秒钟。

请注意没有正式的指标可以告诉您应用程序何时变为非活动状态，但是您可以在各种博客上找到当前大约需要20分钟的非活动状态。

Avoiding cold start with a premium plan

You can eliminate most cold start issues if you buy a "premium" instance of Azure Functions :

• 这些实例更强大，导致“冷启动”很容易在5秒以内（包括Spring Boot启动不到2秒）。他们还提供了“预热”实例，无论如何，它们都会消除大多数问题，因为总会有活动的实例准备服务请求。

Is Spring Boot fast enough?

一旦通过了“冷启动”问题，如下图所示，我们的大多数请求将花费不到100毫秒：

这不是100毫秒的随机标记：这是每次执行函数时要向您收取的最短执行时间。 因此，保持执行时间非常重要，但是从成本的角度来看，低于100 ms并没有太大的意义。 这就是为什么在这里调整任何内容可能没有任何意义的原因。

Is Spring Boot using too much memory?

从下图可以看出，我们的应用程序始终使用少于1 Gb的RAM：

根据我的经验，您可以运行少于512 Mb的复杂Spring Boot应用程序，如果对其进行良好的调整，则可能会低于256 Mb。 由于Azure Functions按128Mb的片数向您收费，因此可能可以在这里节省您的账单，而不用花费执行时间。 不过，仍无法设置JAVA_OPTS在正常的Azure函数上（您需要使用“高级”计划才能受益于此选项），因此，如果您使用的是JVM，则很难对其进行调整。

A "low traffic" function

Please note that all calculations are done at the time of this blog post's publication, using the official pricing documentation.

让我们为“低流量”功能进行计算。 “低流量”是指我们的应用在一天的一半时间内每秒可处理1个请求。 因此，这是具有几个用户的业务应用程序的典型情况。 另外，随着“冷开始”非官方地如果某个应用程序处于非活动状态超过20分钟，则会发生这种情况，因此这种应用程序通常不会发生这种情况，因此我们可以在计算时忽略它们。

此成本分为两部分，首先是消耗部分：

• 60 * 60 * 24 * 30 * 0.5 = 1,290,000次执行由于执行时间（大部分时间）少于100毫秒，因此转换为129,000秒正如我们在图中看到的，我们使用少于1 Gb的RAM的方式，因此我们可以假设它将占用少于7张128 mb（或896 mb）的幻灯片。 因此，这将我们先前的计算形式转换为129,000 * 896/1024 = 112,875 Gb / s由于这远远低于我们免费提供的400,000 Gb / s，因此不会有任何损失的风险

然后，执行成本部分：

• 同样，60 * 60 * 24 * 30 * 0.5 = 1,290,000次执行由于我们有1,000,000次免费执行，因此有290,000笔交易需要支付由于执行成本为每1,000,000次执行$ 0.2，这将花费几美分

因此，此“低流量”选项对我们来说是免费的。 除非我们的流量激增，否则我们付出的风险非常有限，因为它的成本超过了几美分。

A "medium traffic" function

我们将进行相同的计算，但是这次我们仍在一天中的一半时间内每秒每秒有10个请求。

这是消耗部分：

• 10 * 60 * 60 * 24 * 30 * 0.5 = 12,900,000次执行由于执行时间少于100毫秒，因此转换为1,290,000秒这使得1,290,000 * 896/1024 = 1,128,750 Gb / s由于我们仍然有400,000 Gb / s的免费空间，因此我们总共要支付728,750 Gb / s因此最终消费价格为0,000016 * 728,750 = $ 11,66

对于执行部分：

• 同样，10 * 60 * 60 * 24 * 30 * 0.5 = 12,900,000次执行由于我们有1,000,000次免费执行，因此有1,190万笔交易需要支付由于执行成本为每1,000,000次执行$ 0.2，因此即$ 2,38

结果，这种“中等流量”功能的总价格约为每月14美元。

A "high traffic" function

现在，我们将执行“高流量”功能，在半天的时间内每秒发送50个请求。小心在这里，因为有一个窍门：除非其他无服务器提供程序，否则Azure Functions可以并行运行您的函数。 因此，对于每秒50个请求，我们非常确定Azure Function将在同一实例上并行执行多个函数。 这意味着我们在Azure上将减少“冷启动”问题，这当然是个好消息。

这是消耗部分：

• 50 * 60 * 60 * 24 * 30 * 0.5 = 64,800,000次执行由于执行时间少于100毫秒，因此转换为648万秒这使得1,290,000 * 896/1024 = 5,670,000 Gb / s由于我们仍然有400,000 Gb / s的免费空间，因此我们总共要支付5,270,000 Gb / s因此最终消费价格为0,000016 * 5,270,000 = $ 84,32

对于执行部分：

• 同样，50 * 60 * 60 * 24 * 30 * 0.5 = 64,800,000次执行由于我们有1,000,000次免费执行，因此有63,800,000笔交易需要支付由于执行成本为每1,000,000次执行$ 0.2，因此为$ 12,76

结果，这种“高流量”功能的总价格约为每月97美元。

Summary and final thoughts

Spring Boot在Azure Functions上运行得非常好！ 只有几件事要记住：

• 冷启动可能会很烦人，但只有在流量非常低的情况下才会发生。 如果那对您很重要，您还可以通过购买“高级”计划来完全避免它们。执行时间对于降低成本非常重要，Spring Boot（和JVM！）应该足够快才能保证此处的价格合理。内存是一个更大的问题，对于所有基于JVM的框架来说，内存可能一直是一个问题，因为无法设置JAVA_OPTS在“溢价计划”之外。即使对于每秒10到50个请求的应用程序，价格也极低，因此并发用户数量很多。

from: https://dev.to//azure/is-it-cost-efficient-to-run-spring-boot-on-azure-functions-1kce