陌陌Service Mesh落地实践

分享内容

1. 陌陌微服务架构演进

1. 架构痛点与 Service Mesh

1. 陌陌 Service Mesh 架构实践

1. 总结

​

背景

2016 年，Service Mesh 进入公众视野之后一直保持着高速发展的状态，目前已成为业内广泛认可的下一代微服务架构，并且被 CNCF 列入构建容错性好、易于管理与观察的云原生应用所依赖的关键技术。

2019 年底，经过多年微服务架构实践积累、对现有架构痛点总结分析以及多个阶段的思考与评估后，陌陌正式启动了 Service Mesh 落地项目 MOA Mesh。本次分享将从原有微服务架构谈起，详细讲述陌陌 Service Mesh 架构的探索过程，希望能给业内同样关注如何落地 Service Mesh 的技术人员提供参考。

陌陌微服务架构演进

2013 年，陌陌架构团队完成了微服务架构的研发与推广，考虑到当时业内还没有成熟的开源产品，陌陌自研了服务框架 MOA（Momo service Oriented Architecture），并应用到了多条业务线，例如附近动态、直播、IM、短视频等。

随着业务的不断增长，MOA 完成了对自身能力与稳定性的验证，发布服务 2000+，注册实例 2 万 +，全天调用量 3500 亿，峰值时 QPS 达到 600 万。

发展历程

为了支撑大规模业务服务运行，MOA 除了需要不断完善自身之外，还需要与其他基础架构产品协同运作，如：监控、异步、配置、日志、分布式跟踪、压测等平台与系统。

回顾陌陌整个微服务体系的发展历程，2011 年还是在使用单体应用，2012 年开始拆分系统，2013 年自研了微服务框架 MOA，2017 年实现了应用容器化，2020 年落地 Service Mesh 架构。

陌陌微服务体系发展历程

多语言支持

陌陌服务端架构采用了 PHP API + Java 后端服务的多语言架构，以同时获得 PHP 的开发效率与 Java 的高性能优势。这也使得 MOA 从一开始就要应对跨语言调用带来的挑战。

MOA 的核心组件是 Java 语言的 SDK，在微服务体系中我们又进一步引入以下机制简化其他语言 SDK 的开发工作

• 能够复用成熟 Redis 客户端的 Redis GET 跨语言传输协议
• 通过域名访问、与普通服务调用方式一致的地址查询服务 Lookup
• 由 Java 开发、以 sidecar 方式部署、作为入流量代理的 MOA Proxy，支持非 Java 语言发布服务、接入整体微服务体系

整体架构

在融入相关基础架构产品以及多语言支持机制后，MOA 1.0 微服务体系已具备较为全面的服务治理能力。

MOA 整体架构如下图所示，其中 MOA Watcher 是中心化的健康检测系统，同时 MOA 客户端也具备自动容错机制；并行调用代理是为了支持 PHP 语言实现并行调用的中心化出流量代理。

架构痛点与 Service Mesh

架构痛点分析

在业务规模不断扩大、微服务架构持续演进的过程中，存在一些始终无法彻底得到解决的问题，它们可以统一归纳为 “服务治理能力滞后” 问题。

非 Java 应用能力滞后

原有架构中采取了很多简化开发多语言 SDK 的机制，但在中间件团队以 Java 工程师为主导的情况下，其他语言 SDK 的迭代速度还是会远落后于 Java SDK，导致其他语言 SDK 缺少很多关键的功能，并且无法快速完成修复与补充。

Java 应用能力滞后

Java SDK 具备最完善的服务治理能力，但当 Java 应用的数量达到数千规模，SDK 的升级会成为极其困难的工作，使新开发的功能同样无法快速在每个应用上得以运用。即使在一些紧急情况下集中进行推广，每个应用修改版本依赖、重新发布的过程也会耗费业务团队和基础架构团队大量的时间精力，对整体业务迭代效率产生负面影响。

滞后问题危害

服务治理能力滞后问题使整体的微服务架构无法实现统一。缺失的能力会使应用的稳定性受损，甚至引发故障。在进行重大架构变更时，缺失以及无法快速补充的能力会成为理想方案的阻碍，从而被迫选择其他存在缺陷的方案。

引入 Service Mesh

Service Mesh 将服务框架核心逻辑剥离到本地代理进程的方式，能够使 Java SDK 升级和多语言 SDK 重复开发问题得到彻底解决。但是否应该引入这项全新的架构方案，还需要对以下问题进行深入、全面的评估：

• 是否足够成熟、不对稳定性造成影响
• 是否有其他方案能够达成相同的目标
• 是否投入有限、可以接受的成本
• 是否能真正解决问题、带来期望的价值