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

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

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

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