陌陌云原生微服务架构落地实践总结
陌陌微服务平滑演进之路
陌陌微服务架构经历了从单体应用到 MOA 架构再到 Service Mesh 的演进过程，以支撑业务快速发展需求。
单体应用阶段
- 公司初期采用单体应用架构，适应功能快速迭代。
- 随着业务规模扩张，单体应用出现局限性：可靠性差、复杂度高、可扩展性差。
MOA 架构建立
- 2013 年开始引入微服务架构，自研 MOA 架构至今。
- MOA 架构优势：围绕业务能力构建、分散治理、独立自主组件、容错性设计、演进式设计。
- MOA 架构核心组件：注册中心（MomoKeeper）、服务发现（MOA 协议）、多语言支持。
可观测性建设
- 问题：异常定位困难、监控告警缺失、服务间依赖复杂、日志信息缺失。
- 解决方案：
- 统一监控平台（hubble）：分钟级打点监控、下游资源访问监控、上游调用来源监控、应用关联监控。
- 分布式跟踪系统（momotrace）：调用链路分析、慢请求分析。
- 应用日志：秒级 STAT 日志、慢请求及异常请求日志。
异构语言服务代理
- 背景：Java 生态外语言（如 Python、C++）需要提供服务。
- 实现：服务端通过 MOA Proxy 转发流量，客户端重复实现 MOA Client SDK。
- 问题：客户端流量未代理，导致服务治理困难。
Service Mesh 架构引入
- 痛点：Java SDK 升级缓慢、版本碎片化严重、异构语言治理落后。
- 解决方案：
- 将治理逻辑下沉到 sidecar 代理，实现业务解耦、独立容器自主升级、跨语言统一治理。
- Mesh 方案选型：
- 兼容存量服务，对接内部系统。
- 数据平面使用 Java 开发，自研控制平面。
- Mesh 架构设计：
- 数据平面：业务容器 + BAgent（MOA MESH 协议）。
- 控制平面：MOA 注册中心 + 服务治理（hubble） + 配置中心（pangu）。
平滑升级 Agent
- 技术：基于 Linux fd 迁移机制，旧 Agent 迁移存量连接到新 Agent，业务无感知。
- 效率：升级过程自主进行，无需业务方配合。
转发时延优化
- 问题：Agent 转发增加服务请求耗时。
- 优化措施：
- 减少编解码成本：请求分为 header 和 body。
- 构建对象池：减少对象创建。
- 非主干逻辑异步处理。
- 零拷贝 Netty 请求响应的 ByteBuf 数据。
- protobuf 编码优化。
- 结果：平均时延增加低于 0.3ms。
落地情况
- 线上服务覆盖率：70%。
- 项目升级速度：230 个/人天。
Mesh 时代的服务治理
- 优化：监控指标细化到 10 秒粒度、优化 p99 耗时指标、优化长尾请求、优化容错调用端异常实例检测。
- 推广效率：治理能力推广全覆盖仅耗费几周时间。
Service Mesh 的问题
- 问题：Agent 时延对时延敏感业务影响明显，大消息体服务问题更突出。
- 解决方案：
- 共享内存通信：时延可降低到 0.1ms 以内。
- Java Agent 形式提供服务治理能力：消除进程间通信成本。
总结
陌陌微服务架构演进的核心是为支撑业务发展，部分参考业界实践，部分自主探索。引入 Mesh 架构主要解决服务治理问题。架构选择应坚持实用主义和保持兼容原则。
