API 网关上的数据聚合

Question

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

例如，Frontend 调用 API Gateway，API Gateway 调用两个微服务 Customer 和 Order 微服务。客户微服务 returns 客户详细信息和订单微服务 returns 所有客户订购的产品。

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

格式 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 实现，但数据合并是基于 Gateway 上的 ID，需要一些处理。

使用业务逻辑在 Gateway 上聚合数据是一种好做法吗？如果不是，这种聚合应该遵循什么做法？

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

Answer 1

这被称为API composition or Backend for Frontend。我会说使用 API 网关聚合数据很好，因为它允许您的 API 客户端使用更简单的 API 界面。实际映射将在 API 网关中完成。

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

关于如何在 Azure 中实现它的参考是 API Aggregation Using Azure API Management。

Answer 2

@Seth 清楚地回答了问题。有两种方法可以实现第二个格式，简单的和复杂的。

注意：由于您在 API 网关中尝试过，所以您似乎想为客户端准备格式。

Api.Gateway 聚合（简单的）：您可以获得第一种格式并在客户端应用程序中对其进行修改，以便获得所需的数据格式。以这种方式，您的架构保持简单，因为在您的服务区和客户端之间只有一个人。
聚合根（复数）：如@Seth 所述

dedicated microservice that aggregates the datasets from the other microservices and expose a single API

所以它是 n 个服务，它与一组服务通信并收集数据集，在那里您可以通过某些调用形成所需的数据格式。在您的情况下 API 网关与聚合根通信。使这种方法变得复杂的原因是，当聚合根发挥作用时，它们的责任不仅仅是格式化数据。在领域驱动设计的视野中，它们就像特定业务环境的 HEADQUARTERS，并且有它们的边界和子域需要管理。在这种情况下，聚合根还负责不同业务上下文之间的微服务相互通信，并且不仅充当 api 网关的大门并为外部客户端做事，而且在某些情况下他们也有自己的数据库。

结论： 因此，如果您想使用聚合根模式，那么您可能会推动您的系统遵循其文化（您可以添加聚合器以便仅格式化数据而不应用它的复杂文化并将其用作您之间的桥梁非常后端服务和前端用户，它可以制作场景。)。这使它变得复杂，但是我认为对于更大的微服务生态系统聚合根是必须的。但如果你只是处理格式化数据，我建议坚持第一种方法。

API 网关上的数据聚合

Aggregation of data on API Gateway

microservices

aws-api-gateway

azure-api-management

api-gateway

ocelot