闲鱼在ServiceMesh的探索和实践

2019 年 8 月 16 日

闲鱼在ServiceMesh的探索和实践

背景


在阿里服务端开发以 Java 为主的大背景下,其他异构语言业务如何调用现有 Java 服务,如何与集团中间件打通,就成为使用非 Java 语言团队必须要解决的首要问题。


现状


在 ServiceMesh 方案成熟之前,我们采用:通过 DartC/C++扩展方式调用各中间件客户端 SO 库(类 JNI)。该方案在业务初期很好的解决了 Dart 服务端生态建设问题。但是该方案还存在以下几个问题:


  • 运维耦合度高。业务代码和客户端SO库代码打包在一起,运行在同一进程,一旦微服务框架需要升级,业务代码也需要维护和重启。

  • 复杂性:进程内的多个语言环境,跨语言数据表示和传输等问题,都会增加系统的复杂性,降低原有服务的性能。

  • 接入成本高

  • 新功能滞后


ServiceMesh


由于现有方案存在的一些问题,我们转向 ServiceMesh 寻找解决问题的思路。



如上图所示:与目前比较常见的微服务框架相比,ServiceMesh 把微服务客户端核心功能独立出来,并作为一个独立 Proxy 进程部署在每一个主机上,业务进程通过 Proxy 进程与外界通信。这个独立的 Proxy 进程就是 ServiceMesh 的核心:SideCar。


业务进程和 SideCar 之间最常见的两种通信方案:1.基于 Iptables 的流量拦截转发方案,2.业务进程通过轻量化 Mesh 客户端直连 SideCar。从实现原理上看,Iptables 方案相比直连方案会有一定的性能损耗和延迟。我们选择的 ALiMesh 方案采用了轻量级 Mesh 客户端方案。


Mesh 化之后,业务进程只包含业务代码和轻量化的 MeshClient,代码逻辑变得简单,问题定位更清晰。业务同学可以更专注业务开发,而不用关注微服务庞杂的逻辑。微服务框架核心功能的开发维护扩展升级等工作由专门的 Mesh 团队负责,独立升级维护,与业务解耦,业务无感知。


ServiceMesh 方案解决了现有方案存在的:运维成本、接入成本问题,代码复杂问题。而且采用开源的 Mesh 方案,还可以借助开源的力量,不断增加新的功能。


AliMesh


SideCar 的引入,使得原本业务跟微服务之间的进程内通信转变成进程间的通信,进出流量增加了一跳,那么 ServiceMesh 的引入对业务性能带来的影响具体怎么样?接下来我们基于 ALiMesh(Istio 开源方案阿里版本)一起分情况看下。


ALiMesh 提供了 2 种接入方案:Http 方式、HSF 方式。其中 Http 方式又分为 Http1.0 和 Http2.0 方式。


AliMesh http 方案(快速接入)



如图所示,Http 方式下:在数据面,业务进程与 SideCar,SideCar 与 ServiceProvider 之间采用 Http 协议交互,数据编码采用 Json。业务进程集成了基于 Http 协议的 MeshClient,MeshSideCar 通过泛化调用远程调用 JavaHSF 服务。


而在控制面:ISTIO 控制面同步 ConfigServer 的服务提供者列表数据,SideCar 跟 ISTIOpilot 走原生的服务同步通道。


由于 Http 协议的通用性,该方案接入简单,快速的验证了 Mesh 方案的可行性,但是性能还达不到业务的线上要求,经测试,主要指标如下:



备注:目前闲鱼只使用了 ServiceMeshOutBound 功能。为了模拟线上详情页真实流量情况,每次上游请求处理过程会调用 21 次下游 JavaHSF 服务,所以图中 QPS 换算成 Mesh 流量时,需要乘以 21 倍,以下测试都是如此。


如图所示:Mesh 方式相比直连方式,Consumer 侧 CPU 消耗增长一倍,每一次 RPC 调用 RT 增加了近 2ms。且 HSFProvider 侧 CPU 也有近 40%的增加,这一点跟 HSF 同学的测试结果基本吻合。经过分析,我们初步定位引起 CPU 消耗增加的主要原因是 Http1.1 协议的连接方式(已经使用了连接池)和数据编码。


为了验证该方案的问题所在,我们测试接入了 Http2.0 方案。Http2.0 相比 Http1.x,在连接多路复用、数据格式、head 压缩等等方面具有天然的优势。经过测试,ALiMesh 的性能也较 Http1.x 有了较大的提升。部分满足或者接近我们的技术要求。详细指标如下图所示:



