【问题标题】:How to deploy multiple version of an application in production for microservice based application如何在生产环境中为基于微服务的应用程序部署多个版本的应用程序
【发布时间】:2017-10-22 19:44:29
【问题描述】:


是否可以同时在生产中部署多个版本的服务。根据我的假设,对于基于微服务/api 的项目或移动项目来说,这应该是非常常见的模式。我想知道您是如何做到的,以及针对此类问题的行业常见模式是什么。如果您的答案围绕 AWS 环境或 Kubernetes 环境,将会很有帮助。
提前致谢。

【问题讨论】:

    标签: api amazon-web-services amazon-elastic-beanstalk microservices production-environment


    【解决方案1】:

    假设您通过 HTTP REST API 公开服务,一般标准是始终将您的服务 URL 与版本作为基线。

    例如,

    /v1/account/getUserInfo
    

    如果您需要发布新版本,请将其公开:

    /v2/account/getUserInfo
    

    v2 可以在代码库的不同分支上运行。

    【讨论】:

      【解决方案2】:

      是否可以同时在生产环境中部署多个版本的服务

      是的,这是可能的。这个想法是同时保持所有使用微服务在生产中(v1,v2 ...),并降低不再使用的版本。为此,您应该知道某个版本何时不再使用。

      AFAIK,你必须选择:

      1. 对于每个新版本,您创建一个新端点(如 /v2/someApiCall)连接到相同(现已升级)的微服务,并逐渐指示客户端使用新端点;当不再使用旧端点时,您将其删除;这是首选方式。

      2. 对于每个新版本,您都会创建一个与旧微服务共享相同持久性的新微服务;您应该避免使用此解决方案; Netflix 在极少种情况下使用这种策略,因为更换老消费者的成本太高。

      您可以从Building microservices by Sam Newman 阅读第 62 页的更多信息。

      【讨论】:

      • 您能解释一下“与旧微服务共享相同持久性的新微服务”是什么意思...
      • 一种新的 v2 微服务,它作为一个单独的进程运行,具有新的 v2 源代码,但使用与旧版本相同的数据库实例。不建议这样做,因为一般不建议在微服务之间共享数据库。但是,如果要快速替换旧的微服务(v1),那么这可能是允许的。
      【解决方案3】:

      使用 AWS API Gateway,您可以部署多个版本的代码并通过映射模板在它们之间切换,如 here 所述。您可能还想查看stage variables

      【讨论】:

        【解决方案4】:

        我在博客上写过这个:Multi-version Service Discovery using Spring Cloud Netflix Eureka and Ribbon,但专注于Spring Cloud Netflix 组件/库。

        但想法是在新主机/VPS/容器中部署新版本的工件/二进制文件,并让服务注册到注册服务器(Eureka,Consul,...),并包含有关 API 的元数据它支持的版本(v1,v2,...)。客户端应用会发现哪个主机/容器/...服务于所需的 API 版本。

        【讨论】:

          猜你喜欢
          • 2018-03-06
          • 1970-01-01
          • 1970-01-01
          • 2023-04-01
          • 1970-01-01
          • 2016-12-03
          • 1970-01-01
          • 2017-12-18
          • 2020-09-23
          相关资源
          最近更新 更多