Azure ServiceFabric中的蓝/绿部署

14

我正在使用Azure ServiceFabric上的ReliableActors框架构建应用程序。随着我们的规模扩大,我正在研究蓝/绿部署。我可以看到如何在无状态系统中实现此操作。但是,在有状态演员的情况下是否有方法可以做到这一点?

1个回答

35

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版本的实例。通过一些端口和应用程序终点的配置,我可以确保用户仍然访问1.0版本的实例,同时测试2.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版本后开始出现问题,您只需将其“升级”回1.0版本即可!事实上,您可以在应用程序实例之间将应用程序实例“升级”为任意不同版本的应用程序类型!而且,您不需要像交换环境中那样运行所有应用程序版本的实例,您只需要注册不同版本并具有可以在版本之间“升级”的单个应用程序实例即可。
我提到了有关有状态服务的注意事项。需要记住的有状态服务的重要事情是应用程序状态 - 您的用户数据 - 包含在应用程序实例(fabric:/FooApp)中,因此为了让您的用户看到其数据,您需要将它们保留在该实例中。这就是为什么我们进行滚动升级而不是部署交换的原因。
这只是基本的想法。根据您的目标和应用程序的工作方式,您可以通过其他方式处理应用程序类型、版本和实例,但这是另一个时间的问题。

那很有帮助,谢谢Vaclav。在我看来,蓝/绿部署的好处之一是我可以通过负载均衡器将流量逐渐引导到第二个服务中,以确保其正常工作,然后再进行整个交换。在SF上是否有类似的验证方式? - shinybluesphere
1
对于无状态服务,您可以创建v1.0和v2.0的实例,并通过自己的路由将流量引导到v2.0,同时逐渐扩展v2.0并缩小v1.0。对于有状态服务,情况会稍微复杂一些,因为状态本身位于应用程序实例内部,所以如果您将用户发送到应用程序的新实例,则他们的数据将不在那里。这只是有状态事物的本质,这就是为什么Service Fabric具有非常强大的、一流的滚动升级功能。 - Vaclav Turecek
1
我认为滚动升级在某种程度上也可以被称为“逐步推进”,因为你的整个应用程序并不是一次性全部升级的。它是一次升级一个切片,如果在任何时候健康检查失败(你可以进行自定义健康检查),它将回滚。因此,您可以将其视为自动化的逐步推进部署,而我们确实喜欢自动化! - Vaclav Turecek
你好,这是一个有用的解释,但我想暂停一下关于“应用程序升级是在同一升级域中完成的,以便没有停机时间”的部分。它真的没有停机时间吗?也就是说,没有任何停机时间吗?因为根据我的测试,在升级域正在升级时,服务在升级域完成之前不会响应。 - itaysk
我认为更准确的表述应该是:实现无停机升级。当然,您可以通过多种方式自行引起停机,例如只有一个升级域的群集、只有一个副本的有状态服务、未正确解析服务地址的服务代码等。但除此之外,是的,在升级期间您的应用程序不应经历任何停机时间。 - Vaclav Turecek
1
两个版本的Web应用程序在同一集群上运行怎么样?我主要关心端口冲突,因为这些端口对于两个版本来说是相同的。 - Alex Pryiomka

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接