携程ServiceMesh性能优化实践

　　一、背景
　　为了支撑业务的高速发展，从17年开始，携程内部逐步推进应用容器化改造与业务上云工作，同期携程技术架构经历了从集中式单体应用到分布式微服务化的演进过程。
　　随着Kubernetes的不断发展和推广，服务网格（ServiceMesh）在近几年也变得很流行。而ServiveMesh之所以越来越受欢迎，在提供更丰富的服务治理、安全性、可观测性等核心能力外，其从架构设计层面解决了以上几个痛点，服务治理能力以Sidecar的模式下沉到数据面，解决了SDK升级及多语言的问题，对于像负载均衡、熔断、限流等策略配置，由控制面统一管理和配置，并下发到数据面生效。在整体架构上云技术方案选型上，权衡各类方案的功能完备性、架构扩展性、改造维护成本及社区发展等，最终选择基于Istio构建ServiceMesh平台治理方案。1。1携程ServiceMesh发展
　　从2020年中，我们依托K8S底座能力，进行ServiceMesh技术预研，深度定制Istio，并与携程框架部门合作进行了小规模的落地试点。2021年底，接入非核心应用600，为ServiceMesh在携程的最终落地奠定基础。到目前为止，生产环境已有2000个应用（业务POD数近1W）接入，预期下半年推进核心应用的接入。
　　1。2携程ServiceMesh数据表现
　　在前期应用接入过程中，针对Istio稳定性（主要在性能）方面，梳理了以下几个问题：控制面并发性能：pilot对象处理的并发性能是否满足平台需求？控制面配置下发时效性：配置下发的延迟及准确性是否能够满足业务需求？
　　本文主要分享在当前的体量下，回答上述问题，使控制面平稳支撑大规模Sidecar的落地，通过下述优化之后，测试域（IstioCR量级在1W）如下图所示：
　　从实际生产来看，ServiceEntry的处理效率提升了15倍左右从测试域来看，整体initContext时延从原先P9930s左右到目前P99510秒左右从测试域来看，整体优化水平从原先P9930s到目前的P9915s左右（该处为全量推送水平，其中15s的结果是平衡资源使用与推送效率调参的目标值，这里PILOTDEBOUNCEAFTER设置为10s）开启增量推送后，实例推送在测试域的推送效果从1030s缩减至2。5s左右
　　携程目前Istio落地版本为1。10二、ServiceMesh优化的思路与挑战2。1现状
　　针对ServiceMesh在携程落地的服务目标，可以用一句话进行总结：能够通过横向扩展，支撑万级业务服务。为了完成上述目标，团队面临以下挑战：当前Istio的对象处理性能等方面无法满足平台需求配置下发的延迟及准确性无法满足业务需求
　　经过前中期，针对Istio架构进行深入研究以及上线前期测试的性能预研，核心问题聚焦在以下几点：istio对象处理性能较低：在处理ServiceEntry时的并发性缺失及WorkloadEntrySelector模式的计算高耗时等istio配置推送性能较低：配置推送时对象的全量处理拉长下发时延，并会随着Istio对象增长而近线性增长2。2优化实践
　　接下来主要分享携程所经历过的性能问题，和对应的优化的方向：
　　对象处理性能
　　当前istio使用内部queue处理各类Object事件，其为线性处理流程，效率比较低下，为此社区提供namespacefilter方式进行处理，以减缓性能问题，但针对Istio相关对象，未实现基于namespace的隔离，因此效率提升不太符合预期。
　　推送性能
　　xDS是istio控制面和数据面envoy之间的通信协议，其中x表示多种协议的集合，可以简单的把xDS理解为，网格内的服务发现数据和治理规则的集合。xDS数据量的大小和网格规模是正相关的。
　　当前istio下发xDS使用的是全量下发策略，也就是网格里的所有sidecar，内存里都会有整个网格内所有的服务发现数据。在大量服务实例的情况下，全量下发会影响Pilot和Sidecar的性能和稳定性，虽然Istio在不断的演进过程中引入了一些scoping的机制，就是Sidecar这个CRD，这个配置可以显式的定义服务之间的依赖关系，但该scoping方案还是无法达到业务侧的推送延迟预期。
　　首先，简要介绍一下Istio推送的过程：
　　注：这里使用海东同学的推送源码分析图
　　根据上图结合源码可知：StreamAggregatedResources会和当前的Proxy创建一个连接，并创建一个接受请求的reqChannel。同时开启一个新的协程receiveThread处理客户端主动发起的请求，期间调用s。globalPushContext（）。InitContext（s。Env，nil，nil）进行数据初始化，其中InitContext需要处理Istio所有CR的全量数据（如VirtualServices、DestinationRules、EnvoyFilters和SidecarScopes等），该操作耗时较长，因测试环境上述对象量级在2w左右，导致执行耗时P99在28s左右。从con。pushConnection中获取到pushEv事件后，调用s。pushConnection（）进行处理，判断是否为全量推送：ifpushRequest。Full｛UpdateProxywithcurrentinformation。s。updateProxy（con。proxy，pushRequest。Push）｝
　　其中updateProxy更新proxy当前信息，主要逻辑如下所示：func（sDiscoveryServer）updateProxy（proxymodel。Proxy，pushmodel。PushContext）｛s。setProxyState（proxy，push）ifutil。IsLocalityEmpty（proxy。Locality）｛。。。iflen（proxy。ServiceInstances）0｛proxy。Localityutil。ConvertLocality（proxy。ServiceInstances〔0〕。Endpoint。Locality。Label）｝｝｝func（sDiscoveryServer）setProxyState（proxymodel。Proxy，pushmodel。PushContext）｛proxy。SetWorkloadLabels（s。Env）proxy。SetServiceInstances（push。ServiceDiscovery）。。。proxy。SetSidecarScope（push）proxy。SetGatewaysForProxy（push）｝
　　在setProxyState方法中的环节获取SidecarScope等相关信息。针对上述介绍可以明确下面几个优化方向：虽然Istio针对K8S对象实现了基于namespace级别的隔离，但未对IstioCR对象实现namespace级别隔离在InitContext方法中，Push（）这么慢，主要是在req。Full做全量推送的时候，需要初始化PushContext，初始化PushContext的过程中需要调用initServiceRegistry、initEnvoyFilters和initSidecarScopes等，耗时巨大2。2。1Pilot性能优化
　　资源基于Namespace隔离
　　虽然Istio针对K8S对象实现了基于namespace级别的隔离，但未对IstioCR对象实现namespace级别隔离，基于此，内部团队针对Istio1。10。3版本针对IstioCR对象实现namespace隔离，使其影响范围控制在指定namespace下，其他用户操作IstioCR而彼此互不干扰，且能够极大缩减IstioEvent事件的处理，加速Pilot启动速度，提升事件处理效率，促进配置下发效率，在CRClient结构体中，新增namespaceFilter等相关字段，定义如下：ClientisaclientforIstioCRDs，implementingconfigstorecacheThisisusedforCRUDoperatorsonIstioconfiguration，aswellashandlingofeventsonconfigchangestypeClientstruct｛。。。namespaceInformerv1。NamespaceInformernamespaceFilterfilter。DiscoveryNamespacesFilter。。。｝
　　截至目前为止，携程Mesh平台主要分为SLB、SOA两大namespace，基于namespace隔离之后，效率提升预估在50左右。
　　ServiceEntryStore改造
　　ServiceEntryStore的数据处理性能问题，主要有以下几点：它里面有一个步骤，会全量更新实例的索引，这意味着service有一个发生变化了，它会更新全部service的索引，这是一个量级写放大WorkloadEntry与ServiceEntry的关联查询的耗时，随着彼此的数量逐步放大configController的Queue队列为线性处理，效率低下
　　因此，携程通过针对ServiceEntryStore进行ControllerRuntime改造，将ServiceEntry对象由线性处理改为并发处理，同时将WorkloadEntry结构体废弃，选择直接使用ServiceEntry，业务方Operator管理ServiceEntry对应Endpoint方式，优化处理性能，从实际生产效率来看，ServiceEntry的处理效率提升了4倍左右。
　　EnvoyFilter增量化改造
　　通过上述简介可知，Push（）这么慢，主要是在req。Full做全量推送的时候，需要初始化PushContext，初始化PushContext的过程，都是全量且嵌套循环处理，因此当多个对象量级巨大，则计算耗时成倍增长，针对EnvoyFilter的全量处理，不涉及其他对象，可以通过定义EnvoyFilterController结构体以Controller方式运行，从而实现全量改增量，结构体定义如下：typeControllerstruct｛xdsUpdatermodel。XDSUpdaterclientkube。Clientqueuecontrollers。QueueprocessedingressesenvoyFiltermap〔types。NamespacedName〕wrapEnvoyFilterWrapperenvoyFilterInformercache。SharedInformerenvoyFilterListerv1alpha3。EnvoyFilterListermutexsync。MutexenvoyFiltersByNamespacemap〔string〕〔〕wrapEnvoyFilterWrapper｝
　　Sidecar延迟及按需计算
　　在InitContext方法中，除了EnvoyFilter耗时较多外，initSidecarScopes同样耗时巨大，通过代码可知，Sidecar有两种，一种是带WorkloadSelector的，一种是不带的。不带Selector的话就是对这个命名空间所有服务生效。如果没有手动创建默认的Sidecar，Pilot会通过DefaultSidecarScopeForNamespace为当前命名空间创建一个默认的Sidecar，会将网格中所有的服务都遍历一遍，写入SidecarScope中。initSidecarScopes循环计算如下：sidecar数量x（egressConfigs数量x（selectVirtualServices耗时selectServices耗时）out。EgressListeners数量x（listener。services数量listener。virtualServices数量。。。））
　　因SidecarScope涉及其他CR对象结果，因此无法简单的由全量改增量，但可以通过延迟计算和按需计算方式，进行效率提升，延迟计算主要通过将initSidecarScopes计算逻辑后移至push阶段，按需计算即没必要计算所有Sidecar，只需要根据链接的proxy进行计算即可，通过上述的优化，可以做以下针对性调整：如果集群内服务较多，为每一个应用创建一个sidecar，防止所有服务信息推送给envoy，导致envoyOOM。在上述优化之后，InitContext的处理耗时可以从P9930s下降到P995s左右，此时，配置推送效率得到5倍左右的提升，那么setProxyState处的耗时，将会被放大，CPU的使用率将会成倍增长，可以通过下述配置进行优化。2。2。2Pilot配置优化
　　启用XDS增量推送
　　通过给istiod配置PILOTENABLEEDSDEBOUNCE环境变量，我们启用istiod的增量推送而无需等待fullpush。
　　减少推送量
　　将istiod的PILOTFILTERGATEWAYCLUSTERCONFIG环境变量配置为true，这样Istio将仅推送Gateway所需的服务信息，这个配置将极大的减少每次推送的量。开启这个特性之后，集群内的istiod每次向Gateway推送的服务信息降低90。
　　关闭Headless
　　将istiod的PILOTENABLEHEADLESSSERVICEPODLISTENERS环境变量配置为false，因为headlesssvc对应的endpoints发生了变化，会触发fullpush的行为。
　　提高吞吐
　　默认情况下，单个istiod的推送并发数只有100，在较大的集群内，可能会导致配置生效的延迟。istiod环境变量PILOTPUSHTHROTTLE可以配置这个并发数。建议根据集群规模进行配置。
　　避免频发推送
　　PILOTDEBOUNCEAFTER与PILOTDEBOUNCEMAX是配置istiod去抖动的两个参数。
　　默认配置是100ms与10s，这也就意味着，当集群中有任何事件发生时，Istio会等待100ms，如果开启EDS，则增量推送不会等待。
　　若100ms内无任何事件进入，Istio会立即触发推送。否则Istio将会等待另一个100ms，重复这一操作，直到总共等待的时间达到10s时，会强制触发推送。实践中可以适当调整这两个值以匹配集群规模和实际应用。携程内部调高PILOTDEBOUNCEAFTER到10s，以避免频繁推送对性能产生影响，也能够避免极端情况下推送不及时导致的503问题。三、ServiceMesh未来展望
　　控制面的重心在于解决规模化问题，后续控制面将会在下述领域深入探索：控制去除对k8s的资源的依赖，推送耗时下降到秒级别，满更规模的接使NDS实现DNS解析功能，避免search域多次查询，提升Mesh的可性
　　团队将与社区深度合作，针对控制面，密切关注增量推送等特性，后续将优先实现控制面稳定性增强，如下述功能：连接限流：通过限流功能，降低大量Sidecar同时连接同一个Pilot实例的风险，减少服务风暴发生的机率。熔断：基于生产场景的压测数据，测算出单实例Pilot可服务的Sidecar上限，超过上限值后，新连接会被Pilot拒绝。
　　ServiceMesh作为云原生领域下一代微服务技术，经过2年多摸索与演进，携程完成了多语言、多场景的业务落地，实际论证了ServiceMesh在流量管控、系统扩展性的优势，具有下沉服务治理能力到基础设施层，高度解耦中间件与业务系统的可行性。
　　后续，携程将在总结前期非核心应用ServiceMesh化改造的基础上，逐步推进核心应用的落地，同步打磨完善平台能力，全面提升稳定性，为行业落地ServiceMesh提供最佳实践和相关借鉴。参考资料百度大规模ServiceMesh落地实践不是所有的应用都需要ServiceMesh控制面核心组件istio在知乎大规模集群的落地实践IstioPilot源码分析（三）
　　【作者简介】
　　本文作者佐思、烧鱼、Shirley博，来自于携程CloudContainer团队，主要从事ServiceMesh在携程的落地，负责控制面的可用性及优化建设，以及推进各类基础设施服务的云原生化。该团队负责K8s容器平台的研发和优化工作，专注于推动基础设施云原生架构升级，以及创新产品的研发和落地。