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

本文涉及的产品
服务治理 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


相关文章
|
7天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
2天前
|
运维 Kubernetes Cloud Native
Kubernetes云原生架构深度解析与实践指南####
本文深入探讨了Kubernetes作为领先的云原生应用编排平台,其设计理念、核心组件及高级特性。通过剖析Kubernetes的工作原理,结合具体案例分析,为读者呈现如何在实际项目中高效部署、管理和扩展容器化应用的策略与技巧。文章还涵盖了服务发现、负载均衡、配置管理、自动化伸缩等关键议题,旨在帮助开发者和运维人员掌握利用Kubernetes构建健壮、可伸缩的云原生生态系统的能力。 ####
|
8天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
9天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
27 2
|
9天前
|
弹性计算 监控 Cloud Native
云原生架构下的性能优化实践与策略####
在数字化转型加速的今天,云原生技术以其弹性、敏捷和高效的特点成为企业IT架构转型的首选。本文深入探讨了云原生架构的核心理念,通过具体案例分析,揭示了性能优化的关键路径与策略,为开发者和企业提供了可操作的实践指南。 ####
|
11天前
|
敏捷开发 Cloud Native 持续交付
云原生技术在现代企业中的应用与实践
【10月更文挑战第23天】本文将深入探讨云原生技术在现代企业中的广泛应用,并结合具体案例分析其对企业数字化转型的推动作用。我们将从云原生技术的基本原理出发,逐步揭示其在提高业务敏捷性、降低成本和增强系统可靠性方面的优势。同时,文章还将分享一系列成功实施云原生技术的企业案例,为读者提供实践中的参考和启示。最后,我们将讨论云原生技术面临的挑战及未来的发展趋势,为企业在这一领域的进一步探索提供指导。
|
12天前
|
监控 Cloud Native 测试技术
云原生架构下的性能优化与实践####
【10月更文挑战第21天】 本文深入探讨了在云原生环境下,如何通过一系列技术手段和最佳实践来提升应用性能。文章首先概述了云原生架构的基本原则与优势,随后详细分析了影响性能的关键因素,包括容器编排、微服务设计、持续集成/持续部署(CI/CD)流程以及监控与日志管理。针对这些因素,文中不仅介绍了具体的优化策略,如资源请求与限制的合理配置、服务间通信的高效实现、自动化测试与部署的优化,还结合案例分析,展示了如何在实际项目中有效实施这些策略以显著提升系统响应速度和处理能力。此外,文章还强调了性能测试的重要性,并提供了几种常用的性能测试工具和方法。最后,总结了云原生性能优化的未来趋势,为开发者和架构师
12 2
|
12天前
|
Cloud Native 持续交付 云计算
云原生技术深度探索:构建现代化应用的基石####
【10月更文挑战第21天】 本文将深入探讨云原生技术的核心概念、关键技术及其在现代软件开发中的应用。我们将从容器化、微服务架构、持续集成/持续部署(CI/CD)、无服务器架构等关键方面展开,揭示这些技术如何共同作用,帮助企业实现高效、弹性且易于维护的应用部署与管理。通过实例分析,展现云原生技术在实际项目中的显著优势,为读者提供一套全面理解并应用云原生技术的指南。 ####
31 2
|
12天前
|
Kubernetes Cloud Native JavaScript
为使用WebSocket构建的双向通信应用带来基于服务网格的全链路灰度
介绍如何使用为基于WebSocket的云原生应用构建全链路灰度方案。
|
2天前
|
Cloud Native API 云计算
云原生架构的深度探索与实践####
本文深入探讨了云原生架构的核心概念、技术特点及其在现代软件开发中的应用实践。通过分析云原生架构如何促进企业数字化转型,提升业务敏捷性与可扩展性,本文旨在为读者提供一个全面而深入的理解框架。我们将从云原生的定义出发,逐步深入到其关键技术组件、最佳实践案例及面临的挑战与解决方案,为开发者和企业决策者提供宝贵的参考与启示。 ####

相关产品

  • 服务网格