14

我目前正在使用 Azure ServiceFabric 上的 ReliableActors 框架构建应用程序。随着我们扩大规模，我正在考虑进行蓝/绿部署。我可以看到如何使用无状态系统来做到这一点。有没有办法使用有状态的演员来做到这一点？

4

1 回答 1

34

Service Fabric 完全是关于滚动升级，而不是部署交换，如 VIP 交换。无状态服务和有状态服务都以相同的方式升级，但有状态服务还有一些细微差别，我稍后会提到。

通过滚动升级，我的意思是对应用程序的升级是就地完成的，一次升级一个域，因此没有停机时间，也没有突然切换。Service Fabric 中的滚动升级可以在安全的“托管”模式下完成，平台将在进入下一个升级域之前执行运行状况检查，如果运行状况检查失败，将自动回滚。

好的，这一切听起来不错。但是当升级总是滚动升级时，你如何进行蓝/绿部署呢？

这就是应用程序类型和版本的用武之地。Service Fabric 没有两个“环境”可以容纳两个正在运行的应用程序，而是具有版本化应用程序类型的概念，可以从中创建应用程序实例。这是一个如何工作的示例：

假设我想创建一个名为 Foo 的应用程序。我的 Foo 应用程序被定义为一个应用程序类型，称之为 FooType。这类似于在 C# 中定义一个类。和 C# 中的类一样，我可以创建我的类型的实例。每个实例都有一个唯一的名称，类似于类的每个对象实例都有一个唯一的变量名。但与 C# 中的类不同，我的 FooType 有一个版本号。然后我可以在我的集群中“注册”应用程序类型和版本：

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 版应用程序的新实例：

"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 因为那只是为了测试。

蓝/绿的好处之一是，如果新部署失败，则能够切换回另一个部署。好吧，您仍然注册了 FooType 的 1.0 和 2.0。因此，如果您的应用程序在从 1.0 升级到 2.0 后开始出现异常行为，您可以将其“升级”回 1.0！事实上，您可以根据需要在其应用程序类型的多个不同版本之间“升级”应用程序实例！而且您不需要像在交换环境中那样运行所有应用程序版本的实例，您只需注册不同的版本和一个可以在版本之间“升级”的应用程序实例。

我提到了有状态服务的注意事项。使用有状态服务要记住的重要一点是，应用程序状态（用户的数据）包含在应用程序实例（fabric:/FooApp）中，因此为了让您的用户看到他们的数据，您需要将它们保存在该实例中。这就是我们进行滚动升级而不是部署交换的原因。

这只是基本的想法。根据您的目标和应用程序的工作方式，您还可以通过其他方式来处理应用程序类型、版本和实例，但那是另一回事了。

于 2016-03-09T01:20:18.943 回答