携程Service Mesh性能优化实践

作者简介

本文作者佐思、烧鱼、Shirley博，来自于携程Cloud Container团队，主要从事Service Mesh在携程的落地，负责控制面的可用性及优化建设，以及推进各类基础设施服务的云原生化。该团队负责K8s容器平台的研发和优化工作，专注于推动基础设施云原生架构升级，以及创新产品的研发和落地。

一、背景

为了支撑业务的高速发展，从17年开始，携程内部逐步推进应用容器化改造与业务上云工作，同期携程技术架构经历了从集中式单体应用到分布式微服务化的演进过程。

随着Kubernetes的不断发展和推广，服务网格（Service Mesh）在近几年也变得很流行。而 Servive Mesh 之所以越来越受欢迎，在提供更丰富的服务治理、安全性、可观测性等核心能力外，其从架构设计层面解决了以上几个痛点，服务治理能力以 Sidecar 的模式下沉到数据面，解决了 SDK 升级及多语言的问题，对于像负载均衡、熔断、限流等策略配置，由控制面统一管理和配置，并下发到数据面生效。在整体架构上云技术方案选型上，权衡各类方案的功能完备性、架构扩展性、改造维护成本及社区发展等，最终选择基于Istio构建Service Mesh平台治理方案。

1.1 携程Service Mesh发展

从2020年中，我们依托K8S底座能力，进行Service Mesh技术预研，深度定制Istio，并与携程框架部门合作进行了小规模的落地试点。2021年底，接入非核心应用600 ，为Service Mesh在携程的最终落地奠定基础。到目前为止，生产环境已有2000个应用（业务POD数近1W）接入，预期下半年推进核心应用的接入。

1.2 携程Service Mesh数据表现

在前期应用接入过程中，针对Istio稳定性（主要在性能）方面，梳理了以下几个问题：

控制面并发性能：pilot对象处理的并发性能是否满足平台需求？

控制面配置下发时效性：配置下发的延迟及准确性是否能够满足业务需求？

本文主要分享在当前的体量下，回答上述问题，使控制面平稳支撑大规模 Sidecar 的落地，通过下述优化之后，测试域（Istio CR量级在1W ）如下图所示：

从实际生产来看，ServiceEntry的处理效率提升了15倍左右从测试域来看，整体initContext时延从原先P99 30s左右到目前P99 5-10秒左右从测试域来看，整体优化水平从原先P99 30s 到目前的P99 15s左右（该处为全量推送水平，其中15s的结果是平衡资源使用与推送效率调参的目标值，这里PILOT_DEBOUNCE_AFTER