Azure Functions PowerShell 開發人員指南

發行項
01/23/2025

本文提供如何使用 PowerShell 撰寫 Azure Functions 的詳細資料。

PowerShell Azure 函式 (函式) 會表示為觸發時執行的 PowerShell 指令碼。每個函式腳本都有一個相關 function.json 檔案，可定義函式的行為方式，例如觸發方式及其輸入和輸出參數。若要深入了解，請參閱觸發程序和繫結文章。

如同其他類型的函式，PowerShell 指令碼函式會採用符合 function.json 檔案中所定義所有輸入繫結名稱的參數。也會傳遞 TriggerMetadata 參數，其中包含啟動函式所用觸發程序的其他資訊。

本文假設您已經讀過 Azure Functions 開發人員參考。它也假設您已完成 PowerShell 的 Functions 快速入門，以建立您的第一個 PowerShell 函式。

資料夾結構

PowerShell 專案的必要資料夾結構如下所示。此預設值可以變更。如需詳細資訊，請參閱 scriptFile 一節。

PSFunctionApp
 | - MyFirstFunction
 | | - run.ps1
 | | - function.json
 | - MySecondFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - myFirstHelperModule
 | | | - myFirstHelperModule.psd1
 | | | - myFirstHelperModule.psm1
 | | - mySecondHelperModule
 | | | - mySecondHelperModule.psd1
 | | | - mySecondHelperModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1
 | - profile.ps1
 | - extensions.csproj
 | - bin

在專案根目錄中，有共用的 host.json 檔案可用來設定函式應用程式。每個函式都有包含本身程式碼檔案 (.ps1) 和繫結組態檔 (function.json) 的資料夾。 function.json 檔案的父目錄名稱一律是函式的名稱。

某些繫結需要 extensions.csproj 檔案存在。在 Functions 執行階段 2.x 版和更新版本中所需的繫結延伸模組，是以 bin 資料夾中的實際程式庫檔案在 extensions.csproj 檔案中所定義。在本機開發時，您必須註冊繫結擴充功能。當您在 Azure 入口網站中開發函式時，會為您完成此註冊。

在 PowerShell 函式應用程式中，您可以選擇性使用 profile.ps1，這會在函式應用程式開始執行時執行 (也稱為冷啟動)。如需詳細資訊，請參閱 PowerShell 設定檔。

將 PowerShell 指令碼定義為函式

根據預設，Functions 執行階段會在 run.ps1 中尋找您的函式，其中 run.ps1 與對應的 function.json 會共用相同的父目錄。

您的文稿會在執行時傳遞數個自變數。若要處理這些參數，請將 param 區塊新增至指令碼頂端，如下列範例所示：

# $TriggerMetadata is optional here. If you don't need it, you can safely remove it from the param block
param($MyFirstInputBinding, $MySecondInputBinding, $TriggerMetadata)

TriggerMetadata 參數

TriggerMetadata 參數可用來提供有關觸發程序的其他資訊。此元數據會因系結到系結而有所不同，但它們都包含 sys 包含下列數據的屬性：

$TriggerMetadata.sys

屬性	描述	類型
UtcNow	函式觸發的時間 (UTC)	Datetime
MethodName	觸發的函式名稱	string
RandGuid	此函式執行的唯一 GUID	string

每個觸發程序類型都有一組不同的中繼資料。例如，QueueTrigger 的 $TriggerMetadata 包含 InsertionTime、Id、DequeueCount 等等。如需有關佇列觸發程序中繼資料的詳細資訊，請移至佇列觸發程序的官方文件。請查看您所用觸發程序的文件，以了解觸發程序中繼資料的內容。

繫結

在 PowerShell 中，繫結會設定並定義於函式的 function.json 中。函式會以多種方式與系結互動。

讀取觸發程序和輸入資料

觸發程序和輸入繫結會讀取為傳遞至函式的參數。輸入繫結在 function.json 中有一個設定為 in 的 direction。 function.json 中定義的 name 屬性是 param 區塊中的參數名稱。由於 PowerShell 會使用具名參數進行繫結，因此參數的順序並不重要。不過，最佳做法是遵循 function.json 中定義的繫結順序。

