【问题标题】:Versioning services版本控制服务
【发布时间】:2016-02-20 05:48:34
【问题描述】:

我们正在尝试使用 MS 的 ServiceFabric 来做微服务。

场景: 我们有一个 Service1 正在运行 version1 并准备升级到 v2。

其他三个服务依赖于Service1的接口。我们希望能够发布 Service1 的 v2,但保持 v1 运行,直到我们针对 v2 升级和测试这三个服务。

我找到的所有示例,v2 立即替换了 v1。这个可以配置吗?有没有办法告诉服务发现机制我依赖给定服务的特定版本?

【问题讨论】:

    标签: microservices azure-service-fabric


    【解决方案1】:

    正如您所提到的,应用程序升级工作流程将 v1 替换为 v2。但是,如果您希望 v1 和 v2 共存一段时间(以允许您进行测试、逐步将一些用户引导到新版本等),您可以通过稍微复杂的工作流程来实现这一点:

    1. 使用版本 v2 提供并创建一个新的服务实例。
    2. 针对此实例执行测试 (v2)。
    3. 对测试感到满意后,将依赖服务指向新实例 (v2)。
    4. 一旦不再使用 v1 实例,请将其删除。

    这当然可能会给您带来额外的麻烦,因为您需要自己管理这个过程,处理您的依赖链等等。这就是权衡 - 如果您想更好地控制升级/推出过程,您必须自己处理更多细节。

    或者,您可以考虑建立一个“暂存”集群,您可以在其中部署和测试新版本的服务,而不会影响您的生产服务,并且只有在阶段验证后才将部署部署到您的生产集群.我们的一些客户选择了这条路线,因为它使部署和验证工作流程更加简单,但需要花费额外的资源。

    【讨论】:

    • 这似乎有点冒险,因为它是手动的——我们必须在每次升级服务时给它一个新名称——而且忘记它的风险太高了。编辑:哦 - 这会引起连锁反应 - 其他服务将依赖于三个更新的服务等等......
    • 确实,您需要的控制越多,依赖链越复杂,您的运维问题就会越大。我相信最简单(尽管最昂贵)的模型是拥有多个集群,在新部署得到完全验证之前,您的生产服务不会受到影响。正如我在答案中添加的那样,一些客户使用临时集群来验证他们在与生产非常相似的环境中的部署。大型团队通常还会使用额外的测试集群,为他们的暂存过程添加多个级别(随着稳定性级别的提高)。
    • @Goblin 对于这些情况,我们正在做的是在我们的服务 url 中注入版本名称,例如 service/v1/blabla。服务/v2/blabla。在我们发布 v2 之后,我们正在计划 service-v1 的日落。在那之前,我们一直在保持这两项服务。我们正在监控 service-v1 的使用情况,并进行必要的提醒并关闭 v1。我不确定您提供什么样的服务以及有多少不同的客户在使用您的服务,但如果您需要向后兼容和平稳过渡,这似乎是唯一的方法。
    • @cool 这正是我们想要的 :-) 您是否在同一个代码库中托管这两个版本?我们正在考虑做不可变的服务,但就我在服务结构中所能想到的而言,这并不是一个真正的选择
    • @Goblin 好吧,我对 ServiceFabric 一无所知。但是是的,我们将两个版本都托管在同一个代码库中。
    猜你喜欢
    • 2010-09-21
    • 2017-01-21
    • 1970-01-01
    • 2023-03-16
    • 2021-02-06
    • 1970-01-01
    • 2016-01-17
    • 2013-01-06
    • 1970-01-01
    相关资源
    最近更新 更多