从单体到混乱的微服务，阿里云托管式服务网格

小提示：您能找到这篇{从单体到混乱的微服务，阿里云托管式服务网格}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的从单体到混乱的微服务，阿里云托管式服务网格内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">作者|王夕宁阿里巴巴高级技术专家

< font-size: 16px;">在服务网格技术使用之前，为了更快更灵活地进行业务创新,我们常常会把现有应用进行现代化改造,把单体应用程序分拆为分布式的微服务架构。通常来说,在微服务架构模式的变迁过程中,最初都是面向代码库的模式。

< font-size: 16px;">对这些微服务治理的实现,往往是以代码库的方式把这些服务治理的逻辑构建在应用程序本身中，这些代码库中包括了流量管理、熔断、重试、客户端负载均衡、安全以及可观测性等这样的一些功能。这些代码库随着功能的不断增强,版本也随之变更，因为版本不同导致的冲突问题处处可见。此外，库的版本一旦变更，即使你的应用逻辑并没有任何变化，整个应用也要随之全部变更。由此可见,随着应用的增长和团队数量的增加，跨服务一致地使用这些服务治理功能会变得非常复杂。

< font-size: 16px;">

< font-size: 16px;">服务治理的能力Sidecar化

< font-size: 16px;">通过把这些服务治理的能力Sidecar化，就能够把服务治理的能力与应用程序本身进行了解耦，可以较好地支持多种编程语言、同时这些Sidecar能力不需要依赖于某种特定技术框架。这就是我们常说的面向Sidecar proxy的架构模式。

< font-size: 16px;">随着这些Sidecar代理功能的增强，原本需要在代码库中实现的服务治理功能被抽象化为一个个通用组件,并被逐渐地下沉到代理中。这些服务治理能力的标准化、统一化，可以解决复杂系统微服务实现中面临的差异大、缺少共性的问题，可以很好地支持不同的编程语言、不同的框架。

< font-size: 16px;">通过把应用服务通信能力抽象下沉到基础设施,使得开发人员可以更加聚焦于业务应用本身开发,而让基础设施来提供这些通用的能力。

< font-size: 16px;">与此同时，容器编排技术的更加成熟，也加速了Sidecar代理的普及与使用的便捷。Kubernetes作为一个出色的容器部署和管理平台、Istio作为应用服务治理的平台，两者的结合成为了将这些应用服务通信能力下沉到基础设施的载体。

< font-size: 16px;">在云原生应用模型中，一个应用程序可能会包含数百个服务，每个服务又有数百个实例构成，那么这些成百上千个应用程序的Sidecar代理如何统一管理，这就是服务网格中定义的控制平面部分要解决的问店铺代运营商题。作为代理，Envoy非常适合服务网格的场景，但要发挥Envoy的最大价值，就需要使它很好地与底层基础设施或组件紧密配合。

< font-size: 16px;">

< font-size: 16px;">这些Sidecar代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面扮演了一个用来建立、保护和控制通过网格的流量的角色。

< font-size: 16px;">负责数据平面如何执行的管理组件称为控制平面。控制平面是服务网格的大脑，并为网格使用人员提供公开API，以便较容易地操纵网络行为。

< font-size: 16px;">启用服务网格之后,开发人员、运维人员以及SRE团队将以统一的、声明的方式解决应用服务管理问题。

< font-size: 16px;">

< font-size: 16px;">服务网格ASM产品架构

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

< font-size: 16px;">在深入分析服务网格方面，提供了网格诊断能力，把过去一年多来客户遇到的问题以及如何解决这些问题的手段变成产品能力,帮助用户快速定位遇到的问题；

< font-size: 16px;">在扩展与集成方面，ASM产品整合阿里云服务包括可观测性服务链路追踪/日志服务/Prometheus监控等、跨VPC网络互连CEN能力等，同时也优化整合了社区开源软件包括OPA的支持、授权服务的定制化能力、限流服务等。

< font-size: 16px;">此外，随着Istio新架构的优化，将WebAssembly技术引入服务网格，解决代理扩展的问题。这样一来,ASM架构就变成了“托管的高可用弹性控制平面+可扩展的插件式的数据平面“的模式。

