如何处理 Service Broker策略

根据策略定义处理策略。特别是，当有多个策略可能适用于单个部署时，范围和实施级别决定了哪个策略有效。

本文提供有关策略处理的一般信息，但也包含有关不同策略类型的更多详细信息。

如何根据组织级别和实施类型对策略进行排名

当作为项目成员的用户创建部署时，可能有多个应用于该部署的策略。

	为评估策略，系统首先会确定策略并对其进行排名。 在组织级别或项目级别是否有任何硬性策略。如果同时有硬性策略和软性策略，则只有硬性策略才会考虑在内并进行排名。如果只有软性策略，则对软性策略进行排名。 所有硬性策略或所有软性策略的排名按范围排序，且组织级别策略具有比项目级别策略更高的排名。 最终区分特性是创建日期，且较早日期具有比较晚日期更高的排名。

如何根据组织级别和实施类型处理策略

系统将对策略进行评估和排名，并合并适用的策略以生成有效策略。有效策略将产生预期结果，但并非始终是特定的命名策略。

此部分包括以下示例：

• 租约策略
• 实施后操作策略

查看以下租约策略示例。

	确定要考虑的策略并对其进行排名后，将评估这些策略以确定合并顺序。 排名最高的策略将成为基准。第二级别策略在排名最高的策略之后应用，依此类推。 如果某个策略与前面的策略不兼容，则该策略不考虑在内。例如，值高于前面的策略。 丢弃的任何策略都将被忽略。要查看应用的策略，请选择内容和策略 > 策略 > 实施，找到部署，然后查看决策说明。
	系统将合并策略并且可能包含来自多个单独策略的值，而非应用一个策略并排除其上的所有其他策略。 在此示例中，合并过程排除策略 2，因为值高于策略 1。 接着，根据策略 1 评估策略 3。策略 3 中的“租约”值和“租约总数”值低于策略 1，因此这两个值将和“宽限期”一起成为有效策略的一部分。

请查看以下实施后操作策略示例。

	确定要考虑的策略并对其进行排名后，将评估这些策略以确定合并顺序。 排名最高的策略将成为基准。第二级别策略在排名最高的策略之后应用，依此类推。 如果某个策略由前面的策略（例如，策略 3）强制实施，则会放弃考虑它。 丢弃的任何策略都将被忽略。要查看应用的策略，请选择内容和策略 > 策略 > 实施，找到部署，然后查看决策说明。

租约策略管理目标注意事项

既然您知道如何处理租约策略，请确定您的策略管理目标。通过了解如何处理策略，您可以实现自己的管理目标，而不必创建过多无法管理的策略。

当决定如何实施策略时，请考虑以下场景。

• 租约策略目标和实施示例
• 实施后策略目标和实施示例

表 1. 租约策略目标和实施示例

管理目标	配置示例	行为
有意义的组织级别默认策略仍允许项目级别策略值影响应用的值。	组织级别策略 = 软性 宽限期：10 租约：100 租约总数：100 项目 1 策略 1 = 软性 租约：20 租约总数：50 项目 2 策略 1 = 软性 租约：10 租约总数：30	项目 1 的成员请求目录项。 项目 2 不考虑在内，因为它对项目 1 部署不适用。 合并的有效策略为： 宽限期：10 租约：20 租约总数：50
始终默认为组织级别策略。	组织级别策略 = 硬性 宽限期：10 租约：100 租约总数：100 项目 1 策略 1 = 软性 租约：20 租约总数：50	项目 1 的成员请求目录项。 项目 1 策略 1 不考虑在内，因为组织级别硬性策略具有更高的排名并且软性策略不考虑在内。 有效策略为： 宽限期：10 租约：100 租约总数：100
所有策略均在项目级别定义，且没有任何组织级别默认策略。	项目 1 策略 1 = 软性 宽限期：10 租约：100 租约总数：100 项目 1 策略 2 = 软性 租约：20	项目 1 的成员请求目录项。 它们都是软性策略，且都用于项目 1。值将合并。 有效策略为： 宽限期：10 租约：20 租约总数：100

在这些示例中使用了实施后操作策略。

表 2. 实施后策略目标和实施示例

管理目标	配置示例	行为
有意义的组织级别默认策略仍允许项目级别策略值影响应用的值。	组织级别策略 = 软性 操作：Deployment.* 项目 1 策略 1 = 软性 操作：Cloud.vSphere.Machine.* 项目 2 策略 1 = 软性 操作：Cloud.Azure.Machine.*	项目 1 的成员请求目录项。 项目 2 不考虑在内，因为它对项目 1 部署不适用。 合并的有效策略为： 操作：{Deployment.* ,Cloud.vSphere.Machine.*}
始终默认为组织级别策略。	组织级别策略 = 硬性 操作：Deployment.* 项目 1 策略 1 = 软性 操作：Cloud.vSphere.Machine.*	项目 1 的成员请求目录项。 项目 1 策略 1 不考虑在内，因为组织级别硬性策略具有更高的排名并且软性策略不考虑在内。 有效策略为： 操作：{Deployment.* }
所有策略均在项目级别定义，且没有任何组织级别默认策略。	项目 1 策略 1 = 软性 操作：Deployment.ChangeLease 项目 1 策略 2 = 软性 操作：Deployment.Delete	项目 1 的成员请求目录项。 它们都是软性策略，且都用于项目 1。值将合并。 有效策略为： 操作：{Deployment.ChangeLease , Deployment.Delete}

批准策略目标和实施示例

批准策略评估将遵循此过程。

1. 已提交部署或实施后操作的请求。
2. 批准服务将查询适用于正在请求目录项或更改已部署项目的项目的策略。
3. 将返回所有适用的项目和组织级别的范围策略。
4. 将根据部署条件筛选批准策略。部署条件适用于部署和实施后操作。
5. 如果未找到匹配的策略，则不需要批准，并且部署过程将继续进行。
6. 如果存在匹配的策略（例如，AP1、AP2、APn），则会创建一个批准项目，如下所示：
   • 实施的策略 = AP1、AP2、APn。
   • 审批者 = 所有实施的策略中所有审批者的联合。
   • 如果任何策略具有拒绝值，则自动过期 = 拒绝；否则，为“批准”。
   • 过期 = 任何实施的策略的最小天数。

下表提供了多个策略的示例。该表的下面介绍了如何进行处理。

策略	配置示例
AP1	范围 = 组织 自动过期 = 批准 过期时间 = 7 天
AP2	范围 = 项目 1 自动过期 - 批准 过期时间 = 3 天
AP3	范围 = 项目 1 自动过期 = 拒绝 过期时间 = 4 天
AP4	范围 = 项目 2 自动过期 = 批准 过期时间 = 5 天

根据上述策略和配置示例，以下信息说明了如何处理项目 1 请求。

1. 范围评估将返回 AP1、AP2 和 AP3。AP4 不包括在内，因为它是项目 2 的策略。
2. 假设 AP1、AP2 和 AP3 满足部署和操作条件，则批准项包含以下值：
   • 审批者 = AP1、AP2 和 AP3 中的任意审批者或所有审批者都将添加为审批者。
   • 自动过期 = 拒绝。AP3 提供更严格的行为。
   • 到期时间 = 3 天。AP2 提供最低的值。