將多個獨立的應用程式元件副本（包括資料儲存庫）部署為單一資源群組。 每個副本稱為 印記，有時也稱為 服務單元、擴展單元或 單元。 在多租戶環境中，每個郵票服務於預先定義的租戶數量。 部署更多印章以幾乎線性擴展解決方案，服務越來越多的租戶，部署多個區域的實例，並分離客戶資料。
Note
如需詳細資訊，請參閱 在 Azure 上建構多租用戶解決方案。
內容和問題
當你在雲端架設應用程式時，請考慮應用程式的效能與可靠性。 如果你只架設單一實例，可能會有以下限制：
尺度限制： 你的應用程式單一實例可能會達到自然的擴展極限。 例如，您使用的服務可能會限制入站連線數量、主機名稱、傳輸控制協定（TCP）套接字或其他資源。
非線性縮放或成本： 你的解決方案中有些元件可能無法隨著請求數量或資料量的線性擴展。 相反地，當你達到某個門檻後，效能可能會下降或成本飆升。 例如，你可能會發現增加資料庫容量或擴大容量的成本會變得過於昂貴，而擴大規模化反而更具成本效益。
客戶分離： 你可能需要將一位客戶的資料與另一位客戶的資料隔離開來。 你也可能遇到客戶比其他客戶消耗更多系統資源。 你可以把它們分組於不同的基礎設施環境中。
單一租戶與多租戶實例： 有些大型客戶可能需要獨立的解決方案實例。 較小的客戶可以共享多租戶部署。
複雜的部署需求： 你可能需要以受控的方式部署更新，並在不同時間部署給不同客戶群。
更新頻率： 有些客戶能容忍頻繁更新，而風險規避型客戶則希望系統更新頻率不高。 你可以將這些客戶部署到隔離的環境中。
地理或地緣政治限制： 為了達成低延遲或符合資料主權要求，你可能會將部分客戶部署到特定區域。
這些限制通常適用於開發軟體即服務（SaaS）的軟體開發公司，他們通常以多租戶方式設計軟體。 同樣的限制也可能適用於其他情境。
解法
為避免這些問題，建議將資源分組成 比例單位 ，並準備多份印 章。 每個規模單位承載並服務你部分租戶。 印章彼此獨立運作，你可以獨立部署和更新它們。 單一地理區域可能包含一枚或多個郵票，這些郵票在該區域內水平擴展。 每張郵票服務於你的某些顧客。
圖示顯示五排堆疊。 每一行代表一個部署標記。 每列左上角都有標籤，標示印章及其 Azure 區域，右上角有標籤列出該印章所服務的租戶，標籤下方有兩個元件，左側是 Azure App 服務，右側是 SQL 資料庫。 從上到下，這些郵票分別是西美國2號公路的1號郵票，服務租戶A、B和C;西美國2號公路的郵票2號，服務租戶D;東美國的 Stamp 3，服務租戶 E、F 和 G;西歐的第4號郵票，服務租戶H、I和J;以及位於澳洲東部的 Stamp 5，服務租戶 K、L 和 M。這五枚郵票內部成分相同，但在區域及分配租戶組上有所不同，西美國2號區域包含兩枚獨立郵票，而其他區域各含一枚郵票。
部署印章可適用於您的解決方案中使用基礎設施即服務（IaaS）、平台即服務（PaaS）元件，或是兩者皆用。 IaaS 工作負載通常需要更多介入來擴展，因此這種模式能幫助 IaaS 重度工作負載擴展。
你可以用標籤來實作 部署環。 如果不同客戶需要不同頻率的服務更新，可以將它們分組到不同的印章上，並以不同的頻率部署更新給每個印章。
印章是獨立運作的，所以它們會隱含 地分片 你的資料。 單一郵票內部也可進一步分片以保持彈性。
部署相同元件的相同副本很複雜，因此良好的 DevOps 實務至關重要。 將你的基礎設施描述為程式碼，使每個印章的部署可預測且可重複。
部署標記與 晶洞相關但有所不同。 在部署印章架構中，系統的每個獨立實例服務於部分客戶與使用者。 在晶洞架構中，每個實例都能從任何使用者那裡提供請求，但這種方式通常設計和建構起來較為複雜。 你也可以將這兩種圖案合併在一個解決方案中。 本文後述的 流量路由方法 即為此類混合情境的範例。
問題和考慮
在決定如何實施此模式時，請考慮以下幾點：
部署流程： 當你部署多個印章時，請自動化並完整重複你的部署流程。 使用 Bicep 或 Terraform模組來宣告性地定義你的印章，並保持定義一致。
十字蓋章作業： 當你在多個郵票上獨立部署解決方案時，很難判斷你在所有郵票上有多少客戶。 你可能需要查詢每張郵票並彙整結果。 或者，你也可以讓所有印章都將資料發布到集中的資料倉儲，以便合併報告。
擴展政策： 集群有有限的容量，你可以使用代理度量來定義，例如可部署到集群中的租戶數量。 監控每個印章的可用與使用容量，並主動部署更多印章，引導新租戶使用。
最少部署單元數： 當你使用部署印章模式時，至少部署兩個單元來實現你的解決方案。 如果你只部署一個印章，很容易在程式碼或設定中硬編碼一些假設，這些假設在擴展時不會適用。
費用： 部署印章模式會部署多份基礎架構元件，這大幅增加了解決方案的運作成本。
郵票間切換： 每張郵票獨立運作，因此租戶在不同郵票間移動可能很困難。 您的應用程式需要自訂邏輯，將客戶資訊傳送到不同的印章，然後從原始印章中移除租戶的資訊。 這個過程可能需要一個背板來在郵票間通訊，這會進一步增加解決方案的複雜度。
交通規劃： 如本文先前所述，將流量導向特定請求的正確印章可能需要額外元件來解決租戶的印章。 這個元件可能也需要高可用性。
跨郵票的可觀察性： 隨著郵票數量增加，了解整體健康狀況和快速偵測事件變得越來越困難。 使用 Azure 監視器 收集並關聯所有郵票的指標、日誌、追蹤與警示。 利用這些數據辨識不健康的郵票並診斷問題。
區域故障影響： Stamp 獨立運行，但在不同地區間沒有內建的冗餘。 如果承載一個或多個印章的地區變得不可用，該地區的租戶將失去存取權，直到地區恢復或你將租戶遷移到其他地區的印章。 為此情境做準備，請記錄復原程序、設定租戶期望，並考慮關鍵租戶是否需要地理冗餘印章。
共用組件： 你可能有一些可以在郵票間共享的元件。 舉例來說，如果你有一個所有租戶共用的單頁應用程式，請部署到一個區域，並用 Azure Front Door 邊緣快取將其全球複製。
治理與配置漂移： 隨著印章數量增加，保持安全政策、基於角色的存取控制（RBAC）指派、網路控制、可觀察性設定及服務配置的一致性變得越來越困難。 使用 Azure 原則 將治理視為程式碼，並持續驗證每個印章是否有漂移，以防止行為不一致及合規缺口。
使用此模式的時機
當下列情況時，請使用此模式：
你的解決方案在擴展性上有自然的限制。 例如，如果某些元件無法或不應該擴展超過一定數量的客戶或請求，就用印章來擴展。
你需要將某些租戶與其他租戶區分開來。 如果安全考量無法將部分客戶部署到多租戶印章中，請將他們部署到獨立的印章上。
你需要同時在不同版本的解決方案中佈署多個租戶。
你要建置多區域應用程式，將每個租戶的資料和流量導向特定區域。
你要在停電時達到韌性。 郵票獨立運作，因此如果停電影響到單一郵票，其他郵票上的租戶則不受影響。 此隔離區包含事件或系統故障的 爆炸半徑。
在下列情況下，此模式可能不適用：
你的解決方案很簡單，不需要大幅擴展。
你可以在單一實例內擴展或擴充系統，例如擴大應用層規模，或增加資料庫與儲存層的預留容量。
你需要在所有已部署的實例中複製資料。 在此情境中，請考慮使用Geode 模式。
你只需要調整某些元件，而不需要調整其他的元件。 舉例來說，考慮是否可以透過 將資料儲存區分片 來擴展解決方案，而不是部署所有解決方案元件的新副本。
你的解決方案僅包含靜態內容，例如前端 JavaScript 應用程式。 透過 內容傳遞網路來傳遞這些內容。
工作負載設計
評估如何在工作負載設計中使用部署印章模式，以達成Azure Well-Architected框架支柱所涵蓋的目標與原則。 下表提供此模式如何支援每個要素目標的指引。
| 支柱 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性 設計決策有助於使工作負載具有韌性，並確保在故障發生後能復原到正常運作的狀態。 | 郵票是獨立運作的，因此單一郵票的故障是孤立的，不會影響其他郵票上的租戶。 跨區域部署多枚印章，也為冗餘與復原規劃奠定基礎，減少區域停電的爆炸半徑。 - RE：05 備援 - RE：07 自我保護 |
| 卓越營運有助於透過標準化流程和團隊凝聚力來提供工作負載品質。 | 此模式支援不可變的基礎結構目標、進階部署模型，並可協助安全部署做法。 - OE：05 基礎結構即程序代碼 - OE：11 安全部署做法 |
| 效能效率 可透過調整、數據和程式碼的優化， 有效率地協助您的工作負載符合需求 。 | 這種模式通常會與你工作量中定義的尺度單位相符。 當你需要超過單一規模單位的容量時，你會部署另一個印章來擴展規模。 - PE：05 縮放和分區 |
如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。
範例
以下範例架構使用 Azure Front Door、Azure API 管理 及 Azure Cosmos DB，將流量全球路由至一系列區域特定印章。
假設使用者住在紐約。 東美地區的 Stamp 3 則儲存他們的資料。
如果使用者前往加州並存取系統，系統會將連線路由至西美國2號區域，因為該區域在他們提出請求時距離最近。 然而，戳記3最終必須處理請求，因為它儲存了他們的資料。 流量路由系統會將請求導向正確的印章。
Deployment
用程式碼描述你的基礎設施，可以用 Bicep 或 Terraform。 此方法確保每枚郵票的部署可預測且可重複。 它也會降低人為錯誤的可能性，例如戳記之間的設定意外不符。
你可以同時自動部署更新到所有印章。 像 Bicep 這類技術可以協調基礎設施和應用程式的部署。 或者，你也可以先逐步更新某些郵票，再逐步擴展到其他郵票。 請考慮使用 Azure Pipelines 或 GitHub Actions 等發行管理工具，來協調每個戳記的部署。
請仔細考慮部署的 Azure 訂用帳戶和資源群組拓撲：
通常，訂閱包含單一解決方案的所有資源，因此建議考慮使用單一訂閱來處理所有郵票。 然而，部分Azure服務對訂閱者實施配額。 如果你用這種模式來實現高度擴展，可能需要在不同訂閱中部署印章。
資源群組通常包含具有相同生命週期的元件。 如果你打算同時部署所有印章的更新，可以使用一個包含所有印章所有元件的資源群組。 使用資源命名規則和標籤來識別屬於每個郵票的組成部分。 或者，如果你打算獨立部署每個印章的更新，也可以將每個印章部署到獨立的資源群組。
產能規劃
使用負載和效能測試來判斷指定戳記可以容納的近似負載。 負載指標可能基於單一郵票可容納的客戶或租戶數量，或是郵票中服務所發出的指標。 對每張郵票進行儀器檢查，以便測量其接近產能時的狀況，並確保能迅速部署新郵票以回應需求。
交通路由
部署標記模式在獨立處理每個標記時效果良好。 例如，如果 Contoso 在多個印章上部署相同的 API 應用程式，Contoso 可能會使用網域名稱系統（DNS）將流量導向相關印章：
-
unit1.aus.myapi.contoso.com將流量路由至澳大利亞區域內的unit1。 -
unit2.aus.myapi.contoso.com將流量路由至澳大利亞區域內的unit2。 -
unit1.eu.myapi.contoso.com將流量路由至歐洲區域內的節點unit1。
在Azure中，你可以將這些紀錄放在Azure DNS，並為每個區域和印章使用一致的子網域慣例。 此方法維持可預測的路由與操作。
客戶有責任連接正確的印章。
如果您的解決方案需要所有流量的單一入口點，您可以使用流量路由服務來解析特定請求、客戶或租戶的印章。 流量路由服務會引導用戶端至該印章相關的 URL（例如回傳 HTTP 302 回應狀態碼），或作為反向代理，將流量轉發至相關印章，而用戶端不知情。
集中式流量路由服務可以是一個複雜的元件來設計，尤其是在解決方案跨多個區域執行時。 考慮將流量路由服務部署到多個區域，可能涵蓋所有承載印章的區域，並同步將租戶映射到印章的資料庫。 流量路由元件本身可能就是 晶狀體圖案的實例。
例如，你可以部署 API 管理 作為流量路由服務。 API 管理透過查詢儲存租戶與印章間映射的 Azure Cosmos DB 集合資料，來判斷請求所需的適當印章。 API 管理接著 動態地將後端 URL 設定 為相關郵票的 API 服務。
為了地理分布請求並為流量路由服務提供地理冗餘， 在多個區域部署 API 管理，並使用 Azure Front Door 將流量導向最近的 API 管理閘道。 在此拓撲中，Azure Front Door 使用 origin groups、health probes，以及適當的 routing 方法 來將請求路由遠離不健康的 API 管理區域閘道。 API 管理然後使用租戶到印章的映射及其後端配置（或後端池）將流量導向至適當的印章，包括需要時在印章端點間設置失敗切換規則。 如果你的應用程式沒有透過 HTTP 或 HTTPS 暴露，你可以使用 跨區域Azure負載平衡器來將來電分配給區域Azure負載平衡器。 請使用 Azure Cosmos DB 的
如果你的解決方案包含流量路由服務，請考慮它是否作為 閘道 ，並能為其他服務（如令牌驗證、限速和授權）執行 閘道卸載 。
下一步
投稿人
本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。
主要作者：
- 約翰·唐斯 | 首席軟體工程師, Azure 模式與實踐
其他投稿人：
- 費德里科·阿蘭巴里 |Clarius Consulting 資深軟體開發
- Daniel Larsen | FastTrack for Azure 主要客戶工程師
- 安吉爾·洛佩茲 |Azure 模式和做法資深軟體工程師
- Paolo Salvatori | FastTrack for Azure 首席客戶工程師
- 阿森·弗拉基米爾斯基 | Azure FastTrack 的首席客戶工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。