你如何发布微服务？

Question

这个问题更多地与 CI/CD 实践和基础架构相关。在我们遵循的版本中，我们将一组微服务 docker 镜像标签组合为一个版本，并执行 CI/CD 管道并将该 version.yaml 推广到登台和生产 - 比如说一种 Mono-release 模式。这样做的问题是，在某一时刻我们需要序列化并且其他更改必须等待，直到一个单一版本经过测试并标记为准备好进入下一阶段。关于此here 的更多描述。

另一种选择是微发布策略，其中每个微服务通过 CI/CD 管道通过生产并行发布。但这是否意味着管道的数量与微服务的数量一样多？替代方案可能有一个管道，但并行测试用例和轮询 CD - 有点像 GitOps 方式，它采用最新的生产标记 Docker 图像。

关于 MS 发布方式的信息似乎很少。大多数人都在谈论接口级别或 API 级别的版本控制和发布，这并不是我真正想要的。

Answer 1

同意，关于这方面的信息很少。据我所知，为每个服务保留一个管道的方法听起来很合理。随着微服务数量的增加，您将遇到几个问题：

• 如何跟踪配置的变化
• 如何使用回归和集成测试有效地测试服务
• 如何有效地设置环境

这里的关键很可能是您更好地利用参数化环境变量，然后以有效的方式查看版本。这将使您能够以有效的方式跟踪更改。要实现这一点，请确保 a.) 严格参数化容器配置和代码中的所有变量，以及 b.) 以允许您在运行时注入它们的方式组织配置变量。 This is a piece of content 对我的观点很有帮助。）； 至于b点。）这有点棘手。看起来你正在使用 Kubernetes，所以你可能只想选择像 helm-charts 这样的东西。问题是你如何构建你的配置文件，你有两个选择：

• 使用 Kustomize 之类的工具，这是一种配置管理工具，可让您按照 GitOps 方法在一定程度上进行版本控制。这（在我的偏见中）有很多缺陷。 Git 最终不是用于配置管理，如果您处理大量服务，则很难跟踪更改、构建差异、识别相关历史记录。
• 您使用的是持续交付 API（我使用的是持续交付 API，因此请确保您对此提出了充分的质疑）。 CDAPI 连接到您的所有系统（CI 管道、集群、映像注册表、外部资源（数据库、文件存储）、内部资源（弹性、redis）等。它们在运行时动态注入环境变量并在每次部署时创建清单。他们将这些缓存为所谓的“部署集”。部署集是部署时环境状态的表示。这种方法有几个优点：它允许您共享、版本、差异和重新启动任何服务和应用程序的任何状态在任何给定的时间点。它提供了一个非常清晰和防弹的审计 auf 任何设置。QA 环境或测试功能环境可以通过 API 或 UI 进行旋转，允许功能齐全的回归和集成测试。李>

Answer 2

假设您的组织正在开发微服务架构中的服务并部署在 Kubernetes 集群中，您必须使用一些 CD 工具（持续交付工具）来发布新的微服务服务，甚至更新微服务。

看看像 Jenkins (https://www.jenkins.io)、DroneIO (https://drone.io) 这样的工具...一些组织使用 Python 脚本或 Go 等等...我个人不喜欢这种方法，我认为最好的解决方案是从持续集成和交付组的 CNCF Landscape (https://landscape.cncf.io/zoom=150) 中选择一个工具，这些工具是经过市场测试和使用的。

另一种选择是微发布策略，其中每个微服务通过 CI/CD 管道通过生产并行发布。但这是否意味着管道的数量与微服务的数量一样多？

在某些工具中，您可以使用参数化管道，根据接收到的参数构建项目，但我认为最好的解决方案是每个服务都有一个管道，以及一些参数化管道来部署或应用特定测试、存档资产和等等...就像你说的微发布策略