我目前正在Azure ServiceFabric上使用ReliableActors框架构建应用程序。随着我们的扩展，我正在考虑进行蓝/绿部署。我可以看到如何使用无状态系统来做到这一点。有没有办法使用有状态的演员？
答案 0 :(得分：30)
Service Fabric完全是关于滚动升级，而不是像VIP交换那样的部署交换。无状态和有状态服务都以同样的方式升级，但是有一些额外的细微差别，我稍后会提到。
通过滚动升级，我的意思是升级到应用程序，一次完成一个升级域，这样就没有停机时间，也没有突然切换。 Service Fabric中的滚动升级可以在安全的“托管”中完成。平台将在进入下一个升级域之前执行运行状况检查的模式，并在运行状况检查失败时自动回滚。
好的，听起来不错。但是，当升级总是滚动升级时，如何进行蓝/绿部署呢？
应用程序类型和版本的来源。而不是有两个＆＃34;环境＆＃34; Service Fabric可以容纳两个正在运行的应用程序，它具有版本化应用程序类型的概念，可以从中创建应用程序实例。以下是其工作原理的示例：
让我们说我想创建一个名为Foo的应用程序。 My Foo应用程序被定义为应用程序类型，称之为FooType。这类似于在C＃中定义一个类。和C＃中的类一样，我可以创建我的类型的实例。每个实例都有一个唯一的名称，类似于类的每个对象实例具有唯一的变量名称。但与C＃中的类不同，我的FooType有一个版本号。然后我就可以注册＆＃34;我的群集中的应用程序类型和版本：
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
在这里，它变得有趣。我可以做一些有趣的事情：
我可以采取＆＃34; fabric：/ FooApp＆＃34; - FooType 1.0的一个实例 - 并将其升级到FooType 2.0。这将是正在运行的应用程序的滚动升级。
或..我可以离开＆＃34; fabric：/ FooApp＆＃34;单独，并创建我的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实例和升级它转换为2.0的FooType。同样，这是该实例（结构：/ FooApp）的滚动升级，它不会将用户迁移到新实例（结构：/ FooAppv2Test）。稍后我会去删除fabric：/ FooAppv2Test，因为那只是为了测试。
蓝/绿的一个好处是，如果新的部署失败，可以换回其他部署。好吧，你仍然注册了1.0和2.0的FooType。因此，如果您的应用程序在从1.0升级到2.0后开始行为不端，您可以“升级”＃34;它回到了1.0！事实上，你可以升级＆＃34;应用程序实例之间的应用程序类型的多个不同版本！并且您不需要像在交换环境中那样运行所有应用程序版本的实例，只需注册不同的版本，并且可以使用单个应用程序实例。升级＆＃34;版本之间。
我提到了有状态服务的警告。有状态服务要记住的重要一点是应用程序状态 - 您的用户＆＃39; data - 包含在应用程序实例（fabric：/ FooApp）中，因此您的用户需要查看他们的数据才能将其保留在该实例上。这就是我们进行滚动升级而不是部署交换的原因。
这只是基本的想法。您可以通过其他方式使用应用程序类型，版本和实例，具体取决于您的目标和应用程序的工作方式，但这又是另一种方式。