陌陌服务器怎么了？

我无法获取陌陌内部的机密架构文档，但可以根据公开发布的技术分享、行业通用实践以及招聘信息中透露的技术栈，为你梳理和解析陌陌服务器后端是如何“搭建”和工作的。

陌陌的服务器技术可以拆解为以下几个核心层面：

宏观架构：微服务与分布式

陌陌早已从早期的单体架构演进为微服务架构，这意味着整个App的功能被拆分成数十个甚至上百个独立的、小型化的服务。

好处

解耦每个服务（如用户服务、动态（时刻）服务、直播服务、消息服务、充值服务）独立开发、部署和扩展，一个服务出问题不会导致整个系统崩溃。

技术栈灵活不同的服务可以根据业务特点选择最适合的语言和框架（如Go, Java, Python, C++）。

弹性伸缩哪个功能忙就扩展哪个服务对应的服务器资源，比如直播晚高峰就扩展直播相关的服务集群。

核心技术组件与方案

a. 通信与消息推送 - 核心中的核心

作为社交App，即时消息（IM）和实时推送是生命线。

长连接网关用户App和服务器之间维持一个TCP长连接通道，用于实现消息的实时收发和推送，这个网关集群需要承受海量连接。

协议很可能采用自研或深度优化的TCP协议，也可能使用MQTT等轻量级协议，保证在弱网络下的效率和可靠性。

技术选型早期可能使用Netty（Java）或Mina等高性能网络框架自研网关，现在也更可能使用Go语言来构建，因为Go在并发连接处理上极具优势。

b. 动态（时刻）与社交信息流

类似于朋友圈或微博，这是一个“读多写少”的场景。

写扩散 vs 读扩散

写扩散（推模式）你发布一条动态后，系统会立刻将这条动态“推”送到你所有粉丝的“收件箱”（缓存）里，当粉丝刷新时，直接从自己的缓存里读取，体验快，但对发布者粉丝量巨大的大V不友好（爆炸性写入，即“粉丝写扩散”）。

读扩散（拉模式）动态只存在发布者的个人页，粉丝刷新时，系统去把所有关注的人的动态“拉”过来再聚合排序，对发布者友好，但读取时延迟高、压力大。

陌陌的实践通常采用混合模式，对普通用户采用写扩散，保证读取速度；对粉丝数超阈值的大V采用读扩散，平衡系统负载，这需要非常智能的调度系统。

技术选型大量使用Redis作为缓存，使用MySQL分库分表存储最终数据，使用Elasticsearch等进行搜索和推荐。

c. 直播与音视频服务

这是技术门槛最高的部分之一，涉及信令控制和流媒体处理。

信令服务器负责处理“创建房间”、“加入房间”、“送礼”、“弹幕”等指令，可能用Node.js或Go实现高并发信令交互。

音视频传输绝不会由业务服务器直接传输，而是由专门的流媒体服务器集群处理。

* 主播端采集音视频 -> 推流到陌陌的CDN节点或自建流媒体集群（可能基于SRS、ZLMediaKit等开源方案，或自研）。

* 观众端从CDN节点拉流观看。

CDN大量使用CDN进行音视频内容的分发，加速访问，降低中心机房压力。

d. 数据存储

关系型数据库MySQL是绝对的主力，但单台MySQL肯定不够，会进行大量的分库分表（如根据用户ID取模拆分），形成分布式数据库集群，中间会使用MyCAT或ShardingSphere等中间件来管理。

缓存Redis无处不在，用作热点数据缓存、会话存储、计数器（点赞、粉丝数）、消息队列等，极大提升读写性能。

对象存储用户上传的图片、视频文件等会存储到对象存储（如自建HDFS集群或使用云服务）中，并通过CDN加速访问。

大数据与 analytics使用Hadoop、Spark、Flink、Kafka等技术构建大数据平台，处理用户行为日志，进行实时分析和推荐算法计算。

e. 协调与发现

在庞大的微服务集群中，服务如何互相发现和调用？

服务注册与发现使用Etcd、ZooKeeper或Nacos等服务，让每个服务启动时都“注册”自己，调用者从这些中心发现目标服务的地址。

RPC框架服务之间的内部通信使用高效的RPC（远程过程调用）框架，如Apache Thrift、gRPC或自研的RPC框架，而不是低效的HTTP API。

f. 运维与监控

容器化几乎可以肯定，陌陌的服务现在都运行在Docker容器中。

编排使用Kubernetes来管理和调度成千上万的容器实例，实现自动化部署、扩缩容和故障恢复。

监控使用Prometheus监控机器和服务指标，Grafana做可视化仪表盘，ELK（Elasticsearch, Logstash, Kibana）套件收集和查询日志，时刻掌握系统健康度。

“陌陌怎么服务器”这个问题可以概括为：

> 它是一个基于微服务架构，通过Kubernetes管理的Docker容器集群，使用Go、Java等语言构建了长连接网关、业务逻辑和信令服务，依赖MySQL（分库分表）、Redis（缓存）、CDN和流媒体服务器存储和处理数据与音视频流，利用Etcd等服务发现组件和RPC框架实现内部通信，并通过Prometheus、ELK等工具实现全面监控。

这背后是成百上千台服务器协同工作的结果，分布在多个数据中心（机房），通过负载均衡器将全球用户的请求分发到最合适的节点上，以此支撑起千万级用户的同时在线和互动。

文章摘自：https://idc.huochengrm.cn/fwq/15559.html