param($MyFirstInputBinding, $MySecondInputBinding)

寫入輸出資料

在函式中，輸出繫結在 function.json 中有一個設定為 out 的 direction。您可以使用 Functions 執行階段可用的 Push-OutputBinding Cmdlet 來寫入輸出繫結。在所有情況下，繫結的 name 屬性 (如 function.json 中所定義) 都會對應到 Push-OutputBinding Cmdlet 的 Name 參數。

下列範例示範如何在函式腳本中呼叫 Push-OutputBinding ：

param($MyFirstInputBinding, $MySecondInputBinding)

Push-OutputBinding -Name myQueue -Value $myValue

您也可以透過管線傳入特定繫結的值。

param($MyFirstInputBinding, $MySecondInputBinding)

Produce-MyOutputValue | Push-OutputBinding -Name myQueue

Push-OutputBinding 會根據為 -Name 指定的值，以不同的方式運作：

當指定的名稱無法解析為有效的輸出系結時，就會擲回錯誤。
當輸出繫結接受值的集合時，您可以重複呼叫 Push-OutputBinding 以推送多個值。
當輸出繫結只接受單一值時，第二次呼叫 Push-OutputBinding 會引發錯誤。

Push-OutputBinding 語法

以下是呼叫 Push-OutputBinding 的有效參數：

名稱	類型	位置	描述
`-Name`	String	1	您想要設定的輸出繫結名稱。
`-Value`	Object	2	您想要設定的輸出繫結值，這是從管線 ByValue 接受的值。
`-Clobber`	SwitchParameter	已命名	(選擇性) 指定此值時會強制為指定的輸出繫結設定值。

也支援下列常見參數：

Verbose
Debug
ErrorAction
ErrorVariable
WarningAction
WarningVariable
OutBuffer
PipelineVariable
OutVariable

如需詳細資訊，請參閱關於 CommonParameters。

Push-OutputBinding 範例：HTTP 回應

HTTP 觸發程序會使用名為 response 的輸出繫結傳回回應。在下列範例中，response 的輸出繫結具有 "output #1" 的值：

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #1"
})

因為輸出的目標是只接受單一值的 HTTP，所以第二次呼叫 Push-OutputBinding 時會擲回錯誤。

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #2"
})

對於只接受單一值的輸出，您可以使用 -Clobber 參數來覆寫舊值，而不是嘗試新增至集合。下列範例假設您已經新增值。藉由使用 -Clobber，下列範例的回應會覆寫現有的值，以傳回 "output #3" 的值：

PS >Push-OutputBinding -Name response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "output #3"
}) -Clobber

Push-OutputBinding 範例：佇列輸出繫結

Push-OutputBinding 會用來將資料傳送至輸出繫結，例如 Azure 佇列儲存體輸出繫結。在下列範例中，寫入佇列的訊息值為 "output #1"：

PS >Push-OutputBinding -Name outQueue -Value "output #1"

儲存體佇列的輸出繫結可接受多個輸出值。在此案例中，在第一次呼叫後呼叫下列範例會將包含以下兩個項目的清單寫入佇列："output #1" 和 "output #2"。

PS >Push-OutputBinding -Name outQueue -Value "output #2"

在前兩次呼叫之後呼叫下列範例，則會再將兩個值新增至輸出集合：

PS >Push-OutputBinding -Name outQueue -Value @("output #3", "output #4")

寫入佇列時，訊息會包含下列四個值："output #1"、"output #2"、"output #3" 和 "output #4"。

Get-OutputBinding Cmdlet

您可以使用 Get-OutputBinding Cmdlet 來擷取目前為輸出繫結設定的值。此 Cmdlet 會擷取雜湊表，其中包含輸出繫結名稱和其個別值。

以下是使用 Get-OutputBinding 傳回目前繫結值的範例：

Get-OutputBinding

Name                           Value
----                           -----
MyQueue                        myData
MyOtherQueue                   myData

Get-OutputBinding 也會包含稱為 -Name 的參數，可用來篩選傳回的繫結，如下列範例所示：

Get-OutputBinding -Name MyQ*

Name                           Value
----                           -----
MyQueue                        myData

Get-OutputBinding 中支援萬用字元 (*)。

記錄

PowerShell 函式中的記錄運作方式就像一般 PowerShell 記錄。您可以使用記錄 Cmdlet 來寫入每個輸出串流。每個 Cmdlet 都會對應至 Functions 所使用的記錄層級。

函式記錄層級	記錄 Cmdlet
錯誤	`Write-Error`
警告	`Write-Warning`
資訊	`Write-Information` `Write-Host` `Write-Output` 寫入 `Information` 記錄層級。
偵錯	`Write-Debug`
追蹤	`Write-Progress` `Write-Verbose`

除了這些 Cmdlet 之外，寫入管線的任何項目都會重新導向至 Information 記錄層級，並以預設的 PowerShell 格式顯示。

重要

使用 Write-Verbose 或 Write-Debug Cmdlet 不足以查看詳細資訊和偵錯層級記錄。您也必須設定記錄層級閾值，以宣告您實際關注的記錄層級。若要深入了解，請參閱設定函式應用程式記錄層級。

設定函式應用程式記錄層級

Azure Functions 可讓您定義閾值層級，讓您輕鬆地控制 Functions 寫入記錄的方式。若要設定寫入至主控台之所有追蹤的閾值，請使用 host.json 檔案中的 logging.logLevel.default 屬性。這個設定會套用到函式應用程式中的所有函式。

下列範例將閾值設定為針對所有函式啟用詳細資訊記錄，但將閾值設定為針對名為 MyFunction 的函式啟用偵錯記錄：

{
    "logging": {
        "logLevel": {
            "Function.MyFunction": "Debug",
            "default": "Trace"
        }
    }
}

如需詳細資訊，請參閱 host.json 參考。

檢視記錄

如果您的函式應用程式正在 Azure 中執行，您可以使用 Application Insights 來進行監視。參閱監視 Azure Functions 深入了解如何檢視和查詢函式記錄。

如果您要在本機執行函式應用程式以進行開發，則會預設為記錄到檔案系統。若要在主控台中查看記錄，請在啟動函式應用程式之前，將 AZURE_FUNCTIONS_ENVIRONMENT 環境變數設定為 Development。

觸發程序和繫結類型

有許多觸發程式和系結可供您搭配函式應用程式使用。您可以在這裡找到觸發程序和繫結的完整清單。

所有觸發程序和繫結都會以程式碼表示為幾個實際資料類型：

Hashtable
string
byte[]
int
double
HttpRequestContext
HttpResponseContext

此清單中的前五個類型是標準 .NET 類型。最後兩個只會由 HttpTrigger 觸發程序使用。

函式中的每個繫結參數都必須是下列其中一種類型。

HTTP 觸發程序和繫結

HTTP 和 Webhook 觸發程序以及 HTTP 輸出繫結會使用要求和回應物件來代表 HTTP 傳訊。

要求物件

傳遞至文稿的要求物件屬於類型 HttpRequestContext，其具有下列屬性：

屬性	描述	類型
`Body`	包含要求本文的物件。 `Body` 會根據資料序列化為最佳類型。例如，如果數據是 JSON，則會以哈希表的形式傳入。如果資料是字串，則會以字串的形式傳入。	object
`Headers`	包含要求標頭的字典。	Dictionary<string,string>^*
`Method`	要求的 HTTP 方法。	string
`Params`	包含要求之路由傳送參數的物件。	Dictionary<string,string>^*
`Query`	包含查詢參數的物件。	Dictionary<string,string>^*
`Url`	要求的 URL。	string

^* 所有 Dictionary<string,string> 索引鍵皆不區分大小寫。

回應物件

您應該傳回的回應物件屬於 HttpResponseContext 類型，其具有下列屬性：

屬性	描述	類型
`Body`	包含回應本文的物件。	object
`ContentType`	設定回應內容類型的速記方式。	string
`Headers`	包含回應標頭的物件。	字典或雜湊表
`StatusCode`	回應的 HTTP 狀態碼。	字串或整數

