API网关上的数据聚合

Question

我正在研究微服务架构，我想聚合来自两个微服务的数据。

例如，前台调用API网关，API网关调用两个微服务客户和订单微服务。客户微服务返回客户详细信息，订单微服务按客户返回所有订购的产品。

这是API网关使用Ocelot或Azure API Management从两个微服务聚合后返回的格式。

格式1

{ 
   "Customers":[ 
      { 
         "customerId":1001,
         "customerName":"Tom"
      },
      { 
         "customerId":1002,
         "customerName":"Jerry"
      }
   ],
   "Orders":[ 
      { 
         "CustomerId":1001,
         "Orders":[ 
            { 
               "ProductId":"PRO1",
               "ProductName":"Books"
            },
            { 
               "ProductId":"PRO2",
               "ProductName":"Pens"
            }
         ]
      },
      { 
         "CustomerId":1002,
         "Orders":[ 
            { 
               "ProductId":"PRO3",
               "ProductName":"Pencils"
            },
            { 
               "ProductId":"PRO4",
               "ProductName":"Toys"
            }
         ]
      }
   ]
}

我想要的格式是格式 2。

格式2

{
   "OrderDetails":[
      {
         "customerId":1001,
         "customerName":"Tom",
         "Orders":[
            {
               "ProductId":"PRO1",
               "ProductName":"Books"
            },
            {
               "ProductId":"PRO2",
               "ProductName":"Pens"
            }
         ]
      },
      {
         "customerId":1002,
         "customerName":"Jerry",
         "Orders":[
            {
               "ProductId":"PRO3",
               "ProductName":"Pencils"
            },
            {
               "ProductId":"PRO4",
               "ProductName":"Toys"
            }
         ]
      }
   ]
}

第二种格式可以使用Ocelot实现，但数据的合并基于网关上的id，需要一些处理。

使用业务逻辑聚合网关上的数据是否是一种良好的做法。如果不是，这种聚合应该遵循哪些实践？

如果能提供一些使用 Azure API 管理实现此聚合的参考，那就太好了。

Answer 1

这被称为前端的API组合或后端。我想说使用API网关聚合数据很好，因为它允许您的API客户端使用更简单的API接口。实际映射将在API网关中完成。

然而，当您将多个微服务链接在一个Web API中时，一个服务的失败将导致整个Web API失败。另一种（更复杂的）解决方案是创建一个专用的微服务，该服务聚合来自其他微服务的数据集，并公开一个显示连接数据的API。请参见-CQRS模式。

关于如何在Azure中实现这一点的参考是使用Azure API管理的API聚合。