Blue/Green 使用 Azure ServiceFabric 的部署
Blue/Green Deployments with Azure ServiceFabric
我目前正在 Azure ServiceFabric 上使用 ReliableActors 框架构建应用程序。随着我们扩大规模，我正在考虑进行 blue/green 部署。我可以看到如何使用无状态系统来做到这一点。有没有办法使用有状态的演员来做到这一点？
Service Fabric 是关于滚动升级的，而不是像 VIP 交换那样的部署交换。无状态和有状态服务都以相同的方式升级，但有一些额外的细微差别我将在后面提到。
通过滚动升级，我的意思是对应用程序的升级是就地完成的，一次升级一个域，这样就没有停机时间，也没有突然切换。 Service Fabric 中的滚动升级可以在安全 "managed" 模式下完成，平台将在进入下一个升级域之前执行健康检查，如果健康检查失败，将自动回滚。
好的，听起来不错。但是，当升级总是滚动升级时，您如何进行 blue/green 部署？
这是应用程序类型和版本的来源。Service Fabric 没有两个 "environments" 可以容纳两个 运行 应用程序，而是具有版本化应用程序类型的概念，可以从中创建应用程序实例.以下是其工作原理的示例：
假设我想创建一个名为 Foo 的应用程序。我的 Foo 应用程序被定义为一个应用程序类型，称之为 FooType。这类似于在 C# 中定义 class。就像 C# 中的 class 一样，我可以创建我的类型的实例。每个实例都有一个唯一的名称，类似于 class 的每个对象实例都有一个唯一的变量名称。但与 C# 中的 classes 不同，我的 FooType 有一个版本号。然后我可以 "register" 我的集群中的应用程序类型和版本：
FooType 1.0
注册后，我可以创建该应用程序的实例：
"fabric:/FooApp" of FooType 1.0
现在，假设我开发了我的应用程序的 2.0 版。所以我在集群中注册了 FooType 的 2.0 版：
FooType 1.0
FooType 2.0
现在我注册了两个版本的 FooType，我还有一个 1.0 的实例 运行:
"fabric:/FooApp" of FooType 1.0
有趣的地方就在这里。我可以做一些有趣的事情：
我可以使用 "fabric:/FooApp" - FooType 1.0 的一个实例 - 并将其升级到 FooType 2.0。这将是该 运行 应用程序的滚动升级。
或者.. 我可以不理会 "fabric:/FooApp"，并为我的 2.0 版应用程序创建一个 new 实例：
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
现在我有两个应用程序，运行 并排在同一个集群中。一个是1.0的实例，一个是2.0的实例。通过对端口和应用程序端点进行一些配置，我可以确保在测试 2.0 实例时用户仍会访问 1.0 实例。
太好了，我的所有测试都通过了 2.0 实例，所以现在我可以安全地使用 1.0 实例并将其升级 到 FooType 的 2.0。同样，这是该实例 (fabric:/FooApp) 的滚动升级，它不会将用户迁移到新实例 (fabric:/FooAppv2Test)。稍后我将删除 fabric:/FooAppv2Test 因为那只是为了测试。
不过，blue/green 的一个好处是能够在新部署失败时切换回其他部署。好吧，您仍然注册了 FooType 的 1.0 和 2.0。因此，如果您的应用程序在从 1.0 升级到 2.0 后开始出现问题，您可以 "upgrade" 将其恢复到 1.0！事实上，您可以 "upgrade" 应用程序实例在其应用程序类型的任意多个不同版本之间！而且您不需要像在交换环境中那样拥有所有应用程序版本 运行 的 个实例 ，您只需注册不同的版本和一个应用程序实例可以 "upgrade" 版本之间。
我提到了有状态服务的注意事项。对于有状态服务，需要记住的重要一点是应用程序状态——您的用户数据——包含在应用程序实例 (fabric:/FooApp) 中，因此为了让您的用户看到他们的数据，您需要将他们保存在该实例上。这就是我们进行滚动升级而不是部署交换的原因。
这只是基本思路。根据您的目标和应用程序的工作方式，您可以通过其他方式尝试应用程序类型、版本和实例，但那是以后的事了。
我目前正在 Azure ServiceFabric 上使用 ReliableActors 框架构建应用程序。随着我们扩大规模，我正在考虑进行 blue/green 部署。我可以看到如何使用无状态系统来做到这一点。有没有办法使用有状态的演员来做到这一点？
Service Fabric 是关于滚动升级的，而不是像 VIP 交换那样的部署交换。无状态和有状态服务都以相同的方式升级，但有一些额外的细微差别我将在后面提到。
通过滚动升级，我的意思是对应用程序的升级是就地完成的，一次升级一个域，这样就没有停机时间，也没有突然切换。 Service Fabric 中的滚动升级可以在安全 "managed" 模式下完成，平台将在进入下一个升级域之前执行健康检查，如果健康检查失败，将自动回滚。
好的，听起来不错。但是，当升级总是滚动升级时，您如何进行 blue/green 部署？
这是应用程序类型和版本的来源。Service Fabric 没有两个 "environments" 可以容纳两个 运行 应用程序，而是具有版本化应用程序类型的概念，可以从中创建应用程序实例.以下是其工作原理的示例：
假设我想创建一个名为 Foo 的应用程序。我的 Foo 应用程序被定义为一个应用程序类型，称之为 FooType。这类似于在 C# 中定义 class。就像 C# 中的 class 一样，我可以创建我的类型的实例。每个实例都有一个唯一的名称，类似于 class 的每个对象实例都有一个唯一的变量名称。但与 C# 中的 classes 不同，我的 FooType 有一个版本号。然后我可以 "register" 我的集群中的应用程序类型和版本：
FooType 1.0
注册后，我可以创建该应用程序的实例：
"fabric:/FooApp" of FooType 1.0
现在，假设我开发了我的应用程序的 2.0 版。所以我在集群中注册了 FooType 的 2.0 版：
FooType 1.0
FooType 2.0
现在我注册了两个版本的 FooType，我还有一个 1.0 的实例 运行:
"fabric:/FooApp" of FooType 1.0
有趣的地方就在这里。我可以做一些有趣的事情：
我可以使用 "fabric:/FooApp" - FooType 1.0 的一个实例 - 并将其升级到 FooType 2.0。这将是该 运行 应用程序的滚动升级。
或者.. 我可以不理会 "fabric:/FooApp"，并为我的 2.0 版应用程序创建一个 new 实例：
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
现在我有两个应用程序，运行 并排在同一个集群中。一个是1.0的实例，一个是2.0的实例。通过对端口和应用程序端点进行一些配置，我可以确保在测试 2.0 实例时用户仍会访问 1.0 实例。
太好了，我的所有测试都通过了 2.0 实例，所以现在我可以安全地使用 1.0 实例并将其升级 到 FooType 的 2.0。同样，这是该实例 (fabric:/FooApp) 的滚动升级，它不会将用户迁移到新实例 (fabric:/FooAppv2Test)。稍后我将删除 fabric:/FooAppv2Test 因为那只是为了测试。
不过，blue/green 的一个好处是能够在新部署失败时切换回其他部署。好吧，您仍然注册了 FooType 的 1.0 和 2.0。因此，如果您的应用程序在从 1.0 升级到 2.0 后开始出现问题，您可以 "upgrade" 将其恢复到 1.0！事实上，您可以 "upgrade" 应用程序实例在其应用程序类型的任意多个不同版本之间！而且您不需要像在交换环境中那样拥有所有应用程序版本 运行 的 个实例 ，您只需注册不同的版本和一个应用程序实例可以 "upgrade" 版本之间。
我提到了有状态服务的注意事项。对于有状态服务，需要记住的重要一点是应用程序状态——您的用户数据——包含在应用程序实例 (fabric:/FooApp) 中，因此为了让您的用户看到他们的数据，您需要将他们保存在该实例上。这就是我们进行滚动升级而不是部署交换的原因。
这只是基本思路。根据您的目标和应用程序的工作方式，您可以通过其他方式尝试应用程序类型、版本和实例，但那是以后的事了。