华为云应用服务网格核心特性解读

小提示：您能找到这篇{华为云应用服务网格核心特性解读}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的华为云应用服务网格核心特性解读内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">华为云应用服务网格（Application Service Mesh，简称ASM）于2018年8月对外公测，2019年7月正式商用。是一种高性能、高可靠性和易用性的全托管的服务网格，支持虚拟机、容器等多种基础设施，支持跨区域多云多集群服务的统一治理。以基础设施的方式为用户提供服务流量管理、服务运行监控、服务访问安全以及服务发布能力。

< ">ASM控制面和数据面均和开源Istio完全兼容，无缝对接华为云的企业级Kubernetes集群服务云容器引擎（Cloud Container Engine，简称CCE），可为客户提供开箱即用的上手体验。包括并不限于：

< ">内置金丝雀、蓝绿等多种灰度发布流程，提供一站式自动化的发布管理；

< ">提供非侵入式的微服务治理解决方案，支持完整的生命周期管理和流量治理，包括跨集群的负载均衡、熔断、限流等多种治理能力；

< ">提供端到端的透明安全，支持跨集群的服务访问认证和授权；

< ">同时基于无侵入的监控数据采集，提供实时流量拓扑、调用链等服务性能监控和运行诊断，构建全景的服务运行视图；

< ">基于流量数据进行弹性扩缩容，保障服务访问延时满足SLA目标；

< ">另外除了对常用的HTTP、gRPC等通用协议的服务治理外，扩展了对Dubbo协议的治理支持，并提供了对Springcloud、Dubbo等传统微服务框架的结合方案。

< ">核心特性介绍

< ">1、丰富的灰度发布流程

< ">基于网格提供的细粒度的分流规则，在ASM中实现了多种典型的灰度发布流程，提供一个灰度发布的向导，方便用户便捷的进行灰度发布实践。在一个服务版本正常工作，正常处理流量的同时，用户可以创建一个新的灰度版本。当灰度版本启动成功后，引导用户配置灰度规则来分割流量。

< ">灰度规则可以是基于权重的按比例切分流量，也可以根据服务访问的内容来将特定内容的请求发往灰度版本，对于常用的HTTP协议，如请求中的OS、浏览器、Cookie和Header信息等。在配置了灰度规则后，可以实时的观察到多个线上版本的运行和访问信息，从而在向导中一键式完成版本选择，将所有流量都切换到最终选定的版本上。

< ">用户也可以将以上灰度发布流程进行自动化配置，从而实现无人值守的灰度发布。即只要灰度版本运行成功就会自动触发预制的灰度策略给灰度版本分配流量，在流量运行特定的时间后，根据预制规则自动的切换流量完成灰度发布。

< ">除了服务粒度的灰度发布外，用户也可以对多个服务组成的应用，在入口服务处配置灰度规则，对一组服务使用同样的分流策略，进行灰度发布。

< ">2、多集群流量管理

< ">ASM作为一个控制面全托管的服务，进一步减轻了用户对网格服务自身的运维成本，同时作为独立的控制面可以支持对多云多集群的网格数据面、容器、虚拟机等多种基础设施的服务进行统一管理。

< ">对最终用户来说多个Kubernetes集群上的服务可以使用服务名进行全局的服务发现和负载均衡。可以应用多种不同的负载均衡策略，可以进行会话保持连接管理。而且，这些配置的负载均衡策略可以在跨服务的实例间分发流量。这种方式较之常见的基于外部DNS+负载均衡的在使用方式无疑要优雅和简单很多，而管理粒度和功能上也要要强大很多。

< ">对服务配置的连接池管理、熔断功能也可以在多集群上生效。无论服务请求来自本集群还是其他集群，在同一个目标服务上都可以应用统一的熔断规则。从而对目标服务进行保护，提高总体的服务质量。

< ">在隔离目标服务的故障实例时，可以对该服务跨集群的多个实例进行统一处理，如服务A有5个实例：3个实例在集群1；2个实例在集群2。当配置了熔断策略，最大隔离比例配置为40%，则当集群1和集群2中的实例均出现连续访问不正常，触发熔断阈值条件时，集群1和集群2各会被隔离一个实例。

< ">限流功能落在多集群场景中应用也会非常广泛。通过限流功能可以限制无论调用来自哪个集群的哪个服务，根据限流策略，在单位时间内对于目标服务的访问不能超过配置的阈值，从而对服务进行全局的流控。

< ">网格的流量管理功能在多集群场景下的应用会使得传统很多的难题变的简单。如流量镜像能力在多集群的场景下可以方便的将特定条件的HTTP流量镜像到另外一个集群的服务中。

< ">如流量在发往生产集群中的同时，往另外一个测试集群镜像一份。这个过程完全不会对生产集群的服务产生影响，网格的数据面代理只需关注原来转发的流量就可以，不用等待镜像目标地址的返回。根据具体场景也可以是集群间对请求的重定向、重写等处理。

< ">在多云多集群场景下，另外一种更常用的客户场景是网格提供的灵活的分流能力。比如前面介绍的灰度发布功能，用户可以选择将灰度版本和生产版本部署在不同的集群，渐进的切分流量。这样不只是把开发和生产环境的流量药物软文推广打通，更重要的是通过流水线配合可以将开发和生产的流程打通。

< ">3、多集群端到端透明安全

< ">ASM是以一种安全基础设施方式的方式向用户提供透明的安全能力。让不涉及安全问题的代码安全运行，让不太懂安全的人可以开发和运维安全的服务，不用修改业务代码就能提供服务访问安全。网格提供了一个透明的分布式安全层，并提供了底层安全的通信通道，管理服务通信的认证、授权和加密，提供Po公关公司怎么找d到Pod、服务到服务的通信安全。开发人员在这个安全基础设施层上只需专注于应用程序级别的安全性。

