Google Cloud宣布Cloud Run的最少实例（“最少”）

无服务器的伟大之处之一是其按需付费的操作模型，可让您将服务缩减至0。但是对于某些应用程序类别，无服务器的不那么重要之处在于它缩小为0，导致应用程序再次唤醒时处理第一个请求的延迟。所谓的“启动税”对于无服务器来说是新颖的，因为顾名思义，如果应用程序没有收到流量，则没有服务器在运行。

今天，我们很高兴宣布托管的无服务器计算平台Cloud Run的最少（“最少”）实例。这项重要的新功能可以极大地提高应用程序的性能。结果，它使得可以在Cloud Run上运行对延迟敏感的应用程序，因此它们也可以从无服务器计算平台中受益。让我们更深入地了解一下。

使用此功能，您可以配置一组最小数量的处于待机状态并准备提供流量的Cloud Run实例，以便您的服务可以以最少的冷启动来开始服务请求。

要使用Cloud Run的新的最小实例功能，只需使用简单的gcloud命令或UI为您的Cloud Run服务配置最小实例数。

配置完成后，最小实例将准备就绪，正在等待为您的应用程序提供流量，从而最大程度地减少了应用程序的冷启动，并使您能够在Cloud Run上运行对延迟敏感的应用程序。

除了最大程度地减少冷启动，Cloud Run min实例还可以帮助您减少关键操作的引导时间，例如打开数据库连接或将文件从Cloud Storage加载到内存中。通过减少引导时间，最小实例有助于进一步减少请求延迟，因为您只需要运行一次引导逻辑，然后在多个请求中利用它来配置配置的最小实例数。

考虑以下golang无服务器功能，该功能说明如何运行一次引导逻辑，并在最小实例中重用它：

包主 导入（ ＆＃34; fmt＆＃34; ＆＃34; log＆＃34; ＆＃34; net / http＆＃34; ） func init（）{ setupDBConnection（dbName） } func handler（w http.ResponseWriter，r * http.Request）{ fmt.Fprintf（w，＆＃34;嗨，我爱％s！＆＃34;，r.URL.Path [1：]） } func main（）{ fmt.Println（＆＃34;处理无服务器请求＆＃34;） http.HandleFunc（＆＃34; /＆＃34;处理程序） log.Fatal（http.ListenAndServe（＆＃34;：8080＆＃34 ;, nil）） }

除了设置最小实例数之外，Cloud Run min实例还允许您使用节流的CPU对其进行配置，因此您可以以更低的成本利用此功能。这样，您也可以吃蛋糕：利用无服务器的效率和成本优势，同时将对延迟敏感的工作负载转移到无服务器。

因此，我们讨论了Cloud Run min实例可以带来的好处，以及如何使用该功能，但是它在现实生活中如何工作以及为什么要使用它？

传统上，无服务器平台迎合了从缩放到零受益的应用程序，但是由于引导期间的冷启动延迟，因此在初始响应时间上需要做出一定的权衡。对于您从头开始构建的应用程序，并且您可以完全控制源代码以及运行时的行为，这是可以接受的。但是，人们需要使用一整类应用程序，而传统的无服务器方法并不适合这些应用程序。可以考虑使用诸如Prometheus之类的自定义控制平面来收集度量，并使用Open Policy Agent（OPA）来制定策略决策。这些控制平面通常需要在首次启动时进行高级配置并需要一些引导程序，并且无法承受额外的延迟。

例如，在启动OPA时，通常会从远程源获取策略并进行缓存，以加快将来的策略决策速度。在典型的无服务器环境中，OPA之类的控制平面在扩展到零并再次备份以处理策略请求时会受到性能影响，因为它位于关键用户事务的请求路径中。

Cloud Run min实例使您可以直接解决此问题。现在，我们可以确保每个请求将由OPA的“热”实例处理，而不必缩放为零，也不必在每个请求之间重新引导策略引擎。

让我们看看实际情况。在以下部分中，我们将OPA部署为作为中央控制平面运行，并使最小的实例满足我们的性能要求。

我们将OPA服务器配置为在运行时从Cloud Storage存储桶中提取策略捆绑包，查询该查询包将允许针对“ / health” HTTP路径的http GET请求。这是OPA政策的样子：

