开发者学堂课程【服务网格技术开源、自研、商业化三位一体战略解读：服务网格技术开源、自研、商业化三位一体战略解读】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/960/detail/14881
服务网格技术开源、自研、商业化三位一体战略解读
内容介绍
一、阿里云原生三位一体战略回顾
二、拥抱开源技术：k8s、Istio＆Envoy
三、内部实践：服务网格技术在阿里巴巴的落地
四、云产品：阿里云服务网格 ASM
第一块讲三位一体、开源、自研和商业背后的逻辑，第二块服务网格领域在 k8s、Istio＆Envoy 服务网格这一套生态里，做了哪些开源的产品的贡献，第三块 survice 和网格技术在阿里巴巴的一个集团落地的实践，最后一块结合开源技术和一些生态在内部的结合，落地到一些实践和探索，去把对应的技术产品输出到阿里云服务网格 ASM 里来。
一、阿里云原生三位一体战略回顾
阿里云原生三位一体背后逻辑，三位一体概念，首先第一块开源，是服务网格，一个开源产品，Isio 是形成了一定的标准，形成了一个生态，是一个开放的思路，可以去用这样一套开源的产品。但是不是有了开源就可以直接来用。
在内部落地的一些经验，在阿里云一个比较大的规模的体量下面，其实是需要做一些大量的优化适配的工作，也就意味着自研。要去结合开源，去结合自己的内部的一些业务的特点，结合内部的一些，比如说对高可用的 ASL 的一些核心的一些研究和探索。商业化对阿里云内部来说继续开源，然后结合自己队伍的落地实践，内部的一些特定的一些业务的产品，比如说做了一些针对服务网格做了一些扩展，比如说像阿里双11的，比如说那是全天都要测，然后不在大量使用的那个全链路灰度的这样一些能力对于外部客户来说他也会有这样的一些促销产品，然后包括流量调度，包括服务治理这一套能符合服务网格核心的一些能力，其实也会有一些特定的业务场景，结合这样的一些考虑会把这样一套成长性可用的一套服务网格的产品输出到阿里云 ASM，还有 Istio 这里面来，这是一些背后的逻辑。
二、拥抱开源技术：k8s、Istio＆Envoy
先讲到开源，在 Istio 这个生态里面做了的事情可以先看一下，Istio 生态里面其实是会有这样一些东西，最上面一排的话就是指 Istio 的一些原生能力，第二排是存量的一些微服务，比如说像 Dubbo cloud 这项业务，在 Mesh 的一些研究的过程中，怎么去做一些融合做一些互联互通，或者做一些直接的一些能力。
先看第一块，其实是指就是 Dubbo。其实 Dubbo 在阿里开源的，在阿里内部，或者在一些外部的一些电商的一些公司，全是有大规模的使用的，但是有了 Mesh 出来之后其实也会有一些。
就比如说多语言的一些产品，比如说像那个阿里内部比如说收购饿了吗就是之前世而再次采用 PHP 的基础上，然后在这个过程中其实也会做需要有一些互联互通的一些功能，怎么去和多元互动，或者说直接把 Dubbo 演进到 Mesh 这样一个架构里面来，其实我们需要做一些适配的工作，首先第一块的话可以看到左边这张图的，是一个典型的一个Istio 一个架构，然后对接得住的东西 Istiod 着做出去，业务两个 Dubbo 的业务员可是没有投来的，通过 Sidecar 去达到一个流量治理或者说流量调度的一个能力，其实因为 Sidecar 原生最开始他是不支持 Dubbo 的，然后阿里云的团队其实是为了去揭露 Dubbo 协议的话，，因为社区贡献了 Dubbo proxy filter 的一个完整的实现。
第二块的话其实伴随基础设施的不断的演进，然后结合本身服务网格领域的一些理解，Dubbo 是在不断的向前演进，然后可以看到就是由 Dubbo 应该是由 Dubbo 二点七点八。开始由进口力度的一个服务注册项应急服务注册去做一些版本的演变，然后另外一块的话是 Dubbo 协议，就是有 Dubbo2的那个原始的私有的一个 Dubbo 协议，去过渡到基于 HTTP/2的 RPC 协议，Triple 目前已经在 Dubbo3，其实已经在社区发布，可以去看一下 Dubbo 社区的一些相关的文章介绍，然后着重看一下左边这张图，左边这张图的话其实可以大家可以看到，其实最左边的这一块的话是。
Dubbo 基于 Sidecar 模式去。服务网格来解决，这个服务的一些服务治理的一些能力，右边这一块的话，其实是一个基于 SDK 的模式，SDK 直接通过 A7对接控制，然后这样的话可以做到一个 Proxyless Mesh 的一个类型的模式，这两个模式其实可能都会有一定的适配的一些业务的场景，其实要结合自己的一些业务特点去看，采用哪种或者说采用这种融合的模式，还是采用之前比如说 SDK 的模式去对接。
再比如像传统的这种经典的微服务架构，其实在下面的 Mesh 演变的过程中，其实不是一蹴而就的，会遇到一些就是过渡的阶段，会有一些过渡的阶段，比如像右边这个 double，会需要和左边这个多元的一个业务去做一些互通，不能说 Dubbo 这个业务它都迁移到目前 Mesh 架构里面来的时候，要求又翻去说，之前是采用的那个难的做些，目前是不支持的，能不能直接把这些改为比如说开发 Nacos 这样其实是对有关系的，是有大量的改造的功能。
对于这一块来说，觉得是怎么做的，是通过开放的 Istio 协议，去做到让老师直接对接的这个协议，让过程无缝的去对接 Istio 可以提供一个直接发现那个中心的一些服务信息，这样的话可以做到多元和原有的这个存量。微服务架构Dubbo 可以实现互联互通的一个逻辑。
其实用开源产品觉得会有一些门槛，包括就是需要一些背后的一些专业知识，然后对于一些用方来说，其实如果没有这样一个核心的基础积累，其实对于这样的一个门槛来说是比较高的，就比如说像英特尔开源的这个 Multi-Buffer 的计数是一个什么样的一个技术？这里简单介绍一下，其实是指就说英特尔他提供了一个基于因为的一个 K9s 的加解密的一个技术，加解密的技术可以去结合英特尔的 CPU 的一些指令，目前的话只在这个机型提供，然后去做 CPU 的一个特定的指令，可以加速 TOS 的加解密，就是对称非对称加密前面的一个处理过程，最核心的其实是之前的那个。
流程变成了一个处理的逻辑可以达到一个加速的效果，所以在用英特尔的加速的逻辑的过程中，其实是需要，对开源的这一套东西，首先要有一个深刻的理解，背后的话还要去做一定的失败的逻辑，比如说这里是印度的，一开始他只是提供了一个，因为下游的一个数据面的一个事件，对于控制面的话目前是还没有开放出来，然后需要做的，首先第一步就是要去做一些配置的一个金融的一些扩展，让其可以理解这个发现这个环境当前的这个配置是不是支持阿里巴巴的，然后这样的话对应的就下发，这样一张配置，然后实现一个可以让用户无感开箱即用，然后达到一个就是可以看傻瓜式使用这一条能力的一个效果。这里额外加一块，目前其实已经将要在类似的新的版本上面提供，就可以达到一个网关的讲述，也可以达到一个 Sidecar 这个效果。
说到开源说到服务网格确实很难避免去 Dapr，就是经常被人问到，就说 Dapr 和服务网格的这样一个区别，然后Dapr的话，就是目前在那里也有一个团队在做一些开源的贡献，这里可以讲的话就是说 Dapr 怎么和服务网格的一些对比，这个对比的话就是有一个比较明确的一个界限是什么呢？就 Dapr 本身是面向开发者的，服务网格是有一定的能力的一些重叠，大家可以看到就是这个，这个是他们重叠的部分，但 Dapr 没做哪一块啊，就是没做这个流量的这个，路由盒子可以说是高级的一些流量控制的一些能力，他是没有做的。这个是核心，是 Mesh 的宣传面，典型的区别。
三、内部实践：服务网格技术在阿里巴巴的落地
接下来讲一下就服务网格在阿里云内部的一些落地啊，这一块的话其实主要是指我们内部的一个类型的一个产品就是叫阿里 Mesh，然后目前是支持了集团内部几个 pu 的一些大规模的一些实践，看一下这些实践是怎么来做的具体的一些工作。
首先看到一个架构图，这个架构图的话讲的是说，就是内部的这个风管的产品阿里 Mesh，是怎么去满足这些内部的一些客户的一些服务网格的这种规模化的一些需求的。类似于它提供了一个开箱即用的就是一套控制台，这份控制台的话是可以去让右方去通过控制台去做到 Mesh 的一些相流量规则的，深入的一些配置，同时也可以以应用为维度去做一些全生命周期的一些管理，包括像它集成的 CSCD，结束了一些安全生产一些其他的一些的 CRE 一些系统，可以做到对应用的这些，或者说像owner他可以去管理自己的应用，可以去迭代发布，可以去控制直接用那些流量调度的一些能力。然后它的核心能力有哪些，首先第一块的话他是支持的 double，然后支持的 HSF 发布了一个内部版本，然后也支持了那些像钉钉，其实也在实用服务网格技术他内部的一个协议 Iwppp 协议同时也支持，melq 的话是，就是在开元有一个产品叫 q 也是阿里开源的，因为社区的话就是也支持了 filter。
然后另外一块的话就是结合内部的一些业务的产品的一些需求，可以做一些像去年的灰度发布这样的一些业务产品的一些逻辑，然后也做了一些比如说像环境治理的，然后流量隔离这样的一些逻辑。当然这里是通用的一些业务产品，把这些通用产品也受到 ASM 里面来。接下来会着重讲到。
可以看到这个图，这个图是首先左最左边这一块确实是啊，就是一个控制面和一个数据面数据面的话是采用位，然后控制面大家可以看到这里，有一个可能比较陌生的一个 Diamond、configServer，Diamond 像那个 Server 里面的那个做服务配置用的，然后 ConfigServer 就是做服务发现的那个功能。在内部落地的时候，确实是需要去对接这两个，就不配置它，相当于是说把一些 server 的配置或者把一些服务里的一些路由的一些配置，或者说一些治理的一些啊其他相关的一些配置，会存储到一个存储的一个系统里面。社区的话呢，就是采用配方是采用 CAD 方式，然后在内部的一些存量系统，更多的是采用 Diamond 的这种方式，然后包括在中间它没有采用K8s是做软件的方式，是那些像这样的一个 SDK 的注册方式的话，其实需要去对接的，这是和那个开源产品的不同的点。但另外一块就是学的抽象出了一个运维平面。里面的话做了几个功能介绍一下，就是第一个就是通过刚才说的一个英文里面它提供了一个UI的控制台，可以达到一个效果，就是可以对有些 Survice 设备是可以对我们抽选出的一些其他的一些路由逻辑或者说CRD去做一个界面化的一些配置，然后同时结合了 Opscore 的这样一些能力，可以做到 Sidecar 的一个热升级和一个热重启。
直接讲一下就是。阿里集团 Mesh 内部落地，选择分为几个阶段，这个不同的阶段可能考虑的点是不一样的，第一个点是可能是，比如说一开始在1718年就是Mesh可能还在一点零的阶段的时候，其实 Mesh 他不是一个特别成熟的一个产品，就是内部其实也是以慢慢的一个探索的一个阶段，这是一个部分规模化，然后随着那个 Mesh 的不断成熟也是在规模化是不断的向在做一些版本的迭代作业，不断的一些新的业务去使用那些这样一套技术，然后最终的话会过渡到一个原生的一个生态的一个领域，然后为什么这里有个核心的一个关键词叫无限路，可以了解一些存量的业务在三个小度过程中迁移Mesh这套技术。为什么呢？义务它本身它其实是会有一个配合度的，就是本身如果是五千，如果愿意配合去改，到这样的一个给送了一套服务框架，如果本来这里也需要做到很多，比如说业务代表的层面的一些适配，它就是没有迁移的动力的。这也是为什么采用无迁的这种方式。
首先看到就是，是怎么去做到这样一个过渡的，就是首先第一个就是其实最开始就是在前面有讲到就是我们在数据面在 Sidecar，这一次去支持了这样一套那是最大的一个协议，然后支持 Hession2和当然这是内部，除了会上学的话的话，要用其他的序列化的话，就比如说像 Java，这一块序列化的话，其实对于未来来做一个完整的设备的话，其实是相对来说是需要做就很大的一些开发量，然后可能还不是特别完美的支持，对于这些前期的话我们采用这个方案就是说对于 Hessian2的事可以采用完整的一个便签的一个支持，对 Java 的话采用一个透传方式，其实可以让业务快速的一个上来去去用到面试这一块相关的技术。就是在内部也实现了一套，就是基于 Dubbo 的流量的一个编码解码的话，可以对流量进行达标，然后基于标的一些，然后再去扩展了一些 Survice 设备是可以通过一些设备时区，读取这个标签的方式，就是通过 Mesh这 个标签的方式，可以路由到特定的一个目标的一个复杂纠纷的。
这个是终态却没有讲到那个 Dubbo，是在也是不断的在原生这个大背景前提下的，也是在不断的向前进，由Dubbo2.0演进到 Dubbo3.0有讲到一些核心的一些版本的一些研究的一些逻辑，对Mesh来说是更友好了，然后首先从协议层面就是 Dubbo3.0的话是一个 gRPC 的这个协议是基于 IPC 的一个，然后另外一块的话服务注册不注册，有一个接口纳入注册，演变成一个应用及服务发现的一个注册，然后在这个演变过程中，其实内部也有一些业务也是Dubbo3.0，已经相当于是说 Mesh 的已经是支持 Dubbo3.0这一块啊，以及在内部业务做了一些落地，不久的将来也会在 s 门来支持 Dubbo3.0的一个支持。
这里核心讲这类业务其实是本身业务复杂度是特别高的，特别是电商这种，比如说在步骤上面去的时候，会因为 s6的要求，会做到几个维度的不同的 essay 的保障，首先部署层面可能是类似阿里的这些业务，其实都是多基板部署的，然后流量在掉头的过程中，其实会有一个统计法路由，然后不同的机房，同一个机房应该说同一个机房内部，其实也会返回不同的业务单元，还需要去整结合一些业务流量的一些单元指标去。内部浏览一些单元的一些标签，去做一些单元化、大众化的一些路由，不同的这些业务属性不同的纬度的线路，尤其是把它抽象出的前面这样一个图就是说在流量，经过一些路由的话，确实会经过一系列的路由插件，这些以前的路由插件其实会去决策当前的这个流量的特征是符合，比如是符合两个机房的，需要去路由到这个机房的这个对着这个目标服务里面去，然后是符合哪个机房符合哪个单元的，然后需要结合这个对应的单元的这个路由的一些配置，去路由大推定的特定的一些单元里面去，当然这里也包括一些fullbag逻辑，比如说这个单元可能他的服务不可用，是需要有一些的时候就逻辑录到其他的单元里面去，这样一系列的一些路由的一些策略却是很复杂的，然后把这些路由的一些能力，包括这些流量的一些达标能力，把它抽象出来一些特定的 CRD。
在 Istio 基础上做了一些扩展，比如说抽象出这里的一系列的这些 Router，可以他是一个一个念，抽象出了一个Routerchell 的一个 study 的话，现在是可以针对这些路由的一些不同维度的路由。举个很简单的例子就是流量比如说在 Istio 里面，是可能是有一个区域优先调度，然后经过区优先调度，假设还对这个目标服务做了一些版本的一些路由，其实需要经过两层路由逻辑相当是，那有的时候确认这个配置之后，学生可以很清晰的去配置优先路由去了到哪个比如说是哪个区域，然后再如果路由到这个区域之后再结合，比如说版本路由的这个路由配置逻辑，什么样的命令，什么样的标签的流量，需要去路由到位 V1版本，什么标准能量需要路由到v2版本。
然后另外一块就是 troublulable，现在实现了这个可以对留言区达标，然后结合一些 Survice 扩展，可以去这个流量的标签做一些暗标路由的一些能力，这一块的话其实也会输入到 s 十的这个产品里面来，可以看到就是x产品目前已经支持的那个金丝雀发布、全链路灰度发布，其实也是基于这一套背后的技术来实现的。
四、云产品：阿里云服务网格 ASM
首先简单介绍一下阿里云服务网格产品。阿里云服务网格（简称 ASM）是一个统一管理微服务应用流量，而且是业界首个兼容 Istio 的托管式服务网格平台，继续打磨“托管式、标准化、安全稳定、更易用、易扩展”的产品特性，支持完整的服务网格产品能力，主要包括精细化的应用流量管理，端到端的可观测性能力，安全和高可用。同时支持多语言多环境，多种微服务框架、多协议互联互通等复杂场景；支持全面的异构计算基础设施，包括 Kubernetes 集群、Serverless Kubernetes 集群、ECS 虚拟机以及自建Kubernetes集群同时支持虚拟机和容器等多种异构计算基础设施的混合部署，支持跨地域多集群、多元混合云上的服务的统一治理。
阿里云服务网格 SM，通过总结业务场景落地经验，持续驱动继续发展，沉淀了一系列服务网格核心技术，在大规模落地方面。比如按需动态推送配置。支持大规模业务无损下 Sidecar 热升级，支持最全面的异构计算基础设施，支持多注册中心与平台。
在流量治理方案提供了精细化的流量控制，按需对流量协议或者端口动态拦截。实现零配置请求标签路由以及流量染色，支持多种协议的精细化治理，在可观测性方面提供了日志监控和跟踪融合的一体化智能运维，同时基于eBPF增强可观测性，实现了无侵入全链路可观测辅助业务快速排障，在安全能力方面，支持 Spiffe/spire,实现零信任网络，增强认证鉴权机制支持渐进式逐步实现 mTLS，在竞争优化方面进行了通过 ebp f技术进行网络加速，通过卸载实现软硬一体的性能优化，通用 sidecar 加速的软件架构。
阿里云服务网格 ASM 技术架构已经全面升级到二点零时代。网格 ASM 托管的控制面的核心组件保证了标准版和专业版的架构是统一平滑支持社区各个版本的升级并在和社区标准保持统一的基础上。支持各种能力的增强主要包括流量管理和协议增强支持零信任安全能力之前对接 Lacos、control 多种注册中心,除此外通过网格诊断能力能够快速分析网格的近期健康状况。配合控制面告警可以快速响应。服务网格 ASM 管控面优化融合多种云服务能力。
在左边看到包括链路追踪 prometheus。日志服务等可观测性能力，集成了 ARS 支持伏线流集权下流自适应交流。同时结合微服务以及 EMC 支持服务治理，并能并且能够给跨 VBC 多集群提供一致的治理体验。右边自定义扩展方面，支持 OPA 安全引擎，基于自定义扩展能力，用户可以在，在这可以看到，用户可以通过 ASM 控制台，Open API 数据面和 Copconfig 控制面的使用服务网格技术。通过服务网格ASM在控制面和管控层面的持续打磨，运行在异构基础上设施上的服务提供统一的网格化治理能力，做到 Anywhere Service Mesh。包括从出入口网关到数据面，注入支持和外部注册以及 Cubnet 是虚拟机的设施。
接下来介绍一下在各个产品能力上的设计。在微服务软件架构下业务新功能，上线前一般要搭建完整的一套测试系统进行验证，而且这项工作是相当费时和费人的。企业拆出了微服的，数量的不断增大，其难度也越来越大，那么基于流量打标。能力是一个通用的很好的解决方案。而且基于服务网格技术，可以做到与开发与语言无关。目前这种方案支持多协议（HTTP/gPRC/Dubbo）流量标签。沉淀路流量，控制进行逻辑隔离，对流量进行打标和染色以及按标路由，通过市政府网给咱们的技术研发。无需每个人都部署一套整套环境，实现多环境的治理，大幅度降低研发成本，在图中可以看到极限环境开发环境一号开关房间。流量的达标之前一个自动的环境的一个流量的路由。
第二个，市府网基于服务网格没实现的金丝雀发布等功能更新到线上的最后一个环节。一些研发过程中累积的问题可能到最后发布环节才会出发，同时发布，本身也是一个比较复杂的过程。在发布过程中往往需容易出现一些错误操作，或者是遗漏关键操作，金丝雀发布，通过他的策略的自定义可以按照流量或者是具体的内容竞争灰度，这样之后出现问题的时候不会影响到的全网用户，途中给应用打上了第一步，给应用打上了环境标签，那么出现问题。
所以就根据第二部的灰度规则，可以 ASM 支持 A7，比如说只给一个 uc 取模，一百等于二十的时候，可以路由到国内的灰度环境，否则将路由到正常环境。那么通过这种权威不能用于定一个卡所需的流量标签，在服务网格中可以很好的实现一个金丝雀发布。就是百分之20，30，各种流量百分比，或者是基于这种 HP 黑的方法参数的请求特征。来路由并且这种路由方式可以和服务网格 ASM 的入口网关做一个完美的集成，目前如果是 HP 和 MP 三，可以直接享受这种金丝雀发布能力。除了使用流量达标和标签，路由实现产量度灰度和金丝雀发布。
服务网格 ASM 也支持 KubeVela 实验渐进式发布，是一个开箱器中的现代化的应用交互与管理平台，能够简化面向混合环境的应用，交付个人，同时又足够灵活，可以随时满足业务不断高速变化时代来了迭代压力。
KubeVela 后面的应用交互模型实际上是一个以应用为中心的 OEM 的模型。从设计和实践上都是一个高度可扩展的模型，完成应用为中心，而且是一个可编程式的交互工作流程，阿里云服务网格 ASM 支持。精确发布时可以把A1的相关配置转化为流量治理规则，通过控制的规则下，金丝雀发布流程。由于服装跟单模式控制的是控制平面托管，支持管控及群。
主要讲最近一个功能可以支持数据 API 访问 Istio 资源，这个功能主要是为了支持用户在非托管模式下的操作习惯，能够使用数据面的 K8s 集群中来读写I stio 资源，同时也支持 Helm 命令工具，来进行应用部署也兼容其他开源软件在单集群 addon 模式下的 API 操作，阿里云网格服务网格通过，这是这种能力，最下面就是数据面，最上面是控制面板，可以使用竖直面的 kubernetesAPI 来操作 Istio 资源对象，那么自然对象会同步到控制面。老的客户利润也可以使用控制面来 Control 来操作，顺便两种能力都可以同时对外提供使用。
主要讲服务网格 ASM 零信任安全，没完整时间的阿里策略，在网络中使用 APP 通信的交互并不安全，那么攻击者能够以机器作为跳板来攻击内网，服务网格 ASM 能够减少人生环境中被攻击的面积，并提供零信任。应用网购社区的技术框架，通过 SIM 管理服务到服务的安全锁。短信可以确保服务网格的端到端的加密，认证和力度的策略，那么相比传统的在应用程序代码中构建安全机制，ASM 零信任安全体系具有以下优势。
首先第一个 Sidecar 代理的生命周期管理独立就是说由于 Sidecar 代理的模式，让策略生命周期和应用程式是保持独立的，因此可以很轻松地管理这些代理，
第二个就是支持动态的配置策略更新策略变得更加容易，立即生效，而无需重新部署应用程序。
第三个就是支持工作负载身份和请求身份验证 ASM 提供的对付请求终端用户的凭证，进行身份验证的能力，比如说其他目的。
第四个 ASM 支持集中式管理安全策略。也可以促进企业的安全带可以构建管理和部署。是整个企业的安全策略，从而默认情况下能够保持应用开发人员构建的业务和安全，无需额外的工作及格，来享用这些安全策略。验证和授权系统也作为服务网部署在网格中，那么网格中的这些安全系统也和其他服务下，能够得到这个传输的加密身份认证策略执行点以及终端用户凭证等身份验证和授权。
第五个保障身份验证和授权系统的安全性那么策略控制面板定可以定一多种的类型的策略，网格控制面赋予网格工作负载身份并自动认证书，数据面 Sidecar 代码来执行这一策略用户配置的规则只允许，比如说只允许交易服务发起。
调用订单，购物车服务来调用这个订单服务，这就是一个简单的一些安全能力的实现。
具体可以参考右边，一个截图大家可以直接在服务网格 ASM 控台上，直接以产品化的能力方式来使用零信任安全能力。
主要讲一下服务网格 ASM 那么数据面的升级，可以分为两种方式，第一种就是滚动冲击力，滚动升级能力，需要设置论文的，那么以后在发布以后自动升到最新的版本，那么图中主要是介绍第二种方式，阿里云服务网格。
结合 Openkruice 的项目实现了热升级能力。再升级数据面平面时不为终端服务，使得数据平面在应用无感上完全升级。左边就是应用发布，应用发布时，应用发布更新成自动生成 Sidecar 配置的，这个配置它是也是基于开源的，那个模板，所以说整个的是配置可以跟开元的注入的的参数是保持一致。那么应用 ir管理人员就可以只呆在 ASM 控制台来进行那个 Sidecar 更新从而完成我们数据面的热升级。
除了以上功能以外，服务网格 consumer 也可以配合阿里云的应用服务，对部署在网格内的应用进行流量控制，目前已经支持服务限流、集群限流、自适应线流，同时辅以原生由使用传统 GDP 服务。直接限制每个实例的请求。根据自己的应用的特点一起使用。
这个支持这个 cp，就是说好 x协议对接注册中心，比如说 Nacos。使用这样的话，用户只是在只需要在这个创建网格实例或者是更新网格识屏，控制台上选择实力就可以开通 m cp 把这个 double cloud 的服务注册在这个路口子上的服务同步到网格提起来，嗯，可以很方便的实现这个 WS，像这个服务的网格化。以上是今天介绍的一些服务网格，而在最近上线的一些功能。
介绍几个客户案例给大家来看一下，客户是怎么使用网格什么的。第一个就是东风日产数据服务有限公司，他是汽车领域的一个数据服务供应商，那么随着东风日产的业务的发展，早期打造的这个十二生肖系统，其实已经没法满足众多的宾方要求，那么甚至需要这个摇号来分配环境，东风日产服务有限公司引入了阿里云服务网格 ASM，构建了基于流量管理的这个无线生肖系统，满足的自动按需提供环境的诉求，基于 ASM 提供的免运维、易升级以及产品丰富支持能力，让产研团队集中享受 Service Mesh 带来的价值；缩短服务网格技术基础落地周期，减轻异常排错成本，同时节省控制的资源成本。
第二个就是，符合 SM 多地域的一个事件，是一个全球化部署的一个业务，它主要使用了阿里云服务 SIM 和容器服务ACK。在数据面上将业务的应用进行了一个跨区域部署。可以优化的啊，整个环境的访问体验。有效的降低，业务的访问延迟，从而提高整个业务的响应速度，关于ASM管理多个领域的 k8s 的数据面的一个实现，大家可以参考这个服务网格什么的官方文档。
第三个客户是也是一个很经典的客户，商米科技，他也是引入了阿里云服务网格 ASM,构建商业智能 POS 软硬件一体化系统解决方案，基于 ASM 提供的免运维以及全面的服务治理能力，让产研团队专注于 Service Mesh 带来的技术架构优化，比如 gRPC 服务负载均衡、链路追踪以及流量统一管理等核心问题。服务网格技术落地周期减少75%，更新迭代效率提升70%，排错时间缩短80%。
最后我是介绍一下服务网格最近上线的一些功能，比如说我们十月份的一个基于动态，首先第一个 feature 就是支持通过数据面 K8s Istio 访问托管所的一所自然对象，也就是我刚才前面讲到的，我们也是我们十月份上线的一个能力，满足用户的使用习惯问题，就是说习惯就是在那个控制面和数据面部署在一个k8s集群使用，访问来操作我们的 Istio自然对象，
第二个就是我们支持跨地域流量分布和故障转移，可以实现多地域的负载均衡和那个跨地域容载，到某一个地方呢。可以将流量转移到其他地域，这项能力大家可以直接在网格网格信息里面直接可以配置。
第三个就是我们服务，网格也支持控制面，数据面访问支持。
第四个是就是也是刚才讲的，与课本有一个很好的结合来支持这个渐进式发布。
第五个是网格 ASM 网关在十月份的优化和 ASM 支持，在控制台上创建入口，网关后出口网关来管理南北向流量。十月份专业版也可以通过那个 CPU memory 来制定 HAP 策略。第五个控台集成了监控，可以查看这个数据面的流量详情，在可观测性方面的一个能力最近也会推出一些新的，流量的，大家可以通过 ASM 控制而直接的。其实可以看到自己被网格以后，流量详情。
最后一个是也支持 Istio 资源的版本，管理用户，可根据你需要。回滚时可以把你的你所配置回滚到你最近就是说变更的版本，这个可以直接在那个流量之旅规则页面可以看到。
