HATEOAS和Microservices
我很难理解HATEOAS和Microservices是如何共存的。
让我们举一个例子：
假设我们有购物车资源。我们需要将产品的快照放入其中，例如产品Id、产品价格、添加到购物车中时当前价格的快照，以及可能的其他值。实际的用例并不相关，只是为了了解手头的问题。
当我在前面做HATEOAS时，我会在购物车资源中放一个链接到产品，或者一个链接到特定产品的模板url。
这样，客户端仍然可以不了解资源URL。
但是在微观服务世界中，一个服务应该对其他服务一无所知。AFAIK。
那他们怎么能一起工作呢？
我对微服务的理解是，它们不能连接到除自身之外的任何东西，这基本上是一个Self链接。
我在其他地方发现了同样的问题，比如zFc
其中使用了像“宏服务”这样的解决方案，将所有这些都编织在一起。这似乎不是解决问题的一个干净的方法。
编辑
我找到了一些关于这个主题的更好的信息：https://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress
这似乎很好，有一些工具用链接来估算资源，但这让我想到，决定一个资源应该拥有哪些链接的逻辑在哪里？在公开资源的服务中？在中央服务登记处？
回答 2
Stack Overflow用户
发布于 2015-03-27 16:34:06
但是在微观服务世界中，一个服务应该对其他服务一无所知。AFAIK。
我想这就是你困惑的根源。我的理解是，为了软件开发的目的，服务不应该依赖于的带外信息与其他服务进行通信。这意味着一个服务不应该知道它的对等服务器的内部结构，但是说它不应该了解其他服务是没有任何意义的。这与美洲组织并无冲突，事实上，它们是相辅相成的。
链接到其他服务没有问题。否则，您将如何从微服务构建宏服务？依赖带外信息是有问题的。
Stack Overflow用户
发布于 2017-01-24 13:29:01
服务的中介、编排和编排不仅限于SOA，还同样适用于Microservices体系结构。
这意味着，微服务可以与其他微服务进行通信以传递或获取一些信息。例如，一个微服务也需要依赖于容器堆栈中的有状态数据存储。因此它需要知道(RESTFull)数据库的API/接口。
HATEOAS主要提供接口和通信设计模式，因此您可以不使用诸如WSDL或Swagger之类的固定接口定义语言。
诚然，REST (HTTP)已经成为最著名的，它有时被认为是理所当然的，即微服务将充当REST，但事实并非如此。
微服务的美妙之处在于，它们不会限制你使用一两种通信模式，它是独立的。没有标准。
例如，反应性微服务强调使用消息驱动的通信模式，使位置变得透明。但这并不意味着不知道要传递或检索的其他微服务的谓词&有效载荷。
同样，我们可以将基于HATEOAS的通信模式内置到我们的微服务体系结构中，以便为不断变化/升级的微服务接口提供完全的灵活性。但总的来说，您需要知道要与之通信的微服务的位置。因此，微服务中存在服务发现和服务注册模式，它们同样适用于HATEOAS体系结构。根据负载的不同，我们的微服务容器可以生存和死亡(缩小和减少)；我们的客户经常需要知道要消费的微服务的活动位置。
https://stackoverflow.com/questions/29303048
复制相似问题
腾讯云开发者
