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