背景：
在阿里服务端开发以Java为主的大背景下，其他异构语言业务如何调用现有Java服务，如何与集团中间件打通，就成为使用非Java语言团队必须要解决的首要问题。
已有方案问题：
在ServiceMesh方案成熟之前，我们采用：通过Dart C/C++扩展方式调用各中间件客户端SO库（类JNI）。该方案在业务初期很好的解决了Dart服务端生态建设问题。但是该方案还存在以下几个问题：
- 运维耦合度高。业务代码和客户端SO库代码打包在一起，运行在同一进程，一旦微服务框架需要升级，业务代码也需要维护和重启。
- 复杂性：进程内的多个语言环境，跨语言数据表示和传输等问题，都会增加系统的复杂性，降低原有服务的性能。
- 接入成本高
- 新功能滞后
ServiceMesh方案:
由于现有方案存在的一些问题，我们转向ServiceMesh寻找解决问题的思路
如上图所示：与目前比较常见的微服务框架相比，ServiceMesh把微服务客户端核心功能独立出来，并作为一个独立Proxy进程部署在每一个主机上，业务进程通过Proxy进程与外界通信。这个独立的Proxy进程就是ServiceMesh的核心: SideCar。
业务进程和SideCar之间最常见的两种通信方案：1. 基于Iptables的流量拦截转发方案，2. 业务进程通过轻量化Mesh客户端直连SideCar。从实现原理上看，Iptables方案相比直连方案会有一定的性能损耗和延迟。我们选择的ALiMesh方案采用了轻量级Mesh客户端方案。
Mesh化之后，业务进程只包含业务代码和轻量化的Mesh Client，代码逻辑变得简单，问题定位更清晰。业务同学可以更专注业务开发，而不用关注微服务庞杂的逻辑。微服务框架核心功能的开发维护扩展升级等工作由专门的Mesh团队负责，独立升级维护，与业务解耦，业务无感知。
ServiceMesh方案解决了现有方案存在的：运维成本、接入成本问题，代码复杂问题。 而且采用开源的Mesh方案，还可以借助开源的力量，不断增加新的功能。
ALiMesh接入:
SideCar的引入，使得原本业务跟微服务之间的进程内通信转变成进程间的通信，进出流量增加了一跳，那么ServiceMesh的引入对业务性能带来的影响具体怎么样？接下来我们基于ALiMesh(Istio开源方案阿里版本)一起分情况看下。
ALiMesh提供了2种接入方案：Http方式、HSF方式。其中Http方式又分为Http1.0和Http2.0方式。
AliMesh Http方案（快速接入方案）：
如图所示，Http方式下：在数据面，业务进程与SideCar，SideCar与Service Provider之间采用Http协议交互，数据编码采用Json。业务进程集成了基于Http协议的Mesh Client，Mesh SideCar通过泛化调用远程调用Java HSF服务。
而在控制面： ISTIO控制面同步ConfigServer的服务提供者列表数据，SideCar跟ISTIO pilot走原生的服务同步通道。
由于Http协议的通用性，该方案接入简单，快速的验证了Mesh方案的可行性，但是性能还达不到业务的线上要求，经测试，主要指标如下：
备注：目前闲鱼只使用了ServiceMesh OutBound功能。为了模拟线上详情页真实流量情况，每次上游请求处理过程会调用21次下游Java HSF服务, 所以图中QPS换算成Mesh流量时，需要乘以21倍，以下测试都是如此
如图所示：Mesh方式相比直连方式，Consumer侧CPU消耗增长一倍，每一次RPC调用RT增加了近2ms。且HSF Provider侧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方案下，HSF RPC协议实现为Mesh SideCar的一个扩展协议。在数据面：业务进程与SideCar，SideCar与Service Provider 之间采用HSF 2.0私有协议，数据编码采用Hessian 1.0。业务进程集成了Mesh化改造的HSFCPP SO库作为MeshClient，负责与Mesh SideCar通信。而在控制面：SideCar与Configsvr直连，同步服务提供者列表和配置信息，采用差量同步方式，以降低控制面板的CPU消耗。详细测试数据如下：
经过不断优化，最终成功将Mesh CPU增长控制在20%以内，每跳RPC调用RT增加控制在1ms以内。
ServiceMesh在闲鱼的应用：
目前Dart+ALiMesh方案在闲鱼服务端已经稳定运行八个月+，服务于闲鱼详情页、猜你喜欢，租房首页等业务, 期间Mesh多次进行优化、升级、扩展功能等运维工作，业务进程都无感，正常对外提供服务，业务同学不需要参与。
ALiMesh引入后，对线上业务RT的影响如下图所示：橙色的曲线是Mesh化后的业务RT监控曲线，蓝色的曲线是Mesh化前一周业务RT监控曲线，排除线上环境日常的波动后，ALiMesh的引入对线上业务RT的影响相当小。
总结与展望:
ServiceMesh方案，将微服务逻辑和服务间通信这些与业务无关的逻辑从业务应用中解耦出来，让业务应用瘦身，让业务同学更专注于业务开发。同时也让异构语言能够低成本的建立服务端生态，接入现有系统。
当然对于性能损失，个人认为总体利大于弊。业务团队可以根据自己业务实际情况进行测试评估，权衡利弊是否要接入ServiceMesh。
接下来我们会进一步扩大AliMesh在闲鱼的应用，并与ALiMesh合作，推动AliMesh在Dart Faas落地，适配更多的中间件。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
