有赞搜索系统的架构演进

本文来自于网络，从架构上介绍了有赞搜索系统演进产生的背景以及希望解决的问题，有赞搜索平台是一个面向公司内部各项搜索应用以及部分NoSQL存储应用的 PaaS产品，帮助应用合理高效的支持检索和多维过滤功能，有赞搜索平台目前支持了大大小小一百多个检索业务，服务于近百亿数据。在为传统的搜索应用提供高级检索和大数据交互能力的同时，有赞搜索平台还需要为其他比如商品管理、订单检索、粉丝筛选等海量数据过滤提供支持，从工程的角度看，如何扩展平台以支持多样的检索需求是一个巨大的挑战。我是有赞搜索团队的第一位员工，也有幸负责设计开发了有赞搜索平台到 有赞搜索系统的架构演进是其应对不断增长的检索需求和大数据挑战的过程。有赞搜索平台作为公司的PaaS产品，服务于各种内部搜索应用和NoSQL存储应用，支持高效的检索和多维过滤，处理上百个业务和近百亿的数据。平台不仅需要提供高级检索功能，还要处理商品管理、订单检索等海量数据过滤。 初期的架构1.0，基于Elasticsearch，采用几台高配虚拟机组成集群。数据通过Canal从数据库同步到Elasticsearch。然而，这种单体应用方式存在耦合度高、数据库性能损耗和扩展性问题。例如，数据库变动需频繁调整同步程序，多个Canal监听同一数据库可能导致性能下降，且一次性处理大量数据可能导致内存溢出。 为了解决这些问题，演进到了架构2.0。这一阶段引入了数据总线和消息队列，解耦了与业务库的连接，避免了多个Canal的资源浪费。同时，为了支持更复杂的查询需求，引入了高级查询中间件，实现了对搜索结果的精细化排序控制。此外，通过缓存搜索结果，减少了不必要的实时计算，提升了性能。 在大数据集成方面，2.0架构利用es-hadoop组件建立了Hive与Elasticsearch的交互，通过Flume收集日志进行离线分析，为搜索提示词提供支持，进一步丰富了搜索体验。 然而，架构2.0仍然面临维护成本高、消息顺序问题以及流量不可预测等问题。因此，演进至架构3.0。在这个版本中，有赞采取了以下改进措施： 1. 通过开放接口，将系统与业务代码完全解耦，降低维护复杂性。 2. 引入Proxy层，对用户请求进行预处理，实现流量控制和缓存管理，增强了系统的稳定性和性能。 3. 提供管理平台，简化索引管理和集群运维，降低了运维成本。 通过这些演进，有赞搜索系统逐步提高了其可扩展性、可靠性和效率，以满足日益增长的业务需求和大数据处理挑战。