我们正在从单片架构转向微服务架构应用程序，我们仍处于规划阶段，我们想知道构建它的最佳实践是什么。
假设我们有两项服务：
每个用户都有多个设备
要求服务器获取所有用户设备的最常见，更清晰，最正确的方法是什么？
1- {api-url} / User / {UserId} / devices
需要另一个HTTP请求才能与Device服务进行通信。
对于用户X，从用户服务获取链接的设备。
// 或
2- {api-url} / Device / {UserId} / devices
对于用户X，从设备服务获取链接的设备。
答案 0 :(得分：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/
答案 1 :(得分：0)
它可能真的是两种方式，但根据我的喜好，我会选择将它放在/ Devices / {userId} / devices下，因为您正在寻找具有用户ID的设备。我希望这有帮助。祝你好一个！
答案 2 :(得分：0)
您正在从服务请求资源，资源是设备，服务是设备服务。 从休息的角度来看，您正在寻找资源，而您的服务正在提供各种方法来操纵该资源。
可以使用以下网址。
[GET] ../device?user_id=xyz
可以通过 ../ device / {device_id}
获取设备信息话虽如此，如果你有一项提供用户和设备数据的服务，那么下面的内容是有意义的。
[GET] ../user/{userId}/device
请注意，这只是一个命名约定，你可以选择最适合你的东西，选择一个并抓住它。 暴露api一致性更重要。
答案 3 :(得分：0)
微服务架构的一个核心原则是 确定每个微服务的明确界限和责任。
我可以说它与SOLID中的单一责任原则相同，但在宏观层面上。 我们得到了这个原则：
你的问题是
..要求服务器获取所有用户设备的正确方法
设备服务和用户服务100％负责设备。
我可以看到你只考虑路由术语（是的，API一致性也很重要）。
从一侧来看，更好更合理的网址是/api/users/{userId}/devices
- 您尝试获取用户的设备，这些设备属于用户。
从另一方面，您可以使用/api/devices/user/{userId}（/api/devices/{deviceId}）等路线，这样可以更轻松地处理
由路由系统向Devices服务发送请求。
考虑到其他限制因素，您可以选择适合您设计的选项。
还有一点：
需要另一个HTTP请求才能与Device服务进行通信。
在您的解决方案的体系结构中，您可以创建一个额外的特殊且独立的组件，将请求路由到所需的微服务，不仅可以从一个微服务直接调用到另一个微服务。
答案 4 :(得分：0)
您应该只查询设备服务。
将用户ID视为设备服务中的过滤器。例如：您应该搜索userid，类似于您根据设备类型搜索设备的方式。只是另一个过滤器
例如：/ devices？userid =
此外，您可以在设备服务中缓存用户的一些基本信息，以节省获取用户数据的往返次数
答案 5 :(得分：0)
使用微服务，两个选项都没有错。然而，device api 更有意义，而且我更喜欢
GET ../device/{userId}/devices
在
GET ../device?user_id=123
有两个原因：