我目前正在使用Azure ServiceFabric上的ReliableActors框架来构建应用程序。随着规模的扩大，我正在考虑进行蓝色/绿色部署。我可以看到如何使用无状态系统来执行此操作。有没有办法使用有状态的参与者来做到这一点？
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）中，因此要让用户看到他们的数据，需要将其保留在该实例上。这就是为什么我们进行滚动升级而不是部署交换。
这只是基本思想。您还可以通过其他方法来处理应用程序类型，版本和实例，这取决于您的目标和应用程序的工作方式，但这是另一回事了。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句