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

Posted 2021-04-02

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

假设我们有两项服务：

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

每个用户都有多个设备

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

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

需要另一个HTTP请求与Device服务通信。

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

// 要么

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

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

答案

有许多经典模式可用于解决微服务中的此类问题。你有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/

另一答案

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

另一答案

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

可以使用以下URL。

 [GET] ../device?user_id=xyz

设备信息可以通过../device/{device_id获取

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

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

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

另一答案

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

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

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

你的问题是

..proper方式要求服务器获取所有用户设备

它是设备服务和用户服务的100％责任，对设备一无所知。

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

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

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

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

还有一点：

需要另一个HTTP请求与Device服务通信。

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

另一答案

您应该只查询设备服务。

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

例如：/ devices？userid =

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

另一答案

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

GET ../device/{userId}/devices

过度

GET ../device?user_id=123

有两个原因：

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