托管式服务网格:云原生时代的应用体系架构进化

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 以下内容是基于作者在云原生产业2022年大会上的演讲内容。

回顾下应用服务架构体系的演进。从服务调用方与提供方的处理方式来看, 可以分为3个阶段。

image.png


第一个阶段是集中式负载均衡, 也就是说服务调用方是通过一个外部的负载均衡路由到对应的服务提供方。 其优势显而易见, 对应用本身无侵入, 可以支持多语言多框架来开发实现应用本身, 负载均衡统一集中管理, 整个部署简单。但劣势也非常显著, 因为是集中式所以导致伸缩性受限, 同时这种集中式负载均衡的服务治理能力相对都较弱。

第二阶段是指微服务的分布式治理, 即服务调用方内置治理能力, SDK库的方式集成到应用中。带来的优势是整个伸缩性较好, 服务治理能力强, 但同时会注意到它的劣势, 包括对应用本身的侵入、因为依赖于SDK所以导致对多语言支持比较困难、分布式管理部署带来的复杂性等。

第三阶段就是现在的服务网格技术。通过把这些服务治理的能力Sidecar化,就能够把服务治理的能力与应用程序本身进行了解耦,可以较好地支持多种编程语言、同时这些sidecar能力不需要依赖于某种特定技术框架。这些sidecar代理形成一个网状的数据平面,通过该数据平面处理和观察所有服务间的流量。控制面对这些sidecar代理进行统一管理。但因此带来了一定的复杂度。

 

这是服务网格的架构图。 前面提到, 在服务网格技术下, 每一个应用服务实例都会伴随了一个Sidecar代理, 业务代码不感知Sidecar的存在。这个Sidecar代理负责拦截应用的流量,并且提供流量治理、安全、可观测三大功能。

image.png


在云原生应用模型中,一个应用程序可能会包含若干个服务,每个服务又有若干个实例构成,那么这些成百上千个应用程序的sidecar代理就形成了一个数据面, 也就是图中的数据平面层。

而如何统一管理这些Sidecar代理, 这就是服务网格中的控制平面部分要解决的问题。控制平面是服务网格的大脑,负责为数据平面的Sidecar代理下发配置, 管理数据面的组件如何执行, 同时也为网格使用人员提供统一的API,以便较容易地操纵网格管理能力。

通常来说, 启用服务网格之后, 开发人员、运维人员以及SRE团队将以统一的、声明的方式解决应用服务管理问题。

 

服务网格作为一种用来管理应用服务通信的基础核心技术,  为应用服务间的调用带来了安全、可靠、快速、应用无感知的流量路由、安全、可观测能力。

可以看到, 服务网格加持下的云原生应用基础设施带来了重要的优势, 分为六个方面。

image.png


优势之一:异构服务统一治理

 

•       多语言多框架的互通与治理、与传统微服务体系融合的双模架构

•       精细化的多协议流量控制、东西向与南北向流量的统一管理

•       统一的异构计算基础设施的自动服务发现

优势之二:端到端的可观测

•       日志、监控与跟踪融合的一体化智能运维

•       直观易用的可视化网格拓扑、基于颜色标识的健康识别体系

•       内置最佳实践、自助式网格诊断

优势之三:零信任安全

•       端到端mTLS加密、基于属性的访问控制(ABAC)

