相较于其余函数计算我的项目，OpenFunction 有很多独特的性能，其中之一便是通过 Dapr 与各种后端服务（BaaS）无缝集成。目前 OpenFunction 曾经反对了 Dapr 的 pub/sub 和 bindings 构建模块，将来还会反对更多功能。截止到 v0.7.0，OpenFunction 与 BaaS 的集成还不算特地丝滑，须要在每个函数实例的 Pod 中注入一个 Dapr Sidecar 容器，这就会导致一个问题： 整个函数实例的启动工夫会受到 Dapr Sidecar 容器启动工夫的影响 ，甚至 Dapr Sidecar 容器可能会比函数容器自身耗费的资源更多。
为了解决这个问题，OpenFunction 公布了 v0.8.0，引入了 Dapr Standalone 模式。
Dapr Standalone 模式
在新的 Dapr Standalone 模式中，无需为每个函数实例启动一个独立的 Dapr Sidecar 容器，而是为每个函数创立一个 Dapr Proxy 服务，这个函数的所有实例都会共享这个 Dapr Proxy 服务，大大减少了函数的启动工夫。
如何抉择 Dapr 服务模式
当然，除了新增的 Dapr Standalone 模式之外，您还能够持续抉择应用 Dapr Sidecar 模式，建议您依据本人的理论业务来抉择适合的 Dapr 服务模式。默认举荐应用 Dapr Standalone 模式，如果您的函数实例不须要频繁伸缩，或者因为一些其余起因无奈应用 Dapr Standalone 模式，则能够应用 Dpar Sidecar 模式。
您能够通过在自定义资源 Function 中增加 spec.serving.annotations 来管制应用何种 Dapr 模式与 BaaS 集成，总共有两个 annotations：
openfunction.io/enable-dapr：能够设置为true或者false；openfunction.io/dapr-service-mode：能够设置为standalone或者sidecar。
当 openfunction.io/enable-dapr 设置为 true 时，能够调整 openfunction.io/dapr-service-mode 的值来抉择不同的 Dapr 服务模式。
当 openfunction.io/enable-dapr 设置为 false 时，openfunction.io/dapr-service-mode 的值会被疏忽，Dapr Standalone 模式与 Dapr Sidecar 模式都不会启用。
这两个 annotations 的默认值如下：
- 如果 Function 中没有增加
spec.serving.annotations配置块，并且 Function 中蕴含spec.serving.inputs和spec.serving.outputs配置块，openfunction.io/enable-dapr会被主动设置为true；否则openfunction.io/enable-dapr就会被设置为false。 openfunction.io/dapr-service-mode默认值是standalone。
示例：
apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
name: cron-input-kafka-output
spec:
...
serving:
annotations:
openfunction.io/enable-dapr: "true"
openfunction.io/dapr-service-mode: "standalone"
template:
containers:
- name: function # DO NOT change this
imagePullPolicy: IfNotPresent
runtime: "async"
inputs:
- name: cron
component: cron
outputs:
- name: sample
component: kafka-server
operation: "create"
...对于 v0.8.0 的更多发版细节能够参考 OpenFunction v0.8.0 的 Release Notes。
本文由博客一文多发平台 OpenWrite 公布！