作为业内首个全托管Istio兼容的阿里云服务网格产品ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM产品是基于社区Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了Istio组件与所管理的K8s集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。从2022年4月1日起，阿里云服务网格ASM正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障，更好地满足客户的不同需求场景，详情可进入阿里云官方网站 - 搜索服务网格ASM。
在上一篇文档一个开关就让服务网格变快——概述篇中，我们简要阐述了ASM自适应配置推送优化能力的工作原理。本文将通过对照实验的方式，展示在大规模集群的场景下自适应配置推送对性能具体的优化效果。
实验环境
我们部署了一个包含50个节点的集群作为实验集群，每个节点的规格统一为4vCPU，32G内存，使用ASM服务网格对集群进行管理。在集群中我们创建两个的命名空间：adaptive和controll，其中adaptive命名空间为实验组，开启自适应配置推送优化能力，controll命名空间为对照组，不做特殊处理。
在实验过程中，我们分批次向集群中添加共计700个httbpin应用的pod，每批次添加100个，其中每个命名空间各50个，观察这个过程中集群中envoy的内存占用。Pod准备完成后，我们在两个命名空间中各使用一个包含curl的pod轮流访问此命名空间中全部350个httpbin服务以建立服务间的依赖关系，然后向两个命名空间中配置同样的虚拟服务以触发路由规则变更，观察控制面向Sidercar代理下发的xDS配置数量。
数据分析
下图展示了随着集群中应用规模的扩大，envoy代理所消耗的内存的变化情况，其中红色代表开启了自适应配置推送的adaptive命名空间，绿色代表未开启的controll命名空间。可以看到，随着pod数量的增加，自适应配置推送优化能力节省内存的效果越明显。在700pods的规模下，相较于对照组，adaptive命名空间中envoy使用的总内存减少了约22G，降低比例约68%。
下图展示的则是集群中应用规模扩大的过程中，envoy接受到的新增cluster配置推送的数量，其中红色代表开启了自适应配置推送的adaptive命名空间，绿色代表未开启的controll命名空间。结果显示开启自适应配置推送优化能够减少约41%左右的推送。
当集群内服务的依赖关系建立完成后，控制面将不再向envoy更新其“不感兴趣”的服务的配置信息。我们通过向两个命名空间添加相同的虚拟服务来验证这一点。
服务网格ASM的控制面日志采集功能可以方便地将控制面的日志采集至阿里云日志服务SLS，以便查询、分析和配置日志告警。我们使用此功能，对测试期间控制面的配置推送情况进行了分析。
从日志能够得出，在测试期间，控制面向adaptive命名空间进行了255次rDS推送，向controll命名空间进行了1053次rDS推送。不难看出，在更新路由配置时，开启自适应配置推送优化将大大减轻控制面的压力。
结论
服务网格ASM提供的自适应配置推送优化能力能够帮助用户简化繁琐的Sidercar配置，以一键式开关的方式，自动生成Sidercar资源对网格中的envoy代理进行优化。在服务间依赖关系发生改变时，通过该能力生成的Sidecar资源也能够自动地发生变更，无需用户手动管理。通过对照实验我们可以看出，开启自适应配置推送优化后，能够减少集群中envoy的内存占用、xDS推送流量、控制面压力，并且随着集群规模的增加，优化的效果越明显。利用服务网格ASM提供的这一能力，能够在大规模集群中为用户提供更强大的性能和资源占用表现。
