比较集中式和分布式部署模式 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

比较集中式和分布式部署模式

您可以采用集中式或分布式部署模式部署 OPA,多租户应用程序的理想方法取决于用例。有关这些模式的示例,请参阅本指南前面的 “ PEPs 在开启的情况下使用集中式 PD P” APIs 和 “使用分布式 PDP 及 PEPs on” APIs 部分。由于 OPA 可以作为守护程序部署在操作系统或容器中,因此可以通过多种方式实现以支持多租户应用程序。

在集中部署模式中,OPA 作为容器或守护程序部署,其 RESTful API 可供应用程序中的其他服务使用。当一项服务需要 OPA 做出决策时,会调用中央 OPA RESTful API 来做出此决策。这种方法易于部署和维护,因为只有一个部署 OPA。这种方法的缺点是它没有提供任何机制来维持租户数据的分离。由于 OPA 只有一个部署,因此 OPA 决策中使用的所有租户数据,包括 OPA 引用的任何外部数据,都必须可用于 OPA。您可以使用这种方法保持租户数据隔离,但必须通过 OPA 的策略和文档结构或对外部数据的访问来强制执行。集中部署模式还需要更高的延迟,因为每个授权决策都必须对其他服务 RESTful 进行 API 调用。

在分布式部署模式中,OPA 作为容器或守护程序与多租户应用程序的服务一起部署。它可以作为 sidecar 容器部署,也可以部署为在操作系统上本地运行的守护程序。要从 OPA 检索决策,该服务会对本地 OPA 部署进行 RESTful API 调用。(由于 OPA 可以作为 Go 包部署,因此您可以原生使用 Go 来检索决策,而不必使用 RESTful API 调用。) 与集中式部署模式不同,分布式模式需要付出更大的努力来部署、维护和更新,因为它存在于应用程序的多个区域。分布式部署模式的一个好处是能够保持租户数据的隔离,特别是对于使用孤立的 SaaS 模型的应用程序。租户特定的数据可以在特定于该租户的 OPA 部署中隔离,因为分布式模型中的 OPA 是与租户一起部署的。此外,分布式部署模式的延迟要比集中式部署模式低得多,因为每个授权决策都可以在本地做出。

在多租户应用程序中选择 OPA 部署模式时,请务必评估对您的应用程序最重要的标准。如果您的多租户应用程序对延迟很敏感,则分布式部署模式可以提供更好的性能,但会牺牲更复杂的部署和维护。尽管您可以通过 DevOps 和自动化来管理其中的一些复杂性,但与集中式部署模式相比,它仍然需要付出额外的努力。

如果您的多租户应用程序使用孤立的 SaaS 模型,则可以使用分布式 OPA 部署模式来模仿租户数据隔离的孤立方法。这是因为当 OPA 与每个租户特定的应用程序服务一起运行时,您可以自定义每个 OPA 部署,使其仅包含与该租户关联的数据。在集中式 OPA 部署模式中孤立 OPA 数据是不可能的。如果您将集中部署模式或分布式模式与池化 SaaS 模型结合使用,则必须在 OPA 文档模型中维护租户数据隔离。