租使用者整合和數據存取的架構方法
系統通常會整合在一起，甚至跨越組織界限。 當您建置多租用戶解決方案時，可能需要將數據傳回租用戶的系統，或從這些系統接收數據。 在本文中，我們將概述建構及開發多租用戶解決方案整合的重要考慮和方法。
注意
如果您提供多個整合點，最好獨立考慮每個整合點。 通常，不同的整合點有不同的需求，而且設計方式不同，即使它們以多種不同方式將相同的系統連接在一起也一樣。
重要考慮和需求
數據流的方向
請務必了解數據流的方向。 數據流方向會影響架構的數個層面，例如您管理身分識別和解決方案的網路拓撲。 有兩個常見的數據流：
- 匯出，這表示數據會從多租用戶系統流向個別租用戶的系統。
- 匯入，這表示數據來自租用戶的系統到您的多租用戶系統。
也請務必考慮網路數據流方向，這不一定對應到邏輯數據流方向。 例如，您可以起始與租用戶的輸出連線，以便從租用戶的系統匯入數據。
完整或使用者委派的存取權
在許多系統中，特定數據的存取僅限於特定使用者。 一位使用者可以存取的數據可能與另一位使用者可以存取的數據不同。 請務必考慮您是否預期使用完整的數據集，或您匯入或匯出的數據集是否以特定用戶有權存取的許可權為基礎。
例如，請考慮Microsoft Power BI，這是一項多租用戶服務，可在客戶擁有的數據存放區上提供報告和商業智慧。 當您設定 Power BI 時，您會將資料源設定為從資料庫、API 和其他資料存放區提取數據。 您可以透過不同的方式設定資料存放區：
- 從基礎數據存放區匯入所有數據。 此方法會要求Power BI隨附可存取完整資料存放區之身分識別的認證。 然後，Power BI 系統管理員可以在匯入 Power BI 之後，個別設定匯入數據的許可權。 Power BI 會強制執行許可權。
- 根據使用者的許可權，從基礎數據存放區匯入數據子集。 當使用者建立數據源時，他們會使用其認證和相關聯的許可權。 Power BI 匯入的確切數據子集取決於建立數據源的使用者存取層級。
這兩種方法都有有效的使用案例，因此請務必清楚瞭解租使用者的需求。
如果您使用完整的數據集，來源系統會有效地將目的地系統 視為受信任的子系統。 針對這種類型的整合，您也應該考慮使用 工作負載身 分識別，而不是使用者身分識別。 工作負載身分識別是未對應至單一用戶的系統身分識別。 工作負載身分識別會獲得來源系統中數據的高階許可權。
或者，如果您使用使用者範圍的數據，您可能需要使用委派之類的方法，從數據集存取正確的數據子集。 然後，目的地系統實際上會取得與特定使用者相同的許可權。 如需使用者委派的詳細資訊，請參閱 下面的委派使用者存取 方法。 如果您使用委派，請考慮如何處理使用者取消布建或其許可權變更的案例。
即時或批次
請考慮您將使用即時數據，或數據是否會以批次傳送。
針對即時整合，這些方法很常見：
- 要求/回應 是用戶端起始伺服器要求並接收回應的位置。 一般而言，要求/回應整合是使用 API 或 Webhook 來實作。 要求可能是 同步的，其會等候通知和回應。 或者，要求可以是異步的，使用異步要求-回復模式來等候回應。
- 鬆散結合的通訊 通常是透過專為鬆散結合系統而設計的傳訊元件來啟用。 例如，Azure 服務匯流排 提供消息佇列功能，Azure 事件方格 和事件中樞提供事件功能。 這些元件通常用於整合架構的一部分。
相反地，批次整合通常會透過背景作業進行管理，這可能會在一天中的特定時間觸發。 通常，批次整合會透過 暫存位置進行，例如 Blob 記憶體容器，因為交換的數據集可能很大。
資料量
請務必瞭解透過整合交換的數據量，因為這項資訊可協助您規劃整體系統容量。 當您規劃系統的容量時，請記住，不同的租使用者可能會有不同的數據量來交換。
針對即時整合，您可以將磁碟區量測量為指定時段內的交易數目。 針對批次整合，您可以將磁碟區測量為交換的記錄數目或以位元組為單位的數據量。
資料格式
當兩方之間交換數據時，請務必清楚了解數據的格式和結構化方式。 請考慮下列資料格式的部分：
- 檔格式，例如 JSON、Parquet、CSV 或 XML。
- 架構，例如將包含的欄位清單、日期格式，以及欄位的可為 Null。
當您使用多租用戶系統時，最好將所有租用戶標準化並使用相同的數據格式。 如此一來，您就不必針對每個租使用者的需求自定義及重新測試整合元件。 不過，在某些情況下，您可能需要使用不同的數據格式來與不同的租用戶通訊，因此您可能需要實作多個整合。 如需可協助簡化這類情況的方法，請參閱 Composable 整合元件一節。
存取租用戶的系統
某些整合會要求您建立租用戶系統或數據存放區的連線。 當您連線到租用戶的系統時，必須仔細考慮連線的網路和身分識別元件。
網路存取
請考慮用來存取租使用者系統的網路拓撲，其中可能包含下列選項：
- 透過因特網連線。 如果您透過因特網連線，如何保護連線，以及如何加密數據？ 如果您的租用戶計劃根據您的IP位址進行限制，請確定解決方案所使用的 Azure 服務可以支援輸出連線的靜態 IP 位址。 例如，請考慮視 需要使用 NAT 閘道 來提供靜態 IP 位址。 如果您需要 VPN，請考慮如何安全地與租使用者交換密鑰。
- 部署至租用戶環境的代理程式可以提供彈性的方法，並協助您避免租使用者需要允許輸入連線。
- 轉送，例如 Azure 轉送，也提供避免輸入連線的方法。
如需詳細資訊，請參閱多租用戶網路方法的指引。
驗證
請考慮在起始連線時，如何向每個租用戶進行驗證。 請考慮下列方法：
- 秘密，例如 API 金鑰或憑證。 請務必規劃如何安全地管理租用戶的認證。 您的租使用者秘密外泄可能會導致重大安全性事件，而可能會影響許多租使用者。
- Microsoft Entra 令牌，您可以在其中使用租使用者自己Microsoft Entra 目錄所簽發的令牌。 令牌可能會使用多租使用者Microsoft Entra 應用程式註冊或特定服務主體，直接發行至您的工作負載。 或者，您的工作負載可以要求委派的許可權，以代表租用戶目錄中的特定使用者存取資源。
無論您選取哪一種方法，請確定租使用者遵循最低許可權原則，並避免授與系統不必要的許可權。 例如，如果您的系統只需要從租用戶的數據存放區讀取數據，則系統所使用的身分識別不應該具有寫入許可權。
租用戶的系統存取權
如果租使用者需要連線到您的系統，請考慮提供專用 API 或其他整合點，然後您可以在解決方案介面區中建立模型。
在某些情況下，您可能會決定為租使用者提供 Azure 資源的直接存取權。 請仔細考慮影響，並確定您瞭解如何以安全的方式將存取權授與租使用者。 例如，您可以使用下列其中一種方法：
- 使用代客密鑰模式，其牽涉到使用安全性措施，例如共用存取簽章來授與特定 Azure 資源的受限存取權。
- 針對整合點使用專用資源，例如專用的記憶體帳戶。 最好讓整合資源與核心系統資源分開。 這種方法可協助您將安全性事件的爆破半徑降到最低。 它也可確保，如果租使用者不小心起始大量連線到資源並耗盡其容量，則系統的其餘部分會繼續執行。
法規遵循
當您開始直接與租用戶的數據互動，或傳輸該數據時，請務必清楚瞭解租使用者的 治理和合規性需求。
要考慮的方法和模式
公開 API
即時整合通常牽涉到將 API 公開給租使用者或其他要使用的合作物件。 API 需要特殊考慮，特別是在外部合作物件使用時。 請考量下列問題：
- 誰獲授與 API 的存取權？
- 您要如何驗證 API 的使用者？
- API 用戶可以在一段時間內提出的要求數目有限制嗎？
- 如何提供每個 API 的 API 和文件相關信息？ 例如，您需要實作開發人員入口網站嗎？
最佳做法是使用 API 閘道，例如 Azure API 管理，來處理這些考慮和其他許多問題。 API 閘道可讓您在單一位置實作 API 遵循的原則，並簡化後端 API 系統的實作。 若要深入瞭解 API 管理 如何支援多租用戶架構，請參閱在多租使用者方案中使用 Azure API 管理。
代客金鑰模式
有時候，租使用者可能需要直接存取數據源，例如 Azure 儲存體。 請考慮遵循 代客密鑰模式 安全地共享數據，以及限制數據存放區的存取。
例如，您可以在批次導出大型數據檔時使用此方法。 產生匯出檔案之後，您可以將它儲存至 Azure 儲存體 中的 Blob 容器，然後產生時間系結的唯讀共用存取簽章。 此簽章可以提供給租使用者，以及 Blob URL。 租用戶接著可以從 Azure 儲存體 下載檔案，直到簽章到期為止。
同樣地，您可以產生具有寫入特定 Blob 許可權的共用存取簽章。 當您提供租用戶的共用存取簽章時，他們可以將其數據寫入 Blob。 藉由使用事件方格整合進行 Azure 儲存體，您的應用程式就可以收到處理和匯入數據檔的通知。
Webhooks
Webhook 可讓您以提供給您的URL，將事件傳送至租使用者。 當您有要傳送的資訊時，您會起始與租使用者 Webhook 的連線，並將您的數據包含在 HTTP 要求承載中。
如果您選擇建置自己的 Webhook 事件系統，請考慮遵循 CloudEvents 標準來簡化租使用者的整合需求。
或者，您可以使用 Azure 事件方格 之類的服務來提供 Webhook 功能。 事件方格可與 CloudEvents 原生運作，並支援 事件網域，這對多租用戶解決方案很有用。
注意
每當您對租使用者的系統進行輸出連線時，請記住您正在連線到外部系統。 遵循建議的雲端做法，包括使用重試模式、斷路器模式和大量分頭模式，以確保租用戶系統中的問題不會傳播到您的系統。
委派的使用者存取權
當您從租用戶的數據存放區存取數據時，請考慮是否需要使用特定使用者的身分識別來存取數據。 當您這麼做時，您的整合受限於用戶擁有的相同許可權。 這種方法通常稱為 委派存取。
例如，假設您的多租使用者服務會透過租用戶的數據執行機器學習模型。 您必須存取每個租用戶的服務實例，例如 Azure Synapse Analytics、Azure 儲存體、Azure Cosmos DB 等。 每個租使用者都有自己的Microsoft Entra 目錄。 您可以將解決方案的委派存取權授與數據存放區，以便擷取特定使用者可以存取的數據。
如果數據存放區支援 Microsoft Entra 驗證，委派存取會比較容易。 許多 Azure 服務都支援Microsoft Entra 身分識別。
例如，假設您的多租使用者 Web 應用程式和背景進程需要使用租使用者的使用者身分識別，從 Microsoft Entra ID 存取 Azure 儲存體。 您可以執行下列步驟：
- 建立代表您解決方案的多租使用者Microsoft Entra 應用程式註冊 。
- 將存取 Azure 儲存體 許可權授與應用程式委派的許可權，作為登入的使用者。
- 使用 Microsoft Entra 識別碼，設定您的應用程式來驗證使用者。
使用者登入之後，Microsoft Entra ID 會發出應用程式短期存取令牌，以代表使用者存取 Azure 儲存體，併發出較長的重新整理令牌。 您的系統必須安全地儲存重新整理令牌，讓您的背景進程可以取得新的存取令牌，並可以代表用戶繼續存取 Azure 儲存體。
傳訊
傳訊允許系統或元件之間的異步、鬆散結合通訊。 在整合案例中，通常會使用傳訊來分離來源和目的地系統。 如需傳訊和多租使用者的詳細資訊，請參閱 多租使用者解決方案中傳訊的架構方法。
當您使用傳訊作為與租用戶系統整合的一部分時，請考慮您是否應該針對 Azure 服務匯流排 或 Azure 事件中樞 使用共用存取簽章。 共用存取簽章可讓您將訊息資源的有限存取權授與第三方，而不需要讓他們存取傳訊子系統的其餘部分。
在某些情況下，您可能會為不同的租使用者提供不同的服務等級協定（SLA）或服務品質（QoS）。 例如，租使用者的子集可能會預期其數據導出要求比其他人更快處理。 藉由使用 優先順序佇列模式，您可以針對不同層級的優先順序建立個別佇列，並使用不同的背景工作實例據此設定優先順序。
可組合整合元件
有時候您可能需要與許多不同的租使用者整合，每個租用戶都會使用不同的數據格式或不同類型的網路連線。
整合的常見方法是建置及測試執行下列動作類型的個別步驟：
- 從數據存放區擷取數據。
- 將數據轉換成特定格式或架構。
- 使用特定網路傳輸或已知目的地類型來傳輸數據。
一般而言，您可以使用 Azure Functions 和 Azure Logic Apps 等服務來建置這些個別元素。 接著，您可以使用Logic Apps 或 Azure Data Factory 之類的工具來定義整體整合程式，並叫用每個預先定義的步驟。
當您使用複雜的多租使用者整合案例時，定義可重複使用整合步驟的連結庫會很有説明。 然後，您可以建置每個租使用者的工作流程，根據該租使用者的需求，將適用的部分組合在一起。 或者，您可能能夠將某些數據集或整合元件直接公開給租使用者，以便他們從租用戶建置自己的整合工作流程。
同樣地，您可能需要從使用不同數據格式或不同傳輸給其他人的租用戶匯入數據。 此案例的一個很好的方法是建置租使用者特定的 連接器。 連接器是將數據正規化並匯入標準化格式和位置的工作流程，然後觸發主要共用匯入程式。
如果您需要建置租使用者特定的邏輯或程式碼，請考慮遵循 反損毀層模式。 此模式可協助您封裝租使用者特定元件，同時讓解決方案的其餘部分不知道新增的複雜性。
如果您使用 階層式定價模型，您可以選擇要求低定價層的租使用者遵循一組有限的數據格式和傳輸的標準方法。 較高的定價層可能會在您提供的整合元件中啟用更多自定義或彈性。
要避免的反模式
- 將主要數據存放區直接公開給租使用者。 當租使用者存取主要數據存放區時，保護這些數據存放區可能會變得困難，而且可能會不小心造成影響解決方案的效能問題。 請避免將認證提供給您的資料存放區給您的客戶，而且不要將數據從主資料庫直接復寫到客戶對相同資料庫系統的讀取複本。 請改為建立專用 整合數據存放區，並使用 代客密鑰模式 來公開數據。
- 在沒有 API 閘道的情況下公開 API。 API 有訪問控制、計費和計量的特定考慮。 即使您不打算一開始使用 API 原則，還是建議您儘早包含 API 閘道。 如此一來，如果您需要在未來自定義 API 原則，就不需要對第三方相依的 URL 進行重大變更。
- 不必要的緊密結合。 鬆散結合，例如使用 傳訊 方法，可為安全性、效能隔離和復原提供一系列優點。 可能的話，最好鬆散結合您的整合與第三方。 如果您需要緊密結合到第三方，請確定您遵循良好的做法，例如 重試模式、 斷路器模式和 Bulkhead 模式。
- 特定租使用者的自定義整合。 租使用者特定的功能或程式碼可讓您的解決方案更難測試。 它也會讓您在未來更難修改解決方案，因為您必須瞭解更多程式代碼路徑。 相反地，請嘗試建置 可組合的元件，以抽象化任何特定租使用者的需求，並在具有類似需求的多個租用戶之間重複使用這些元件 。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- John Downs |首席軟體工程師
- 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
其他參與者：
- Will Velida |客戶工程師 2，適用於 Azure 的 FastTrack
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
檢閱 多租使用者解決方案中傳訊的架構方法。