资源层次结构有助于您在 Google Cloud 中整理资源。本文档介绍如何在设计着陆区的过程中选择资源层次结构。本教程面向参与设计资源层次结构的云系统管理员、架构师和技术从业人员。本文档是有关着陆区的系列文章中的一篇。本文档包含的示例层次结构演示了企业在 Google Cloud 中构建资源的常见方式。
资源层次结构的设计因素
在 Google Cloud 中定义资源层次结构时，您必须考虑您的组织目前的工作方式以及云转换的理想结束状态。管理资源的最佳方法取决于您的组织的云端工作方式。由于每个组织各不相同，因此对于资源层次结构，不存在单一的最佳方法。
但是，我们不建议您将公司的组织结构映射到资源层次结构；而应关注您在 Google Cloud 中的业务需求和运营。
Google Cloud 资源层次结构
Google Cloud 中的资源层次结构从根节点（称为组织）开始。我们建议企业仅拥有一个根节点，但特定情况除外。您可以使用文件夹和项目来定义层次结构中的较低级层，并且您还可以在一个文件夹中创建更多文件夹来构建层次结构。您可以创建项目，项目可以在层次结构的任何级层托管工作负载。
下图显示了一个名为 Organization 的根节点，以及位于第一级层、第二级层和第三级层的文件夹。项目和子文件夹在第二级层的文件夹下创建。
资源层次结构考虑因素
在确定资源层次结构时，请考虑以下因素：
- 谁负责管理云资源？是您的部门、子公司、技术团队还是法律实体？
- 您有哪些合规性需求？
- 您是否有即将发生的业务活动，例如并购、收购和剥离？
了解整个层次结构中的资源交互
组织政策会被资源层次结构中的后代继承，但可能会被在较低级层定义的政策所取代。如需了解详情，请参阅了解层次结构评估。您可以使用组织政策限制条件来围绕整个组织或其重要部分设定准则，并且仍然允许例外情况。
允许政策（以前称为 IAM 政策）会被后代继承，并且较低级层的允许政策是会累加的。不过，允许政策可以被拒绝政策取代，因此您可以在项目、文件夹和组织级层限制权限。拒绝政策会先于允许政策应用。
您还需要考虑以下事项：
- Cloud Logging 提供聚合接收器，可用于汇总文件夹级层或组织级层的日志。 如需了解详情，请参阅确定 Google Cloud 着陆区的安全性。
- 结算是在项目级层分配的，与资源层次结构没有直接关联。但是，要在文件夹级层获取汇总信息，您可以使用结算报告按项目层次结构分析费用。
- 分层防火墙政策可让您在整个组织或特定文件夹中实施一致的防火墙政策。继承关系是隐式的，这意味着您可以允许或拒绝任何级层的流量，也可以将该项决策委托给较低的级层。
资源层次结构设计决策点
以下流程图展示了为组织选择最佳资源层次结构时需要考虑的事项。
上图概述了以下决策点：
- 不同的子公司、区域组或业务部门是否具有不同的政策要求？
- 如果是，请按照基于区域或子公司的设计进行操作。
- 否则，请转至下一个决策点。
您的工作负载或产品团队是否需要对其政策具有高度自主性？ 例如，您没有一个中央安全团队来确定所有工作负载或产品团队的政策。
您的具体用例可能需要使用其他资源层次结构设计，而不是决策图建议的那些设计。大多数组织会选择混合方法并在资源层次结构的不同级层选择不同的设计，从对政策和访问权限影响最大的设计开始进行选择。
方案 1：基于应用环境的层次结构
在许多组织中，您可以为不同的应用环境（例如开发、生产和测试）定义不同的政策和访问权限控制。在每个环境中使用标准化的独立政策可以简化管理和配置。例如，您的生产环境中的安全政策可能比测试环境中更为严格。
如果满足以下条件，请使用基于应用环境的层次结构：
- 您拥有多个具有不同政策和管理要求的单独应用环境。
- 您具有集中式安全或审核要求，中央安全团队必须能够对所有生产工作负载和数据实现一致的强制执行。
- 您需要使用不同的 Identity and Access Management (IAM) 角色来访问不同环境中的 Google Cloud 资源。
如果满足以下条件，请避免使用此层次结构：
- 您没有运行多个应用环境。
- 您的多个环境没有使用不同的应用依赖项和业务流程。
- 对于不同的区域、团队或应用，存在巨大的政策差异。
下图展示了一个虚构的金融技术公司（即 example.com）的层次结构。
如上图所示，example.com 有三个应用环境，它们具有不同的政策、访问权限控制、监管要求和流程。这些环境如下所示：
开发和质量检查环境：此环境由开发者管理，他们可以是内部员工，也可以是顾问团队。这些开发者会持续推送代码并负责质量保证。此环境绝不会供企业客户使用。与生产环境相比，该环境对集成和身份验证的要求没有那么严格，并且会为开发者分配具有适当权限的已批准角色。开发和质量检查环境仅适用于 example.com 中的标准应用产品。
测试环境：此环境用于回归和应用测试，并且为使用 example.com API 的 example.com 客户端提供企业对企业 (B2B) 产品支持。为此，example.com 创建了两个项目类型：
- 内部测试项目，用于完成针对 B2B 产品的内部回归、性能和配置测试。
- 支持多租户的客户端 UAT 项目，使 B2B 客户端可以验证其配置，并且符合 example.com 在用户体验、品牌塑造、工作流、报告等方面的要求。
生产环境：此环境托管经过验证、为系统所接受且已发布的所有产品。此环境受支付卡行业数据安全标准 (PCI DSS) 法规的约束，使用硬件安全模块 (HSM)，并在身份验证和支付结算等方面与第三方处理方集成。审核和合规性团队是此环境的关键利益相关方。对此环境的访问会受到严格的控制，并且主要仅限自动化部署流程对其进行访问。
如需详细了解如何设计基于应用环境的层次结构，请参阅企业基础蓝图中的组织结构。
方案 2：基于区域或子公司的层次结构
一些组织在许多区域运营，并且这些子公司在不同的地理位置开展业务，或者它们是在并购和收购后产生的组织。这些组织需要一个资源层次结构能够充分利用 Google Cloud 中提供的可伸缩性和管理选项，并保持区域或子公司之间存在的不同流程和政策相互独立。此层次结构使用子公司或区域作为资源层次结构中的最高文件夹级层。部署过程通常围绕区域展开。
如果满足以下条件，请使用此层次结构：
- 不同的区域或子公司独立运营。
- 区域或子公司具有不同的运营主干、数字平台产品和流程。
- 您的企业对这些区域或子公司具有不同的监管和合规性标准。
下图展示了一个全球性组织的示例层次结构，该组织拥有两个子公司以及一个具有区域化结构的保全组。
上图具有以下层次结构：
- 以下文件夹位于第一层级：
- 在第二层级的 Group Holding 文件夹中，包含以下文件夹：
APAC、EMEA和Americas文件夹代表该组中具有不同治理要求、访问权限和政策的各个区域。Shared infrastructure文件夹代表在所有区域中全局使用的资源。
- 每个文件夹中包含各种项目，这些项目又包含各子公司或区域负责管理的资源。
您可以添加更多文件夹来分隔公司内的不同法律实体、部门和团队。
方案 3：基于责任框架的层次结构
如果您的产品是独立运行的，或者各组织部门明确定义了拥有产品生命周期的团队，那么基于责任框架的层次结构效果最佳。在这些组织中，产品所有者负责整个产品生命周期，包括其流程、支持、政策、安全性和访问权限。您的各产品彼此独立，并且不常使用组织范围的准则和控制措施。
如果满足以下条件，请使用此层次结构：
- 您运行的组织对每个产品都有明确的所有权和问责制机制。
- 您的工作负载是独立的，并且不共享许多通用政策。
- 您的流程和外部开发者平台作为服务或产品提供。
下图展示了一个电子商务平台提供商的示例层次结构。
上图具有以下层次结构：
- 以下文件夹位于第一层级：
- 名为
Ecommerce Modules和Logistics and Warehousing Modules的文件夹代表平台产品中的两个模块，它们在产品生命周期中需要使用相同的访问权限和政策。 Reconciliation and Billing文件夹代表负责该平台产品内特定业务组件的端到端模块的产品团队。Bootstrap文件夹代表部署 Google Cloud 基础设施所需的常见资源，如企业基础蓝图中所述。
- 名为
- 每个文件夹中包含各种项目，这些项目又包含不同产品团队负责的各个独立模块。
如需了解详情，请参阅 Fabric FAST Terraform 框架资源层次结构。
资源层次结构的最佳做法
以下部分介绍了我们建议的设计资源层次结构的最佳做法，无论您选择的是哪种资源层次结构，这些最佳做法都适用。
如需详细了解有关如何配置 Cloud Identity 和 Google Workspace 账号和组织的最佳做法，请参阅规划账号和组织的最佳做法。
使用单个组织节点
为了避免产生管理开销，请尽可能使用单个组织节点。但是，对于以下用例，请考虑使用多个组织节点：
- 您希望测试对 IAM 级别或资源层次结构所做的重大更改。
- 您希望在具有不同组织政策的沙盒环境中进行实验。
- 您的组织包含将来可能会被出售或作为完全独立的实体运行的子公司。
使用标准化命名惯例
在整个组织中使用标准化命名惯例。安全基础蓝图中提供了示例命名惯例，您可以根据自己的需求进行调整。
将引导资源和通用服务分开
将单独的文件夹分别用来使用基础架构即代码 (IaC) 引导 Google Cloud 环境，以及用来存放在环境或应用之间共享的通用服务。将引导文件夹放在资源层次结构中组织节点的正下方。
将通用服务的文件夹放在层次结构的不同层级上，具体取决于您选择的结构。
如果符合以下情况，请将通用服务的文件夹放在组织节点的正下方：
- 您的层次结构使用位于最高级层的应用环境和位于第二层的团队或应用。
- 您的各个环境之间存在共享的通用服务，例如监控功能。
如果符合以下情况，请将通用服务的文件夹放在应用文件夹下的较低级层：
您在应用之间共享服务，并且为每个部署环境部署单独的实例。
应用共享需要为每个部署环境分别进行开发和测试的微服务。
下图展示了一个示例层次结构，其中有一个供所有环境使用的共享基础架构文件夹，以及一些可用于层次结构中较低级层的每个应用环境的共享服务文件夹：
上图具有以下层次结构：
- 位于第一级层的文件夹如下所示：
Development environment和Production environment文件夹包含应用环境。Shared infrastructure文件夹包含在各个环境之间共享的通用资源，例如监控功能。Bootstrap文件夹包含部署 Google Cloud 基础设施所需的常见资源，如企业基础蓝图中所述。
- 第二级层包含以下文件夹：
- 每个应用的每个环境对应一个文件夹（
App 1和App 2），其中包含这些应用的资源。 - 这两个应用环境的
Shared文件夹，其中包含在应用之间共享但对每个环境独立的服务。例如，您可能有一个文件夹级 Secret 项目，以便您可以对生产 Secret 和非生产 Secret 分别应用不同的允许政策。
- 每个应用的每个环境对应一个文件夹（
- 每个应用文件夹中包含各种项目，这些项目又包含属于每个应用的独立模块。
后续步骤
- 为着陆区设计网络（本系列的下一个文档）。
- 查看企业基础蓝图。
- 请参阅 Google Cloud 安全措施最佳做法中心提供的各种蓝图和白皮书。