有赞搜索系统的架构演进
参考原文地址：
https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455758888&idx=1&sn=802a6f0eb8ddcd03b88538a2c0f44d5a&chksm=8c686e0dbb1fe71b6dda89d8863aa0f221d3b9ee0e182f205aafc4ab01832933a14c8aff637a&scene=21#wechat_redirect
有赞搜索平台是一个面向公司内部各项搜索应用以及部分 NoSQL 存储应用的 PaaS 产品，帮助应用合理高效的支持检索和多维过滤功能，有赞搜索平台目前支持了大大小小一百多个检索业务，服务于近百亿数据。
在为传统的搜索应用提供高级检索和大数据交互能力的同时，有赞搜索平台还需要为其他比如商品管理、订单检索、粉丝筛选等海量数据过滤提供支持，从工程的角度看，如何扩展平台以支持多样的检索需求是一个巨大的挑战。
我是有赞搜索团队的第一位员工，也有幸负责设计开发了有赞搜索平台到目前为止的大部分功能特性，我们搜索团队目前主要负责平台的性能、可扩展性和可靠性方面的问题，并尽可能降低平台的运维成本以及业务的开发成本。
Elasticsearch 是一个高可用分布式搜索引擎，一方面技术相对成熟稳定，另一方面社区也比较活跃，因此我们在搭建搜索系统过程中也是选择了 Elasticsearch 作为我们的基础引擎。
架构1.0
时间回到 2015 年，彼时运行在生产环境的有赞搜索系统是一个由几台高配虚拟机组成的 Elasticsearch 集群，主要运行商品和粉丝索引，数据通过 Canal 从 DB 同步到 Elasticsearch，
通过这种方式，在业务量较小时，可以低成本的快速为不同业务索引创建同步应用，适合业务快速发展时期，但相对的每个同步程序都是单体应用，不仅与业务库地址耦合，需要适应业务库快速的变化，如迁库、分库分表等，而且多个 canal 同时订阅同一个库，也会造成数据库性能的下降。
架构 2.0
首先数据总线将数据变更消息同步到 mq，同步应用通过消费 mq 消息来同步业务库数据，借数据总线实现与业务库的解耦，引入数据总线也可以避免多个 canal 监听消费同一张表 binlog 的虚耗。
目前的架构 3.0
针对 2.0 时代的问题，我们在 3.0 架构中做了一些针对性调整，列举主要的几点：
通过开放接口接收用户调用，与业务代码完全解耦；
增加 proxy 用来对外服务，预处理用户请求并执行必要的流控、缓存等操作；
提供管理平台简化索引变更和集群管理 这样的演变让有赞搜索系统逐渐的平台化，已经初具了一个搜索平台的架构。
未来的架构 4.0
当前架构通过开放接口接受用户的数据同步需求，虽然实现了与业务解耦，降低了我们团队自身的开发成本，但是相对的用户开发成本也变高了，数据从数据库到索引需要经历从数据总线获取数据、同步应用处理数据、调用搜索平台开放接口写入数据三个步骤，其中从数据总线获取数据与写入搜索平台这两个步骤在多个业务的同步程序中都会被重复开发，造成资源浪费。这里我们目前也准备与 PaaS 团队内自研的DTS（Data Transporter，数据同步服务）进行集成，通过配置化的方式实现 Elasticsearch 与多种数据源之间的自动化数据同步。