存取要求和回應

當您使用 HTTP 觸發程序時，您可以使用與任何其他輸入繫結相同的方式來存取 HTTP 要求。其位於 param。

HttpResponseContext使用物件傳回回應，如下列範例所示：

function.json

{
  "bindings": [
    {
      "type": "httpTrigger",
      "direction": "in",
      "authLevel": "anonymous"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

run.ps1

param($req, $TriggerMetadata)

$name = $req.Query.Name

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [System.Net.HttpStatusCode]::OK
    Body = "Hello $name!"
})

叫用此函式的結果如下：

PS > irm http://localhost:5001?Name=Functions
Hello Functions!

觸發程序和繫結的類型轉換

對於 Blob 繫結之類的特定繫結，您可以指定參數的類型。

例如，若要將 Blob 儲存體中的資料提供為字串，請將下列類型轉換新增至我的 param 區塊：

param([string] $myBlob)

PowerShell 設定檔

PowerShell 中會有 PowerShell 設定檔的概念。如果您不熟悉 PowerShell 設定檔，請參閱關於設定檔。

在 PowerShell 函式中，設定檔指令碼會在第一次部署時和閒置之後，針對應用程式中的每個 PowerShell 背景工作執行個體執行一次 (冷啟動)。藉由設定 PSWorkerInProcConcurrencyUpperBound 值來啟用並行功能時，設定檔指令碼會針對每個建立的 Runspace 執行。

當您使用 Visual Studio Code 和 Azure Functions Core Tools 等工具來建立函式應用程式時，系統會為您建立預設的 profile.ps1。預設設定檔會保留在 Core Tools GitHub 存放庫上，並且包含：

自動向 Azure 進行 MSI 驗證。
開啟 Azure PowerShell AzureRM PowerShell 別名的能力 (若有需要的話)。

PowerShell 版本

下表顯示每個 Functions 執行階段主要版本可用的 PowerShell 版本，以及所需的 .NET 版本：

Functions 版本	PowerShell 版本	.NET 版本
4.x	PowerShell 7.4	.NET 8
4.x	PowerShell 7.2 (支援結束)	.NET 6

您可以藉由從任何函式列印 $PSVersionTable，來查看目前的版本。

若要深入瞭解 Azure Functions 運行時間支持原則，請參閱這篇文章

注意

Azure Functions 中的 PowerShell 7.2 支援將於 2024 年 11 月 8 日結束。升級 PowerShell 7.2 函式以在 PowerShell 7.4 上執行時，您可能必須解析一些重大變更。請遵循此移轉指南，以升級至 PowerShell 7.4。

在特定版本上採取本機執行

若要在本機執行時執行 PowerShell 函式，您必須將 "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4" 設定新增至專案根目錄內 local.setting.json 檔案中的 Values 陣列。在 PowerShell 7.4 上採取本機執行時，local.settings.json 檔案看起來會像下列範例：

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "",
    "FUNCTIONS_WORKER_RUNTIME": "powershell",
    "FUNCTIONS_WORKER_RUNTIME_VERSION" : "7.4"
  }
}

注意

在 PowerShell Functions 中，FUNCTIONS_WORKER_RUNTIME_VERSION 的值 "~7" 是指 "7.0.x"。我們不會自動將具有 "~7" 的 PowerShell Function 應用程式升級為 "7.4"。未來，對於 PowerShell Function Apps，我們將要求應用程式指定它們想要鎖定的主要版本和次要版本。因此，如果您想要以 "7.4.x" 為目標，就必須提及 "7.4"

變更 PowerShell 版本

將 PowerShell 函式應用程式移轉至 PowerShell 7.4 之前，請先考量以下幾點：

因為移轉可能會在應用程式中導致重大變更，請在將應用程式升級至PowerShell 7.4 之前，先檢閱此移轉指南。
請確定函式應用程式正在 Azure 中最新版的 Functions 執行階段 ( 4.x 版) 上執行。如需詳細資訊，請參閱檢視及更新目前的執行階段版本。

