如何发布微服务？

Question

这个问题更多的是和CICD的实践和基础架构联系在一起。在我们遵循的发布中，我们将一组微服务docker镜像标签作为一个单一的发布，并做CICD流水线，将该version.yaml推广到staging和production--说是一种mono-release模式。这样做的问题是，在某一点上，我们需要序列化，其他的变化必须等待，直到一个mono-release被测试和标记为下一阶段的准备。此处.

另一个选择是微发布策略，即每个微服务通过CICD管道并行发布到生产中。但这是否意味着有多少个管道就有多少个微服务？一个替代方案可能有一个单一的管道，但平行的测试用例和一个轮询CD--有点像GitOps的方式，它采取最新的生产标记的Docker图像。

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

Answer 1

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

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

另一种选择是微发布策略，即每个微服务通过CICD管道并行发布到生产中。但这样一来，会不会意味着有多少微服务就有多少流水线？

在一些工具中，你有一个参数化的流水线，根据接收到的参数来构建项目，这是可以的，但我认为最好的解决方案是每个服务有一个流水线，还有一些参数化的流水线来部署，或者应用特定的测试，归档资产等等。就像你说的 微释放策略

Answer 2

同意，外面关于这方面的信息很少。据我了解，每个服务保持一个管道的做法听起来很合理。随着微服务数量的增加，你会遇到几个问题。

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

这里的关键很可能是你更好地利用参数化的环境变量，然后以有效的方式寻找版本。这将允许你以一种有效的方式跟踪变化。为了实现这一点，请确保a.）严格参数化容器配置和代码中的所有变量，b.）以允许你在运行时注入的方式组织配置变量。这是一块内容 我发现对我的a.)点很有帮助；至于b.)点，这就有点棘手了。因为看起来你使用的是Kubernetes，所以你可能只想选择像 helm-charts这样的东西。问题是你如何架构你的配置文件，你有两个选择。

• 使用像Kustomize这样的东西，这是一个配置管理工具，将允许你在一定程度上按照GitOps的方法进行版本管理。这样做（在我的偏见看来）有不少缺陷。Git终究不是用来进行配置管理的，如果你处理了那么多的服务，就很难跟踪变化，建立差异，识别相关的历史。
• 你使用的是持续交付API（我在一家公司工作，所以请确保你充分质疑这一点）。CDAPIs连接到你的所有系统（CI管道、集群、镜像注册表、外部资源（DB、文件存储）、内部资源（弹性、redis）等。它们在运行时动态地注入环境变量，并在每次部署时创建清单。它们将这些变量缓存为所谓的 "部署集"。部署集是环境在部署时的状态表示。这种方法有几个优点。它允许你共享，版本，差异和重新启动任何状态 任何服务和应用程序在任何给定的时间点。它提供了一个非常清晰和防弹的审计设置中的任何东西。QA环境或测试功能环境可以通过API或UI来实现全功能回归和集成测试。