微服务架构中的规范数据模型

Question

假设我有 2 个微服务（服务 A，服务 B），它们可以双向调用，假设如果 A 调用 B，那么 A 的响应 json 的一些参数将作为 B 的请求参数的一些其他参数使用

现在我意识到，这个问题可以通过使用规范数据模型更好地解决，以便每个服务消费/产生一个规范数据模型，

我的问题是这种情况下的规范模型（json）应该是什么样子

假设 A 的响应看起来像

{
  "A1": false,
  "A2": {
    "width": 5,
    "height": 10
  },
  "A3": "A green door"
}

会有相应的 json 架构，这里我就不包括了

B 的类似请求看起来像

{
      "B1": false,
      "B2": {
        "width": 5,
        "height": 10
      },
      "B3": "A green door",
      "B4": ""
       .
       .

    }

属性 A1 映射到 B1，如果我的规范数据模型仅包含具有某个名称的第一个属性（业务名称：例如 -->A1 是分数 B1 -->报告然后业务名称可能是 --> 点）通常与这两个微服务相关，还是应该更多地是两个 json 的聚合，每个属性都替换为相应的业务名称？

Answer 1

理论上，设计良好的微服务架构不需要“传统”规范数据模型，因为每个服务都有其独特的责任域，并且只对来自其特定域的数据进行建模。因此，当一个服务使用其他服务时，数据重叠应该是最小的。当使用其他服务时，数据建模的责任在于源而不是消费者。

但在实践中可能并非总是如此，例如您必须从相似但不相同的来源中提取数据。所以对于您的问题 - 如果您发现需要将服务的数据转换为规范模型，您可能希望尽快执行转换为单个表示（您的第一个想法），而不是保留两种表示（您的第二个主意）。这将有助于进一步简化下游的消费（想象一下需要检查数据结构中多个位置的混乱消费代码）。如果服务在您的控制之下，您可能希望首先将它们发展为在规范模型中提供数据。