从零到英雄：有赞订单搜索 AKF 架构演进之路

有赞订单搜索 AKF 架构的演进之路

随着时间的推移，技术不断更新，商业需求也不断变化。有赞订单搜索的 AKF 架构也经历了多次演进，以适应新的挑战和需求。

AKF 架构概述

AKF 架构是一种分布式搜索架构，由三个主要组件组成：

• A（Aggregated） ：聚合服务，负责将分散在多个数据库分片中的数据聚合到 Elasticsearch 中。
• K（Kafka） ：消息队列，用于在聚合服务和索引服务之间传递数据更改。
• F（Full-text） ：索引服务，负责将数据编入索引并提供搜索功能。

演进之路

阶段一：ES 聚合

最初，订单数据分散在 MySQL 的多个分片中。为了改善搜索性能，将这些数据聚合到了 Elasticsearch 中。聚合服务使用 Kafka 订阅 MySQL 的 binlog，并将数据更改发送到 Elasticsearch。

阶段二：数据分片

随着订单数量的增加，Elasticsearch 集群不堪重负。因此，将订单数据按时间范围分成了多个分片，每个分片对应一个单独的 Elasticsearch 集群。

阶段三：多活架构

为了提高可用性和容错性，采用了多活架构。在该架构中，每个 Elasticsearch 分片都有两个主节点，分别位于不同的数据中心。如果一个主节点发生故障，另一个主节点将自动接管。

阶段四：实时同步

在之前的架构中，数据更改通过 Kafka 异步传递到 Elasticsearch。为了降低延迟，引入了实时同步机制。聚合服务直接向 Elasticsearch 发送数据更改，从而显著减少了同步延迟。

阶段五：全量重建

随着时间的推移，Elasticsearch 索引可能会变得碎片化，导致搜索性能下降。因此，定期进行全量重建，以优化索引并提高搜索效率。

面临的挑战

在 AKF 架构的演进过程中，也遇到了以下挑战：

• 数据一致性 ：确保聚合服务和索引服务之间的数据一致性至关重要。
• 数据量庞大 ：订单数据量庞大，对存储和索引提出了挑战。
• 高可用性 ：AKF 架构需要保持高可用性，以避免影响搜索服务。

收获

AKF 架构的演进带来了以下收获：

• 搜索性能提升 ：将订单数据聚合到 Elasticsearch 大大提高了搜索性能。
• 扩展性增强 ：通过数据分片和多活架构，提高了架构的可扩展性。
• 可用性提升 ：多活架构和实时同步机制提高了架构的可用性。

总结

有赞订单搜索 AKF 架构的演进之路是不断适应变化需求和克服挑战的过程。通过持续优化和创新，AKF 架构始终为有赞提供高效、稳定、可扩展的搜索服务。