标签搜索系统设计——导读
这是一个关于"系统如何在业务压力下一步步演进"的真实故事。
如果你曾经面对过这样的困境：需求越来越多、代码越来越乱、每次迭代都像在拆炸弹——那这个系列或许能给你一些参考。
全系列文章在【专题文章】-【标签搜索系统】下找到
这个系列是写给谁的
写给那些在业务快速发展期做过后端系统设计的工程师。不是教科书式的架构讲解，而是一个系统从零开始、在真实业务压力下不断演进的过程记录——包括当时为什么这么选、踩了哪些坑、又是怎么一步步把坑填上的。
读完这个系列，你会看到：
- 一个搜索系统是如何从最简单的 CQRS 架构出发，逐步演进成支持配置化标签规则的复杂系统的
- EAV 模型、责任链、自定义 DSL 这些技术方案，在真实业务场景下是怎么被"逼出来"的
- 工程师在面对"最小成本"和"长期可维护性"之间的权衡时，是如何做决策的
系统演进的主线
整个系列围绕一个图书信息聚合搜索系统展开。这个系统的演进可以分为两个阶段：
业务发展期：系统从无到有，每一步都在用最小成本解决当前最紧迫的问题。
业务稳定保障期：系统已经积累了足够多的"技术债"，到了不得不做大迭代的时候。
两个阶段的核心矛盾不同：发展期追求"快"，稳定期追求"可维护"。这个转变本身，也是这个系列想传递的一个重要观点。
文章列表
业务发展期
- [01] 基本搜索系统搭建 —— 从 CQRS 架构开始
- [02] 灵活扩展非自有属性 —— EAV 存储模型的引入
- [03] 外部系统接入 —— 如何保障跨系统数据一致性
- [04] 搜索项和属性解绑 —— 业务发展带来的熵增
- [05] 配置化标签系统 —— 搜索项的双重身份
- [06] EAV 存储异构优化 —— 修复问题，扩展性重构
- [07] 标签嵌套规则 —— 系统中的妥协与代价
业务稳定保障期：大迭代
- [08] 离线属性计算解耦 —— 用 HiveSQL 替代 Java 代码
- [09] 事件聚合异构更新 —— 责任链重构 CQRS 设计
- [10] 自定义标签规则 DSL —— 用 TDD 推动设计
每篇文章的结构
为了方便阅读，每篇文章都遵循相同的结构：
- 需求背景：当时业务上发生了什么，为什么需要做这件事
- 核心矛盾：问题的本质是什么，为什么不能用更简单的方式解决
- 方案设计：选择了什么方案，为什么是这个方案而不是其他方案
- 技术 Demo：关键代码和数据模型示例
- 成本评估：这次迭代前后，开发维护成本的变化
一个贯穿始终的设计原则
在整个演进过程中，有两个原则反复出现：
原则一：用最小成本解决当前问题。 不要为了技术而技术，不要在业务还没验证的时候就过度设计。
原则二：当系统难以维护时，果断重构。 技术债是有利息的，拖得越久代价越大。
这两个原则看起来有些矛盾，但它们其实是同一件事的两面：在合适的时机做合适的事。
从下一篇开始，我们从最简单的搜索系统出发。