< ">在多集群场景下ASM提供了全局的服务访问安全。多个集群的网格共享一套根证书，对给数据面的服务实例分发密钥和证书对，并定期替换密钥证书，根据需要撤销密钥证书。在服务间访问时，网格的数据面代理就会代理本地服务和对端进行双向认证、通道加密。这里的双向认证的服务双方可以来自两个不同的集群，从而做到跨集群的透明的端到端双向认证。

< ">在认证的基础上，就可以进行服务间的访问授权管理，可以控制某个服务，或者服务的一个特定接口进行授权管理。如只开放给特定的一个Namespace下的服务，或者开放给某个特定的一个服务。源服务和目标服务可以在不同的集群，甚至源服务的不同实例在不同的集群，目标服务的不同实例在不同的集群。

< ">4、全局立体监控

< ">在我们日常实际工作中，比上面各种治理功能更常用的是各种服务运行监控。特别是在复杂应用的场景下，服务间的访问拓扑，调用链，监控等都是我们对服务整体运行状况进行管理，服务访问异常时进行定位定界的必要手段。服务网格技术的一项重要能力就是以应用非侵入的方式提供这些监控数据的采集，用户只需关注自己的业务开发，无需额外关注监控数据的生成。

< ">ASM基于网格生成服务访问数据，集成各种不同的APM服务，提供跨集群智能的服务运行管理。包括跨集群的服务调用链、服务访问拓扑和服务运行状态健康。通过跨集群的全局视图来关联服务间的访问状况。

< ">在拓扑图上通过服务的访问数据，可以直观的观察到服务的健康状况，服务间的依赖情况。并且可以对关心的服务进行下钻，从服务级别下钻到服务版本级别，还可以进一步下钻到服务实例级别。如下图通过这种实例级别的拓扑可以观察到配置了熔断规则后，网格如何隔离故障实例，使其逐渐接收不到流量。并且可以在故障实例正常时，如何进行实例的故障恢复，自动的给恢复的实例重新分配流量。

< ">故障实例隔离

< ">故障实例恢复

< ">在ASM中，我们把上面介绍到的复杂均衡、熔断限流流量管理、服务访问安全、服务访问拓扑、监控调用链等能力除了多个容器集群外，扩展到VM等其他基础设施。用户可以无差别的对VM间的访问、容器到VM间的访问进行以上的流量管理、安全访问和服务访问监控，从而便捷对容器和虚机的统一、细粒度、全方位管理。

< ">5、智能弹性扩缩容

< ">基于前面介绍的网格上产生的服务访问数据，可以对网格的服务实例进行更及时智能的弹性扩缩容。传统的HPA负责Pod水平伸缩通过定期的扫实例的资源情况，如CPU和内存，比较和设定的目标的比值，来水平调整应用的实例数。

< ">例如当前的指标值是200m，目标值是100m，那么按照公式计算期望的实例数就会翻倍。在实际过程中，可能会遇到实例数值反复伸缩，导致集群震荡。基于指标的伸缩存在一定的时延，经常会导致应用CPU飚高，相应时间变慢。

< ">为了解决以上问题，保证最终用户的体验，在ASM中设计开发了另外一种基于网格服务访问数据的扩缩容。在网格的应用场景中，用户最关注的指标还是延时，扩缩容的目标是即怎么去做扩缩容保证客户访问的延时在一个目标的区间内。

< ">我们使用时间序列根据前几个周期的流量预测下个周期的流量，并根据当前的实例数，选定下个周期可能的实例数范围，将范围内的实例数和多个当前资源指标、访问指标作为神经网络的输入，对下个阶段的形影时间进行预测。从满足相应时间SLA目标的实例中根据成本选择最佳的目标实例数，执行扩缩容。

< ">这种自动扩缩容方式调用资源扩容/缩容的命令，在下个周期到来的时候资源数目恰好已经改变成下个周期需要的最合理的资源数目，提高了扩缩容的及时性。另外省去了传统阈值法对阈值的设定进行调整尝试的步骤，可以直接在使用时自动的将实例数目调整到一个合理的值。

< ">遗留微服务SDK框架结合方案

< ">对于大量当前使用传统SDK的开发的服务，当要使用服务网格能力时，ASM提供了一套迁移业务无侵入的迁移方案。在服务调用方将Outbound的流量引流到网格的数据面上来。即短路原有SDK里的服务发现和负载均衡，直接通过Kubernetes的服务名访问，使用Kubernetes的服务发现，SDK里的治理逻辑也可逐步的被网格替换。这样服务的运行治理能力都下沉到由k8s和服务网格提供基础设施上。

< ">通过这种方式：控制面使用ASM统一的控制面做服务发现和治理规则管理，不需要独立的注册中心和配置中心；数据面的服务发现、负载均衡、和各种治理都在ASM数据面Envoy上执行，SDK作为开发框架，回归到开发框架的本来职能，作为一个纯净轻量的应用开发框架供用户开发代码。

< ">在方案中，数据面可以是容器，也可以是VM。服务可以是各种语言，本身开发框架也没有限制。统一通过网格的控制面下发流量规则，对所有形态的数据面进行一致的管理。

< ">未来规划

< ">应用服务网格ASM作为连接上层应用和下层基础设施的重要环节，将在4个方向上不断增强能力：向上与业务融合，以非侵入的方式提供更细致的应用层能力；向下与基础设施融合，使能面向应用的基础设施；并不断增强网格的治理、发布和弹性的业务能力；并加强网格自身的能力优化，包括性能、资源利用和运维能力。同时结合ASM大量的实际落地场景中的客户需求，进一步催熟Istio社区的大特性演进和发展，推进服务网格技术在业界的推广和使用。