此參考架構提供部署任務關鍵性工作負載的指引，該工作負載使用集中式共用服務、需要內部部署連線能力，並與企業的其他工作負載整合。 本指南適用於屬於組織中應用程式小組的工作負載擁有者。
當您的組織想要在繼承 Corp. Management 群組的 Azure 應用程式登陸區域中部署工作負載時，您可能會發現自己處於這種情況。 工作負載應與集中式小組所管理的 Azure 平臺登陸區域中預先布建的共用資源整合。
重要
什麼是 Azure 登陸區域? 應用程式登陸區域是工作負載執行所在的 Azure 訂用帳戶。 它已連線到組織的共享資源。 透過該連線，它可以存取執行工作負載所需的基本基礎結構，例如網路、身分識別存取管理、原則和監視。 平臺登陸區域是各種訂用帳戶的集合，每個訂用帳戶都有特定的功能。 例如，連線ivity訂用帳戶提供集中式 DNS 解析、內部部署連線，以及可供應用程式小組使用的網路虛擬設備（NVA）。
身為工作負載擁有者，您可以將共用資源的管理卸除給中央小組，並專注於工作負載開發工作，以受益。 組織可藉由在多個工作負載之間套用一致的治理和分攤成本，來受益。
強烈建議您瞭解 Azure 登陸區域的概念。
在這種方法中，最大的可靠性是您與平臺小組之間的共同責任。 集中管理的元件必須高度可靠，任務關鍵性工作負載才能如預期般運作。 您必須與平臺小組有信任的關係，才能在平臺層級緩解會影響工作負載的集中式服務中無法使用的問題。 但是，您的小組負責推動平臺小組的需求，以達成您的目標。
此架構是以具有網路控件的任務關鍵基準架構為基礎。 建議您先熟悉基準架構，再繼續進行本文。
注意
此指引受到生產等級 範例實 作的支援，可展示 Azure 上的任務關鍵性應用程式開發。 此實作可作為進一步解決方案開發的基礎，作為進入生產環境的第一步。
關鍵設計策略
將這些策略套用在任務關鍵性基準之上：
重要路徑
並非所有架構的元件都必須同樣可靠。 關鍵路徑包含必須保持運作狀態的元件，讓工作負載不會遇到任何中斷時間或效能降低。 讓該路徑保持精簡，將會將失敗點降到最低。
元件的生命週期
請考慮重要元件的生命週期，因為它會影響您達到接近零下限的目標。 元件可以是 暫時 或短期的資源，可以視需要建立和終結; 與系統或區域共用存留期的非暫時 或長期資源。
外部相依性
將元件和進程的外部相依性降到最低，這可能會導致失敗點。 此架構擁有您小組外部各種小組所擁有的資源。 這些元件（如果關鍵）屬於此架構的範圍。
訂用帳戶拓撲
Azure 登陸區域並不表示單一訂用帳戶拓撲。 請與平臺小組事先規劃訂用帳戶使用量，以因應所有環境的工作負載可靠性需求。
自主可觀察性進入關鍵路徑
擁有專用的監視資源，可讓小組快速查詢其數據收集（特別是關鍵路徑），並採取行動進行補救。
架構
此架構的元件與 具有網路控件的任務關鍵基準架構相同。 描述是簡明的簡短描述。 如果您需要詳細資訊，請參閱連結的文章。 如需 Azure 服務的產品檔，請參閱 相關資源。
全域資源
這些資源位於應用程式登陸區域訂用帳戶中。 全域資源不是暫時的，且會共享系統的存留期。 Azure 服務及其設定會與基準全域資源保持相同。
區域網路資源
這些資源會即時存在於平臺登陸區域訂用帳戶和應用程式登陸區域訂用帳戶上。 基準 架構 會部署您擁有的所有資源。 不過，在此架構中，網路資源會透過 連線ivity訂用帳戶來布建，作為平臺登陸區域的一部分。
在本文中，請參閱 區域中樞虛擬網路 一節。
區域戳記資源
這些資源位於應用程式登陸區域訂用帳戶中。 這些資源不會與其他資源分享，但全域資源除外。
除了平臺小組預先布建的網路資源之外，大部分的 Azure 服務及其設定都與基準戳記架構相同。
在本文中，請參閱 區域支點虛擬網路 一節。
外部資源
工作負載會與內部部署資源互動。 其中有些是工作負載的關鍵路徑，例如內部部署資料庫。 這些資源和與其通訊會納入工作負載的整體複合服務等級協定（SLA）。 所有通訊都是透過 連線 訂用帳戶。 工作負載可能會連線到其他外部資源，但不會被視為重要資源。
部署管線資源
針對任務關鍵性應用程式建置和發行管線必須完全自動化，才能保證部署已驗證戳記的一致方式。 這些資源與基準部署管線保持不變。
區域監視資源
這些資源位於應用程式登陸區域訂用帳戶中。 全域資源和區域資源的監視數據會獨立儲存。 Azure 服務及其組態與基準監視資源保持不變。
在本文中，請參閱 監視考慮 一節。
管理資源
為了存取私人計算叢集和其他資源，此架構會使用私人組建代理程式和跳板式虛擬機實例。 Azure Bastion 可讓您安全地存取跳躍方塊。 戳記內的資源仍與基準管理資源相同。
網路考量
在此設計中，工作負載會部署在應用程式登陸區域中，且需要連線到平臺登陸區域中的同盟資源。 其用途可能是存取內部部署資源、控制輸出流量等等。
網路拓撲
平臺小組會決定整個組織的網路拓撲。 此架構中假設中樞輪輻拓撲 。 替代方式可能是 Azure 虛擬 WAN。
區域中樞虛擬網路
連線ivity訂用帳戶包含具有整個組織共用資源的中樞虛擬網路。 這些資源是由平臺小組所擁有和維護。
從任務關鍵性的觀點來看，此網路不是暫時的，而且這些資源位於關鍵路徑上。
| Azure 資源 | 目的 |
|---|---|
| Azure ExpressRoute | 提供從內部部署到 Azure 基礎結構的私人連線。 |
| Azure 防火牆 | 作為檢查和限制輸出流量的 NVA。 |
| Azure DNS | 提供跨單位名稱解析。 |
| VPN 閘道 | 連線 透過公用因特網對 Azure 基礎結構的遠端組織分支。 也可做為備份連線能力替代專案，以新增復原功能。 |
資源會布建在每個區域中，並對等互連至輪輻虛擬網路（如下所述）。 請確定您已瞭解並同意 NVA 的更新、防火牆規則、路由規則、ExpressRoute 故障轉移至 VPN 閘道、DNS 基礎結構等等。
注意
使用同盟中樞的主要優點是工作負載可以透過周遊組織管理的網路中樞，與 Azure 中的其他工作負載整合，或跨單位整合。 這項變更也會降低您的營運成本，因為責任的一部分會轉移到平臺小組。
區域輪輻虛擬網路
應用程式登陸區域至少有兩個預先布建的 Azure 虛擬網絡，每個區域都是區域戳記所參考。 這些網路不是暫時的。 一個服務生產流量，另一個則以 vNext 部署為目標。 此方法可讓您執行 可靠且安全的部署做法。
作業虛擬網路
作業流量會在個別的虛擬網路中隔離。 此虛擬網路不是暫時的，而且您擁有此網路。 此架構會使用網路控制項來保留與基準架構相同的設計。
作業網路與輪輻網路之間沒有對等互連。 所有通訊都是透過 Private Link。
共同責任
清楚瞭解哪一個小組負責架構的每個設計元素。 以下是一些關鍵領域。
IP 位址規劃
在您估計執行工作負載所需的大小之後，請與平臺小組合作，以便他們適當地布建網路。
平臺小組
為參與對等互連的虛擬網路提供不同的位址。 重疊的位址，例如內部部署和工作負載網路，可能會導致中斷。
配置足以包含運行時間和部署資源的IP位址空間、處理故障轉移，以及支援延展性。
預先布建的虛擬網路和對等互連必須能夠支援工作負載的預期成長。 您必須定期評估平臺小組的成長。 如需詳細資訊，請參閱 連線 Azure。
區域輪輻網路子網
您必須負責配置區域虛擬網路中的子網。 子網及其中的資源是暫時的。 地址空間應該夠大，以容納潛在的成長。
私人端點子網 流量到達虛擬網路之後，與網路內的 PaaS 服務通訊會受限於使用私人端點，就像使用網路控件的基準架構一樣。 這些端點會放在專用子網中。 私人IP位址會從該子網指派給私人端點。
叢集子網 工作負載的延展性需求會影響應該為子網配置多少位址空間。 當 AKS 節點和 Pod 相應放大時，IP 位址會從這個子網指派。
網路分割
維護適當的分割，讓工作負載的可靠性不會受到未經授權的存取所危害。
此架構會使用網路安全組 （NSG） 來限制子網和 連線 性訂用帳戶之間的流量。 NSG 會針對支持的服務使用 ServiceTags。
平臺小組
透過 Azure 網路管理員原則強制執行 NSG 的使用。
請注意工作負載設計。 戳記之間沒有任何直接流量。 此外，區域間沒有流程。 如果需要這些路徑，流量必須流經 連線ivity訂用帳戶。
防止來自其他工作負載到任務關鍵性工作負載的不必要的中樞流量。
來自區域戳記的輸出流量
來自每個區域輪輻網路的所有傳出流量都會透過區域中樞網路中集中 Azure 防火牆 路由傳送。 它會做為下一個檢查，然後允許或拒絕流量的躍點。
平臺小組
建立該自定義路由的 UDR。
指派 Azure 原則，以封鎖應用程式小組建立沒有新路由表的子網。
為應用程式小組提供適當的角色型訪問控制 （RBAC） 許可權，以便根據工作負載的需求來擴充路由。
多重區域備援
您的任務關鍵性工作負載必須部署在多個區域中，才能承受區域性中斷。 請與平臺小組合作，確保基礎結構可靠。
平臺小組
為每個區域部署集中式網路資源。 任務關鍵性設計方法需要區域隔離。
請與應用程式小組合作，找出隱藏的區域相依性，讓某個區域中的平臺資源降低不會影響另一個區域中的工作負載。
DNS 解析
連線ivity訂用帳戶提供私人 DNS 區域。 不過，集中式方法可能不會考慮可能專屬於使用案例的 DNS 需求。 布建您自己的 DNS 區域，並連結至區域戳記。 如果應用程式小組沒有 DNS，則私人連結的管理對於全域資源而言會變得具有挑戰性，例如 Azure Cosmos DB。
平臺小組
將 Azure 私用 DNS 區域委派給應用程式小組，以涵蓋其使用案例。
針對區域中樞網路，將 DNS 伺服器值設定為 [預設] （Azure 提供），以支援應用程式小組所管理的私人 DNS 區域。
環境設計考慮
一般做法是將工作負載放在生產、生產前和開發的不同環境中。 以下是一些重要考慮。
如何維護隔離？
生產環境 必須 與其他環境隔離。 較低的環境也應該維持隔離等級。 避免在環境之間共用應用程式擁有的資源。
應用程式小組所擁有的全域、區域和戳記資源需要一個生產環境。 需要生產前環境，例如預備環境與整合，以確保應用程式在模擬生產環境中盡可能進行測試。 開發環境應該是相應減少的生產版本。
預期的生命周期為何？
在驗證測試完成之後，生產前環境可以終結。 建議開發環境共用功能的存留期，並在開發完成時終結。 持續整合/持續部署 （CI/CD） 自動化所完成的動作。
權衡取捨是什麼？
請考慮隔離環境、管理複雜度與成本優化之間的取捨。
提示
所有環境都應該相依於外部資源的生產實例，包括平台資源。 例如，連線ivity訂用帳戶中的生產區域中樞。 您將能夠將生產前與生產環境之間的差異降到最低。
工作負載基礎結構的訂用帳戶拓撲
平臺小組會為您提供訂用帳戶。 視 環境數目而定，您只會針對一個工作負載要求數個訂用帳戶。 視 環境類型而定，某些環境可能需要專用訂用帳戶，而其他環境可能會合併成一個訂用帳戶。
無論如何，請與平臺小組合作，設計符合工作負載整體可靠性目標的拓撲。 在相同訂用帳戶中的環境之間共享平臺提供的資源有好處，因為它會反映生產環境。
注意
使用多個訂用帳戶來包含環境，即可達到所需的隔離等級。 登陸區域訂用帳戶繼承自相同的管理群組。 因此，確保與生產環境的一致性以進行測試和驗證。
生產訂用帳戶
針對您提供的訂用帳戶，可能會有資源限制。 如果您將所有這些資源共置在一個訂用帳戶中，您可能會達到這些限制。 根據您的縮放單位和預期的縮放比例，請考慮更分散式的模型。 例如，
一個訂用帳戶，其中包含 Azure DevOps 組建代理程式和全域資源。
每個區域的一個訂用帳戶。 其中包含區域資源、戳記資源和區域戳記的跳躍方塊。
以下是此架構中使用的範例訂用帳戶拓撲。
生產前訂用帳戶
至少需要一個訂用帳戶。 不過，您可以執行許多獨立環境，但建議在專用訂用帳戶中有多個環境。 此訂用帳戶也可能受限於資源限制，例如生產訂用帳戶，如上述。
開發訂用帳戶
至少需要一個訂用帳戶。 如果執行所有獨立環境，此訂用帳戶可能會受限於資源限制。 因此，您可以要求多個訂用帳戶。 建議在其專用訂用帳戶中擁有個別環境。
嘗試盡可能比對生產拓撲。
部署考量
失敗的部署或錯誤版本是應用程式中斷的常見原因。 在應用程式生命週期中徹底測試您的應用程式（和新功能）。 在登陸區域中部署工作負載時，您必須將設計與平臺提供的資源和治理整合。
請參閱： 架構完善的任務關鍵性工作負載：部署和測試。
部署基礎結構
部署基礎結構的可靠性，例如組建代理程式及其網路，通常與工作負載的運行時間資源一樣重要。
此架構會使用私人組建代理程式來防止未經授權的存取可能會影響應用程式的可用性。
強烈建議維護部署資源之間的隔離。 部署基礎結構應該系結至該環境的工作負載訂用帳戶。 如果您在生產前訂用帳戶中使用多個環境，請藉由限制只存取這些個別環境來建立進一步的分隔。 您可以考慮每個區域部署資源，讓部署基礎結構更可靠。
零停機部署
更新 至應用程式可能會導致中斷。 強制執行一致的部署將提升可靠性。 建議使用下列方法：
- 擁有完全自動化的部署管線。
- 在全新戳記上，在生產前環境中部署更新。
如需詳細資訊，請參閱 任務關鍵部署和測試指導方針。
在基準架構中，這些策略是透過取消布建來實作，然後使用每個更新卸除戳記。 在此設計中，無法完成取消布建，因為平臺小組擁有一些資源。 因此，部署模型已變更。
部署模型
基準 架構 會使用 Blue-Green 模型來部署應用程式更新。 具有變更的新戳記會與現有的戳記一起部署。 將流量移至新的戳記之後，就會終結現有的戳記。
在此情況下，指定的對等互連虛擬網路是非暫時的。 戳記不允許建立虛擬網路或對等互連至區域中樞。 您必須在每個部署中重複使用這些資源。
Canary 模型可以使用復原的選項來達成安全部署。 首先，會使用程式代碼變更來部署新的戳記。 部署管線會參考預先布建的虛擬網路，並配置子網、部署資源、新增私人端點。 然後，它會將此預先布建的虛擬網路中的流量轉移至這些子網。
不再需要現有的戳記時，管線會刪除所有戳記資源，但平臺擁有的資源除外。 系統會保留虛擬網路、診斷設定、對等互連、IP 位址空間、DNS 組態和角色型訪問控制 （RBAC）。 此時，戳記處於全新狀態，並準備好進行下一個新的部署。
DINE （deploy-if-not-exists） Azure 原則
Azure 應用程式登陸區域可能會有 DINE （deploy-if-not-exists） Azure 原則。 這些檢查可確保已部署的資源符合應用程式登陸區域中的公司標準，即使它們是由應用程式小組所擁有也一樣。 您的部署與最終資源組態之間可能會不符。
瞭解將套用至資源之所有 DINE 原則的影響。 如果資源組態有變更，請在工作負載開發週期早期將原則的意圖納入宣告式部署。 否則，可能會有漂移導致所需狀態與已部署狀態之間的差異。
部署訂用帳戶存取管理
將訂用帳戶界限視為您的安全性界限，以限制爆破半徑。 威脅可能會影響工作負載的可靠性。
平臺小組
- 為應用程式小組提供許可權範圍設定為應用程式登陸區域訂用帳戶的作業授權。
如果您在單一訂用帳戶內執行多個部署，缺口會影響這兩個部署。 建議在專用訂用帳戶中執行部署。 為每個環境建立服務主體，以維護邏輯區隔。
服務主體應該提供工作負載資源的自主權。 此外，它應該有限制，以防止過度操作訂用帳戶內的平台資源。
監視考慮
Azure 登陸區域平臺會在管理訂用帳戶中提供共用的可觀察性資源。 集中式作業小組鼓勵應用程式小組 使用同盟模型。 但是對於任務關鍵性工作負載，不建議使用單一集中式觀察性存放區，因為它可能是單一失敗點。 任務關鍵性工作負載也會產生可能不適用於或可採取動作的遙測，以供集中式作業小組使用。
因此，強烈建議使用自動方法來監視。 工作負載操作員最終負責監視，而且必須能夠存取代表整體健康情況的所有數據。
基準 架構 會遵循該方法，並繼續進行此參考架構。 Azure Log Analytics 和 Azure 應用程式 Insights 會以區域和全域方式部署，以監視這些範圍中的資源。 匯總記錄、建立儀錶板和警示是小組的範圍。 利用將計量和記錄傳送至各種接收的 Azure 診斷 功能，以支持記錄和計量收集的平臺需求。
健全狀況模型
任務關鍵性設計方法需要系統 健康情況模型。 當您定義整體健康情況分數時，請包含應用程式相依的範圍平臺登陸區域流程。 建置記錄、健康情況和警示查詢，以執行跨工作區監視。
平臺小組
為任務關鍵性應用程式關鍵路徑中使用的相關平台資源授與角色型訪問控制 （RBAC） 查詢和讀取記錄接收。
藉由提供應用程式小組足夠的許可權來執行其作業，來支援對任務關鍵性工作負載的可靠性組織目標。
在此架構中，健康情況模型包含 連線ivity訂用帳戶中所布建資源的記錄和計量。 如果您擴充此設計以連線到資料庫之類的內部部署資源，健康情況模型必須包含與該資源的網路連線能力，包括 Azure 和 內部部署中的網路虛擬設備等安全性界限。 此資訊對於快速判斷根本原因並補救可靠性影響非常重要。 例如，嘗試路由至資料庫時是否發生失敗，或資料庫發生問題？
請參閱： 架構完善的任務關鍵性工作負載：健康情況模型化。
與平臺提供的原則和規則整合
應用程式登陸區域訂用帳戶會從其管理群組繼承 Azure 原則、Azure 網路管理員規則和其他控制件。 平臺小組會提供這些護欄。
針對部署，請勿完全相依於平臺提供的原則，因為：
- 其並非設計來涵蓋個別工作負載的需求。
- 原則和規則可能會在小組外部更新或移除，因此可能會影響可靠性。
強烈建議您在部署內建立和指派 Azure 原則。 這項工作可能會導致一些重複，但考慮到系統可靠性的潛在影響，這是可以接受的。 如果平台原則中有變更，工作負載原則仍會在本機生效。
平臺小組
- 隨著原則的發展，讓應用程式小組參與原則的變更管理程式。
- 請注意應用程式小組所使用的原則。 評估是否應該新增至管理群組。
部署此架構
此架構的網路層面會在任務關鍵性 連線 實作中實作。
注意
連線 實作旨在說明依賴組織資源、與其他工作負載整合及使用共用服務的任務關鍵性工作負載。 實作假設 連線ivity訂閱已經存在。
下一步
檢閱 Azure 架構完善的架構中的網路和連線設計區域。
相關資源
除了 基準架構中使用的 Azure 服務之外，這些服務對於此架構很重要。