如图所示,优化后,业务进程 Consumer 侧,CPU 和 RT 消耗稍稍有些超标(CPU 增加不超过 20%)。为了探索更高性能,更低延迟的方案,我们转向了 HSF 私有协议方案。


AliMesh HSF 扩展协议方案(高性能)



如图所示,HSF 方案下,HSFRPC 协议实现为 MeshSideCar 的一个扩展协议。在数据面:业务进程与 SideCar,SideCar 与 ServiceProvider 之间采用 HSF2.0 私有协议,数据编码采用 Hessian1.0。业务进程集成了 Mesh 化改造的 HSFCPPSO 库作为 MeshClient,负责与 MeshSideCar 通信。而在控制面:SideCar 与 Configsvr 直连,同步服务提供者列表和配置信息,采用差量同步方式,以降低控制面板的 CPU 消耗。详细测试数据如下:



经过不断优化,最终成功将 MeshCPU 增长控制在 20%以内,每跳 RPC 调用 RT 增加控制在 1ms 以内。


ServiceMesh 在闲鱼的落地


目前 Dart+ALiMesh 方案在闲鱼服务端已经稳定运行八个月+,服务于闲鱼详情页、猜你喜欢,租房首页等业务,期间 Mesh 多次进行优化、升级、扩展功能等运维工作,业务进程都无感,正常对外提供服务,业务同学不需要参与。


ALiMesh 引入后,对线上业务 RT 的影响如下图所示:橙色的曲线是 Mesh 化后的业务 RT 监控曲线,蓝色的曲线是 Mesh 化前一周业务 RT 监控曲线,排除线上环境日常的波动后,ALiMesh 的引入对线上业务 RT 的影响相当小。



说在最后


ServiceMesh 方案,将微服务逻辑和服务间通信这些与业务无关的逻辑从业务应用中解耦出来,让业务应用瘦身,让业务同学更专注于业务开发。同时也让异构语言能够低成本的建立服务端生态,接入现有系统。


当然对于性能损失,个人认为总体利大于弊。业务团队可以根据自己业务实际情况进行测试评估,权衡利弊是否要接入 ServiceMesh。


接下来我们会进一步扩大 AliMesh 在闲鱼的应用,并与 ALiMesh 合作,推动 AliMesh 在 DartFaas 落地,适配更多的中间件。


本文转载自公众号闲鱼技术(ID:XYtech_Alibaba)


原文链接


https://mp.weixin.qq.com/s/-sXV_Cjg1vugNUiqv7RqEQ


2019 年 8 月 16 日 08:006280

评论

发布
暂无评论
发现更多内容

架构师训练营 - 第八周 - 总结

桔子

第九周作业

新世界

架构师训练营第8周学习总结

TH

第八周总结

LEAF

Homework - 数据结构与算法

River Tree

极客大学架构师训练营

架构师训练营 - 第八周 - 作业

桔子

要都练基本功

架构师

架构师训练营week08 学习总结

GunShotPanda

网络通讯协议总结

李广富

单向链表合并算法

走过路过飞过

学习总结 - 架构师训练营 - 第八周

走过路过飞过

第8周回顾

慵秋

架构师训练营第 0 期第 8 周作业

无名氏

第8周数据结构与算法&网络与数据库

架构师训练营week08 作业

GunShotPanda

【架构师训练营】第八期笔记

云064

网络通信

阿飞

架构 架构师

第八周总结

Acker飏

JVM详解之:HotSpot VM中的Intrinsic methods

程序那些事

Java JVM GC

DataNode服务机节点宕机时,HDFS的处理过程时序图。

Jam

【解构系统设计面试】什么是系统设计?以及如何设计一个新鲜事系统?

罗远航

系统设计

架构师训练营 - 总结 8

进击的炮灰

架构师训练营第 0 期 - 第 8 周 - 学习总结

架构师训练营 第 8 周总结

Jam

架构师培训 -08总结 数据结构算法,网络通信协议,非阻塞网络 I/O,数据库原理

刘敏

wordpress迁移+更换域名

wood

WordPress

判断两个链表是否合并

Acker飏

第八周链表练习

李广富

当DataNode 节点宕机的时,HDFS处理过程时序图

stars

使用Spring Validation优雅地校验参数

Java课代表

springboot

面试官问:僵尸进程和孤儿进程有了解过吗

Java小咖秀

Linux 学习 面试 进程 经验

闲鱼在ServiceMesh的探索和实践-InfoQ