請使用下列步驟來變更函式應用程式所使用的 PowerShell 版本。您可以在 Azure 入口網站或使用 PowerShell 來執行這項作業。

入口網站
PowerShell

在 Azure 入口網站中，瀏覽至函式應用程式。
在 [設定] 底下，選擇 [組態]。在 [一般設定] 索引標籤中，找出 PowerShell 版本。
選擇您想要的 PowerShell Core 版本，然後選取 [儲存]。出現重新啟動擱置的警告時，請選擇 [繼續]。函式應用程式會在所選的 PowerShell 版本上重新啟動。

注意

PowerShell 7.4 的 Azure Functions 支援已正式推出 (GA)。您可能會在 Azure 入口網站中看到 PowerShell 7.4 仍顯示為預覽狀態，但這很快就會更新，以反映 GA 狀態。

執行下列指令碼來變更 PowerShell 版本：

Set-AzResource -ResourceId "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<FUNCTION_APP>/config/web" -Properties @{  powerShellVersion  = '<VERSION>' } -Force -UsePatchSemantics

將 <SUBSCRIPTION_ID>、<RESOURCE_GROUP> 和 <FUNCTION_APP> 分別取代為 Azure 訂用帳戶的識別碼、資源群組和函式應用程式的名稱。此外，請將 7.4 取代為 <VERSION>。您可以在所傳回雜湊表的 Properties 中驗證 powerShellVersion 設定的更新值。

函式應用程式會在變更組態後重新啟動。

相依性管理

您可以使用下列兩種方式來處理以PowerShell撰寫的 Azure Functions 中的模組：使用受控相依性功能，或直接在應用程式內容中包含模組。每個方法都有自己的優點，而選擇正確的方法取決於您的特定需求。

選擇正確的模組管理方法

為什麼要使用受控相依性功能？

簡化的初始安裝：根據您的 requirements.psd1 檔案自動處理模組安裝。
自動升級：模組會自動更新，包括安全性修正，而不需要手動介入。

為什麼在應用程式內容中包含模組？

PowerShell 資源庫沒有相依性：模組會與您的應用程式搭配使用，而不需要外部相依性。
更多控制：避免自動升級所造成的回歸風險，讓您完全控制使用哪些模組版本。
相容性：適用於彈性取用，並建議用於其他Linux SKU。

受控相依性功能

受控相依性功能可讓 Azure Functions 自動下載及管理檔案中指定的 requirements.psd1 PowerShell 模組。這項功能預設會在新的PowerShell函式應用程式中啟用。

設定 requirements.psd1

若要搭配 PowerShell 在 Azure Functions 中使用受控相依性，您必須配置檔 requirements.psd1 案。此檔案會指定函式所需的模組，而 Azure Functions 會自動下載並更新這些模組，以確保您的環境保持最新狀態。

以下說明如何設定和設定檔 requirements.psd1 案：

requirements.psd1如果 Azure 函式的根目錄中還沒有檔案，請建立檔案。
在 PowerShell 數據結構中定義模組及其版本。

範例 requirements.psd1 檔案：

@{
    'Az' = '9.*'  # Specifies the Az module and will use the latest version with major version 9
}

在應用程式內容中包含模組

若要進一步控制模組版本，並避免相依於外部資源，您可以直接在函式應用程式的內容中包含模組。

若要包含自訂模組：

在 Modules 函式應用程式的根目錄建立資料夾 。
```
mkdir ./Modules
```
使用下列其中一種方法，將模組複製到 Modules 資料夾 ：
- 如果模組已在本機使用：
```
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse
```
- 使用 Save-Module 從 PowerShell 資源庫擷取：
```
Save-Module -Name MyCustomModule -Path ./Modules
```
- 從PSResourceGet模組使用Save-PSResource：
```
Save-PSResource -Name MyCustomModule -Path ./Modules
```

您的函式應用程式應該具有下列結構：