< font-size: 16px;">在数据平面的支持上，ASM产品可以支持多种不同的计算基础设施，这包括了阿里云提供的公有云ACK集群（其中包括了托管的K8s集群和专有K8s集群）、也包括对的无服务器Kubernetes容器服务ASK集群的支持。同时,对非容器化应用例如运行在ECS虚拟机上的应用服务网格化的支持。

< font-size: 16px;">此外，ASM也推出了一个支持多云混合云的能力，能够针对外部的非阿里云K8s集群进行支持，不论这个集群是在用户自建的IDC机房，还是在其他的公有云之上，都可以通过ASM进行统一的服务治理。

< font-size: 16px;">多种类型计算服务统一管理的基础设施

< font-size: 16px;">接下来,将会介绍托管式服务网格在成为多种类型计算服务统一管理的基础设施中,如何提供了统一的流量管理能力、统一的服务安全能力、统一的服务可观测性能力、以及如何基于WebAssembly实现统一的数据面可扩展能力。

< font-size: 16px;">1.统一的流量管理能力

< font-size: 16px;">关于统一的流量管理能力方面,重点讲述2个方面。

< font-size: 16px;">第一个是基于位置实现流量路由请求。在大规模服务场景下,成千上万个服务运行在不同地域的多种类型计算设施上,这些服务需要相互调用来完成完整的功能。为了确保获得最佳性能，应当将流量路由到最近的服务，使得流量尽可能在同一个区域内，而不是只依赖于Kubernetes默认提供的轮询方式进行负载均衡。服务网格应当提供这样的基于位置的路由能力，一方面,可以将流量路由到最靠近的容器,实现本地优先的负载均衡能力,并在主服务出现故障时可以切换到备用服务。另一方面,提供局部加权的负载平衡能力,能够根据实际需要,将流量按比例拆分到不同的地域。

< font-size: 16px;">第二个是关于非K8s工作负载的网格化统一管理。在一个托管的服务网格实例中,我们可以添加若干个K8s集群,并在控制面定义路由规则的配置,也可以定义网关服务等。为了能够统一地管理非K8s工作负载,我们通过一个WorkloadEntry的CRD来定义工作负载的标签以及该工作负载运行的IP地址等信息。然后通过ServiceEntry CRD将这个工作负载注册到服务网格中,并提供类似于K8s Pod的处理机制来处理这些非K8s工作负载。譬如可以通过selector机制路由到对应的Pod或者这个非容器应用上。

< font-size: 16px;">2.统一的服务安全能力

< font-size: 16px;">关于统一的服务安全能力,托管服务网格为多种不同计算基础设施上的应用服务提供统一的主子账户支持/RAM授权支持。在此基础上,提供统一的TLS认证与JWT认证,支持启用与禁用TLS认证的简易切换、支持以渐进方式逐步实现双向TLS认证;支持以细粒度的认证范围,包括namespace与workload级别。此外,服务网格也提供对JWT认证能力的支持,使得这种TOKEN认证机制不再依赖于某种特定实现框架就可以统一透出。

< font-size: 16px;">在RBAC授权方面,针对不同协议提供了统一的授权策略,可以在不同粒度上支持,包括namespace/service/port级别的授权；

< font-size: 16px;">在审计方面,可以灵活开启网格审计功能,并可以查看审计报表、查看日志记录以及设置告警规则等；

< font-size: 16px;">在策略管理方面，提供了开放策略代理（OPA）的集成,用户可以使用描述性策略语言定义相应的安全策略。此外也提供了自定义授权服务external_auth grpc的对接。只要遵循这一接口定义,任意授权服务都可以集成到服务网格中。

< font-size: 16px;">3.统一的服务可观测性

< font-size: 16px;">统一的服务可观测性,分为3个方面。

< font-size: 16px;">一是日志分析能力：通过对数据平面的AccessLog采集分析,特别是对入口网关日志的分析,可以分析出服务请求的流量情况、状态码比例等,从而可以进一步优化这些服务间的调用；

< font-size: 16px;">二是分布式追踪能力：为分布式应用的开发者提供了完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具，可以帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率；

