Question

我们正在从单片架构转向微服务架构应用程序，我们仍处于规划阶段，我们想知道构建它的最佳实践是什么。

假设我们有两项服务：

用户
设备
- getUserDevices（用户ID）
- addDevice（DeviceInfo，UserId）
- ...

每个用户都有多个设备

要求服务器获取所有用户设备的最常见，更清晰，最正确的方法是什么？

1- {api-url} / User / {UserId} / devices

需要另一个HTTP请求才能与Device服务进行通信。

对于用户X，从用户服务获取链接的设备。

// 或

2- {api-url} / Device / {UserId} / devices

对于用户X，从设备服务获取链接的设备。

Answer 1

有许多经典模式可用于解决微服务中的此类问题。你有2个微服务 - 1个用户（微服务A）和1个用于设备（微服务B）。微服务的基本原则是为每个微服务建立一个单独的数据库。如果任何微服务想要彼此交谈（或从另一个微服务获取数据），他们可以但他们会使用API来实现。 2个微服务之间通信的另一种方式是事件。当微服务A中发生某些事情时，它会引发事件并将其推送到中央事件存储或消息队列，而微服务B将订阅A发出的部分或全部事件。

我想在您的域中，A会有类似的方法 - 添加/更新/删除用户，B会添加/更新/删除设备。每个用户都可以拥有自己唯一的ID和其他数据字段，如姓名，地址，电子邮件等。每个设备都可以拥有自己唯一的ID，用户ID和其他数据字段，如名称，类型，制造商，价格等。无论何时“添加“设备，您可以向设备微服务发送POST请求或命令（如果您使用CQRS），其中包含有关设备+用户ID的数据的请求，它可能会引发一个名为”DeviceAdded“的事件。它还可以包含与“更新和删除”相对应的事件，如“DeviceUpdated”和“DeviceRemoved”。微服务A可以订阅事件--B发出的“DeviceAdded”，“DeviceRemoved”和“DeviceUpdated”事件，每当引发任何此类事件时，它将处理该事件并将该事件反规范化为其自己的设备数据库（其中你可以打电话给UserRelationships）。将来，它也可以监听来自其他微服务的事件（因此这里的模式可以扩展和扩展）。

现在要获得用户拥有的所有设备，您只需在用户微服务中设置一个终点，如“http：// {microservice-A-host}：{port} / user / {user -id} / devices“它将通过在自己的UserRelationship数据库中查询用户ID来返回设备列表，这些数据库必须通过事件进行维护。

好参考在这里：https://www.nginx.com/blog/event-driven-data-management-microservices/

Answer 2

它可能真的是两种方式，但根据我的喜好，我会选择将它放在/ Devices / {userId} / devices下，因为您正在寻找具有用户ID的设备。我希望这有帮助。祝你好一个！

Answer 3

您正在从服务请求资源，资源是设备，服务是设备服务。从休息的角度来看，您正在寻找资源，而您的服务正在提供各种方法来操纵该资源。

可以使用以下网址。

 [GET] ../device?user_id=xyz

可以通过 ../ device / {device_id}

获取设备信息

话虽如此，如果你有一项提供用户和设备数据的服务，那么下面的内容是有意义的。

[GET] ../user/{userId}/device

请注意，这只是一个命名约定，你可以选择最适合你的东西，选择一个并抓住它。暴露api一致性更重要。

Answer 4

微服务架构的一个核心原则是确定每个微服务的明确界限和责任。

我可以说它与SOLID中的单一责任原则相同，但在宏观层面上。我们得到了这个原则：

用户服务负责用户管理/操作
设备服务负责设备操作

你的问题是

..要求服务器获取所有用户设备的正确方法

设备服务和用户服务100％负责设备。

我可以看到你只考虑路由术语（是的，API一致性也很重要）。

从一侧来看，更好更合理的网址是/api/users/{userId}/devices - 您尝试获取用户的设备，这些设备属于用户。

从另一方面，您可以使用/api/devices/user/{userId}（/api/devices/{deviceId}）等路线，这样可以更轻松地处理由路由系统向Devices服务发送请求。

考虑到其他限制因素，您可以选择适合您设计的选项。

还有一点：

需要另一个HTTP请求才能与Device服务进行通信。

在您的解决方案的体系结构中，您可以创建一个额外的特殊且独立的组件，将请求路由到所需的微服务，不仅可以从一个微服务直接调用到另一个微服务。

Answer 5

您应该只查询设备服务。

将用户ID视为设备服务中的过滤器。例如：您应该搜索userid，类似于您根据设备类型搜索设备的方式。只是另一个过滤器

例如：/ devices？userid =

此外，您可以在设备服务中缓存用户的一些基本信息，以节省获取用户数据的往返次数

Answer 6

使用微服务，两个选项都没有错。然而，device api 更有意义，而且我更喜欢

GET ../device/{userId}/devices

在

GET ../device?user_id=123

有两个原因：

由于userId应该已经存在设备服务，您将保存一个用户服务的呼叫。否则它会像Requester - ＆gt;用户服务 - ＆gt;设备服务
您可以使用POST ../device/{userId}/devices为特定用户创建新设备。这看起来比参数化的URL更安静。

微服务架构中的进程间通信

6 个答案: