Gridwich 管線會內嵌、處理、儲存和傳遞媒體資產，並透過兩個新的方法，Azure 事件方格 三明治和 Terraform 三明治。
架構
Gridwich 架構有兩 個 三明治，可解決異步事件處理和基礎結構即程序代碼的需求：
Event Grid 三明治會藉由在兩個 Event Grid 處理程式之間夾取遠端和長時間執行的進程，例如來自外部傳奇工作流程系統的媒體編碼。 這個三明治可讓外部系統傳送要求事件、監視排程的事件，以及等候可能抵達幾分鐘或數小時后的最終成功或失敗回應。
Terraform Sandwich 是更新為支援基礎結構即程式代碼的多階段 Terraform 模式。 分隔基礎結構和軟體版本表示必須先發行並執行 Azure Functions 應用程式，Terraform 才能部署事件方格訂用帳戶。 為了解決這項需求，CI/CD 管線中有兩個 Terraform 作業：
- Terraform 1 會建立 Azure 事件方格 訂用帳戶以外的所有資源。
- Terraform 2 會在軟體啟動並執行之後建立事件方格訂用帳戶。
如此一來，Terraform 就可以完全管理和部署解決方案基礎結構，即使並非所有 的 Azure 資源 都可以在部署軟體成品之前建立。
工作流程
Gridwich 要求和回應程序涵蓋下列要求：
- 建立
- 傳輸
- Reception
- 分派至 Gridwich 元件
- 通知和動作
- 回覆
下列步驟說明外部系統和 Gridwich 之間的要求和回應程式。 在 Gridwich 中，外部系統是 MAM 和傳奇工作流程協調流程系統。 如需 Gridwich 作業訊息事件的確切格式，請參閱 Gridwich 訊息格式。
外部系統會建立要求，並將它傳送至要求代理程式。
要求代理人負責將要求分派至傳統發行集訂閱模型中的 Gridwich 要求接聽程式。 在此解決方案中，要求代理程式會 Azure 事件方格。 所有要求都會使用 Event Grid 事件架構來封裝。
Gridwich Azure Functions 應用程式會從事件方格取用事件。 為了獲得更好的輸送量，Gridwich 會將 HTTP 端點 定義為 Event Grid 起始的推送模型，而不是 Azure Functions 所提供的事件方格系結 輪詢模型。
Azure Functions 應用程式會讀取事件屬性，並將事件分派至處理該事件類型和版本的 Gridwich 程式代碼部分。
任何將使用目前要求的處理程式都會使用通用 EventGridHandlerBase 類別，在收到要求時立即傳送通知訊息。 處理程序接著會將工作分派至衍生類別。
Gridwich 要求工作流程本質上可以是同步或異步的。 對於易於執行且快速完成的要求， 同步處理程式 會執行工作，並在傳送通知之後幾乎立即傳回成功或失敗事件。
對於長時間執行的要求， 異步處理程式 會評估要求、驗證自變數，並起始長時間執行的作業。 處理程式接著會傳回 Scheduled 回應，以確認它要求工作活動。 完成工作活動時，要求處理程式會負責為工作提供成功或失敗已完成事件。
事件發行集服務會將通知、失敗、排程或成功訊息傳達給事件方格要求代理人。
Azure 函式中的事件發行者會將回應事件傳送至事件方格主題，該主題可作為可靠的訊息代理程式。 外部系統會訂閱主題，並取用訊息。 事件方格平臺會提供其一般重試邏輯，以便發行至外部系統。
訊息順序
雖然通知在成功和排程的回應之前，但 Gridwich 不保證排程的回應一律會在對應的成功回應之前。 有效的回應順序可以是 已確認的 > 已排程 > 成功 或 已確認 > 的成功 > 排程。
要求失敗
要求失敗可能是因為要求錯誤、遺漏先決條件、處理失敗、安全性例外狀況或未處理的例外狀況所造成。 幾乎所有失敗都有相同的訊息格式，並包含原始 作業內容 值。 常見的 EventGridHandlerBase 類別通常會透過 Azure Function 事件發行者介面將失敗回應傳送至事件方格。 Application Insights 也會透過 結構化記錄來記錄失敗。
作業內容
外部系統可能會每天、每小時或每秒產生數千個要求。 對 Gridwich 的每個 要求事件 都必須包含名為 的 operationContextJSON 物件屬性。
如果要求包含作業內容，例如 {"id"="Op1001"}，每個 Gridwich 回應 都必須包含對應的不透明 作業內容，不論要求是短期執行還是長時間執行。 此作業內容會持續執行非常長時間的要求存留期。
回應需求適用於「對應」，而不是「相同」JSON 物件。 Context Muting 之類的 Gridwich 功能會利用外部系統以由上至下的方式處理傳回的 JSON 對象的事實。
具體而言，外部系統具有：
不相依於屬性排序，因此 Gridwich 可以傳回具有相同屬性的物件，可能順序不同。 例如，
{"a":1,"b":2}與{"b":2,"a":1}。沒有額外的屬性存在的問題，因此已收到
{"b":2,"a":1}的 Gridwich 可以有效傳回{"a":1,"b":2,"~somethingExtra":"yes"}。 為了將衝突的可能性降到最低，Gridwich 會在新增的屬性名稱前面加上圖格符號（~），例如~muted。沒有 JSON 格式相依性。 例如，沒有關於空格符填補可能落在 JSON 字串表示法中的假設。 Gridwich 會藉由壓縮 JSON 物件的字串表示中不必要的空格符，來利用這種缺乏格式相依性。 請參閱 JSONHelpers.SerializeOperationContext。
傳奇參與者和作業內容
在 Gridwich 傳奇協調流程系統中，每個 傳奇參與者 都會為系統貢獻一或多個工作活動。 每個傳奇參與者與其他參與者獨立運作，而且一個以上的傳奇參與者可能會根據單一要求採取行動。
每個傳奇參與者都必須保留作業內容，但可能以不同的方式實作。 例如：
- 短期執行的同步作業會保留作業內容。
- Azure 儲存體 提供針對大部分作業呼叫
ClientRequestId的不透明字串屬性。 - 某些服務有 屬性
Job.CorrelationData。 - 其他雲端 API 提供與不透明作業內容類似的概念，這些內容可在發出進度、完成或失敗訊號時傳回。
如需傳奇和傳奇參與者的詳細資訊，請參閱 Saga協調流程。
同步和異步處理程式
系統中的每個事件處理程式都會使用通用 EventGridHandlerBase 類別來提供一般服務，例如要求通知、失敗處理，以及回應事件的發行。 事件發行集服務會將通知、失敗、排程或成功訊息傳達給事件方格要求代理人。
任何計劃使用目前要求的處理程式，都必須在收到要求時提供通知。 基類會立即傳送通知訊息，然後將工作分派至衍生類別。
同步事件處理
對於容易執行且快速完成的要求，處理程式會同步執行工作，並傳回 Success 事件，其作業內容幾乎緊接在傳送通知之後。
.
例如， ChangeBlobTierHandler 是簡單的同步流程。 處理程式會取得要求數據傳輸物件 （DTO）、呼叫並等候單一服務來執行工作，並傳回 Success 或 Failure 回應。
異步事件處理
某些要求長時間執行。 例如，編碼媒體檔案可能需要數小時的時間。 在這些情況下， 異步要求處理程式 會評估要求、驗證自變數，並起始長時間執行的作業。 處理程式接著會傳回 Scheduled 回應，以確認它要求工作活動。
完成工作活動時，要求處理程式會負責為工作提供成功或失敗已完成事件。 當剩餘無狀態時，處理程式必須擷取原始 作業內容 ，並將它放在 Completed 事件訊息承載中。
例如， BlobCopyHandler 會顯示簡單的異步流程。 處理程式會取得 Request DTO、呼叫並等候單一服務來起始工作，併發佈 Scheduled 或 Failure 回應。
若要完成長時間執行的要求流程， BlobCreatedHandler 會取用平臺事件 Microsoft.Storage.BlobCreated、擷取原始作業內容，併發佈成功或失敗完成回應。
長時間執行的函式
當 Gridwich 部署新的 Functions 應用程式時，它可能會卸除目前長時間執行的進程。 如果這些進程突然結束，則沒有狀態，也沒有回報給呼叫端。 Gridwich 必須部署新的 Functions 應用程式，同時正常處理長時間執行函式的轉換，而不會遺漏任何訊息。
解決方案必須：
- 請勿保留 Gridwich 應用程式執行中實例的狀態。
- 不只是因為有新專案正在部署，或新訊息要求相同的活動，才終止進程。
- 請勿叫用任何其他 Azure 工作負載，例如 Durable Functions、Functions Apps、Logic Apps 或 Azure 容器執行個體。
Gridwich 會使用 Azure Functions 位置部署 和 取消令牌 來符合可靠且長時間執行的函式的這些需求。
下圖顯示大部分 Gridwich 作業的運作方式。 綠色方塊代表 Gridwich 傳遞給外部服務的工作。 Gridwich 接著會以事件驅動的方式響應狀態。 紅色方塊會顯示在 Gridwich 本身長時間執行的函式。
Functions 執行時間會在應用程式關閉時新增取消令牌。 Gridwich 會偵測令牌，並傳回所有要求和目前執行中進程的錯誤碼。
位置部署會部署新的軟體版本。 生產位置具有執行中的應用程式，而預備位置具有新版本。 Azure 會執行一系列部署步驟，然後交換位置實例。 舊實例會重新啟動，做為程序的最後一個步驟。
Gridwich 會在重新對應主機名之後等候 30 秒，因此針對 HTTP 觸發的函式，Gridwich 保證在舊的生產位置重新啟動前至少 30 秒。 其他觸發程式可能由沒有等候應用程式設定更新機制的應用程式設定所控制。 這些函式會在舊生產位置重新啟動前立即開始執行，則這些函式可能會中斷。
如需詳細資訊，請參閱在 Azure Functions 和 Azure Functions 部署位置的插槽交換期間會發生什麼情況。
元件
Gridwich 媒體處理解決方案使用 Azure 事件方格、Azure Functions、Azure Blob 儲存體、Azure Logic Apps 和 Azure 金鑰保存庫。 CI/CD 和 Saga 協調流程程式會使用 Azure Repos、Azure Pipelines 和 Terraform。
Azure 事件方格 管理 Gridwich 事件的路由，以及兩個三明治事件方格作業，可允許異步媒體事件處理。 事件方格是高度可靠的要求傳遞端點。 Azure 平臺提供必要的要求傳遞端點運行時間和穩定性。
Gridwich 會將事件封裝在 Event Grid 架構
Event.Data屬性物件內，而事件方格代理程式和傳輸層則不透明。 Gridwich 也會使用eventType和dataVersion物件字段來路由事件。 因此，Event Grid 要求代理程式可以與其他發行集訂閱事件代理程式取代，Gridwich 會視可能最少的事件字段而定，而且不會使用topic或subject字段。Azure Functions 可讓您執行事件觸發的程序代碼，而不需要明確布建或管理基礎結構。 Gridwich 是 Azure Functions 應用程式，可裝載各種函式的執行。
Azure Blob 儲存體 提供可調整、符合成本效益的雲端記憶體，以及媒體資產等非結構化數據的存取。 Gridwich 同時使用 Azure 儲存體 區塊 Blob 和容器。
Azure 金鑰保存庫 保護 Azure 和第三方應用程式和服務所使用的密碼編譯密鑰、密碼和其他秘密。
Azure DevOps 是一組開發人員和作業服務，包括 Git 型程式代碼存放庫，以及與 Azure 整合的自動化建置和發行管線。 Gridwich 會使用 Azure Repos 來儲存和更新程式碼專案，以及 CI/CD 和其他工作流程的 Azure Pipelines 。
Terraform 是一種開放原始碼工具，使用基礎結構即程式代碼來布建和管理基礎結構和服務。
替代項目
Durable Functions 具有長時間執行作業的內建狀態存放區，也可以提供不透明的作業內容。 Durable Functions 可以在作業內建立一系列工作，並將作業內容儲存為作業的輸入或輸出。 事實上，Gridwich 可以針對所有工作活動使用 Durable Functions，但此方法會增加程式碼複雜度。
您可以將 EventGridHandlerBase 重構為
RequestHandlerBase，並移除事件方格物件或類型的任何連結，以達成與 Event Grid 基礎結構更好的分離。 此重構類別只會在基底 DTO 中處理，而不是在傳輸特定物件類型中處理。 同樣地， IEventGridDispatcher 可能會成為IResponseDispatcher具有特定EventGridDispatcher實作的 。Gridwich.SagaParticipants.儲存體。Azure 儲存體 連結庫也包含其他傳奇參與者所使用的記憶體服務。 在核心專案中擁有介面可避免控制反轉問題，但您可以將介面擷取到個別的核心記憶體基礎結構網關連結庫。
Gridwich Functions 應用程式會使用 相依性插入 來註冊特定事件類型和數據版本的一或多個要求處理程式。 應用程式會 插入 EventGridDispatcher 與 Event Grid 事件處理程式的集合，而發送器會查詢處理程式以判斷要處理事件的處理程式。
或者，您可以使用事件方格平臺所提供的事件訂用帳戶和篩選機制。 此機制會強制使用 1：1 部署模型，其中一個 Azure 函式只裝載一個事件處理程式。 雖然 Gridwich 使用 1：多模型，但其 全新架構 表示重構 1：1 的解決方案並不容易。
如需替代微服務，而不是整合型 Gridwich 架構，請參閱 微服務替代方案。
案例詳細資料
知名大眾媒體和娛樂集團取代了其內部部署影片串流服務，並以雲端式解決方案來內嵌、處理和發佈視訊資產。 公司的主要目標是利用 Azure 雲端容量、成本和彈性來：
- 擷取原始視訊檔案、處理和發佈它們，並滿足媒體要求。
- 使用全新架構的方法，大規模改善編碼和新的接收和散發功能。
- 針對媒體資產管理 （MAM） 管線實作持續整合和傳遞 （CI/CD）。
為了達到這些目標，Microsoft 工程小組開發了 Gridwich，這是由外部 傳奇工作流程協調流程系統驅動的無狀態事件處理架構。
潛在的使用案例
工程小組開發了 Gridwich，以符合下列原則和業界標準：
Gridwich 系統體現了在 Azure 上處理和傳遞媒體資產的最佳做法。 雖然 Gridwich 系統是媒體特定的，但是訊息處理和事件架構可以套用至任何無狀態事件處理工作流程。
部署此案例
- 移至 GitHub 上的 Gridwich 存放庫。
- 請遵循 所有程式，從 設定 Azure DevOps 開始。
相關資源
- 適用於 Azure Pipelines 的 Terraform 入門專案
- 具有事件方格和 Terraform 三明治範例的 Azure 函式。 使用 Terraform Sandwich，透過 Terraform 訂閱 Azure 函式的事件方格事件。
- MediaInfoLib 與 Azure 儲存體。 使用跨平臺 .NET Core 來擷取儲存在 Azure 儲存體 之媒體檔案上的報表的 Azure Functions 和控制台範例。
- 事件方格查看器 Blazor。 事件方格查看器應用程式，使用 Blazor 和 SignalR 搭配 Microsoft Entra 授權支援。
- 適用於 Azure 儲存體 的受控服務識別 Azure 函式。 使用 Azure Functions 與 Azure 儲存體 之間的受控服務識別。