有許多方式可以考慮如何在解決方案中使用租使用者。 您選擇的方法主要取決於租使用者之間是否共用資源及方式。 直覺上，您可能會想要避免共用 任何 資源，但這種方法會隨著您的企業規模而快速變得昂貴，而您將更多租使用者上線。
當您考慮多租使用者的各種模型時，先考慮您為組織定義租使用者的方式、商務驅動程式是什麼，以及您計畫調整解決方案的方式會很有説明。 本文提供指引，以協助技術決策者評估租用模型及其取捨。
定義租使用者
首先，您必須為組織定義 租 使用者。 請考慮您的客戶是誰。 換句話說，您提供服務的物件是誰？ 有兩種常見的模型：
- 企業對企業 (B2B) 。 如果您的客戶是其他組織，您可能會將租使用者對應至這些客戶。 不過，請考慮您的客戶是否有部門 (小組或部門) ，以及他們是否在多個國家/地區中存在。 如果這些子群組有不同的需求，您可能需要將單一客戶對應至多個租使用者。 同樣地，客戶可能想要維護兩個服務實例，讓其開發和生產環境彼此分開。 一般而言，單一租使用者有多個使用者。 例如，客戶的所有員工都會是單一租使用者內的使用者。
- 企業對取用者 (B2C) 。 若客戶是取用者，建立客戶、租用戶和使用者間的關聯通常會比較複雜。 在某些情況下，每個取用者可能是個別的租使用者。 不過，請考慮您的解決方案是否可由家庭、朋友群組、俱樂部、關聯或其他可能需要一起存取和管理其資料的群組使用。 例如，音樂串流服務可能同時支援個別使用者和家族，而且當這些帳戶類型分隔為租使用者時，可能會以不同的方式處理這些帳戶類型。
您的 租 使用者定義會影響建構解決方案時需要考慮或強調的一些事項。 例如，請考慮下列類型的租使用者：
- 如果您的租使用者是個別人員或家族，您可能需要特別擔心如何處理個人資料，以及您服務之每個管轄區內有關資料主權法律的資訊。
- 如果您的租使用者是企業，您可能需要留意客戶的法規合規性需求、其資料的隔離，並確保您符合指定的服務等級目標， (SLO) ，例如執行時間或服務可用性。
如何決定要使用哪一個模型？
選取租用模型不只是技術決策。 這也是商業決策。 您需要考慮如下的問題：
- 您的商務目標為何？
- 您的客戶是否接受所有形式的多租使用者？ 每個多租使用者模型如何影響您的合規性需求，或客戶的合規性需求？
- 單一租使用者解決方案是否會調整為未來的成長目標？
- 您的營運小組有多大，以及您可以自動化多少基礎結構管理？
- 您的客戶預期您符合服務等級協定 (SLA) ，或您有目標 SLO 嗎？
如果您預期企業可擴充至大量客戶，請務必部署共用基礎結構。 否則，您必須維護大量且不斷成長的實例。 除非您為每個租使用者布建並使用專用訂用帳戶，否則為每個客戶部署個別的 Azure 資源可能會很輕鬆。 當您在多個租使用者之間共用相同的 Azure 訂用帳戶時， Azure 資源配額和限制 可能會開始套用，以及部署和重新設定這些資源的營運成本會隨著每個新客戶而增加。
相反地，如果您預期企業只有少數客戶，您可能想要考慮使用每個客戶專用的單一租使用者資源。 此外，如果您的客戶的隔離需求很高，則單一租使用者基礎結構可能適用。
租使用者和部署
接下來，您必須判斷特定解決方案的 租 使用者意義，以及是否應該區分邏輯租使用者和部署。
例如，請考慮音樂串流服務。 一開始，您可以建置一個解決方案，輕鬆處理數千個 (或甚至數千個) 使用者。 不過，當您繼續成長時，您可能會發現您需要複製解決方案或其部分元件，以調整為新的客戶需求。 這表示您必須決定如何將特定客戶指派給解決方案的特定實例。 您可以隨機或異地指派客戶，或填滿單一實例，然後啟動另一個實例。 不過，您可能需要維護客戶的記錄，以及其資料和應用程式的可用基礎結構，以便您將流量路由傳送至正確的基礎結構。 在此範例中，您可以將每個客戶表示為個別租使用者，然後將使用者對應至包含其資料的部署。 租使用者與部署之間有一對多的對應，您可以自行決定在部署之間移動租使用者。
相反地，請考慮為法律公司建立雲端軟體的公司。 您的客戶可能會想要擁有自己的專用基礎結構來維護其合規性標準。 因此，您必須準備好從頭開始部署和管理解決方案的許多不同實例。 在此範例中，部署一律包含單一租使用者，而租使用者會對應至自己的專用部署。
租使用者與部署之間的主要差異在於如何強制執行隔離。 當多個租使用者共用單一部署 (一組基礎結構) 時，您通常會依賴應用程式程式碼和資料庫中的租使用者識別碼，讓每個租使用者的資料保持分開。 當您有租使用者有自己的專用部署時，他們有自己的基礎結構，因此您的程式碼可能會比較不重要，因為它在多租使用者環境中運作。
部署有時稱為 超租使用者 或 戳記。
當您收到特定租使用者的要求時，您必須將其對應至保留該租使用者資料的部署，如下所示：
租用戶隔離
多租使用者架構設計中最大的考慮之一是每個租使用者所需的隔離等級。 隔離可能表示不同的事項：
- 擁有單一共用基礎結構，每個租使用者都有個別的應用程式實例和個別的資料庫。
- 共用一些常見的資源，但為每個租使用者保留其他資源。
- 在個別實體基礎結構上保留資料。 在雲端中，此設定可能需要每個租使用者的個別 Azure 資源。 甚至可能表示使用 專用主機部署個別的實體基礎結構。
您應該將其視為連續屬性，而不是將隔離視為離散屬性。 您可以根據需求，比相同結構中的其他元件，以更隔離或更不隔離的方式部署結構元件。 下列圖表示範了隔離的連續性：
隔離等級會影響架構的許多層面，包括下列各項：
- 安全性。 如果您在多個租使用者之間共用基礎結構，當您將回應傳回給另一個租使用者時，必須特別小心不要從某個租使用者存取資料。 您需要身分識別策略的強式基礎，而且您必須在授權程式中考慮租使用者和使用者身分識別。
- 成本。 多個租使用者可以使用共用基礎結構，因此成本較低。
- 效能。 如果您共用基礎結構，系統效能可能會因為更多客戶使用它而受到影響，因為資源可能會更快取用。
- 可靠性。 如果您使用一組共用基礎結構，一個租使用者的元件發生問題可能會導致每個人中斷。
- 回應個別租使用者需求。 當您部署專用於一個租使用者的基礎結構時，您可以調整資源設定以符合該特定租使用者的需求。 您甚至可以在定價模型中考慮這項功能，讓客戶對隔離部署支付更多費用。
您的解決方案架構可能會影響隔離的可用選項。 例如，請考慮三層式解決方案架構：
- 您的使用者介面層可能是共用的多租使用者 Web 應用程式，而您的所有租使用者都會存取單一主機名稱。
- 您的仲介層可以是共用應用層，其中包含共用訊息佇列。
- 您的資料層可以是隔離的資料庫、資料表或 Blob 容器。
您可以考慮在每個層級上使用不同等級的隔離。 您應該根據許多考慮來決定共用的專案和隔離專案，包括成本、複雜度、客戶的需求，以及您可以在達到 Azure 配額和限制之前部署的資源數目。
常見的租用模型
建立需求之後，請根據一些常見的租用模型和對應的部署模式來評估這些需求。
自動化單一租使用者部署
在自動化的單一租使用者部署模型中，您會為每個租使用者部署一組專用的基礎結構，如下列範例所示：
您的應用程式負責起始及協調每個租使用者資源的部署。 一般而言，使用此模型的解決方案會使用基礎結構即程式碼 (IaC) 或 Azure Resource Manager API。 當您需要為每個客戶布建完全個別的基礎結構時，您可以使用此方法。 規劃 部署時，請考慮部署戳記模式 。
好處： 這種方法的主要優點是，每個租使用者的資料都會隔離，進而降低意外外泄的風險。 對於某些具有高法規合規性額外負荷的客戶而言，這項保護可能很重要。 此外，租使用者不太可能影響彼此的系統效能，有時稱為 雜訊鄰近 問題的問題。 更新和變更可以逐漸跨租使用者推出，以減少全系統中斷的可能性。
風險： 如果您使用此方法，則成本效率很低，因為您不會在租使用者之間共用基礎結構。 如果單一租使用者需要特定基礎結構成本，100 個租使用者可能需要 100 倍的成本。 此外，套用新設定或) 軟體更新等持續維護 (可能相當耗時。 請考慮將作業程式自動化，並考慮透過您的環境逐漸套用變更。 您也應該考慮其他跨部署作業，例如整個資產的報告和分析。 同樣地，請務必規劃如何查詢及操作多個部署的資料。
完全多租使用者部署
相反地，您可以考慮共用所有元件的完整多租使用者部署。 您只有一組基礎結構可部署和維護，且所有租使用者都會使用它，如下圖所示：
好處： 此模型很吸引人，因為操作具有共用元件的解決方案成本較低。 即使您需要部署較高層級或資源的 SKU，整體部署成本通常仍低於一組單一租使用者資源的成本。 此外，如果使用者或租使用者需要將其資料移至另一個租使用者，您或許可以更新租使用者識別碼和金鑰，而且您可能不需要在兩個不同的部署之間移轉資料。
風險：
請務必為每個租使用者分隔資料，而且不會在租使用者之間洩漏資料。 您可能需要管理分區化資料。 此外，您可能需要擔心個別租使用者在整體系統上可能擁有的效果。 例如，如果大型租使用者嘗試執行大量查詢或作業，可能會影響其他租使用者。
如果這麼做對您而言很重要，請決定如何 追蹤 Azure 成本並將其與租使用者產生關聯。
單一部署的維護可能比較簡單，因為您只需要更新一組資源。 不過，它通常也會有風險，因為變更可能會影響整個客戶群。
您可能也需要考慮調整規模。 當您有一組共用的基礎結構時，更可能達到 Azure 資源規模限制 。 例如，如果您使用儲存體帳戶作為解決方案的一部分，隨著規模增加，該儲存體帳戶的要求數目可能會達到儲存體帳戶可處理的限制。 若要避免達到資源配額限制，您可以考慮部署資源的多個實例，例如多個 AKS 叢集或儲存體帳戶) (。 您甚至可以考慮將租使用者分散到部署至多個 Azure 訂用帳戶的資源。
您可能會限制您可以調整單一部署的程度，而這樣做的成本可能會以非線性方式增加。 例如，如果您有單一共用資料庫，當您以非常高的規模執行時，可能會耗盡其輸送量，而且需要支付更多費用，以增加輸送量以跟上您的需求。
垂直分割的部署
您不需要選擇這些縮放比例的其中一個極端值。 相反地，您可以採用這種方法來考慮垂直分割租使用者：
- 使用單一租使用者和多租使用者部署的組合。 例如，您可能會在多租使用者基礎結構上擁有大部分客戶的資料和應用層，但針對需要較高效能或資料隔離的客戶部署單一租使用者基礎結構。
- 在地理位置部署解決方案的多個實例，並將每個租使用者對應至特定部署。 當您擁有不同地理位置的租使用者時，此方法特別有效。
以下範例說明某些租使用者的共用部署，以及另一個租使用者的單一租使用者部署：
好處： 因為您仍在共用基礎結構，所以您可以使用共用多租使用者部署來獲得一些成本優勢。 您可以為特定客戶部署較便宜的共用資源，例如使用試用版評估服務的客戶。 您甚至可以向客戶收取較高的費率，以使用單一租使用者部署，進而重新計算一些成本。
風險： 您的程式碼基底可能需要設計來支援多租使用者和單一租使用者部署。 如果您打算允許在基礎結構之間移轉，則必須考慮如何將客戶從多租使用者部署移轉至自己的單一租使用者部署。 您也需要知道每個部署中有哪些租使用者，以便傳達系統問題或升級的相關資訊給相關客戶。
水準分割的部署
您也可以考慮水準分割部署。 在水準部署中，您有一些共用元件，但使用單一租使用者部署維護其他元件。 例如，您可以建置單一應用層，然後為每個租使用者部署個別資料庫，如下圖所示：
好處： 水準分割的部署可協助您減輕雜訊鄰近問題，如果您發現系統上大部分的負載是由您可以針對每個租使用者個別部署的特定元件所造成。 例如，您的資料庫可能會吸收大部分系統負載，因為查詢負載很高。 如果單一租使用者將大量要求傳送至您的解決方案，資料庫效能可能會受到負面影響，但其他租使用者的資料庫 (和共用元件，例如應用層) 不會受到影響。
風險： 使用水準分割的部署，您仍然需要考慮元件的自動化部署和管理，特別是單一租使用者所使用的元件。
測試隔離模型
無論您選擇哪一個隔離模型，請務必測試您的解決方案，以確認某個租使用者的資料不會意外洩漏到另一個租使用者的資料，而且可接受任何 雜訊的鄰近 效果。 請考慮使用 Azure Chaos Studio 來刻意導入錯誤，以模擬真實世界中斷，並確認解決方案的復原能力，即使元件故障也一般。
參與者
本文由 Microsoft 維護。 最初是由下列參與者所撰寫。
主體作者：
- John Downs |適用于 Azure 的 FastTrack 首席客戶工程師
其他參與者：
- 卡達達| 主要軟體工程師
- Paolo Salvatori |適用于 Azure 的 FastTrack 首席客戶工程師
- Arsen | 適用于 Azure 的 FastTrack 首席客戶工程師
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
考慮 租使用者的生命週期