技术选型与性能表现 - 公司原有技术栈以Ruby和Node.js为主，面临支持10万并发用户的实时服务需求时，Ruby被确认不适合该场景 [2][3] - 团队进行四种语言概念验证（Elixir、Rust、Ruby、Node.js），Rust版本由新手开发者编写但仍以显著性能优势胜出：速度最快、内存占用最少 [5][8] - Elixir在并发处理中表现优异，Node.js受限于单线程需分布式部署，Ruby性能垫底 [9][10] Rust的采纳与开发过程 - 团队最终选择Rust因其通用性潜力，包括网络编程、Web服务及多语言SDK开发等战略价值 [10] - 项目时间紧张，由单一开发者采用极简架构实现：基于WebSocket的API，内存哈希表存储，事件推送至Kafka [13][14] - 开发效率极高：2周完成第一版，1-2周部署，一个月内扩展功能，稳定运行零故障 [15][18] 性能优化与管理层冲突 - 服务在50万并发用户活动前招聘3名Rust开发者优化，最终单台64核机器支持100万并发（P99延迟10ms）、200万并发（P99延迟25ms） [19][21] - 管理层因服务过于稳定质疑团队价值，强制要求转用Ruby/Node.js，导致3名Rust开发者离职 [20][22] - 禁用Rust后尝试Node.js重写失败，因单线程无法处理高负载，最终依赖第三方服务仍性能不足 [24][25][26] 结果与行业启示 - 原Rust服务持续在生产环境稳定运行但无人维护，成为"被遗忘的英雄" [28][29] - 技术决策受管理层变动显著影响，人力资源倾向主流技术栈（如Node.js/Ruby）与性能需求存在矛盾 [22][23] - 极端稳定性反成团队风险，揭示技术成功与管理预期错位的悖论 [1][29]