微服务架构的文本搜索

Question

我正在研究在基于微服务的系统上实现文本搜索。我们将不得不搜索跨越多个微服务的数据。

例如，我们有两个服务用于管理组织和管理联系人。我们应该能够在一次搜索操作中通过联系方式搜索组织。

我们首选的搜索解决方案是 Elasticsearch。我们已经有一个基于嵌入对象（和/或父子）的工作解决方案，其中当父域更新时，索引有效负载将通过相关对象数据丰富，这些数据保存在缓存中（我们避免调用服务为此直接管理孩子）。

我想知道是否有更好的解决方案。是否有适用于此类场景的微服务模式？

Answer 1

我建议您使用它并不是一种特别的微服务模式，但它非常适合微服务，它被称为事件溯源

事件源描述了一种架构模式，其中事件由不同的源生成。一个事件现在将触发 0 个或多个所谓的Projections，然后使用事件中包含的数据以所需的形式聚合信息。

这直接适用于您的问题：每当组织服务更改其内部状态（添加/删除/更新组织）时，它都可以触发事件。如果添加了一个组织，它将例如将联系人聚合到该组织并存储该聚合。搜索它现在很简单：在聚合信息中查找组织 ID（可以编入索引）并取回与该组织关联的联系人。当然，如果将合约添加到合约服务中，同样有效：它只是触发一条包含合约创建信息的消息，相应的预测现在会改变不同的聚合，这些聚合可以再次被快速索引和搜索。

您可以有多个预测来响应单个事件——这使您能够以多种不同的形式聚合信息——这正是您以后想要查询的方式。不要害怕重复数据：事件溯源有意进行这种权衡，因为这不是您的业务服务所依赖的数据，您不需要手动更改它 - 这种重复不会伤害您。

如果您按事件发生的时间顺序存储事件（我强烈建议您这样做！）您可以一遍又一遍地“重播”这些事件。例如，如果投影有问题并且必须修复，这会有所帮助！

如果您有兴趣，我建议您阅读事件采购并寻找某种事件商店：

• 事件溯源
• 活动商店

我们使用事件溯源来聚合我们系统中的一系列不同搜索，我们每天将数以百万计的记录聚合到 mongodb 中。所有投影都有自己的集合，创建自己的索引，直到现在我们都不必求助于不同的系统/模式，如弹性搜索等！

如果这有帮助，请告诉我！

修正案

使用事件中包含的数据以所需的形式聚合信息

事件应包含聚合更多信息所需的所有信息。例如，如果您有组织创建活动，您至少需要提供一些关于组织名称、某种 ID、创建日期、上级组织 ID 等信息。根据经验，我们会发送所有信息我们收集获取请求的服务（不要直接从请求中获取它；-) 首先检查它，然后将其写入事件并将其发送出去）因为我们不知道我们需要什么未来。保持谨慎——有效载荷不应变得太大！

我们现在可以有多个预测来响应这个事件：一个将组织添加到它的父聚合中（以便轻松查找给定组织的所有子级），一个将它添加到所有组织的搜索集中，也许还有一个第三个聚合给定子组织的所有父级，因此父级组织的查找既简单又快速。

我们有相同的服务处理这些事件，也处理客户端请求。其背后的动机是，您的投影创建的数据模式与客户端与之交互的服务读取数据的方式紧密耦合。这不一定是那样的，它可以分成两个服务——但是你在那里创建了一个几乎不可见的依赖项，独立发布这两个服务变得更具挑战性。但是，如果您不介意额外的复杂程度 - 您可以将两者分开。

我们目前还在考虑编写一个通用服务，用于从诸如搜索之类的事件中聚合信息，其中可以编写预测脚本。这只会使隐形依赖问题不那么显眼，并不能解决它。