相較于其他函數計算項目,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 模式都不會啟用。
- 如果 Function 中沒有添加
配置塊,并且 Function 中包含 spec.serving.annotations
和 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"
...