我应该使用接收端所需的所有数据发出微服务事件，还是允许服务从数据库中获取额外数据？

Posted 2023-02-16

【中文标题】我应该使用接收端所需的所有数据发出微服务事件，还是允许服务从数据库中获取额外数据？

【英文标题】：Should I emit microservice events with all the data required on the receiving end, or allow the services to fetch extra data from the database?

【发布时间】：2021-05-02 09:26:31

【问题描述】：

我的云上运行以下服务器，每个工作人员执行各种长时间运行的任务，并可能更新我的 PostgreSQL 数据库：

- Main application server
- Service that collects changes and updates my search database
- Worker
- Worker
- Worker

当我的main server 或workers 中的任何一个更新我的数据库时，我的 ORM 中间件会发出数据已更改的 Cloud Pub/Sub 事件。这允许我的search service 然后处理更改并批量更新我的搜索集群。

我正在苦苦挣扎的部分只是我应该在哪里获取处理事件所需的额外数据，同时保持可伸缩性和简洁的架构。

例如：

我的住宿属性的availability 在外部同步。每个day 都会在我的数据库中更新，并且必须反映在搜索索引中。问题是我还需要在我的搜索中更新房产的定价模型和其他各种元数据。 我应该：

A) 发出day 的可用性已更改的事件，并在Search Service 中从数据库中获取属性及其定价

B) 从 ORM 中间件的数据库中获取属性及其定价，然后发出事件，允许 Search Service 简单地使用和更新搜索数据库

我的 PubSub 事件应该有多通用，在事件发出之前和之后应该准备多少数据？

【问题讨论】：

我认为你应该在得到一个好的答案之前对一些事情进行校准，因为有一些事情并不清楚。例如： 1. 其可用性在外部同步的住宿属性？外部同步是什么意思？通过一些异步过程？来自另一个微服务？ 2.选项A：您的意思是从数据库中获取属性数据并将其与事件一起发送以及当天的可用性数据？ 3. 一般来说，谁在发布事件，谁在订阅它，用例是什么？请尝试编辑问题并提供更多信息。

【参考方案1】：

你是怎么做到的？这是我对同一条船上的任何人的想法......

关键是要考虑并正确平衡设计时间和运行时注意事项——例如：

数据波动性。 消费者是否关心历史。 运行时负载。 ​ 易于调试和操作支持。 易于维护/更改系统。 财务成本。

如果数据高度不稳定（经常更改），那么您的方法 A 更好，因为消费者将始终获得最新数据 - 即他们收到通知和获得数据之间的延迟无关紧要。

方法 A 还减少了源系统和中间件/集成的负载：源系统只需要发布事件，不需要做进一步的工作来构建更大的答案（方法 B）。流经中间件的数据较少，这会给中间件带来较少的负载，并且如果您在 *aaS 平台上，可能会影响其运营成本。

方法 A 允许您更改返回数据的 API（“GET”API），而无需更改事件的 API 和规范。这意味着您可以运行一组简单且稳定（不经常/根本不会更改）的事件，以及 GET API 的多个版本，允许消费者在准备好时进行迁移（例如，如果您的支持模型要支持当前版本 -X.2)。

我会在以下情况下考虑方法 B：

消费者需要所有的变化，而不仅仅是最新的变化。 返回的额外数据并不大，即不会降低源系统或中间件的性能。如果对源系统有影响，您可能需要调查减轻负担的方法 - 例如响应缓存，某种代理，等等。 完整数据负载的架构相对稳定。