node.js - 应用程序端加入 Node 的 ORM？

Question

首先:我尝试过 Loopback。环回很好，但不允许跨多个 REST 数据服务建立关系，而是调用初始数据服务并传递要求其执行联接查询的查询参数。

在我重新发明轮子并围绕 Loopback 的 Loopback-rest-connector 编写一个巨大的包装器之前，我需要找出是否有任何现有的库或框架已经解决了这个问题。到目前为止，我广泛的谷歌搜索一无所获。

在真正的微服务环境中，每个数据库都有一个服务。

http://microservices.io/patterns/data/database-per-service.html

摘自这篇文章:

Implementing queries that join data that is now in multiple databases is challenging. There are various solutions:

• Application-side joins - the application performs the join rather than the database. For example, a service (or the API gateway) could retrieve a customer and their orders by first retrieving the customer from the customer service and then querying the order service to return the customer’s most recent orders.

• Command Query Responsibility Segregation (CQRS) - maintain one or more materialized views that contain data from multiple services. The views are kept by services that subscribe to events that each services publishes when it updates its data. For example, the online store could implement a query that finds customers in a particular region and their recent orders by maintaining a view that joins customers and orders. The view is updated by a service that subscribes to customer and order events.

示例:

我有 2 个数据微服务:

GET/pets - 返回类似的对象

{
   "name":"ugly",
   "type":"dog",
   "owner":"chris"
}

在完全不同的微服务上......

GET/owners/{OWNER_NAME} - 返回所有者信息

 {
    "owner":"chris",
    "address":"under a bridge",
    "phone":"123-456-7890"
 }

我有一个 API 级微服务，它将调用这两个数据服务。这是我将应用它的微服务。

我希望能够为 Pet 建立一个模型，这样当我查询 pet 时，在 GET/pets 成功响应后，它将与所有者“加入”(发送 GET/owners/{OWNERS_NAME}对于所有响应)，并且只需向用户返回包含其主人数据的宠物列表即可。

所以 GET/pets (也许类似 Pets.find() 的东西)会返回

{
  "name":"ugly",
  "type":"dog",
  "owner": "chris",
  "address": "under a bridge",
  "phone": "123-456-7890"
}

Answer 1

在 API 网关上应用任何模型/域逻辑都是错误的决定，并且被认为是错误的做法。 API网关应该只执行系统的CAS(依赖于保存逻辑的Auth服务)，并将传入的外部请求转换为内部系统请求(不同的 header /请求者有效负载数据)，并将格式化的请求代理到服务以进行任何其他工作，接收它们，关心封装错误，并以适当的外部形式呈现每个响应。

另一点，如果应用程序核心流程(验证/范围界定等)所需的两个模型之间存在大量联接，那么也许您应该重新考虑您的模型/服务绑定(bind)到哪个业务域。如果是同一个BD也许他们应该在一起。领域驱动设计的原则帮助我理解微服务之间的真正边界在哪里。

如果您使用环回(就像我们一样，并面临与我们面临的相同问题 - 环回没有正确的连接实现)，您可以拥有单独的报告/组合数据服务，它是唯一一个可以访问所有服务数据库的服务，并且它仅用于读取目的 - 即查询。为其提供单独设置的对数据库的只读广泛访问权限 - 而不是只设置一个数据源(单个数据库)，它应该能够读取此查询连接数据库用户范围内的所有数据库.

这样的服务应该能够从配置 json 中生成与预期输出模式的正确连接 - 就像环回模型(这就是我在相同情况下所做的)。一旦抽象完成，构建/添加具有任何复杂连接的任何 equery 就变得非常简单。它很干净，而且很容易推理。而且，它对 DBA 也很友好。对我来说，这种方法到目前为止效果很好。