< font-size: 16px;">三是监控能力：根据监视的四个维度（延迟，流量，错误和饱和度）生成一组服务指标,来了解、监视网格中服务的行为。

< font-size: 16px;">4.统一的数据面可扩展能力

< font-size: 16px;">尽管sidecar代理已经把服务治理过程中常用的一些功能进行了封装实现，但它的可扩展能力一定是必须具备的，譬如如何与已有的后端系统做对接，如何解决用户的一些特定需求。这个时候，一个Sidecar代理的可扩展性显得尤为重要，而且在一定程度上会影响Sidecar代理的普及。

< font-size: 16px;">在Istio之前的架构中，对Sidecar能力的扩展主要集中在Mixer组件上。Sidecar代理的每个服务到服务连接都需要连接到Mixer，以进行指标报告和授权检查，这样会导致服务之间的调用延迟更长，伸缩性也变差。同时，Envoy要求使用代理程序的编程语言C++编河北全网营销写，然后编译为代理二进制文件。对于大多Istio用户而言，这种扩展能力具有一定的挑战性。

< font-size: 16px;">而在采用了新架构之后，Istio把代理的扩展能力从Mixer下移到了数据平面的Envoy本身中,并且使用WebAssembly技术将其扩展模型与Envoy进行了合并。WebAssembly支持几种不同语言的开发，然后将扩展编译为可移植字节码格式。这种扩展方式既简化了向Istio添加自定义功能的过程，又通过将决策过程转移到代理中而不是将其种植到Mixer上来减少了延迟。使用WebAssembly（WASM）实现过滤器Filter的扩展,可以获得以下好处：

< font-size: 16px;">敏捷性：过滤器Filter可以动态加载到正在运行的Envoy进程中，而无需停止或重新编译；

< font-size: 16px;">可维护性：不必更改Envoy自身基础代码库即可扩展其功能；

< font-size: 16px;">多样性：可以将流行的编程语言（例如C/C++和Rust）编译为WASM，因此开发人员可以使用他们选择的编程语言来实现过滤器Filter；

< font-size: 16px;">可靠性和隔离性：过滤器Filter会被部署到VM沙箱中，因此与Envoy进程本身是隔离的；即使当WASM Filter出现问题导致崩溃时，它也不会影响Envoy进程；

< font-size: 16px;">安全性：过滤器Filter通过预定义API与Envoy代理进行通信，因此它们可以访问并只能修改有限数量的连接或请求属性。

< font-size: 16px;">阿里云服务网格ASM产品中提供了对WebAssembly（WASM）技术的支持，服务网格使用人员可以把扩展的WASM Filter通过ASM部署到数据面集群中相应的Envoy代理中。通廊坊市舆情过自研的ASMFilterDeployment组件,可以支持动态加载插件、简单易用、以及支持热更新等能力。

< font-size: 16px;">

< font-size: 16px;">通过这种过滤器扩展机制，可以轻松扩展Envoy的功能并将其在服务网格中的应用推向了新的高度。

< font-size: 16px;">服务网格实践之成熟度模型

< font-size: 16px;">

< font-size: 16px;">服务网格作为应用服务通信的统一基础设施,可以（并且应该）逐步采用。在此,我们推出了它的实践之成熟度模型,分为了5个层次,分别为一键启用、可观测提升、安全加固、多种基础设施的支持,以及多集群混合管理。这5个方面分别涵盖了前面讲述的统一流量管理、统一可观测性、统一服务安全以及支持不同的计算基础设施和多集群非容器化应用的混合管理。

< font-size: 16px;">《Istio服务网格技术解析与实战》读者可免费体验ASM产品进行学习！点击了解阿里云服务网格产品ASM：www.aliyun.com/product/servicemesh

< font-size: 16px;">作者简介

< font-size: 16px;">王夕宁阿里云高级技术专家，阿里云服务网格产品ASM及Istio on ACK技术负责人，关注Kubernetes、云原生、服务网格等领域。之前曾在IBM中国开发中心工作，曾担任专利技术评审委员会主席，作为架构师和主要开发人员负责参与了一系列在SOA中间件、云计算等领域的工作，拥有50多项相关领域的国际技术专利。著有《Istio服务网格技术解析与实践》。xining.wxn alibaba-inc.com