作者：Kelsey Hightower；Vinod Ramachandran
无服务器最为优异的一点在于其按需付费的操作模型，可以让用户将服务规模缩减为零。但是对于某些应用程序来说，无服务器对于他们来说没那么重要的原因也在于其模型可以按需缩减为零。这是因为对于这些应用来说，一旦服务器的规模缩减为零，再次唤醒是的第一个操作请求很有可能会被延迟，这也是很多人常说的“启动税”。所谓的“启动税”对于无服务器来说很新颖的一个词语，顾名思义，如果应用程序没有收到流量，那么就没有服务器在运行。
不久前，谷歌对外宣布Cloud Run（托管无服务器计算平台）的min实例，这项重要的新功能可以极大地提高应用程序的性能。可以让那些对延迟非常敏感的应用程序也能够从Cloud Run上获益，至于如何获益，下文我们将深入介绍。
减少冷启动
通过使用Cloud Run min实例，用户可以配置一组数量最小、处于待机状态并随时准备提供流量的Cloud Run实例，从而帮助应用减少冷启动而更快的开始服务请求。
要使用Cloud Run的新的min实例功能，只需使用简单的gcloud命令或UI配置Cloud Run服务的min实例数。
$ gcloud beta run deploy --image gcr.io/cloudrun/hello --min-instances=3 helloservice
配置完成后，最小实例将准备就绪，随时准备魏应用程序提供服务，从而最大程度地减少了应用程序的冷启动，这样，即使您的应用对延迟非常敏感也可以在Cloud Run上运行。
重用自举逻辑
除了最大程度地减少冷启动，Cloud Run min实例还可以帮助用户减少关键操作的引导时间，例如打开数据库连接或将文件从Cloud Storage加载到内存中。通过减少引导时间，min实例有助于进一步减少请求延迟，因为您只需要运行一次引导逻辑，然后在多个请求中利用它来配置min实例数。
参考下面的golang无服务器功能，该功能说明如何运行一次引导逻辑，并在min实例中重用它：
一次运行引导逻辑，然后在min实例中重复使用
package main
import ( "fmt"
"log"
"net/http"
)
func init() {
setupDBConnection(dbName)
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])
}
func main() {
fmt.Println("Processing your serverless request")
http.HandleFunc("/", handler)
log.Fatal(http.ListenAndServe(":8080", nil))
}
以更低的成本发挥无服务器的优势
除了设置min实例数之外，Cloud Run min实例还允许您使用节流的CPU对其进行配置，因此您可以以更低的成本利用这个功能。这样既可以利用无服务器的效率和成本优势，同时将对延迟敏感的工作负载转移到无服务器。
运行中的Cloud Run min实例
我们讨论了Cloud Run min实例可以带来的好处，以及如何使用该功能，但是它在现实生活中如何工作以及为什么要使用它？ 传统上，无服务器平台迎合了从缩放到零受益的应用程序，但是由于引导期间的冷启动延迟而在初始响应时间上做出了一定的权衡。这对于从头开始构建的应用程序是可以接受的，并且可以完全控制源代码及其在运行时的行为。但是，人们需要使用一整类应用程序，而传统的无服务器方法并不适合这些应用程序。
可以考虑使用诸如Prometheus之类的自定义控制平面来收集度量，并使用Open Policy Agent（OPA）来制定策略决策。这些控制平面通常需要在初始启动期间进行高级配置并需要一些引导程序，并且不能忍受额外的延迟。 例如，在启动OPA时，通常会从远程源获取策略并将其缓存，以加快将来的策略决策速度。在典型的无服务器环境中，控制平面（例如OPA）在扩展到零并再次备份以处理策略请求时会受到性能影响，因为它位于关键用户事务的请求路径中。Cloud Run min实例可以直接解决这个问题。现在，我们可以确保每个请求将由OPA的“热”实例处理，而不必缩放为零，也不必在每个请求之间重新引导策略引擎。让我们看看实际情况。
在以下部分中，我们将OPA部署为作为中央控制平面运行，并使最小的实例满足我们的性能要求。我们将OPA服务器配置为在运行时从Cloud Storage存储桶中提取策略捆绑包，查询该查包将允许针对“ / health” HTTP路径的http GET请求。
这是OPA政策的例子