在郑州做婚恋交友系统时，最先碰到的不是功能单，而是两类痛点：一是海量并发下的实时通信和音视频稳定性，二是虚假身份与骚扰带来的信任危机。项目初期把这些当作非功能需求，就少走了很多弯路；回头看，产品成功很大程度上靠的是技术边界的早期划定与持续验证。

      架构选型上，我倾向微服务+容器化：Spring Boot 做业务微服务，gRPC 负责服务间低延迟调用，Kubernetes 做编排，Ingress 用 Envoy 做边缘流量管理。实践里学到：别过早拆到数十个服务，先用模块化单体跑通业务，确定瓶颈再切分。Helm 管理部署，GitLab CI 做流水线，保证可回滚。

      实时通讯是重中之重。文本即时消息用 WebSocket（基于 Netty 自研长连接池），音视频则走 WebRTC + TURN 部署（coturn）配合 mediasoup 做多方混流或转码。遇到最多的问题是 NAT 与断链重连：解决策略包括短连接心跳、基于 token 的无状态恢复、以及在负载均衡层做会话亲和或通过路由表指向特定媒体节点。

      推荐与匹配采用混合架构：属性过滤靠 Elasticsearch，相似度检索用向量索引 Faiss（HNSW），离线特征通过 Kafka + Spark 批处理生成。实际经验告诉我，向量召回速度与内存占用成正比，必须做候选集裁剪和多级召回，且在冷启动阶段用规则覆盖以免推荐结果奇怪。

      安全与反作弊上不做表面工作：手机号与身份证使用脱敏和不可逆哈希存储，图片做人脸检测（MTCNN）+特征比对（InsightFace）并结合活体检测。限流用 Envoy 结合 Redis token-bucket，垃圾行为用布隆过滤器做快速去重；另外把密钥管理交给 Vault，实现定期轮换。这里要提醒：模型误判会影响用户体验，必须留人工复核通道。

      运维与观测不能靠事后补救。我用 Prometheus + Grafana 做指标，Jaeger 做分布式追踪，ELK 处理日志。CI/CD 推行灰度发布与金丝雀策略；压测用 k6，热点问题用 async-profiler 分析CPU火焰图。一次真实故障是因为单点媒体节点的内存泄露，幸亏追踪链路让定位在半小时内完成。

      总结一句经验：面向交友平台的工程不是单项技术堆叠，而是连续折中与快速验证。优先保证可观测性与安全边界，逐步优化匹配与媒体链路。未来可尝试把部分实时能力迁移到边缘节点以降低延迟，但先把基础夯实再做大动作，通常更稳妥。