我们知道，服务网格作为一种用来管理应用服务通信的基础核心技术, 为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。我们针对开源社区Istio和阿里云服务网格ASM产品分别进行了调研，通过试用了解到作为云厂商的产品， ASM具备了若干生产使用的功能和实战经验，具体来说， ASM增强了多协议支持以及动态扩展能力，提供精细化服务治理，完善零信任安全体系，并持续提升性能及大规模集群支持能力，降低在生产环境落地服务网格的门槛。商业版适用于有多语言互通，服务精细治理需求，在生产环境大规模使用服务网格的场景。详细的介绍可以参见：https://help.aliyun.com/document_detail/176082.html

通过调研，我们了解到作为业内首个全托管Istio兼容的服务网格产品ASM，一开始从架构上就保持了与社区、业界趋势的一致性，控制平面的组件托管在阿里云侧，与数据面侧的用户集群独立。ASM产品是基于社区开源的Istio定制实现的，在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式，解耦了Istio组件与所管理的K8s集群的生命周期管理，使得架构更加灵活，提升了系统的可伸缩性。

托管式服务网格ASM在成为多种异构类型计算服务统一管理的基础设施中, 提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及实现统一的代理可扩展能力, 以此构筑企业级能力。可以通过https://www.aliyun.com/product/servicemesh 查看具体的内容介绍。

基于上述的调研，我们决定开始使用阿里云服务网格ASM产品进行迁移。

迁移到阿里云ASM

1. 【ACK-PROD】我们首先将一个足够规模体量的单一客户生产环境（门店供应链）（每天50万笔订单，1500万库存流水）注入Istio，因为这个环境的使用场景不是全天候的，出现问题会有半个小时的缓冲时间来解决问题，并且应用系统做了完善的自动补偿，确保在出现问题我们取消Istio以后业务也能够正常恢复，第一次注入非常成功。

2.【ACK-PROD】然后我们将另外一个门店供应链的生产环境也做了Istio注入，相对于第一个环境，规模体量小一点，但业务环境更加复杂，有更多的应用服务在运行，第二次注入非常成功。

3.【ACK-SAAS】随着前面两次的成功实践，我们在一个更加重要的实时生产系统（门店全渠道交易）的基础服务部分引入了Istio，因为这些服务只使用Golang编写，都是一些实时处理要求比较高，但业务相对简单的，第三次注入成功。

4.【ACK-SAAS】我们在生产环境开始注入部分交易链路，注入以后系统生产可用，在第二天高峰期发现了会有部分服务出现istio-proxy crash导致应用不可用，从而影响了部分应用的正常运行。

鉴于对生产环境的谨慎，我们重新复盘了出现问题的场景，最终得到的结论是：

·Java应用的启动对于资源的要求比较苛刻，我们没有提前配置好更加合理的启动参数，将会导致Java应用启动缓慢；

·检查机制不完善，将会导致流量打给还没有完全准备就绪的服务，此时K8s的健康检查机制会在多次没有响应时会再次重启服务；

·Istio Sidecar默认的设置也会推慢整个Pod的启动时间，之前应用的假设是15s内完成启动，随着Sidecar代理的注入，有时候会遇到更长的时间；

·Java应用提供gPRC服务的时候，istio-proxy会出现某种特殊情况的 Crash，这也是导致生产服务不可用的直接原因。

简单而言，在istio-proxy存在部分bug的情况下，我们的应用的快速启动策略和健康检查机制的不合理，直接导致了注入Sidecar代理的部分服务生产不可用。

针对这个问题，我们在阿里云工程师的支持之下，在另外一个环境复现并做了改进，主要的改进如下：

·针对istio-proxyCRASH问题，社区已经有了解决方案，在（https://github.com/istio/proxy/pull/3658），在阿里云工程师的支持下，我们升级了sidecar，并做了A/B测试，确定复现了这个Crash的场景；

·调整sidecar配置，根据应用优化istio-proxy的启动速度；

在方案得到确认以后，我们开始了第二轮的Istio升级。

1.【ACK-SAAS】我们将SaaS的供应链业务注入Istio，除了升级过程中遇到部分服务资源不足的问题，其他都非常顺利；

2.【ACK-SAAS-QA】我们在测试环境复现了启动速度慢的问题，并通过更加合理的启动参数配置验证了在CPU初始化申请对于Java应用的影响；

3.【ACK-SAAS-QA】A/B 测试Istio crash场景，确认新的sidecar已经修复这个问题；

4.【ACK-SAAS】正式完成全渠道交易的Istio生产注入；

5.【ACK-SAAS】将剩余的应用全部完成注入。

此外，服务网格ASM相比社区Istio能够实现更加丰富的能力，如流量标签、配置推送优化等能力。在实际的应用场景中，我们充分利用配置推送优化能力。在默认情况下，由于无法确定数据平面内所有工作负载与服务之间的关系，服务网格数据平面内的所有Sidecar都必须保存数据平面集群内所有服务信息的全量配置。同时，一次针对控制平面或数据平面的修改（例如在控制平面新建一条虚拟服务规则），都会导致控制平面向数据平面的所有Sidecar推送新的配置。

而在我们的数据平面Kubernetes集群中的工作负载数量比较多，默认情况下会增加Sidecar对数据平面集群的资源消耗，同时控制平面会面临较大的配置推送负担，降低控制平面的效率与可用性。ASM提供了选择性服务发现和Sidecar资源推荐功能，帮助优化配置推送效率。

服务网格ASM可以通过分析数据平面Sidecar产生的访问日志获取数据平面服务之间的调用依赖关系，为数据平面中的每个工作负载自动推荐Sidecar资源。为工作负载推荐Sidecar资源后：

- Sidecar配置内将仅保留该Sidecar对应工作负载所依赖的服务信息。

- 当该Sidecar资源对应的工作负载无依赖关系的服务发生改变，或与该服务相关的资源发生改变（例如虚拟服务等），都不会引起控制平面向该Sidecar的配置推送。