指定一组微服务的好/正确术语是什么？

Question

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

• 我目前正在与其他人一起使用云服务进行微服务架构的项目。
• 有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部署将在机器中部署微服务X和Y）
• cluster：一组内容的良好名称，但您可以从配置部署多台计算机，术语集群已应用于此组计算机。
• 服务：服务是一组微服务。有道理，但许多代码将微服务称为“服务”，这可能会导致混淆。 （def get_version（service） - 他在谈论服务还是微服务？）

你们有没有人能就这个问题给我们任何意见或启示？谢谢！

Answer 1

您可以从12因素应用程序中获取提示，并将其称为发布（http://12factor.net/build-release-run）

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

Answer 2

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

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

Answer 3

我使用了“复杂”一词（如“抵押贷款风险”复杂与“合规”复杂）。这似乎毫不含糊。

人们还在项目中使用了部署的微服务集（例如生产复合体与测试复合体）。