0

我正在打开这个主题，寻找解决/帮助以下问题的建议：

  • 我目前正在与其他人合作开发一个使用云计算的微服务架构项目。
  • 有 6 种不同的微服务，并且有一些微服务不兼容，因此无法在同一台机器上实例化。
  • 每个微服务都有一个版本号。
  • 为了启动任何微服务的一个或多个新实例，我们必须通过静态配置定义哪些微服务将在这台新机器上运行。
  • 这种静态配置，我们称之为“部署”，包含正在部署的微服务，以及每个微服务的版本。（例如：(XY,[(X,v1),(Y,v2)]) - X 和 Y 是微服务，XY 部署实例化 X 的版本 1 和 Y 的版本 2）
  • 这些“部署”也有自己的版本号。在部署中更改微服务的版本号需要更改包含该微服务的任何“部署”的版本。（例如：(XY,v1,[(X,v1),(Y,v2)]) 和 (XY,v2,[(X,v1),(Y,v3)]))

问题是：什么是正确的，或者至少是一个好的术语来指代这个我之前称之为“部署”的实体？

许多开发人员围绕我们的架构编写程序并为此类实体使用不同的名称，这导致我们团队内部的语法和语义不兼容。

在这些不同的名称中，都有优点和缺点：

  • deploy：很有意义，因为您正在部署列表中的所有微服务。但是，术语部署已经指定了我们流程的另一部分，并且可能会过度使用同一术语。（部署 XY deploy 将在一台机器上部署微服务 X 和 Y）
  • 集群：一组东西的好名字，但是你可以从一个配置中部署多台机器，集群这个术语已经适用于这组机器。
  • 服务：服务将是一组微服务。有道理，但许多代码将微服务称为“服务”，这可能会导致混淆。（def get_version(service) - 他说的是服务还是微服务？）

你们中的任何人都可以就这个问题给我们任何意见或启示吗？谢谢！

4

3 回答 3

1

听起来你想要一个合适的集体名词。我建议你谷歌“集体名词”，找到很多列表。阅读一些列表并选择一个您认为合适的名词。

或者，如果微服务实例化集合的定义特征之一是它们相互补充或相互合作，那么术语合作（或简称合作）可能是合适的。

于 2015-09-13T12:45:42.913 回答
1

您可能会从 12-factor App 中获得提示，并将它们称为发布 ( http://12factor.net/build-release-run )

然后，您部署版本化版本。

于 2015-09-13T14:06:26.210 回答
0

我使用了“复杂”一词（如“抵押风险”复杂与“合规”复杂）。这似乎很明确。

人们还在项目中使用该术语来表示已部署的微服务集（例如，生产综合体与测试综合体）。

于 2019-04-02T18:37:48.317 回答