闲鱼在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