管道架构¶
https://blueprints.launchpad.net/searchlight/+spec/pipeline-architecture
此特性启用灵活的管道架构，允许 Searchlight 配置多个发布者来消费增强的数据。
问题描述¶
当前，当通知发送到 Searchlight 时，它会在通知处理器中被处理。该处理器会以多种方式丰富通知，并将丰富后的数据索引到 Elasticsearch 中。由于 Elasticsearch 现在是 Searchlight 中唯一的存储后端，因此这种方法简单直接。随着我们将要引入通知转发器 [1]，这个过程将变得不够灵活。需要一个管道架构来为用户提供额外的灵活性，以定义丰富后的数据发布到哪里。它还允许 Searchlight 在未来支持其他非 Elasticsearch 后端。
提议的变更¶
我们建议 Searchlight 更改为管道架构，以提供通知转发的灵活性。
Searchlight 当前的主要消息流如下所示：源(通知) -> 丰富&索引到 Elasticsearch。
目前通知处理器等待通知，转换它们并将数据索引到 Elasticsearch 中。它紧密耦合且不模块化。需要一个一致的工作流程。
有了管道之后，主要消息流将如下所示：源(通知) -> 数据转换器(丰富) -> 发布者(Elasticsearch, Zaqar)。
为了实现这一点，Searchlight 需要进行一些重构。通知处理器仅专注于捕获受支持的通知事件。之后，通知将被转发到数据转换器。主要有两种类型的数据转换。一种是将通知标准化为 OpenStack 资源负载。该负载是与发布者附加元数据无关的 API 兼容格式。标准化始终通过调用 OpenStack API 服务或更新现有的 Elasticsearch 数据来完成。这些资源转换器是插件依赖的。例如，nova 创建实例的通知可以标准化为服务器信息文档。除了资源数据丰富之外，可能还需要附加一些发布者元数据，例如用户角色字段、父子关系、Elasticsearch 中的版本。这些转换应与资源数据丰富分离。
发布者应实现一种方法来接受丰富的数据、通知信息以及指示资源 CURD 的操作。例如，如果 nova 服务器已更新，管道中的发布者将接收服务器完整信息、服务器更新通知和“更新”操作。发布者如何处理这些信息完全由他们决定。
我们将 Elasticsearch 索引视为发布者的一种情况。它可以是默认发布者，因为对于某些插件，资源更新需要从 Elasticsearch 中获取旧文档，如果没有 Elasticsearch，部分更新将无法工作，尽管将来我们可能会解决此问题。管道中发布者的顺序无关紧要。发布者可以选择如何处理错误，例如请求重新排队或直接忽略异常。重新排队操作对于 Elasticsearch 发布者尤其有用，因为数据完整性对于 Searchlight 的搜索功能很重要。重新排队不应影响其他配置的发布者，因此需要一个过滤器来确保发布者不会两次传递相同消息。
目前 Searchlight 通过两种方式获取其数据，一种是通过通知进行增量更新，另一种是通过 API 调用进行完全索引到 ElasticSearch。增量更新会通知管道中配置的所有发布者。对于重新索引，由发布者决定是否要重新索引。
管道设计有两种替代方案。一种是管道仅由发布者组成。通知由资源转换器标准化，然后传递给配置的发布者。发布者可以在内部附加特定的元数据。用户只能控制 Searchlight 数据前往哪些发布者。另一种替代方案是使转换器和发布者都可配置。通过组合不同的转换器和发布者，可以在相同的通知上生成不同的管道。
