Question

将另一个文档中的数据嵌入另一个集合中时，关于谁应该负责在微服务体系结构中填充该数据的最佳实践是什么？

作为一个例子，假设我具有有关组织的基本信息：

{
  "id" : 1,
  "legalName": "Initech"
}

我希望将其嵌入这样的发票中，以避免进行两次服务请求以显示发票：

{
      "type": "Payable",
      "invoiceStatus": "Preparing Preliminary Version",
      "applicablePeriod": {
        "startDateTime": "2020-07-08T00:10:59.618Z",
        "endDateTime": "2020-07-08T00:10:59.618Z"
      },
      "issuedDateTime": "2020-07-08T00:10:59.618Z"
      "issuingOrganization":{
             "id": 1,
             "legalName": "Initech"
       }
}

在创建/更新发票时提供数据是呼叫者的责任，还是发票服务会使用组织ID检索外部数据，然后根据需要嵌入数据？

我觉得我应该尽可能避免后端具有跨服务依赖性。我知道可以通过更改Feed来维护嵌入式数据，但是我想知道嵌入式数据的初始填充量。

Answer 1

您是否得到了答案？至少我想提供一个答案作为一般指导。它归结为数据状态。请参阅以下文档，其中更详细地介绍了此特定主题：Data modeling in Azure Cosmos DB

通常，在（{{3）}时使用嵌入式数据模型：

实体之间存在包含的关系。

实体之间存在一对关系。

有些嵌入式数据很少更改。

有些嵌入式数据不会无限制。

其中的嵌入数据经常一起查询。

在许多情况下，嵌入数据都可以很好地工作，但是在某些情况下，对数据进行非规范化将导致更多的问题，而不是值得的。那我们现在该怎么办？

何时引用（link）：

通常，在以下情况下使用归一化数据模型：

表示一对多关系。

表示多对多关系。

相关数据经常更改。

参考数据可能无界。

混合数据模型（link）。

我们现在已经看到了嵌入（或非规范化）和引用（或规范化）数据，正如我们所看到的，每种方法都有其自身的优势，并且都有各自的折衷。

并不一定非要如此，不要害怕把事情混在一起。

根据您应用程序的特定使用模式和工作负载，在某些情况下，混合嵌入式数据和参考数据是有意义的，并可能导致应用程序逻辑更简单，服务器往返次数更少，同时仍保持良好的性能水平。

因此，使用上述数据模型信息，等式的另一半是link和Identifying microservice boundaries，但在更简单的情况下，发票服务将执行designing a microservices architecture （通过嵌入发票或链接发票）。

将来自另一个文档的数据嵌入Cosmos DB中

1 个答案: