你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

用于租户集成和数据访问的体系结构方法

系统通常可以集成在一起,甚至跨组织边界进行集成。 生成多租户解决方案时,可能需要将数据发送回租户的系统,或从这些系统接收数据。 本文概述了为多租户解决方案构建和开发集成的关键注意事项和方法。

注意

如果提供多个集成点,最好单独考虑每个集成点。 通常,不同的集成点有不同的要求,设计也不同,即使它们以多种不同方式将同一系统连接在一起。

关键考虑因素和要求

数据流方向

请务必了解数据流动的方向。 数据流方向会影响体系结构的几个方面,例如如何管理标识和解决方案的网络拓扑。 有两个常见数据流:

  • 导出,这意味着数据从多租户系统流向单个租户的系统。
  • 导入,这意味着数据从租户的系统流入多租户系统。

还务必要考虑网络数据流方向,它不一定对应于逻辑数据流方向。 例如,你可以启动到租户的出站连接,以便从租户的系统导入数据。

完全或用户委托的访问权限

在许多系统中,对特定数据的访问权限仅限于特定用户。 一个用户可以访问的数据可能与另一个用户可以访问的数据不同。 重要的是要考虑是否希望使用完整的数据集,或者导入或导出的数据集是否基于特定用户有权访问的内容。

例如,考虑 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 性。

使用多租户系统时,如果可能,最好对所有租户进行标准化并使用相同的数据格式。 这样,就无需针对每个租户的要求自定义和重新测试集成组件。 但是,在某些情况下,可能需要使用不同的数据格式来与不同的租户通信,因此可能需要实现多个集成。 有关有助于简化此类情况的方法,请参阅可组合的集成组件一节。

访问租户的系统

某些集成要求与租户的系统或数据存储建立连接。 连接到租户的系统时,需要仔细考虑连接的网络和标识组件。

网络访问

考虑用于访问租户系统的网络拓扑,其中可能包括以下选项:

  • 通过 Internet 进行连接。 如果通过 Internet 进行连接,该如何保护连接,以及如何加密数据? 如果租户计划基于 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 存储的事件网格集成,可以通知应用程序处理和导入数据文件。

Webhook

借助 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 存储。 可以执行以下步骤:

  1. 创建代表解决方案的多租户 Microsoft Entra 应用程序注册
  2. 授予应用程序以登录用户身份访问 Azure 存储的委托权限
  3. 将应用程序配置为使用 Microsoft Entra ID 对用户进行身份验证。

用户登录后,Microsoft Entra ID 会为应用程序颁发一个短生存期访问令牌,该令牌可用于代表用户访问 Azure 存储,并颁发一个生存期较长的刷新令牌。 系统需要安全地存储该刷新令牌,以便后台进程可以获取新的访问令牌,并且可以代表用户继续访问 Azure 存储。

消息传递

消息传递允许在系统或组件之间进行异步、松散耦合的通信。 在集成场景中,消息传递通常用于解耦源系统和目标系统。 有关消息传递和多租户的详细信息,请参阅多租户解决方案中的消息传递体系结构方法

使用消息传递作为与租户系统集成的一部分时,请考虑是否应使用 Azure 服务总线的共享访问签名Azure 事件中心。 通过共享访问签名,你可以向第三方授予对消息传递资源的有限访问权限,而不允许他们访问消息传递子系统的其余部分。

在某些情况下,你可能会为不同的租户提供不同的服务级别协议 (SLA) 或服务质量 (QoS) 保证。 例如,一部分租户可能希望比其他人更快地处理他们的数据导出请求。 通过使用优先级队列模式,可以为不同的优先级创建单独的队列,并使用不同的辅助角色实例相应地设置优先级。

可组合集成组件

有时,可能需要与许多不同的租户集成,每个租户都使用不同的数据格式或不同类型的网络连接。

集成中的一种常见方法是生成和测试执行以下类型的操作的各个步骤:

  • 从数据存储中检索数据。
  • 将数据转换为特定格式或架构。
  • 通过使用特定网络传输或向已知目标类型传输数据。

通常,使用 Azure Functions 和 Azure 逻辑应用等服务构建这些单独的元素。 然后,使用逻辑应用或 Azure 数据工厂等工具定义整个集成过程,并调用每个预定义步骤。

使用复杂的多租户集成方案时,定义可重用集成步骤库可能会很有帮助。 然后,可以根据租户的要求为每个租户生成工作流,以组合相应的部分。 或者,可能能够直接向租户公开一些数据集或集成组件,以便他们可以从中生成自己的集成工作流。

同样,可能需要将数据从使用不同数据格式或不同传输方式的租户导入到其他租户。 这种情况的一个好方法是生成特定于租户的连接器。 连接器是将数据规范化并导入标准化格式和位置的工作流,它们随即会触发主要共享导入过程。

如果需要生成特定于租户的逻辑或代码,请考虑遵循防损层模式。 该模式可帮助你封装特定于租户的组件,同时使解决方案的其余部分察觉不到增加的复杂性。

如果使用分层定价模型,可能会选择要求低定价层的租户遵循采用一组有限的数据格式和传输的标准方法。 更高的定价层可能会在提供的集成组件中实现更多自定义或灵活性。

要避免的反模式

  • 将主数据存储直接公开给租户。 当租户访问主数据存储时,保护这些数据存储可能会变得更加困难,并且它们可能会意外导致影响解决方案的性能问题。 避免向客户提供数据存储的凭据,并且不要直接将数据从主数据库复制到客户的同一数据库系统的只读副本。 而是创建专用的集成数据存储,并使用附属密钥模式来公开数据。
  • 在没有 API 网关的情况下公开 API。 API 对访问控制、计费和计量有特定考虑。 即使最初不打算使用 API 策略,也最好提前包含一个 API 网关。 这样,如果将来需要自定义 API 策略,则无需对第三方依赖的 URL 进行中断性变更。
  • 不必要的紧密耦合。 松散耦合(如使用消息传递方法)可为安全性、性能隔离和复原能力提供一系列优势。 如果可能,最好将集成与第三方松散耦合。 如果需要紧密耦合到第三方,请确保遵循重试模式断路器模式隔舱模式等良好做法。
  • 特定租户的自定义集成。 特定于租户的功能或代码会使解决方案更难以测试。 它还使得将来更难修改解决方案,因为必须了解更多的代码路径。 相反,请尝试生成可组合组件,将任何特定租户的要求抽象化,并在具有相似要求的多个租户之间重复使用。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

其他参与者:

若要查看非公开领英个人资料,请登录领英。

后续步骤

请查看多租户解决方案中的消息传递体系结构方法