Azure Functions PowerShell 開發人員指南

發行項
10/16/2024

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

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

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

本文假設您已經讀過 Azure Functions 開發人員參考。您應該也已完成 PowerShell 的函式快速入門，建立了您的第一個 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 中。 Functions 會透過數種方式與繫結互動。

讀取觸發程序和輸入資料

觸發程序和輸入繫結會讀取為傳遞至函式的參數。輸入繫結在 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 資源庫來管理相依性。啟用相依性管理後，系統會使用 requirements.psd1 檔案自動下載所需的模組。您可以在 host.json 檔案的根目錄中將 managedDependency 屬性設定為 true 來啟用此行為，如下列範例所示：

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

當您建立新的 PowerShell 函式專案時，預設會啟用相依性管理，且其中會包含 Azure Az模組。目前支援的模組數目上限為 10 個。支援的語法為 MajorNumber.* 或確切的模組版本，如下列 requirements.psd1 範例所示：

@{
	Az = '1.*'
	SqlServer = '21.1.18147'
}

當您更新 requirements.psd1 檔案時，更新的模組會在重新啟動之後安裝。

以特定版本為目標

您可以以 requirements.psd1 檔案中的特定模組版本為目標。例如，如果您想要使用比內含 Az 模組中版本還舊的 Az.Accounts 版本，您需要以特定版本為目標，如下列範例所示：

@{
	'Az.Accounts' = '1.9.5'
}

在此案例中，您也需要將重要陳述式新增至 profile.ps1 檔案頂端，如下列範例所示：

Import-Module Az.Accounts -RequiredVersion '1.9.5'

如此一來，舊版的 Az.Account 模組就會在啟動函式時先載入。

相依性管理考量

使用相依性管理時應考量下列事項：

受控相依性需要存取 https://www.powershellgallery.com 才能下載模組。在本機執行時，請新增任何必要的防火牆規則，確定執行階段可以存取此 URL。
受控相依性目前不支援要求使用者接受授權的模組 (無論是以互動方式接受授權或在叫用 Install-Module 時提供 -AcceptLicense 參數)。
當您在 Flex 使用量方案中裝載函數應用程式時，不支援受控相依性。您必須改為定義自己的自訂模組。

相依性管理應用程式設定

下列應用程式設定可用來變更下載和安裝受控相依性的方式。

函式應用程式設定	預設值	說明
MDMaxBackgroundUpgradePeriod	`7.00:00:00` (7 天)	控制 PowerShell 函式應用程式的背景更新期間。若要深入了解，請參閱 MDMaxBackgroundUpgradePeriod。
MDNewSnapshotCheckPeriod	`01:00:00` (一小時)	指定每個 PowerShell 背景工作角色檢查是否安裝受控相依性升級的頻率。若要深入了解，請參閱 MDNewSnapshotCheckPeriod。
MDMinBackgroundUpgradePeriod	`1.00:00:00` (一天)	先前升級檢查之後到啟動另一個升級檢查之前的時間週期。若要深入了解，請參閱 MDMinBackgroundUpgradePeriod。

基本上，您的應用程式升級會在 MDMaxBackgroundUpgradePeriod 內開始，而升級程序大約會在 MDNewSnapshotCheckPeriod 內完成。

自訂模組

在 Azure Functions 中運用您自己的自訂模組，與 PowerShell 的一般執行方式不同。

在您的本機電腦上，模組會安裝在 $env:PSModulePath 的其中一個全域可用資料夾中。在 Azure 中執行時，您無法存取機器上安裝的模組。這表示 PowerShell 函式應用程式的 $env:PSModulePath 與一般 PowerShell 指令碼中的 $env:PSModulePath 不同。

在 Functions 中，PSModulePath 包含兩個路徑：

存在於函式應用程式根目錄的 Modules 資料夾。
PowerShell 語言背景工作角色所控制 Modules 資料夾的路徑。

函式應用層級模組資料夾

若要使用自訂模組，您可以放置函式在 Modules 資料夾中相依的模組。從此資料夾中，模組會自動提供給函式執行階段使用。函式應用程式中的任何函式都可以使用這些模組。

注意

requirements.psd1 檔案中指定的模組會自動下載並包含在路徑中，因此您不需要將其包含在模組資料夾中。這些會儲存在本機的 $env:LOCALAPPDATA/AzureFunctions 資料夾中，並於雲端中執行時儲存在 /data/ManagedDependencies 資料夾中。

若要利用自訂模組功能，請在函式應用程式的根目錄中建立 Modules 資料夾。將您想要在函式中使用的模組複製到這個位置。

mkdir ./Modules
Copy-Item -Path /mymodules/mycustommodule -Destination ./Modules -Recurse

使用 Modules 資料夾時，您的函式應用程式應該具有下列資料夾結構：

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

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

語言背景工作角色層級模組資料夾

PowerShell 語言背景工作角色通常會使用數個模組。這些模組定義於 PSModulePath 的最後一個位置。

目前的模組清單如下所示：

Microsoft.PowerShell.Archive：用於處理封存的模組，例如 .zip、.nupkg 和其他。
ThreadJob：PowerShell 作業 API 的執行緒型實作。

根據預設，Functions 會使用這些模組的最新版本。若要使用特定的模組版本，請將該特定版本放在函式應用程式的 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 模組

本文已在範本所產生的預設 run.ps1 指令碼檔案中顯示 PowerShell 函式。不過，您也可以在 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，如此一來，您的函式就不需要浪費時間下載模組。如果冷啟動會影響函式，請考慮將函式應用程式部署至設定為一律開啟或進階方案的 App Service 方案。

下一步

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

共用方式為