0

我有 3 个安静的服务（ServiceA、ServiceB 和 ServiceC），它们处理 2 个资源（ResourceA 和 ResourceB）。资源的媒体类型为application/hal+json。

  • ServiceA生成ResourceA；
  • ServiceB消费ResourceA，产生ResourceB；
  • ServiceC 通过从 ServiceA 获取 ResourceA 并将其发布到 ServiceB 来协调 ResourceB 的生产。

我基本上看到了两种组织这种互动的方法。

  1. ServiceC 作为 ResourceA 直接中介

    • ServiceC 从 ServiceA 获取完整的 ResourceA
    • ServiceC 将其发布到 ServiceB
    • 服务 B 返回资源 B

  2. ServiceC 作为 ResourceA 间接中介

    • ServiceC 仅在 ServiceA 上获取到 ResourceA 的链接（例如，通过 ResourceA 创建时的 Content Location 标头）
    • ServiceC 将此链接发布到 ServiceB（使用 HAL 媒体类型的链接 rel）
    • ServiceB 直接从 ServiceA 获取完整的 ResourceA
    • 服务 B 返回资源 B

第一种方法似乎是“经典”方法，而第二种方法会更便宜，因为只有一个完整的 ResourceA 传输（ServiceA -> ServiceB）而不是两个（ServiceA -> ServiceC -> ServiceB）。理想情况下，对于足够大的 ResourceA，第二种方法会更好。

使用第二种方法有什么问题吗？这被认为是“反模式”还是在某种程度上不安全/不值得推荐？有更好的交互模式吗？

4

1 回答 1

0

You can use any approach. In second approach you need to be sure that ServiceA is accessible from ServiceB. If it is accessible, then actually I am not able to guess reason why we need altogether separate service i.e. ServiceC for co-ordination. ServiceB can directly subscribe to events in ServiceA. If you are planning to use some kind of polling then would suggest to have a look at http://resthooks.org/ which will reduce network calls as well as improve server performance.

于 2015-06-30T06:12:41.880 回答