Question

开始：我尝试过Loopback。 Loopback很不错，但不允许跨多个REST数据服务的关系，而是调用初始数据服务并传递请求它执行连接查询的查询参数。

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

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

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

从这篇文章：

实现连接现在位于多个数据库中的数据的查询   很有挑战性。有各种解决方案：



应用程序端连接 - 应用程序执行连接而不是   数据库。例如，服务（或API网关）可以   首先检索客户，检索客户及其订单   从客户服务，然后查询订单服务   返回客户最近的订单。



命令查询责任分离（CQRS） - 维护一个或多个   包含来自多个服务的数据的物化视图。观点   由订阅每个服务的事件的服务保留   在更新数据时发布。例如，在线商店   可以实现查找特定区域中的客户的查询   和他们最近的订单，保持一个加入客户和   命令。该视图由订阅客户的服务更新   并订购活动。

实施例

我有2个数据微服务：

GET / pets - 返回类似

的对象

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

和一个完全不同的微服务......

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

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

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

我希望能够为宠物建立一个模型，这样当我查询宠物时，一旦GET /宠物成功回复，它就会加入＆＃34;与所有者（发送所有回复的GET /所有者/ {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服务），并将传入的外部请求转换为内部系统请求（不同的头/请求者有效负载数据），并将代理格式化的请求转发给任何其他工作的服务，接收它们，关注封装错误，并以适当的外部形式呈现每个响应。

另一点，如果应用程序核心流程（验证/范围等）所需的两个模型之间存在大量连接，那么您可能应该重新考虑您的模型/服务绑定到哪个Business Domain。如果它是相同的BD也许他们应该在一起。 Domain-Driven-Design的原则帮助我了解微服务之间真正的界限。

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

这样的服务应该能够从配置json中生成与预期输出模式的正确连接 - 就像回送模型一样（这就是我在相同的情况下所做的）。一旦完成抽象，使用任何复杂的连接构建/添加任何equery都非常简单。它很干净，很容易推理。此外，它是DBA友好的。对我来说，这种方法迄今为止运作良好。

应用程序端加入ORM for Node？

1 个答案: