Azure service fabric 更改Service Fabric应用程序的应用程序参数时缩短升级时间

我有一个多租户场景（每个租户都有自己的Service Fabric应用程序实例），租户可以激活/停用单个Service Fabric服务（我们在UI中将服务作为扩展概念公开给租户）

示例：租户#1激活电子邮件扩展，该扩展将激活电子邮件服务结构服务

要求：

当租户激活扩展时，他们应该能够提供配置（例如：smtpserver）

租户应该能够快速激活扩展（有大约20个不同的扩展）

分机应在几秒钟内启动并运行

当前实施情况

扩展的激活通过以下方式处理（使用上面的电子邮件示例）：

租户通过UI激活电子邮件扩展，并向smtpserver提供地址

电子邮件服务是在租户的应用程序中创建的

将提供的smtpserver配置添加到应用程序参数列表时，会触发应用程序升级

服务结构开始滚动升级

时光飞逝（在我们的例子中是几分钟）

应用程序已升级，电子邮件服务已启动并运行

在上述场景中，服务启动并可以读取smtpserver配置。然而，承租人的体验并非最佳

问题

在升级过程中，无法激活任何其他服务，因为在服务结构的持续升级过程中无法更改配置

因此，租户必须等待应用程序升级（需要几分钟），然后才能再次激活/取消激活扩展。如果租户想要激活10个扩展，他们将不得不等待很长时间

我尝试了以下方法来缩短升级时间：

将HealthCheckStableDurationInMilliseconds设置为0

将HealthCheckWaitDurationInMilliseconds设置为0

升级过程仍然需要很长时间（大约一分钟）

问题

由于我们只想更改Service Fabric应用程序参数，是否有其他方法加快升级过程或完全解决升级问题

---

注意：由于技术限制，我们无法批量激活扩展。每个扩展必须一次激活一个。

既然您能够在激活和取消激活时动态创建和删除服务，您是否考虑过将所需的配置作为初始化数据参数传递给服务创建

---

请注意，创建服务后，您无法更改初始化数据

很好的建议，谢谢你花时间！但是，由于用户需要能够重新配置服务（扩展），因此在这种情况下，这不适用于我们。主要问题之一是，在更改配置时，整个应用程序处于“升级状态”。您知道是否有任何方法可以只触发单个服务的升级，而不是整个应用程序的升级，从而（可能）加快速度？