03-陌陌云原生微服务架构落地实践-袁世超

陌陌云原生微服务架构落地实践 袁世超 目录 •陌陌微服务平滑演进之路 •陌陌微服务治理现状与挑战 •陌陌ServiceMesh落地实践 陌陌微服务发展历程 单体应用 MOA微服务架构建立 日志平台分布式跟踪系统 应用容器化 限流容错 2011201220132014201520162017201820192020 系统拆分 PHPAPI+Java后端 配置中心监控平台 异步调用平台 并行调用代理异构语言代理 服务鉴权 ServiceMesh 架构落地 陌陌微服务整体架构 注册中心 （MomoKeeper） MOA Watcher （健康检查） 1.注册中心 Redis作为底层存储 MOAWatcher中心化健康检测 服务发现（lookup） 查询 客户端 订阅 XClient 2.多语言支持 中心化地址发现服务 Client C++ClientPHP/Python 服务端 JavaClient MOA协议 MeshAgent 注册 MeshAgent MOA传输协议服务流量代理 3.关联产品支持 配置中心 异步调用平台 C++ServerJavaServer 基于brpc XServer 健康检查 统一监控平台分布式跟踪系统压测平台 陌陌微服务整体情况 服务数 千级 峰值QPS 千万级 实例数 万级 全天调用量 万亿级 关键演进 1 2 3 MOA架构建立可观测性建设 异构语言服务代理 4 ServiceMesh架构引入 MOA架构建立 单体应用的问题 复杂度高，所有业务都堆在一起 可靠性差，一个小问题导致整体不可用 可扩展性差 制约业务 迭代效率 公司初期业务规模小，单体应用架构是合适的，适应功能快速迭代的需求。 但是随着业务规模的扩张，单体应用的局限性也凸显了出来。 MOA架构建立 MOA的时代背景 面对单体应用的问题，首先进行了系统拆分，但是效果并不理想，随后微服务架构开始流行，陌陌于2013年开启了微服务架构的时代，自研MOA架构落地，一直使用至今。放到微服务发展的大背景下，陌陌可以说是最早一批实践微服务的公司。 2011 2012 2013 Dubbo开源 JamesLewis发布著名的《Microservice-Java,theUnixWay》主题演讲 陌陌自研微服务架构MOA落地 2014MartinFowler&JamesLewis发布著名的《Microservice:ADefinitionofThisNewArchitecturalTerm》文章 客户端 PHPAPI 查询 MOA协议 MOA服务A 发现 MOA协议 注册 MOA服务B 注册中心 （MomoKeeper） 服务发现 （lookup） MOA架构建立 MOA的收益 MOA架构为业务快速迭代和扩张提供了坚实的基础，其优势主要体现在： •围绕业务能力构建（康威定律） •分散治理 •通过服务来实现独立自主的组件 •容错性设计 •演进式设计 可观测性建设 异常问题定位 服务间依赖复杂 监控告警缺失 日志信息缺失 无法快速 定位异常 在服务规模越来越大的背景下，当某个服务出异常时，如何快速有效定位成了迫切需要解决的问题。换句话说，我们需要提高MOA架构的可观测性。 可观测性建设 可观测性三大支柱 1.统一监控平台（hubble） 分钟级打点监控（全面、准确）下游资源访问监控（作为客户端）上游调用来源监控（作为服务端） 应用关联监控：GC、进程、Error日志、容器、物理机 2.分布式跟踪系统（momotrace） 调用链路分析慢请求分析 3.应用日志 秒级STAT日志 慢请求及异常请求日志（记录下游IP）日志平台统一采集、分析、展示 The3PillarsofSystemObservability 异构语言服务代理 支持异构语言提供服务 MOA是以Java生态构建的，但是在某些领域Java并不是主流的语言，比如大数据领域主要使用Python和C++，而且他们也有向外提供服务的需求。 MOA对异构语言的支持是通过“服务代理”的形式实现的，该方案在2016年落地，可以说是对ServiceMesh思想的蒙昧尝试。 异构语言服务代理 服务代理实现 PHPClient 查询 MOA协议 MOAProxy 注册 FCGI MOA协议 PHPServer 注册中心 （MomoKeeper） 服务发现 （lookup） PythonClient MOA协议 MOAProxy GRPC PythonServer •服务端 异构语言根据自身情况实现服务MOAProxy提供MOA接口，进行流量转发 •客户端 异构语言重复实现MOAClientSDK 客户端流量没有进行代理，Client由异构语言自己实现，给之后的服务治理埋下了大坑。 版本碎片化严重 *线上使用的版本有50+个 异构语言治理落后 *异构语言SDK功能滞后 *很多组件由业务团队自己维护，无法统一 ServiceMesh架构引入 服务治理的痛点 JavaSDK升级缓慢 *升级周期需要一个季度 *耗费业务团队和SRE大量精力 •MOA在服务治理方法一直存在一些痛点： ServiceMesh架构引入 Mesh解决服务治理的痛点 •MOA治理逻辑下沉到sidecar代理 业务解耦，独立容器 自主升级，统一演进 跨语言统一治理 自研数据平面与控制平面 使用Java开发数据平面 ServiceMesh架构引入 兼容性 • • 使存量服务接入Mesh方案 对接大量内部系统 关键需求 • • 关键收益来源数据平面建设 非完善的控制平面功能 其它因素 • • 最成熟的服务端语言为Java 技术体系内不引入其它语言 Mesh方案选型 ServiceMesh架构引入 服务实例Pod 业务容器 B 数据平面 MOAMESH协议 Agent Kubernetes 私有协议 控制平面 MOA 注册中心 MOA 服务治理 pangu 配置中心 hubble 监控 服务实例Pod 业务容器A Agent Mesh架构 •重点建设Agent •将原有治理平台封装为控制平面 ServiceMesh架构引入 平滑升级Agent 在Mesh架构下，平稳升级Agent成为了服务治理的关键，为此我们基于Linuxfd迁移机制设计了Agent平滑升级： •升级过程业务无感知 旧Agent将存量连接迁移到新Agent，不影响上层业务处理请求 •升级效率大幅提升 升级过程完全自主进行，不需要业务方配合 ServiceMesh架构引入 转发时延 Mesh架构增加了一层Agent转发，在服务治理方法有巨大收益，但是也会增加服务请求耗时，为了减少时延的损耗，我们做了大量优化，最终将平均时延增加降低到了0.3ms以内。 优化措施包括但不限于： 1.减少编解码成本，将请求分为header和body两部分，agent只需处理header； 2.构建对象池，减少对象创建； 3.非主干逻辑改为异步处理； 4.零拷贝Netty请求响应的ByteBuf数据，直接透传； 5.针对agent修改部分字段的场景对protobuf编码进行优化； ServiceMesh架构引入 落地情况 70% 覆盖率 230 升级速度 目前线上服务整体覆盖率超过70% 项目升级速度超过230个/人天 Mesh时代的服务治理 •优化可观测性 监控指标细化到10秒粒度 通过DDSketch算法优化p99耗时指标 •优化长尾请求backuprequest •优化容错 调用端异常实例检测 得益于Mesh架构的优势，这种治理能力的推广全覆盖仅耗费了几周时间，在之前这是不敢想象的推广效率。 ServiceMesh的问题 agent时延 agent转发带来的时延增量，对于我们大部分服务是可以接受的，但是也存在一些时延敏感的业务，另外对于大消息体的服务问题会更明显。 目前已经在两个方向进行尝试： 1.两个进程之间使用共享内存通信。 初步来看时延可以降低到0.1ms以内，并且在高负载场景更稳定 2.以JavaAgent的形式提供服务治理能力。 这样可以消除进程间通信的成本 总结 陌陌微服务架构的演进，总的来说是为了支撑业务的发展。其中有些演进点参考了业界实践，有些演进点是自己摸着石头过河。最近我们引入Mesh架构，也并不是完全复制业界标准，主要的落脚点是解决服务治理的问题。 架构模式层出不穷，如何选择？我们认为应该坚持两个原则： •实用主义 •保持兼容