PSFunctionApp
 | - MyFunction
 | | - run.ps1
 | | - function.json
 | - Modules
 | | - MyCustomModule
 | | - MyOtherCustomModule
 | | - MySpecialModule.psm1
 | - local.settings.json
 | - host.json
 | - requirements.psd1

當您啟動函式應用程式時，PowerShell 語言背景工作角色會將此 Modules 資料夾新增至 $env:PSModulePath，因此您可以依賴模組自動載入，就像您在一般 PowerShell 指令碼中所做的一樣。

針對受控相依性進行疑難解答

啟用受控相依性

若要讓Managed相依性運作，必須在host.json中啟用此功能：

{
  "managedDependency": {
          "enabled": true
       }
}

以特定版本為目標

以特定模組版本為目標時，請務必遵循下列步驟，以確保載入正確的模組版本：

在中 requirements.psd1指定模組版本：
```
@{
  'Az.Accounts' = '1.9.5'
}
```

將 import 語句新增至 profile.ps1：

Import-Module Az.Accounts -RequiredVersion '1.9.5'

遵循下列步驟可確保函式啟動時會載入指定的版本。

設定特定的受控相依性間隔設定

您可以使用下列應用程式設定來設定如何下載及安裝受控相依性：

設定	預設值	說明
MDMaxBackgroundUpgradePeriod	`7.00:00:00` (7 天)	控制 PowerShell 函式應用程式的背景更新期間。
MDNewSnapshotCheckPeriod	`01:00:00` (一小時)	指定 PowerShell 背景工作角色檢查更新的頻率。
MDMinBackgroundUpgradePeriod	`1.00:00:00` (一天)	升級檢查之間的最短時間。

相依性管理考量

因特網存取：受控相依性需要存取以 https://www.powershellgallery.com 下載模組。請確定您的環境允許此存取，包括視需要修改防火牆/VNet 規則。
授權接受：受控相依性不支援需要接受授權的模組。
Flex 取用方案：彈性取用方案中不支援受控相依性功能。請改用自定義模組。
模組位置：在您的本機計算機上，模組通常會安裝在您 $env:PSModulePath中其中一個全域可用的資料夾中。在 Azure 中執行時， $env:PSModulePath 適用於 PowerShell 函式應用程式的與一般 PowerShell 腳本不同 $env:PSModulePath ，而且會包含 Modules 與您的應用程式內容一起上傳的資料夾，以及受受控相依性管理的個別位置。

環境變數

在 Functions 中，應用程式設定 (例如服務連接字串) 在執行期間會公開為環境變數。您可以使用 $env:NAME_OF_ENV_VAR 存取這些設定，如下列範例所示：

param($myTimer)

Write-Host "PowerShell timer trigger function ran! $(Get-Date)"
Write-Host $env:AzureWebJobsStorage
Write-Host $env:WEBSITE_SITE_NAME

有數種方式可供您新增、更新和刪除函式應用程式設定：

對函式應用程式設定的變更需要將函式應用程式重新啟動。

在本機執行時，應用程式設定會讀取自 local.settings.json 專案檔。

並行

根據預設，Functions PowerShell 執行階段一次只能處理一個函式叫用。不過，在下列情況下，此並行層級可能不夠：

當您嘗試同時處理大量叫用時。
當您擁有在相同函式應用程式內叫用其他函式的函式時。

您可以根據工作負載類型來探索幾個並行模型：

增加 FUNCTIONS_WORKER_PROCESS_COUNT。增加此設定可讓處理相同實例內多個進程的函式調用，這會導致特定 CPU 和記憶體額外負荷。一般而言，I/O 系結函式不會因為此額外負荷而受到影響。對於 CPU 繫結函式，該影響可能很明顯。
增加 PSWorkerInProcConcurrencyUpperBound 應用程式設定值。增加此設定可讓您在同一個進程中建立多個 Runspace，這可大幅降低 CPU 和記憶體額外負荷。

您可以在函式應用程式的應用程式設定中設定這些環境變數。

根據您的使用案例，Durable Functions 可能會大幅改善延展性。若要深入了解，請參閱 Durable Functions 應用程式模式。

注意

