相較于其他函式計算專案，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 發布！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/526881.html
標籤：其他
上一篇：【單元測驗】Junit 4（四）--Junit4引數化
下一篇：2022UUCTF--WEB