多个微服务和数据库关联

Question

我有一个关于微服务和数据库的问题。我正在开发一个应用程序：用户看到一个国家列表，可以点击它，这样他就可以看到该国家的景点列表。我创建了一个国家/地区服务，身份验证服务（包含oAuth2的用户）和一个景点服务。每个服务都有自己的数据库。我通过 iso code （例如：BE = belgium）绘制了景点与其国家之间的关联：/ api / attraction / 是。

上面的方法似乎有效但我对以下内容有点困惑：用户必须能够在他/她的收藏列表中添加一个吸引力，但我不知道这有多大可能因为我有这么多不同数据库。

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

提前致谢！

Answer 1

根据您提供的信息，使用独立的收藏服务听起来就像是正确的选项。

另一个更简单，更快捷的选项可能是在您的用户服务上处理此问题，该用户服务会查看用户数据的持久性，因为收藏夹是用户实体所独有的。

至于ID，我还没有看到很多理由说明为什么这可能是一个坏主意？您的个人服务需要为相关数据存储一些识别价值，我认为这里的主要问题只是保持这个ID字段在您的不同服务中保持一致。您选择的只需要可靠且可预测，以便在系统增长时保持简单易行。

Answer 2

如果您使用的是RESTful HTTP，那么您已经拥有了持久的，可收藏的资源标识， URL （如果您想要迂腐，则为URI，IRI）。这些是您可以用来引用另一个微服务中的某个实体的ID。

无需引入另一层ID，无论是国家/地区代码还是数据库ID。无论如何，这些内容都属于您的微服务，对所有客户都应该是透明的，包括其他微服务。

要说清楚，我说，您可以将 URI 存储在景点服务中的国家/地区。无论如何， URI 都不应该更改（尽管您可能希望在收到永久重定向时准备更改它），但无论如何您必须回想起 URI ，才能够将它包含在吸引力表示中。

除了景点的 URI 之外，您对收藏夹并不需要任何“商家密钥”。您可以将 URI 添加为书签，就像在浏览器中一样。

我想如果有一个身份验证服务， URI 也可用于识别个人用户。因此，在“收藏夹”服务中，您只需将用户 URI 与吸引力 URI 链接即可。