您可能會收到「要求已排入佇列，因為沒有可用的 Runspace」警告，請注意這不是錯誤。訊息會告訴您要求已排入佇列，且會在先前的要求完成時進行處理。

使用並行功能的考量

PowerShell 預設為 single_threaded 指令碼語言。不過，您可以在相同程序中使用多個 PowerShell Runspace 來新增並行功能。 PSWorkerInProcConcurrencyUpperBound 應用程式設定會限制建立的 Runspace 數目，因此每個背景工作角色的並行執行緒數目也會受限。根據預設，Runspace 數目在 Functions 執行階段的 4.x 版中會設定為 1,000 個。在 3.x 版和較低版本中，Runspace 數目的上限會設定為 1 個。函式應用程式的輸送量會受到所選方案中可用 CPU 和記憶體數量的影響。

Azure PowerShell 會使用一些程序層級的內容和狀態，協助您避免輸入過多數量。不過，如果您在函式應用程式中開啟並行功能，並叫用變更狀態的動作，最後可能會產生競爭情況。這些競爭情況很難偵錯，因為其中一個叫用會依賴特定狀態，而另一個叫用變更了狀態。

Azure PowerShell 的並行功能有極大的價值，因為某些作業可能需要相當長的時間。不過，您必須小心。如果您懷疑遇到競爭情況，請將 PSWorkerInProcConcurrencyUpperBound 應用程式設定設定為 1，並改為使用語言背景工作角色程序層級隔離來進行並行作業。

設定函式 scriptFile

預設會從 run.ps1 執行 PowerShell 函式，這是與對應的 function.json 共用相同父目錄的檔案。

function.json 中的 scriptFile 屬性可用來取得如下列範例所示的資料夾結構：

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.ps1

在此案例中，myFunction 的 function.json 會包含 scriptFile，其會參考具有待執行匯出函式的檔案。

{
  "scriptFile": "../lib/PSFunction.ps1",
  "bindings": [
    // ...
  ]
}

藉由設定 entryPoint 來使用 PowerShell 模組

本文中的PowerShell函式會顯示範本所產生的預設 run.ps1 腳本檔案。不過，您也可以在 PowerShell 模組中包含函式。您可以使用 function.json 組態檔中的 scriptFile 和 entryPoint 欄位，在模組中參考您的特定函式程式碼。

在此案例中，entryPoint 是 PowerShell 模組中 scriptFile 參考的函式或 Cmdlet 名稱。

考慮下列資料夾結構：

FunctionApp
 | - host.json
 | - myFunction
 | | - function.json
 | - lib
 | | - PSFunction.psm1

其中 PSFunction.psm1 包含：

function Invoke-PSTestFunc {
    param($InputBinding, $TriggerMetadata)

    Push-OutputBinding -Name OutputBinding -Value "output"
}

Export-ModuleMember -Function "Invoke-PSTestFunc"

在此範例中，myFunction 的組態會包含參考 PSFunction.psm1 (這是另一個資料夾中的 PowerShell 模組) 的 scriptFile 屬性。 entryPoint 屬性會參考 Invoke-PSTestFunc 函式，這是模組中的進入點。

{
  "scriptFile": "../lib/PSFunction.psm1",
  "entryPoint": "Invoke-PSTestFunc",
  "bindings": [
    // ...
  ]
}

使用此組態時，Invoke-PSTestFunc 像 run.ps1 一樣執行。

PowerShell 函式的考量

當您使用 PowerShell 函式時，請留意下列小節中的考量事項。

冷啟動

在無伺服器裝載模型中開發 Azure Functions 時，可進行冷啟動。 冷啟動是指函式應用程式開始執行以處理要求所需的時間。冷啟動經常會在取用方案中發生，因為您的函式應用程式會在閒置期間關閉。

避免使用 Install-Module

在每個調用的函式腳本中執行 Install-Module 可能會導致效能問題。請改用 Save-Module 或 Save-PSResource 發佈函式應用程式之前，將必要的模組組合在一起。

如需詳細資訊，請參閱相依性管理一節。

下一步

如需詳細資訊，請參閱以下資源：

共用方式為