多个微服务和数据库关联答案

【问题标题】：Multiple microservices and database associations多个微服务和数据库关联
【发布时间】：2016-11-05 05:42:44
【问题描述】：

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

上面的方法似乎可行，但我有点坚持以下几点：用户必须能够将吸引力添加到他/她的收藏列表中，但我不明白这是怎么可能的，因为我有很多不同的数据库。

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

提前致谢！

【问题讨论】：

标签： database rest spring-boot microservices

【解决方案1】：

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

无需引入另一层 ID，无论是国家代码还是数据库 ID。无论如何，这些东西都是你的微服务内部的，应该对所有客户端都是透明的，包括其他微服务。

明确地说，您可以将 URI 存储到景点服务中的国家/地区。该 URI 无论如何都不应更改（尽管如果您收到永久重定向，您可能希望准备更改它），并且无论如何您都必须记住该 URI，以便能够将其包含在景点表示中。

除了景点的 URI 之外，您也不需要任何“业务密钥”来收藏。您可以像在浏览器中一样为该 URI 添加书签。

我想如果有身份验证服务，也有 URI 用于识别个人用户。因此，在“收藏夹”服务中，您可以简单地将用户 URI 与景点 URI 链接。

【讨论】：

我不太清楚你的意思，你能举个例子吗？
我的意思是用户的“key”是http://auth.mycompany.com/user/123，一个景点是http://attraction.mycompany.com/attraction/654。在“收藏夹”服务中，您可以简单地将这两个字符串关联起来，这样您就不必依赖这些对象内部的任何内容。
但是 123 和 654 不是内部 db id 的吗？
可能是。没关系，因为客户端并没有真正将“123”视为一个单独的实体（它不知道如何解析 URI）。它只将 URI 视为一个完整的整体。它可能是http://attraction.mycompany.com/feda653dffgjknwe，并且在知识方面不会对客户产生任何影响。关键是酷 URI 不会改变 (roy.gbiv.com/untangled/2008/…)。只要此属性成立，URI 中的内容并不重要。
所以这可能没问题 /api/attractions/BE ?

【解决方案2】：

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

第二个更简单、更快捷的选择可能是在您的用户服务上处理此问题，该服务会照顾您的用户数据的持久性，因为收藏夹是用户实体独有的。

至于 ID，我没有看到很多理由说明为什么这可能是个坏主意？您的个人服务将需要为相关数据存储一些识别值，而我认为这里的主要问题是保持此 ID 字段在您的不同服务中保持一致。您选择的内容必须是可靠且可预测的，以便随着系统的发展让事情变得简单易行。

【讨论】：

我在想 id 可能不好，因为虽然它们不应该改变，但它们可能会改变，例如迁移到另一个数据库...
是的，这是一个非常好的观点。与发生这种情况的风险相比，我想这是一个管理额外工作的案例。
问题是，如果我将它存储在最喜欢的特定数据库中，我将如何在不指定用户 ID 的情况下引用用户？也许是用户名？
同时，只要您的服务的 API 与所使用的数据库无关（显然应该），在迁移期间可以通过在需要时实现辅助唯一键来处理诸如此类的迁移问题将允许您继续使用存储在其他服务中的原始密钥。
是的，您需要存储用户 ID 或其他一些对用户的静态引用。您最喜欢的服务就是 RBMS 中多对多查找表的同义词。