包http.example.authz 默认allow = false 允许{ input.method ==＆＃34; GET＆＃34; input.path ==＆＃34; / health＆＃34; }

该策略打包在策略捆绑包中，并上传到Cloud Storage存储桶。但是首先，我们需要引导一些依赖项，如本教程中有关引导过程的说明所示。为了使事情简单，我们利用了一个辅助脚本。

在部署OPA Cloud Run实例之前，我们需要执行以下任务：

$ ./bin/bootstrap 创建开放策略代理服务帐户... 正在创建GCS存储桶以保存OPA策略捆绑包... 创建gs：// opa-policies-hightowerlabs / ... 创建了GCS存储桶opa-policies-hightowerlabs 将OPA策略捆绑包（bundle.tar.gz）复制到gs：// opa-policies-hightowerlabs ... 正在复制file：//bundle.tar.gz [Content-Type = application / x-tar] ... / [1个文件] [280.0 B / 280.0 B] 操作超过1个对象/280.0 B. 向开放策略代理服务帐户授予读取权限 教程自举完成。 服务帐户电子邮件和存储桶名称已写入.env 服务帐号：[email protected] 值区名称：opa-policies-hightowerlabs

至此，主机OPA的所有依赖项均已就绪。我们已经准备好使用“ gcloud”命令部署OPA。存储桶名称和服务帐户电子邮件地址存储在上一步中运行的引导脚本创建的“ .env”文件中。

$ gcloud beta运行部署open-policy-agent \ -并发80 --cpu 2 \ --image gcr.io/hightowerlabs/opa:0.24.0-min-instances \ -内存＆＃39; 2G＆＃39; \ --min-instances 1 \ --no-allow-unauthenticated \ -平台管理 -端口8181 \ --region us-west1 \ --service-account $ {SERVICE_ACCOUNT} \ --set-env-vars =＆＃34; BUCKET_NAME = $ {BUCKET_NAME}＆＃34; \ -超时300

这是命令的输出，表示我们已经成功引导了环境：

在项目[hightowerlabs]区域[us-west1]中将容器部署到Cloud Run服务[open-policy-agent] ✓部署...完成。 ✓创建修订... ✓路由流量... ✓设置IAM策略... 做完了 服务[open-policy-agent]修订版[open-policy-agent-00018-bim]已部署，并为100％的流量提供服务。 服务网址：https：//open-policy-agent-6bn2iswfgq-uw.a.run.app

现在，当OPA服务器首次启动时，它将从Cloud Storage中下载策略捆绑包并对其进行缓存。但是多亏了min实例，这只发生了一次。

现在，我们准备测试做出一项政策决定。我们可以卷曲地做到这一点。检索open-policy-agent云运行URL：

$ OPA_URL = $（gcloud运行服务描述open-policy-agent \ -平台管理 --region us-west1 \ --format json | \ jq -r＆＃39; .status.url＆＃39;）

通过提供一组输入来查询OPA服务器，并根据存储在Cloud Storage中的策略捆绑包检索策略决策：

$ curl -i＆＃34; $ {OPA_URL} / v1 / data / http / example / authz＆＃34; \ -H＆＃34;授权：承载$（gcloud auth打印身份令牌）＆＃34; \ -d＆＃39; {＆＃34 ;: {＆＃34; path＆＃34 ;:＆＃34; / health＆＃34;，＆＃34;方法＆＃34 ;:＆＃34; GET＆ ＃34;}}＆＃39;

HTTP / 2 200 内容类型：application / json 日期：2020年10月29日星期四15:20:06 GMT 内容长度：25 伺服器：Google Frontend {＆＃34; result＆＃34;：{＆＃34; allow＆＃34;：true}} 现在，如果您等待几分钟，您会发现OPA不会扩展为零，并且该过程将在后台冻结，并且仅在下一个请求到达实例时才会解冻。 如果您想进一步了解这会如何影响定价，请务必查看定价页面。 乍一看，Cloud Run min实例看起来似乎不是一件小事，但我们相信，此功能将使更多现成的应用程序能够在无服务器模型下运行，并且更具成本效益，并让您对 无服务器计算中固有的权衡。 要开始使用Cloud Run，请查看这些快速入门。