成都房地产走势,移动端优化,网站建设案例怎么样,wordpress媒体文件背景#xff1a;
在阿里服务端开发以Java为主的大背景下#xff0c;其他异构语言业务如何调用现有Java服务#xff0c;如何与集团中间件打通#xff0c;就成为使用非Java语言团队必须要解决的首要问题。
已有方案问题#xff1a;
在ServiceMesh方案成熟之前#xff0c…背景
在阿里服务端开发以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方式下在数据面业务进程与SideCarSideCar与Service Provider之间采用Http协议交互数据编码采用Json。业务进程集成了基于Http协议的Mesh ClientMesh 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的一个扩展协议。在数据面业务进程与SideCarSideCar与Service Provider 之间采用HSF 2.0私有协议数据编码采用Hessian 1.0。业务进程集成了Mesh化改造的HSFCPP SO库作为MeshClient负责与Mesh SideCar通信。而在控制面SideCar与Configsvr直连同步服务提供者列表和配置信息采用差量同步方式以降低控制面板的CPU消耗。详细测试数据如下 经过不断优化最终成功将Mesh CPU增长控制在20%以内每跳RPC调用RT增加控制在1ms以内。
ServiceMesh在闲鱼的应用
目前DartALiMesh方案在闲鱼服务端已经稳定运行八个月服务于闲鱼详情页、猜你喜欢租房首页等业务, 期间Mesh多次进行优化、升级、扩展功能等运维工作业务进程都无感正常对外提供服务业务同学不需要参与。
ALiMesh引入后对线上业务RT的影响如下图所示橙色的曲线是Mesh化后的业务RT监控曲线蓝色的曲线是Mesh化前一周业务RT监控曲线排除线上环境日常的波动后ALiMesh的引入对线上业务RT的影响相当小。 总结与展望:
ServiceMesh方案将微服务逻辑和服务间通信这些与业务无关的逻辑从业务应用中解耦出来让业务应用瘦身让业务同学更专注于业务开发。同时也让异构语言能够低成本的建立服务端生态接入现有系统。
当然对于性能损失个人认为总体利大于弊。业务团队可以根据自己业务实际情况进行测试评估权衡利弊是否要接入ServiceMesh。
接下来我们会进一步扩大AliMesh在闲鱼的应用并与ALiMesh合作推动AliMesh在Dart Faas落地适配更多的中间件。
原文链接 本文为云栖社区原创内容未经允许不得转载。
