无论是Netflix的"Java秘诀"还是Uber使用Kubernetes（Kubernetes），对于全球广泛使用的热门平台来说，其背后的技术实现总是值得关注。对Discord（Discord）而言，始于2017年的高性能Elasticsearch（Elasticsearch）系统最终在公司快速增长的压力下暴露出问题，迫使工程团队重新设计搜索架构。
多年来，Discord的消息系统通过Elasticsearch集群实现高效运行，每个服务器和直接消息流都拥有独立分片存储。然而，随着平台规模扩大，系统的根本性限制逐渐显现。基于Redis（Redis）的消息索引队列在消息量激增时成为关键故障点。
Discord团队在博客中指出："当Elasticsearch节点发生故障导致索引队列积压时，Redis集群会因CPU负载过高而开始丢弃消息。"批量索引策略在大规模运行时也暴露出意想不到的问题。由于消息来自不同索引和节点，单个节点的故障可能导致约40%的批量索引操作失败。
系统维护也成为一大挑战。无法执行滚动重启或软件升级，使得Discord只能继续运行过时版本，错过安全补丁和性能改进。例如，修复log4shell漏洞时，不得不将整个搜索系统离线进行维护。
Discord在Kubernetes平台上开始重构搜索系统。通过Elastic Kubernetes Operator，团队能够轻松定义集群拓扑和配置。新架构带来显著改进：
新的多集群"单元"架构取代了原有的单体集群方案。Discord将原本200多个大型节点集群改造为40个小型集群，并按逻辑单元组织。每个集群内的节点都承担特定角色，确保主节点具有充足的协调资源，同时入口节点可根据流量动态扩展。
从Redis迁移到Pub/Sub后，消息队列管理得到改善：
新架构还支持了更多搜索功能，包括用户长期需求的跨消息搜索。对于超大规模社区，系统提供专属资源和多分片索引，可处理数十亿条消息，同时保证小型社区的性能不受影响。
改造后的系统性能显著提升：
这次转型使Discord能够高效处理数万亿条消息，同时保持了系统的扩展性和灵活性。