•       OPA声明式策略引擎、全局唯一的工作负载身份(Identity

•       带有仪表板的完整审计历史记录及洞察分析

优势之四:软硬结合性能优化

 

•       首个基于Intel Multi-Buffer技术提升TLS加解密的服务网格平台

•       NFD自动探测硬件特征, 自适应支持诸如AVX指令集、QAT加速等特性

•       首批通过可信云服务网格平台以及性能评测先进级认证

优势之五:SLO驱动的应用弹性

•       服务级别目标 (SLO) 策略

•       基于可观测性数据的应用服务的自动弹性伸缩

•       多集群流量突发下的自动切换与故障容灾

优势之六:开箱即用扩展&生态兼容

•       开箱即用的EnvoyFilter插件市场、WebAssembly插件全生命周期管理

•       Proxyless模式的统一融合, 支持SDK、内核eBPF方式

•       兼容Istio生态系统, 支持Serverless/Knative, AI Serving/KServe

 

 

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

image.png


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

 

 

服务网格技术的下一站如何发展:Sidecar Proxy Proxyless模式的融合一句话来总结的话, 就是 同一个控制面, 支撑不同的数据面形态。同一个控制面就是指使用ASM托管侧组件作为统一的标准形式的控制入口,  这个控制面运行在阿里云侧, 属于hosted托管模式。

image.png


而数据面支持Sidecar Proxy Proxyless模式的融合, 其中数据面的组件虽然不是hosted托管模式, 但是也是managed模式, 也就是说这些组件的生命周期也是由ASM统一来管理, 包括分发到数据面、升级、卸载等。

具体来说, Sidecar Proxy模式下, 除了当前标准的Envoy代理之外, 我们的架构可以比较容易地支持其他Sidecar, 譬如说Dapr sidecar, 当前微软OSM+Dapr就是采用了这种双sidecar模式。

Proxyless模式下,  为了提升QPS降低时延, 可以使用SDK方式, 譬如gRPC已经支持xDS协议客户端, 我们的Dubbo团队也在这条路上。我想今年我和北纬团队双方是可以一起在这个点上进行一些突破实现。

另外一个proxyless模式, 就是指- 内核eBPF + NodeProxy方式。 这个模式是对sidecar 模式的一个根本性改变, 一个节点只有一个Proxy, 并且能力offload到节点上。这部分我们今年也会有些产品落地。

 

围绕服务网格技术, 业界存在着一系列以应用为中心的生态系统, 其中, 阿里云托管服务网格ASM支持了以下多种生态系统。列举如下。

§  现代化软件开发的生命周期管理和DevOps 创新

服务网格的核心原则(安全性、可靠性和可观察性)支持了现代化软件开发的生命周期管理和 DevOps 创新, 为在云计算环境下如何进行架构设计、开发、自动化部署和运维提供了灵活性、可扩展性和可测试性能力。 由此可见, 服务网格为处理现代软件开发提供了坚实的基础,任何为 Kubernetes 构建和部署应用程序的团队都应该认真考虑实施服务网格。

DevOps 的重要组成部分之一是创建持续集成和部署 (CI/CD),以更快更可靠地向生产系统交付容器化应用程序代码。在 CI/CD  Pipeline中启用金丝雀或蓝绿部署可为生产系统中的新应用程序版本提供更强大的测试,并采用安全回滚策略。在这种情况下,服务网格有助于在生产系统中进行金丝雀部署。当前阿里云服务网格ASM支持了与ArgoCDArgo RolloutKubeVela以及云效、Flagger等系统的集成实现了应用的蓝绿或金丝雀发布, 具体如下。

o  ArgoCD职责主要是监听Git仓库中的应用编排的变化,并集群中应用真实运行状态进行对比,自动/手动去同步拉取应用编排的变更到部署集群中。如何在阿里云服务网格ASM中集成ArgoCD进行应用程序的发布、更新,简化了运维成本, 具体参见: https://developer.aliyun.com/article/971976

o  Argo Rollouts提供了更强大的蓝绿、金丝雀部署能力。在实践中可以将两者结合来提供基于GitOps 的渐进式交付能力, 具体参见:https://developer.aliyun.com/article/971975

o  KubeVela是一个开箱即用的、现代化的应用交付与管理平台。使用服务网格ASM结合KubeVela可以实现应用的渐进式灰度发布,达到平缓升级应用的目的。具体参见: https://help.aliyun.com/document_detail/337899.html

o  此外, 阿里云云效流水线 Flow提供了基于阿里云 服务网格ASM完成 Kubernetes 应用的蓝绿发布。具体参见: https://help.aliyun.com/document_detail/160071.html

o  Flagger是另外一种渐进式交付工具,可自动执行在 Kubernetes 上运行的应用程序的发布过程。它通过在测量指标和运行一致性测试的同时,逐渐将流量转移到新版本,降低了在生产中引入新软件版本的风险。阿里云服务网格ASM已经支持通过Flagger实现这种渐进式发布能力, 具体参见: https://docs.flagger.app/install/flagger-install-on-alibaba-servicemesh

 

§  微服务框架兼容

支持 Spring Boot/Cloud 应用无缝迁移至服务网格进行统一纳管和治理, 提供了融合过程中出现的典型问题解决能力, 包括容器集群内外服务如何互通、不同的语言服务之间如何进行互联互通等常见场景。具体参见:https://developer.aliyun.com/article/974941

 

§  Serverless容器与基于流量模式的自动扩缩

ServerlessService Mesh是两种流行的云原生技术,客户正在探索如何从中创造价值。 随着我们与客户深入研究这些解决方案,问题经常出现在这两种流行技术之间的交集以及它们如何相互补充上。我们能否利用Service Mesh 来保护、观察和公开我们的 Knative 无服务器应用程序?在一个托管的服务网格ASM技术平台上支持基于KnativeServerless容器, 以及基于流量模式的自动扩缩能力, 从中可以替换如何通过托管式服务网格来简化用户维护底层基础设施的复杂度, 让用户可以轻松地构建自己的Serverless平台。具体参见:https://developer.aliyun.com/article/975639

 

§  AI Serving

o  Kubeflow Serving是谷歌牵头发起的一个基于Kubernetes支持机器学习的社区项目,它的下一代名称改为KServe, 该项目的目的是可以通过云原生的方式支持不同的机器学习框架,基于服务网格实现流量控制和模型版本的更新及回滚。具体参见:https://developer.aliyun.com/article/971974

o  

§  零信任安全及Policy As Code

在使用 Kubernetes Network Policy 实现三层网络安全控制之上,服务网格 ASM 提供了包括对等身份和请求身份认证能力、Istio 授权策略以及更为精细化管理的基于 OPA(Open Policy Agent) 的策略控制能力。

具体来说, 构建基于服务网格的零信任安全能力体系包括了以下几个方面:

o  零信任的基础 - 工作负载身份;如何为云原生工作负载提供统一的身份;ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义,并根据特定场景提供定制机制用于扩展身份构建体系, 同时兼容社区 SPIFFE 标准;

o  零信任的载体 - 安全证书,ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制,通过 X509 TLS证书建立身份,每个代理都使用该证书。并提供证书和私钥轮换;

o  零信任的引擎 - 策略执行,基于策略的信任引擎是构建零信任的关键核心,ASM 产品除了支持 Istio RBAC 授权策略之外,还提供了基于 OPA 提供更加细粒度的授权策略;

o  零信任的洞察 - 可视化与分析,ASM 产品提供了可观测机制用于监视策略执行的日志和指标,来判断每一个策略的执行情况等;

o  具体可以参见: https://developer.aliyun.com/article/787187

 

改造为云原生应用带来的业务价值非常多,其中一个就是弹性扩缩容,它能够更好地应对流量峰值和低谷,达到降本提效的目的。 服务网格ASM为应用服务间通信提供了一种非侵入式的生成遥测数据的能力, 指标获取不需要修改应用逻辑本身。

image.png


根据监控的四个黄金指标维度(延迟、流量、错误和饱和度),服务网格ASM为管理的服务生成一系列指标, 支持多个协议, 包括HTTP, HTTP/2, GRPC, TCP等。

此外, 服务网格内置了20多个监控标签, 支持所有Envoy代理指标属性定义、通用表达式语言CEL,  支持自定义 Istio 生成的指标。

 

此外,   我们也在探索拓宽服务网格驱动的新场景, 我这儿是举了一个AI Serving示例。

image.png

这个需求来源也是来自我们的实际客户, 这些客户使用场景就是希望在服务网格技术之上运行KServe来实现AI服务。KServe平滑运行于服务网格之上, 实现模型服务的蓝/绿和金丝雀部署、修订版本之间的流量分配等能力。支持自动伸缩的Serverless推理工作负载部署、支持高可扩展性、基于并发的智能负载路由等能力。具体参见: https://developer.aliyun.com/article/971974

 

作为业内首个全托管Istio兼容的阿里云服务网格产品ASM,一开始从架构上就保持了与社区、业界趋势的一致性,控制平面的组件托管在阿里云侧,与数据面侧的用户集群独立。ASM产品是基于社区Istio定制实现的,在托管的控制面侧提供了用于支撑精细化的流量管理和安全管理的组件能力。通过托管模式,解耦了Istio组件与所管理的K8s集群的生命周期管理,使得架构更加灵活,提升了系统的可伸缩性。从202241日起,阿里云服务网格ASM正式推出商业化版本, 提供了更丰富的能力、更大的规模支持及更完善的技术保障,更好地满足客户的不同需求场景, 详情可见产品介绍:https://www.aliyun.com/product/servicemesh


相关文章
|
12天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
7天前
|
监控 Cloud Native 持续交付
云原生技术在现代企业中的应用与实践
本文将深入探讨云原生技术如何改变现代企业的运作模式,提升业务灵活性和创新能力。通过实际案例分析,我们将揭示云原生架构的关键要素、实施步骤以及面临的挑战,为读者提供一套清晰的云原生转型指南。
|
8天前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构
|
11天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
37 5
|
12天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
31 5
|
12天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
12天前
|
消息中间件 缓存 Cloud Native
云原生架构下的性能优化实践与挑战####
随着企业数字化转型的加速,云原生架构以其高度解耦、弹性伸缩和快速迭代的特性,成为现代软件开发的首选模式。本文深入探讨了云原生环境下性能优化的关键策略与面临的主要挑战,通过案例分析,揭示了如何有效利用容器化、微服务、动态调度等技术手段提升应用性能,同时指出了在复杂云环境中确保系统稳定性和高效性的难题,为开发者和架构师提供了实战指南。 ####
27 3
|
12天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####
|
8天前
|
负载均衡 Cloud Native 持续交付
云原生时代的微服务架构:优势、挑战与实践
云原生时代的微服务架构:优势、挑战与实践
19 0
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。

相关产品

  • 服务网格
  • 下一篇
    无影云桌面