部署戳記模式牽涉到布建、管理及監視異質資源群組，以裝載及操作多個工作負載或租使用者。 每個個別復本稱為戳記，有時稱為服務單位、縮放單位或單元格。 在多租用戶環境中，每個戳記或縮放單位都可以為預先定義的租用戶數目提供服務。 您可以部署多個戳記，以幾乎線性方式調整解決方案，並提供越來越多的租使用者。 這種方法可以改善解決方案的延展性、讓您跨多個區域部署實例，以及分隔客戶數據。
注意
如需為 Azure 設計多租使用者解決方案的詳細資訊，請參閱 在 Azure 上建構多租用戶解決方案。
內容和問題
在雲端中裝載應用程式時，請務必考慮應用程式的效能和可靠性。 如果您裝載解決方案的單一實例，可能會受限於下列限制：
- 調整限制。 部署應用程式的單一實例可能會導致自然調整限制。 例如，您可以使用限制輸入連線、主機名、TCP 套接字或其他資源的服務。
- 非線性縮放或成本。 某些解決方案的元件可能無法以線性方式調整要求數目或數據量。 相反地，一旦達到閾值，效能可能會突然降低或成本增加。 例如，您可以使用資料庫並發現增加更多容量（相應增加）的臨界成本變得令人禁止，而相應放大是更具成本效益的策略。
- 區分客戶。 您可能需要將特定客戶的數據與其他客戶的數據隔離。 同樣地，您可能有一些客戶需要比其他人服務更多的系統資源，並考慮將它們分組在不同的基礎結構集合上。
- 處理單一和多租用戶實例。 您可能有一些大型客戶需要自己的解決方案獨立實例。 您可能也有可共用多租使用者部署的較小客戶集區。
- 複雜的部署需求。 您可能需要以受控制的方式將更新部署到您的服務，以及在不同的時間部署到不同客戶群的不同子集。
- 更新頻率。 您可能有一些客戶能夠容忍經常更新您的系統，而其他客戶可能是風險厭惡，而且想要不常更新服務其要求的系統。 讓這些客戶部署到隔離的環境可能很合理。
- 地理或地緣政治限制。 若要建構低延遲或符合數據主權需求，您可以將部分客戶部署到特定區域。
這些限制通常適用於建置軟體即服務（SaaS）的獨立軟體供應商（ISV），後者通常設計為多租使用者。 不過，相同的限制也適用於其他案例。
解決方案
若要避免這些問題，請考慮將資源分組為縮放單位，並布建戳記的多個復本。 每個 縮放單位 都會裝載並提供租使用者的子集。 戳記彼此獨立運作，可以獨立部署和更新。 單一地理區域可能包含單一戳記，或可能包含多個戳記，以允許區域內水準向外延展。 戳記包含客戶的子集。
無論您的解決方案使用基礎結構即服務 （IaaS） 或平臺即服務 （PaaS） 元件，或兩者的混合，都可以套用部署戳記。 一般而言，IaaS 工作負載需要更多介入才能調整，因此模式對於IaaS 繁重的工作負載可能很有用，以允許相應放大。
戳記可用來實 作部署通道。 如果不同的客戶想要以不同的頻率接收服務更新，他們可以分組到不同的戳記，而且每個戳記都可以以不同的步調部署更新。
因為戳記彼此獨立執行，因此數據會 隱含分區化。 此外，單一戳記可以利用進一步分區化，在內部允許戳記內的延展性和彈性。
許多 Azure 服務會在內部使用部署戳記模式，包括 App Service、Azure Stack 和 Azure 儲存體。
部署戳記與地理位置相關，但與 異地不同。 在部署戳記架構中，系統會部署多個獨立的系統實例，並包含客戶和使用者的子集。 在異地設定中，所有實例都可以提供來自任何使用者的要求，但此架構通常對設計和建置更為複雜。 您也可以考慮在一個解決方案中混合這兩種模式; 本文稍後所述的流量路由方法是 這類混合式案例的範例。
部署
由於部署相同元件之相同復本的複雜性，良好的 DevOps 做法對於實作此模式時確保成功至關重要。 請考慮將基礎結構描述為程序代碼，例如使用 Bicep、 JSON Azure Resource Manager 範本 （ARM 範本）、 Terraform 和腳本。 使用此方法，您可以確保每個戳記的部署都是可預測且可重複的。 它也會降低人為錯誤的可能性，例如戳記之間的設定意外不符。
您可以平行部署更新至所有戳記，在此情況下，您可能會考慮 Bicep 或 Resource Manager 範本等技術來協調基礎結構和應用程式的部署。 或者，您可能決定先逐步推出某些戳記的更新，然後再逐漸向其他人推出更新。 請考慮使用 Azure Pipelines 或 GitHub Actions 之類的發行管理工具來協調每個戳記的部署。 如需詳細資訊，請參閱
請仔細考慮部署的 Azure 訂用帳戶和資源群組拓撲：
- 一般而言，訂用帳戶包含單一解決方案的所有資源，因此一般而言，請考慮針對所有戳記使用單一訂用帳戶。 不過， 某些 Azure 服務會強制使用整個訂用帳戶的配額，因此如果您使用此模式來允許高度向外延展，您可能需要考慮跨不同訂用帳戶部署戳記。
- 資源群組通常用來部署具有相同生命週期的元件。 如果您打算一次部署所有戳記的更新，請考慮使用單一資源群組來包含所有戳記的所有元件，並使用資源命名慣例和標籤識別屬於每個戳記的元件。 或者，如果您打算獨立部署每個戳記的更新，請考慮將每個戳記部署到自己的資源群組。
產能規劃
使用負載和效能測試來判斷指定戳記可以容納的近似負載。 負載計量可能以單一戳記可以容納的客戶/租用戶數目為基礎，或來自戳記內元件發出之服務的計量。 請確定您有足夠的檢測來測量指定戳記何時接近其容量，以及快速部署新戳記以回應需求的能力。
流量路由
如果每個戳記都是獨立尋址，則部署戳記模式可正常運作。 例如，如果 Contoso 跨多個戳記部署相同的 API 應用程式，他們可能會考慮使用 DNS 將流量路由傳送至相關戳記：
unit1.aus.myapi.contoso.com將流量路由傳送至澳大利亞區域內的戳記unit1。unit2.aus.myapi.contoso.com將流量路由傳送至澳大利亞區域內的戳記unit2。unit1.eu.myapi.contoso.com將流量路由傳送到歐洲區域內的戳記unit1。
用戶端接著會負責連線到正確的戳記。
如果需要所有流量的單一輸入點，流量路由服務可用來解析指定要求、客戶或租使用者的戳記。 流量路由服務會將客戶端導向至戳記的相關 URL（例如，使用 HTTP 302 回應狀態代碼），或者它可能會作為反向 Proxy，並將流量轉送至相關的戳記，而不需要知道用戶端。
集中式流量路由服務可以是一個複雜的元件來設計，尤其是在解決方案跨多個區域執行時。 請考慮將流量路由服務部署到多個區域（可能包括已部署戳記的每個區域），然後確保數據存放區 （將租用戶對應至戳記） 已同步處理。 流量路由元件本身可能是地理柵欄模式的實例。
例如，Azure API 管理 可以部署為在流量路由服務角色中採取行動。 其可藉由查閱儲存租使用者與戳記之間對應之 Azure Cosmos DB 集合中的數據，來判斷要求的適當戳記。 然後，API 管理 可以將後端URL動態設定為相關戳記的API服務。
若要啟用流量路由服務的異地散發要求和異地備援，API 管理 可以部署到多個區域，或者 Azure Front Door 可用來將流量導向最接近的實例。 Front Door 可以設定後端集區，讓要求導向至最接近的可用 API 管理 實例。 如果您的應用程式未透過 HTTP/S 公開，您可以使用 跨區域 Azure Load Balancer 將連入呼叫散發至區域 Azure Load Balancer 。 Azure Cosmos DB 的全域散發功能可用來讓對應資訊在每個區域中保持更新。
如果您的解決方案中包含流量路由服務，請考慮它是否作為 閘道 ，因此可能會針對其他服務執行 閘道卸除 ，例如令牌驗證、節流和授權。
流量路由架構範例
請考慮下列範例流量路由架構，其使用 Azure Front Door、Azure API 管理 和 Azure Cosmos DB 進行全域流量路由，然後是一系列區域特定的戳記：
假設使用者通常位於紐約。 其數據會儲存在美國東部區域戳記 3 中。
如果使用者前往加州，然後存取系統，則其連線可能會透過美國西部 2 區域路由傳送，因為這是最接近他們提出要求時的地理位置。 不過，要求最終必須由戳記 3 提供服務，因為這是其數據儲存的位置。 流量路由系統可確保要求已路由傳送至正確的戳記。
問題和考慮
決定如何實作此模式時，您應該考慮下列幾點：
- 部署程式。 部署多個戳記時，強烈建議您擁有自動化且完全可重複的部署程式。 請考慮使用 Bicep、 JSON ARM 範本或 Terraform 模組，以宣告方式定義戳記，並讓定義保持一致。
- 跨戳記作業。 當您的解決方案在多個戳記之間獨立部署時，「我們在所有戳記中有多少客戶？」等問題可能會變得更加複雜。 查詢可能需要針對每個戳記和匯總的結果執行。 或者，請考慮將所有戳記發佈數據到集中式數據倉儲以進行合併報告。
- 判斷向外延展原則。 戳記具有有限的容量，可使用 Proxy 計量來定義，例如可以部署至戳記的租用戶數目。 請務必監視每個戳記的可用容量和使用容量，並主動部署額外的戳記，以允許新的租用戶導向它們。
- 戳記數目下限。 當您使用部署戳記模式時，建議至少部署解決方案的兩個戳記。 如果您只部署單一戳記，很容易將硬式程式代碼假設不小心套用到您的程式代碼或設定中，而當您相應放大時不會套用。
- 成本。 部署戳記模式牽涉到部署基礎結構元件的多個複本，這可能需要大幅增加您解決方案的成本。
- 在戳記之間移動。 每個戳記都會獨立部署及運作，因此在戳記之間移動租使用者可能會很困難。 您的應用程式需要自定義邏輯，才能將指定客戶的相關信息傳輸到不同的戳記，然後從原始戳記中移除租用戶的資訊。 此程式可能需要備份程式，以在戳記之間進行通訊，進一步提高整體解決方案的複雜性。
- 流量路由。 如本文稍早所述，將流量路由傳送至指定要求的正確戳記可能需要額外的元件，才能將租使用者解析為戳記。 接著，此元件可能需要提供高可用性。
- 共用元件。 您可能有一些可跨戳記共用的元件。 例如，如果您有所有租用戶的共用單頁應用程式，請考慮將它部署到一個區域，並使用 Azure CDN 全域複寫。
使用此模式的時機
當您有下列情況時，此模式很有用：
- 延展性的自然限制。 例如，如果某些元件無法或不應該調整超過特定數目的客戶或要求，請考慮使用戳記相應放大。
- 將特定租使用者與其他租用戶分開的需求。 如果您有客戶因為安全性考慮而無法與其他客戶部署到多租使用者戳記，則可以部署到自己的隔離戳記上。
- 需要同時在不同版本的解決方案上擁有一些租使用者。
- 多區域應用程式，其中每個租用戶的數據和流量都應該導向至特定區域。
- 想要在中斷期間達到復原能力。 由於戳記彼此無關，如果中斷影響單一戳記，則部署至其他戳記的租使用者不應受到影響。 此隔離有助於包含事件或中斷的「爆炸半徑」。
此模式不適用於：
- 不需要調整為高度的簡單解決方案。
- 可在單一實例內輕鬆相應放大或相應增加的系統，例如增加應用層的大小，或增加資料庫和儲存層的保留容量。
- 應跨所有已部署實例複寫數據的解決方案。 請考慮此案例的 地理柵欄模式 。
- 只有某些元件需要調整，但不需要調整其他元件的解決方案。 例如，請考慮是否可藉由 將資料存放區 分區化來調整您的解決方案，而不是部署所有解決方案元件的新複本。
- 只包含靜態內容的解決方案，例如前端 JavaScript 應用程式。 請考慮將這類內容儲存在 記憶體帳戶 中，並使用 Azure CDN。
工作負載設計
架構設計人員應該評估部署戳記模式如何用於其工作負載的設計，以解決 Azure 架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 此模式支援不可變的基礎結構目標、進階部署模型，並可協助安全部署做法。 - OE：05 基礎結構即程序代碼 - OE：11 保管庫 部署做法 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 此模式通常符合您工作負載中定義的縮放單位：因為除了單一縮放單位所提供的容量之外，還需要額外的容量，因此會部署額外的部署戳記來相應放大。 - PE：05 調整和分割 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
支持技術
- 基礎結構即程式碼 (機器翻譯)。 例如，Bicep、Resource Manager 範本、Azure CLI、Terraform、PowerShell、Bash。
- Azure Front Door，可將流量路由傳送至特定戳記或流量路由服務。
範例
下列範例會部署簡單 PaaS 解決方案的多個戳記，其中包含每個戳記中的應用程式服務和 SQL 資料庫。 雖然戳記可以在支援範本中部署服務的任何區域中設定，但為了圖例目的，此範本會在美國西部 2 區域內部署兩個戳記，並在西歐區域中部署進一步戳記。 在戳記內，App Service 會接收自己的公用 DNS 主機名，而且可以獨立接收所有其他戳記的連線。
警告
下列範例使用 SQL Server 系統管理員帳戶。 從您的應用程式使用系統管理帳戶通常不是很好的做法。 針對實際的應用程式，請考慮 使用受控識別從您的應用程式連線到 SQL 資料庫，或使用最低許可權帳戶。
按兩下下方的連結以部署解決方案。
流量路由方法範例
下列範例會部署流量路由解決方案的實作，該解決方案可與假設 API 應用程式的一組部署戳記搭配使用。 為了允許傳入要求的地理分佈，Front Door 會與取用層上多個 API 管理 實例一起部署。 每個 API 管理 實例都會從要求 URL 讀取租使用者標識碼，然後從異地分散式 Azure Cosmos DB 數據存放區查閱要求的相關戳記。 然後，要求會轉送至相關的後端戳記。
按兩下下方的連結以部署解決方案。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- John Downs |主體計劃管理員
其他投稿人：
- Daniel Larsen |適用於 Azure 的主要客戶工程師 FastTrack
- 天使洛佩茲 |資深軟體工程師、Azure 模式和實務
- Paolo Salvatori |適用於 Azure 的主要客戶工程師 FastTrack
- 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
若要查看非公用LinkedIn配置檔，請登入LinkedIn。