多个微服务和数据库关联

Question

我有一个关于微服务和数据库的问题。我正在开发一个应用程序：用户可以看到国家列表，并可以通过单击它，查看该国家的景点列表。我创建了一个国家服务、一个包含oAuth2用户的认证服务和一个景点服务。每个服务都有自己的数据库。我通过iso代码（例如：BE=比利时）映射了景点和其所属国家之间的关联：/api/attraction/be。

上述方法似乎可行，但是我遇到了一些困难：用户必须能够将景点添加到他/她的收藏夹中，但由于我有很多不同的数据库，我不知道如何实现这一点。

我应该创建一个收藏夹服务吗？我是否应该传递ID（我认为不应该这样做）？我可以创建什么样的业务键？如何正确地关联数据...？

提前感谢您！

- Jdruwe

Answer 1

根据您提供的信息，使用独立的收藏夹服务似乎是正确的选择。

其次，更简单和快速的选项可能是在用户服务中处理此事情，该服务负责用户数据的持久性，因为收藏是专属于用户实体的。

至于ID，我没有看到有很多理由认为这可能是一个坏主意？你的各个服务都需要存储一些标识相关数据的值，我认为主要问题在于保持这个ID字段跨不同服务的一致性。您选择的内容只需要可靠和可预测，以便在系统增长时保持简单易用即可。

- Ian Belcher

---

我在想，使用id可能不太好，因为尽管它们不应该改变，但它们有可能会改变，比如迁移到另一个数据库... - Jdruwe

是的，这是一个非常好的观点。我想这是一个管理额外工作量与发生风险之间的权衡问题。 - Ian Belcher

问题是，如果我将其存储在特定的收藏夹数据库中，如何引用用户而不指定用户ID？也许使用用户名？ - Jdruwe

关于ID，您可以使用客户端创建的GUID，并将该GUID附加到状态更改操作中，这样您就不会在跨微服务引用标识时遇到任何问题，明白吗？ - Sean Farmar

那么，当我创建一个实体（例如国家）时，我也应该为这个实体持久化一个GUID吗？ - Jdruwe

Answer 2

如果您正在使用RESTful HTTP，那么您已经拥有了一种持久的、可标记的资源标识符URL（如果您想要严谨一些，可以使用IRI）。这些是您可以用来引用其他微服务中某个实体的ID。

没有必要引入另一层ID，无论是国家代码还是数据库ID。这些东西在您的微服务内部，对于所有客户端（包括其他微服务）都应该是透明的。

明确一下，我是说，您可以将国家的URI存储在景点服务中。那个URI本来就不应该改变（尽管如果您收到永久重定向，您可能需要准备更改它），而且您必须记住那个URI，才能将其包含在景点表示中。

您实际上也不需要任何“业务键”来收藏，除了景点的URI。您可以像在浏览器中一样收藏那个URI。

我想象如果有一个认证服务，那么也会有用于识别个人用户的URI。因此，在“收藏夹”服务中，您可以将用户URI与景点URI简单地链接起来。

- Robert Bräutigam

---

我不太确定你的意思，请举个例子好吗？ - Jdruwe

我的意思是用户的“key”是http://auth.mycompany.com/user/123，而景点是http://attraction.mycompany.com/attraction/654。在“收藏夹”服务中，您可以简单地关联这两个字符串，这样您就不必依赖于这些对象内部的任何内容。 - Robert Bräutigam

但是123和654不是内部数据库ID吗？ - Jdruwe

所以这样可以吗 /api/attractions/BE<名称的哈希值>? - Jdruwe

那么你的意思是我应该只使用一个数据库ID吗？ - Jdruwe