在做搜索技术架构咨询时，我们经常听到一句话：“我也知道业务系统复杂，但不知道怎么简化架构部署?”
今天，我们想聊聊 “某知名互联网泛娱乐视觉平台 A”（以下简称 A 公司）的搜索架构演进故事。他们的云上迁移经历，是无数正在为“技术栈碎片化”与"AI搜索架构改造"头疼的企业的真实写照。
第一阶段：为了业务的“快”，他们建了三根烟囱
一年前，A 公司的技术架构负责人老李面临着极大的压力。随着原先的检索业务引入全量日志审计的运维管理，再到接入大模型 RAG（检索增强生成），他们的架构变成了典型的“拼凑型”：
通用搜索业务：素材中台、视频/表情包关键词检索，涉及大规模用户、话题及活动信息。跑在开源ES集群上。
日志检索业务：为了合规存储海量 Access Log，采购了独立的日志服务。App 行为日志、服务端系统日志，用于性能监控与运营决策。为了省钱又把部分老日志导到了 对象存储里，查询极其不便。
向量检索业务：基于视觉特征的相似图片检索、基于用户画像的智能推荐（如相似滤镜、模板推荐）。为了做 RAG 和猜你喜欢，又不得不单独搭建了一套 开源 Milvus。
老李的痛点非常具体：
“半夜烧钱”：A 公司的流量有明显的潮汐效应。每天晚上 8 点到 12 点是日志写入洪峰，但凌晨 2 点到早上 8 点流量极低。为了抗住那 4 小时的峰值，他们必须按最高水位购买日志资源。结果就是：每天有 16 个小时，昂贵的计算资源在空转。突发流量导致的扩容压力与存储成本不成正比。
“胶水代码”：在做 RAG 时，开发同学需要在代码里先查 Milvus 拿 ID，再回查 ES 拿文本。不仅代码难维护，一旦出现数据不一致（比如文章删了，向量还在），用户就会点进 404 页面，投诉率飙升。
“三根烟囱”：多种搜索能力隔离分开，开发与运维成本极高，难以支持复杂的跨模态检索。
“蜗行牛步”：全量同步耗时长，大数据量下的实时更新与索引重建效率低下。
第二阶段：做减法，拥抱 All in ES
在与阿里云AI搜索专家团队深聊后，A 公司决定进行一次彻底技术“断舍离”，将AI搜索所需的多种技术栈统一收敛到阿里云 Elasticsearch 上。
1. 日志场景：把“固定资产”变成“电费单”
A 公司首先改造的是最烧钱的日志系统。他们没有继续购买庞大的自建 ES 节点，而是接入了阿里云 ES 的 高性能写入托管服务 Indexing Service 和 混合存储服务 OpenStore。
变化前：为了抗峰值，常驻 20 台 8C32G 的机器。凌晨流量跌到谷底时，这 20 台机器依然在计费。
变化后：彻底 Serverless 化。晚高峰流量来了，云端自动扩容扛压；凌晨流量没了，计费几乎归零。存储方面，数据自动沉降到 OpenStore（对象存储介质），成本直接对其归档存储。
老李的反馈：“以前是养车，不管开不开都得付折旧和保险；现在是打车，跑多少付多少。单这一项，日志账单降了 60%。
2. 向量场景：删掉胶水代码，回归原生
解决了日志，A 公司开始动刀向量搜索。他们利用阿里云 ES 内核级强化的混合向量引擎，替代了独立的向量库。
变化前：应用 -> 查向量库 -> 拿 ID -> 查 ES -> 应用层排序。延迟 200ms+。
变化后：应用 -> 阿里云 ES (混合检索 API) -> 返回结果。
由于阿里云 ES 全自研云原生引擎 FalconSeek 在内核层引入了 SIMD 指令集加速和 HNSW 算法优化，在千万级数据量下，性能完全满足 A 公司的需求。更重要的是，他们终于可以用一个 DSL 语句同时搞定“语义搜索 + 关键词匹配 + 边时间过滤边检索”。
老李的反馈：“架构图上少了一个框，代码里少了几百行胶水逻辑，开发同学终于不用在两个库之间修数据一致性的 Bug 了。”
为什么选择 All in ES？因为“统一”本身就是生产力
A 公司的故事并非孤例。当他们将日志、搜索、向量收敛到阿里云 Elasticsearch 这一套技术栈上时，发生的不仅仅是成本的降低：
系统架构优化：
1. 极致的计算资源弹性（Serverless）： 对于日志这种具有明显“峰谷效应”的数据，传统的预置机器模式注定是浪费。阿里云 ES 的 Indexing Service 让算力像水一样流动，“用时付费，不用免费”，这才是云原生该有的样子。
2. 运维标准的统一： 现在，A 公司的运维团队只需要精通 ES 这一门手艺。无论是查业务慢查询，还是做日志分析，亦或是管理向量索引，都在同一个控制台，遵循同一套安全标准（RBAC/VPC），看同一套监控大盘。
3. 数据价值的闭环： 日志数据进来，清洗后直接可以用于业务分析；业务数据进来，直接生成向量用于推荐。数据在同一个生态内流转，没有中间商赚差价。
日志检索增强：
在 A 公司中广泛使用的日志检索，采用阿里云 Elasticsearch 企业版以下方面进行全面优化。
极致写入优化 - Indexing service 读写分离，综合写入成本降低 60%
- 高性能：专业级写入优化，多自研特性加持(物理复制,定向路由等)
- 高稳定：多集群冗余备份，秒级切换
- 低成本：写入资源，存储大小及介质等优化
- 弹性扩展：写入资源由云端后台调配和管理，以应对流量波动
- 免运维：无须关注写入资源和写入压力, 极大降低集群运维成本
存算分离优化 - OpenStore 混合存储架构，存储成本降低 60% 以上
- 采用存算分离架构，降低数据冗余存储
- 采用对象存储降低存储成本
- 多级缓存及并发查询保证查询性能
专业级查询优化：
- 针对日志场景的典型查询 case 进行深度优化，提高用户查询性能， 如 bkd 查询优化等
- 贴近用户业务，针对用户使用过程中的查询问题进行定制优化，如在支持 A 客户中遇到的 cardinality 开源缺陷导致的查询性能问题等。
向量索引调优：
向量索引在 AI 搜索场景中越来越重要，A 公司为提高性能，降低整体成本，充分采用了阿里云 ES 的若干优化手段。成功的将成本降低一倍以上，查询性能提升数倍以上：
- 自研 FalconSeek 云原生索引应用：阿里云最新发布全自研云原生C++内核引擎, 对文本检索与向量检索性能提升，向量性能进一步提升40%以上。 使用FalconSeek的Filter-Knn特性，性能提升最多4倍。
- 执行 Force Merge：存量数据定期执行 Force Merge，性能提升5倍以上。
- 原文排除向量字段：在写入的 source 中排除向量字段，存储空间节约1倍以上。
- 混合搜索：采用 RRF（Reciprocal Rank Fusion）算法或自定义线性权重，将向量相似度得分与 BM25 文本得分进行加权融合，以兼顾检索的精确性与泛化性。
成本效能对比与选型建议
根据 A 公司迁移阿里云的测算分析，企业在构建多场景 AI 搜索时，可重点关注以下成本指标：
维度 |
建议方案 |
价值产出 |
计算资源 |
自研 FalconSeek 引擎应用 选用计算型 ecs.g8i 或 r8i 系列 |
提升向量运算（HNSW 等算法）的吞吐量 |
存储资源 |
OpenStore 存算分离架构 |
解决日志/冷数据存储高成本痛点 |
写入性能 |
Indexing Service 高写入服务， 开启物理复制（Physical Replication） |
降低高并发写入时的 CPU 占用 |
运维效率 |
统一公用集群与素材中台集群 |
减少 20% 以上的碎片化人力投入 |
总结：One Stack 一站式搜索, 简单架构是最好的架构
回看 A 公司的搜索技术演进之路，其实就是一条从“做加法”到“做减法”的路。
对于架构师：你的系统拓扑图变清晰了，数据链路变短了，系统稳定性变强了。
对于运维：只要精通 ES 一门产品技术手艺，就能搞定全公司的核心数据检索全链路。
对于老板：TCO（总拥有成本）显著下降，同时获得了企业级的安全合规保障。
不要让复杂的工具链拖累你的业务创新的速度。
从今天开始，参考 A 公司的路径，重新审视你的架构。尝试阿里云 Elasticsearch 企业版，体验“All in ES”带来的极简与高效。
更多详情：
阿里云 Elasticsearch官网：https://www.aliyun.com/product/bigdata/elasticsearch
阿里云 AI搜索开放平台：https://help.aliyun.com/zh/open-search/search-platform
阿里云 Elasticsearch Serverless 官网：https://www.aliyun.com/product/es/es-serverless
