10

我在看到 HATEOAS 和微服务如何共存时遇到了一些严重的问题。

举个例子：

假设我们有一个购物车资源。并且我们需要将产品的快照放入其中，例如产品ID，产品价格；将商品添加到购物车时的当前价格快照，可能还有其他一些值。实际用例无关紧要，只是为了对手头的问题有所了解。

当我之前一直在做 HATEOAS 时，我会在购物车资源中放置一个链接到产品的链接或链接到特定产品的模板 url。

这样，客户端仍然可以不知道资源 URL。

但是在微服务世界中，一个服务不应该知道其他服务。AFAIK。

那么他们两个怎么可能一起工作呢？

我对微服务的解释是它们永远不能链接到除了它们自己之外的任何东西，这几乎就是一个Self链接。

我在其他地方发现了同样的问题，例如 https://groups.google.com/forum/#!topic/api-craft/YRkLFVY_zFc

使用诸如“宏服务”之类的解决方案将所有这些结合在一起。这似乎不是解决问题的干净方法。

[编辑]

我发现了一些关于这个主题的更好的信息： https ://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress

有一些工具通过链接来增强资源似乎很好，但这让我想，决定资源应该属于哪些链接的逻辑在哪里？在暴露资源的服务中？在中央服务注册表中？

4

2 回答 2

10

但是在微服务世界中，一个服务不应该知道其他服务。AFAIK。

我认为这是你困惑的根源。我的理解是，出于软件开发的目的，服务不应依赖带外信息与其他服务进行通信。这意味着一个服务不应该知道任何关于其对等点的内部信息，但是说它不应该知道其他服务是没有任何意义的。这与 HATEOAS 并不冲突，实际上它们是相辅相成的。

链接到其他服务没有问题。否则您将如何从微服务构建宏服务？为此依赖带外信息存在问题。

于 2015-03-27T16:34:06.523 回答
1

服务的中介、编排和编排不仅限于 SOA，还同样适用于微服务架构。

这意味着微服务可以与其他微服务通信以传递或获取一些信息。例如，微服务也需要依赖容器堆栈中的有状态数据存储。所以它需要知道（RESTFull）数据库的 API/接口。

HATEOAS 主要提供接口和通信设计模式，因此您可以摆脱固定接口定义语言，如 WSDL 或 Swagger。

虽然 REST (HTTP) 确实已经成为最著名的，但有时人们认为微服务将用作 REST API 是理所当然的，但事实并非如此。

微服务的美妙之处在于它们不会将您限制在一种或两种通信模式中，它是独立的。没有标准。

例如，反应式微服务强调使用消息驱动的通信模式并变得彼此位置透明。但这并不意味着不知道要传递或检索的其他微服务的动词和有效负载。

同样，我们可以将基于 HATEOAS 的通信模式内置到我们的微服务架构中，以便完全灵活地适应不断变化/升级的微服务接口。但总的来说，您仍然需要知道要与之通信的微服务的位置。因此，服务发现和服务注册模式存在于微服务领域；它们同样适用于 HATEOAS 架构。根据负载，我们的微服务容器可以在哪里生存和死亡（横向扩展和缩减）；我们的客户经常需要知道要使用的微服务的活动位置。

于 2017-01-24T13:29:01.687 回答