---
title: "传统方案的平滑升级：从 Elasticsearch 迁移到 Easysearch 实战指南"
date: 2026-03-08
lastmod: 2026-03-08
description: "详细介绍从 Elasticsearch 平滑迁移到 Easysearch 的完整实战方案，通过 INFINI Gateway 实现无侵入、零停机、可回滚的灰度切换，涵盖流量管理、增量双写、存量搬迁、数据校验等关键环节，以及常见问题解答和兜底回滚策略，帮助企业安全高效地完成数据库底座的国产化替代升级。"
tags: ["Easysearch", "迁移", "Gateway"]
summary: "传统方案的平滑升级：从 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：用于历史存量数据的搬运。  三、 实战步骤：五步灰度切换法 #  我们采用 “流量代理 -> 增量双写 -> 存量搬迁 -> 灰度读 -> 全量切换” 的安全路径。"
---


传统方案的平滑升级：从 Elasticsearch 迁移到 Easysearch 实战指南

在国产化替代和降本增效的浪潮下，越来越多的企业选择将 Elasticsearch (ES) 替换为 **INFINI Easysearch**。然而，对于核心业务系统而言，“替换数据库”无异于“给飞行中的飞机换引擎”。

数据会不会丢？业务要不要停机？代码要不要改？升级失败能不能回退？

本文将抛弃传统的“停机导出导入”方案，重点介绍基于 **INFINI Gateway** 的**无侵入、零停机、可回滚**的平滑迁移实战指南。

## 一、 核心底气：极高的兼容性

迁移的信心源于兼容性。Easysearch 在设计之初就将“平滑替代”作为核心目标：

1. **API 协议兼容**：Easysearch 完美兼容 **Elasticsearch 7.10** 的 REST API。这意味着：

- **代码零修改**：您的 Java/Python/Go 客户端代码无需改动，只需修改连接 IP。
- **生态零修改**：Logstash、Filebeat、Fluentd 等采集端配置无需变更。
- **工具零修改**：Kibana（7.10 OSS版）等可视化工具可直接连接。

2. **数据格式兼容**：支持通过 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 获得了控制流量走向的“上帝视角”。

```yaml
# 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，但历史数据还缺失。

```yaml
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 机制，确保历史数据不会覆盖双写进来的新数据。_

### 第四步：数据校验与灰度读

此时，新旧集群的数据应该基本一致。我们需要进行验证。

1. **数据比对**：使用 INFINI Console 的“数据校验”功能，抽样比对两边集群的文档数和字段内容。
2. **灰度切读**：在 Gateway 上配置路由规则。

- 让 1% 的**读请求**（GET/SEARCH）转发到 Easysearch，其余 99% 仍走旧 ES。
- 观察 Easysearch 的报错率、延迟和 CPU 负载。
- 逐步调整比例：10% -> 50% -> 100%。

### 第五步：全量切换与下线

当 100% 的读写流量都稳定运行在 Easysearch 上，且持续观察数天无异常后：

1. **停止双写**：在 Gateway 上摘除指向旧 ES 的流量。
2. **下线旧集群**：归档旧数据，回收服务器资源。

## 四、 兜底策略：回滚方案（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** 的流量治理能力，我们将复杂的数据库迁移问题转化为了简单的网络路由问题。这不仅解决了数据安全顾虑，更为企业未来的搜索架构引入了一个强大的流量管理中枢。