传统方案的平滑升级：从 Elasticsearch 迁移到 Easysearch 实战指南
在国产化替代和降本增效的浪潮下，越来越多的企业选择将 Elasticsearch (ES) 替换为 INFINI Easysearch。然而，对于核心业务系统而言，“替换数据库”无异于“给飞行中的飞机换引擎”。
数据会不会丢？业务要不要停机？代码要不要改？升级失败能不能回退？
本文将抛弃传统的“停机导出导入”方案，重点介绍基于 INFINI Gateway 的无侵入、零停机、可回滚的平滑迁移实战指南。
一、 核心底气：极高的兼容性 #
迁移的信心源于兼容性。Easysearch 在设计之初就将“平滑替代”作为核心目标：
- API 协议兼容：Easysearch 完美兼容 Elasticsearch 7.10 的 REST API。这意味着：
- 代码零修改：您的 Java/Python/Go 客户端代码无需改动，只需修改连接 IP。
- 生态零修改：Logstash、Filebeat、Fluentd 等采集端配置无需变更。
- 工具零修改：Kibana（7.10 OSS版）等可视化工具可直接连接。
- 数据格式兼容：支持通过 Snapshot（快照）方式从 ES 7.x 直接恢复数据到 Easysearch。
二、 迁移神器：INFINI Gateway #
传统的迁移方案往往需要业务方配合修改代码进行“双写”（同时写入旧 ES 和新 Easysearch），侵入性大且容易出错。
我们推荐使用 INFINI Gateway 作为迁移的“中间件”。它像一个智能路由器，挡在业务应用和数据库之间，通过流量镜像和请求转发，实现透明迁移。
工具清单 #
- INFINI Gateway：负责流量拦截、双写分发、读写分离。
- INFINI Console：用于全流程的可视化数据比对和管控。
- Snapshot：用于历史存量数据的搬运。
三、 实战步骤：五步灰度切换法 #
我们采用 “流量代理 -> 增量双写 -> 存量搬迁 -> 灰度读 -> 全量切换” 的安全路径。
第一步：接管流量（透明代理） #
在不改变现有业务逻辑的前提下，将业务流量的入口指向 INFINI Gateway，再由 Gateway 转发给原 ES 集群。
- 操作：部署 Gateway，配置
router将请求转发到原 ES。 - 业务感知：无感知。Gateway 对于业务来说是透明的。
- 价值：此时 Gateway 获得了控制流量走向的“上帝视角”。
# Gateway 配置示例：代理模式
entry:
- name: my_es_entry
enabled: true
router: my_router
network:
binding: 0.0.0.0:8000 # 业务改连这个端口
router:
- name: my_router
default_flow: default_flow
flow:
- name: default_flow
filter:
- elasticsearch:
elasticsearch: old_es_cluster # 转发给旧集群
第二步：开启双写（增量同步） #
在 Gateway 上配置流量复制（Request Mirroring）。当写入请求到来时，Gateway 会将其同时发往“原 ES 集群”和“新 Easysearch 集群”。
- 机制：主流量依然走旧集群，副流量（Shadow Traffic）异步写入新集群。
- 状态：此时，新数据已经实时进入 Easysearch，但历史数据还缺失。
flow:
- name: double_write_flow
filter:
- flow: # 流量复制
target: write_to_easysearch_flow
- elasticsearch:
elasticsearch: old_es_cluster
- name: write_to_easysearch_flow
filter:
- elasticsearch:
elasticsearch: new_easysearch_cluster
第三步：搬运存量（历史数据同步） #
保持双写状态，开始搬运历史存量数据。
- 方案 A（推荐）：Snapshot 快照恢复
- 在原 ES 创建快照，在 Easysearch 中恢复。由于双写已开启，恢复后只需处理快照时间点到当前时间的极小部分数据差异。
- 方案 B：ESM / Logstash 工具
- 使用
elasticdump或medcl/esm工具，将旧数据 Scroll 出来写入 Easysearch。 - 注意：利用 Gateway 的“写去重”或 Easysearch 的 Version 机制，确保历史数据不会覆盖双写进来的新数据。
第四步：数据校验与灰度读 #
此时，新旧集群的数据应该基本一致。我们需要进行验证。
- 数据比对：使用 INFINI Console 的“数据校验”功能，抽样比对两边集群的文档数和字段内容。
- 灰度切读：在 Gateway 上配置路由规则。
- 让 1% 的读请求（GET/SEARCH）转发到 Easysearch，其余 99% 仍走旧 ES。
- 观察 Easysearch 的报错率、延迟和 CPU 负载。
- 逐步调整比例：10% -> 50% -> 100%。
第五步：全量切换与下线 #
当 100% 的读写流量都稳定运行在 Easysearch 上，且持续观察数天无异常后：
- 停止双写：在 Gateway 上摘除指向旧 ES 的流量。
- 下线旧集群：归档旧数据，回收服务器资源。
四、 兜底策略：回滚方案（Rollback） #
任何迁移都必须有“后悔药”。基于 Gateway 的方案，回滚极其简单：
- 场景：在第四步“灰度读”时，发现 Easysearch 响应慢或业务报错。
- 回滚操作：修改 Gateway 配置，将读流量路由规则 瞬间切回 旧 ES 集群。
- 数据一致性：由于整个过程我们保持了“双写”，旧 ES 集群中一直拥有最新、最全的数据。因此，切回旧集群是零数据丢失、零业务感知的。
五、 常见问题 QA #
Q1: 迁移过程中需要停机吗？
A: 不需要。通过 Gateway 接管流量，业务读写全程在线。只有在修改业务应用连接地址（IP）的那一刻可能需要重启应用，如果配合 DNS 或 K8s Service，甚至可以做到完全零停机。
Q2: Easysearch 的资源消耗会比 ES 大吗？
A: 相反，会更小。Easysearch 的 ZSTD 压缩和内存优化，通常能节省 30%-50% 的存储空间和内存占用。迁移后通常会发现集群负载变低了。
Q3: 遇到不兼容的 DSL 怎么办？
A: 虽然极少，但如果遇到（比如 ES 的某些废弃参数），可以在 Gateway 层编写一段 JS 脚本或配置规则，自动改写请求参数，屏蔽差异。
六、 结语 #
从 Elasticsearch 迁移到 Easysearch，不再是一场惊心动魄的冒险，而是一次可控、可视、可逆的技术升级。
利用 INFINI Gateway 的流量治理能力，我们将复杂的数据库迁移问题转化为了简单的网络路由问题。这不仅解决了数据安全顾虑，更为企业未来的搜索架构引入了一个强大的流量管理中枢。
