1、0102微服务发展趋势下一代微服务架构 2020-2027，全球微服务云服务市场 CAGR 18.6%，其中国内市场 CAGR 18.2%（数据来源：Research And Markets）。2022 Gartner应用架构与集成技术成熟度曲线：API管理处于稳步爬升中期，微服务接近稳步爬升初期，有较大增长空间。2022 CSDN 开发者调查报告：58%用户关注微服务架构、API管理及服务治理，关注度高。2020年，37%Ingress 实现选择 Envoy（比 2019 年增加了 116%），Envoy 社区推出 Gateway 开源产品（CNCF）。微服务架构API管理分布式数据库Dev

2、Ops容器调度平台服务观测性混沌工程流式计算来源：CSDN 2021-2022 中国开发者调查报告40%15%14%10%8%4%3%3%3%微服务行业趋势微服务技术趋势（DevOps-DevSecOps）RPC&注册中心进入成熟阶段，服务网格回归理性，网关作为安全的入口蓬勃发展引自：https:/cf.io/Dev效率性能可用安全2011Dubbo2014Spring-Cloud-NetflixEurekaHystrixRibbonZuul2015Service MeshLinkerdLinkerdEnvoyIstio2018Netflix进入维护模式Sping-Cloud-AlibabaN

3、acosSentinelSeata2022HigressOpenSerGoDubbo 3.0Nacos 3.0？微服务发展历程微服务发展历程0102微服务发展趋势下一代微服务架构D Dubbo/S Spring-Cloud-Alibaba/Envoy服务框架+服务网格Higress网关OpensergoIstio控制面易用、标准化、语言无关、可扩展、可持续的架构SentinelSeata服务治理扩展性WASM/LUANacos/Nacos-PilotXDSXDSXDSConsole（Higress/Nacos/Sentinel/Dubbo-admin）下一代微服务架构下一代微服务架构控制面（流

4、量治理控制面（流量治理-服务治理）服务治理）微服务多语言微服务多语言(Lib(Lib&Sidecar)Sidecar)跨语言微服务生态多语言客户端生态微服务最佳实践微服务扩展性微服务扩展性(WASM)(WASM)插件市场控制面Sidecar网关数据面饶子昊（铖朴）010203背景介绍静态编译与GraalVM效果演示03社区规划在正式静态编译技术之前，首先简单回顾一下一个Java应用程序从开发、打包、编译执行的过程：Java源代码Java字节码.class.javajavac编译运行JVM操作系统Java编译执行过程一个Java程序的执行生命周期如下图所示，分为JVM初始化、应用程序初始化、应用

5、预热、应用稳定执行和关闭5个部分：Java应用生命周期图片来自：https:/ imageJVM操作系统图片来自：GraalVM静态编译原理与应用、https:/ JIT Compiler。静态编译框架和运行时由Substrate VM子项目实现，兼容OpenJDK运行时实现，提供了原生镜像程序运行时的异常处理、同步调度、线程管理、内存管理等功能。图片来自：https:/ Cloud Alibaba组件的GraalVM静态编译能力适配。其中基于GraalVM技术的最新版本Spring Cloud Alibaba应用使用Nacos进行服务注册与消费/配置订阅的启动速度提升了近10倍、内存占用率降

6、低为原来1/3。NacosRocketMQSentinelSeata应用类型服务注册服务消费监听配置消息发送消息消费客户端限流 客户端降级Seata客户端启动速度（GraalVM）0.339s0.479s0.182s0.236s0.348s0.534s0.521s2.999s启动速度（JVM）4.161s4.763s2.529s3.138s4.3923.065s3.485s8.611s内存占用（GraalVM）57.9M59.0M50.1M91.0M68.2M61.0M60.7M112.4M内存占用（JVM）141.4M129.8M122.7M217.5M181.8M152.1M151.4M2

7、63.6M上述测试代码样例来自Spring Cloud Alibaba项目中的examples模块，4c16g Mac环境，每组数据测试3次取平均，具体数据因机器不同可能会有差异。010203背景介绍静态编译与GraalVM效果演示03社区规划远程调用负载均衡服务注册与发现分布式配置微服务高可用限流分布式一致性微服务治理微服务基础能力统一控制平面微服务进阶能力熔断降级集群流控分布式消息分布式事务标签路由微服务安全全链路流控离群实例摘除多活容灾发展中稳定态.欢迎大家一起加入Spring Cloud Alibaba社区，一起打造云原生场景下更好用的微服务技术：0102Dubbo 与 gRPC使用

8、gRPC 开发微服务03Dubbo 让 gRPC 微服务开发更简单04总结与规划01Dubbo 与 gRPC主流“RPC”框架开源组织开源组织语言语言序列化序列化协议协议扩展能力扩展能力生态丰富度生态丰富度上手难度上手难度服务治理服务治理DubboAlibabaApacheJava 跨平台Hessian、protobuf、jsonDubbo、gRPC、rest高高(低)中支持gRPCGoogleCNCF跨平台protobufgRPC中高中(高)不支持ThriftFacebookApache跨平台thirftthirft低低中支持Motan微博JavaHessian、JsonMotan、tcp中

9、低低支持*SpringCloudSpringJavaJsonrest高高低支持gRPC 简介：gRPC 是什么？gRPC-ServergRPC-ServergRPC-ServergRPC-GatewayAPIClientRestRest apiapi(JSON(JSON OverOver HTTP/1.1)HTTP/1.1)gRPC 简介：提供了哪些能力1.HTTP/22.双向通信3.Protocol Buffers4.强类型5.多语言 SDK1.高性能2.跨平台、跨语言3.易于使用4.穿透性强5.可扩性6.生态丰富Dubbo 简介：Dubbo 是什么?RPCWEB服务发现流量管控可观测认证鉴

10、权丰富生态全链路追踪Dubbo 简介：基本架构Dubbo 数据面Dubbo Admin 抽象控制面Dubbo 数据面RPC ProtocolDubboConsumerDubboProvider服务发现、流量管控等治理数据流ZookeeperNacosConsoleKubernetesIstioDubbo 简介：与应用开发框架集成Z业务逻辑服务定义IDLInterface编程模型同步异步服务发现NacosZookeeper负载均衡随机一致性hash流量管控路由动态配置上下文Dubbo 简介：灵活的协议选择DubboProviderDubboConsumerHTTP/2Dubbo2gRPCREST

11、Dubbo 简介：合理的抽象和可扩展性流量管控协议与编码TriplegRPCRESTPBHessianFastjsonHashWRRRTagScriptConditionTimeoutLogMetricsFailoverFailfastFailsafeNacosZKConsul服务治理NacosZKApolloNacosZKRedisLog4jSlf4jLogback诊断调优LiveStartReadyLog4jSlf4jLogbackLsOnlineOfflineDubbo 简介：丰富的生态定位不同定位不同gRPC：限定协议与框架Dubbo：提供内置协议，同时提供微服务抽象与治理能力解决问题

12、不同解决问题不同gRPC：解决服务之间通信问题Dubbo：解决微服务全流程(服务定义、开发、通信、治理)中的各种问题gRPCgRPC 是一款是一款 RPCRPC 协议与实现，而协议与实现，而 DubboDubbo 是一款微服务开发框架。是一款微服务开发框架。gRPCgRPC 是是 DubboDubbo 内置内置原生支持的一种通信协议。原生支持的一种通信协议。02使用 gRPC 开发微服务gRPC 的开发模式定义定义IDL(.proto)IDL(.proto)生成生成 stubstubJavaGoRustpluginsprotocgRPCStubgRPCStubgRPCgRPC-ClientCl

13、ientgRPCgRPC-ServerServerProtoProto datadata一些代码示例IDL 服务发布管理无与业务应用框架集成无成体系的编程配置模式112323直接使用 gRPC 框架开发微服务-服务治理协议与数据传输只是构建微服务的基础，我们还需要服务发现、配置管理、可观测性等一系列治理能力。C ontainerO bservability进程S ervice AS erviceDiscoveryC onfigurationManagementF rameworkIntegrationData E xchangeapp logicC ontainer进程S ervice AO

14、bservabilityS erviceDiscoveryC onfigurationManagementF rameworkIntegrationData E xchangeapp logicgR P C直接使用 gRPC 框架开发微服务-更多要解决的问题1.1.与更多微服务生态组件的整合与适配与更多微服务生态组件的整合与适配2.2.集群调用的可视化监测集群调用的可视化监测3.3.内置流量管控策略支持内置流量管控策略支持4.4.面向微服务实践的更多抽象面向微服务实践的更多抽象多注册中心支持多注册中心支持多协议支持多协议支持其他其他让 gRPC 微服务开发规模化推广的解决方案公司内部定制开发公

15、司内部定制开发部分社区生态解决方案部分社区生态解决方案服务网格服务网格更好的选择：更好的选择：Dubbo Dubbo 是另一个轻量级、一站式解决方案是另一个轻量级、一站式解决方案03Dubbo 框架下的 gRPC 微服务开发Dubbo3 中的 HTTP/2 协议实现SPEC 与实现上完全兼容 gRPC，同时提供了更高性能、更灵活的实现Dubbo3 中的 HTTP/2 协议实现重载方法重载方法PojoPojomethodmethod自定义异自定义异常常attachmenattachment tUpperUpper-CaseCaseheaderheaderstreamstreamBackBack-

16、pressurepressureDubboHTTP/2支持支持支持支持支持支持支持gRPC不支持不支持不支持支持不支持支持支持请求头：请求头：响应头响应头(trailer)(trailer)：tritri-serviceservice-version:version:dubbo 应用版本号tritri-serviceservice-groupgroup:dubbo 应用 grouptritri-reqreq-idid:请求idtritri-tracetrace-traceidtraceid:trace idtritri-tracetrace-rpcidrpcid:span idtritri-t

17、racetrace-protoproto-binbin:trace上下文二进制信息tritri-unitunit-infoinfo:集群信息grpcgrpc-statusstatus:grpc 状态码，与 grpc 兼容grpcgrpc-messagemessage:报错信息tracetrace-protoproto-binbin:trace 二进制信息DubboDubbo 微服务开发微服务开发 编码与定义编码与定义添加依赖添加依赖和编译插件和编译插件通过注解引用服务通过注解引用服务通过注解发布服务通过注解发布服务定义定义IDLIDLDubboDubbo 微服务开发微服务开发 配置配置 gRP

18、C 协议协议DubboDubbo ClientClientgRPCStubDubboDubbo ServerServergRPCStubgRPCgRPCDubboDubbo 微服务开发微服务开发 原生服务发现能力原生服务发现能力DubboDubbo ClientClientgRPCStubDubboDubbo ServerServerDubboDubbo ServerServergRPCStubgRPCgRPCDubboDubbo 微服务开发微服务开发 可视化集群状态管控可视化集群状态管控Comment实例 1实例 2FrontendOrder实例 1实例 2用户浏览器网关tag=grayDe

19、tail实例 1实例 2tag=graytag=graytag=gray实例 1Usertag=gray实例 2实例 3实例 3实例 3实例env=gray实例env=gray实例env=gray实例env=graytag=gray58DubboDubbo 微服务开发 便捷的服务治理04总结与规划总结gRPC 是一个优秀的 RPC 协议和框架，得到了云原生时代的肯定。gRPC 专注在协议与框架，gRPC 官方未提供围绕微服务体系的解决方案除 IDL 之外，企业内大规模推广 gRPC 微服务需要有统一的编程与治理模型Dubbo 是阿里等企业微服务整体解决方案的输出Dubbo 提供了灵活的开发模式

20、和强大的服务治理能力Dubbo 不绑定通信协议，支持内置、gRPC 等，同时支持多协议发布使用 Dubbo 开发 gRPC 协议通信的微服务可以同时享受到 gRPC 优势的同时避免当前所存在的不足使用Dubbo作微服务治理总体解决方案+底层一键配置 gRPC 协议通信Dubbo 的未来规划易用性提高IDL 管控平台可观测性增强Dubbo Mesh官方微信公众号官方微信公众号用户交流群用户交流群注注:如失效可如失效可通过公众号回复“加群”0102云原生网关的技术演进脉络云原生网关在阿里的诞生过程03Higress 的关键特性和优势网关软件的演进：流量网关WhoWho运维WhyWhy业务的高可用/

21、可伸缩/接入加速HowHow负载均衡/健康检查/流控/重试/TLS卸载/压缩/缓存网关软件的演进：微服务网关WhoWho研发WhyWhy微服务 API 的聚合管理/API 通用能力解耦HowHow服务发现/RESTful 路由/认证鉴权/扩展机制网关软件的演进：云原生网关WhoWho研发&运维WhyWhyDevOps 驱动/云原生架构/网关形态融合HowHow声明式 API/无损变更/多语言扩展机制在阿里的诞生背景：技术选型创建源于2020年阿里内部的“本地生活战役”，战役的核心技术目标是实现阿里巴巴业务域与蚂蚁业务域之间 RPC 互访。发展历程：支撑内部业务Higress 支持东西向、南北向

22、的全域流量调度Higress 在支付宝、钉钉、淘宝、天猫、优酷、飞猪、口碑、达摩院等阿里各业务系统中使用经过双11海量请求的考验，大促日可轻松承载每秒承载数10万笔请求，日请求量达到百亿级别发展历程：沉淀云产品在与优酷合作时，双方同时提出将 Tengine（流量网关）和Higress（微服务网关）合并的想法由于K8s 集群内外网络的天然隔离性，云上用户需要一款兼顾高性能，安全性，以及服务治理能力的 Ingress 网关2021 年，阿里巴巴开启了中间件“三位一体”战役，目标是使用云产品支撑集团业务，Higress 正式沉淀为云产品，同时服务公有云与阿里内部用户发展历程：云原生网关开源发展历程：

23、云原生网关开源http:/demo.higress.ioHigress 云原生网关：API 标准支持 K8s Ingress API 标准，支持 NginxIngress 核心功能注解无缝转换比 Nginx Ingress 提供更实用的功能注解，如服务级限流，RESTful路由等拥抱 Gateway API 标准，可以实现 IngressAPI 和 Gateway API 混合使用，平滑迁移apiVersionapiVersion:networking.k8s.io/v1:networking.k8s.io/v1kind:Ingresskind:Ingressmetadata:metadata

24、:annotations:annotations:nginx.ingress.kubernetes.ionginx.ingress.kubernetes.io/rewrite/rewrite-target:/target:/higress.iohigress.io/match/match-method:POST PUT PATCHmethod:POST PUT PATCHname:fooname:foospec:spec:ingressClassNameingressClassName:higresshigressrules:rules:-http:http:paths:paths:-path

25、TypepathType:Prefix:Prefixpath:/foopath:/foobackend:backend:service:service:name:fooname:foo-serviceserviceport:port:number:5678number:5678Higress 云原生网关：异构架构下服务发现和路由apiVersionapiVersion:networking.higress.ionetworking.higress.io/v1/v1kind:kind:McpBridgeMcpBridgemetadata:metadata:name:defaultname:def

26、aultspec:spec:registries:registries:-domain:192.168.domain:192.168.1 1.2 2nacosGroupsnacosGroups:-DEFAULT_GROUPDEFAULT_GROUPnacosNamespaceIdnacosNamespaceId:d8ac64f3:d8ac64f3-37f937f9-48574857-a1a9a1a9-47a814ecf35847a814ecf358port:8848port:8848type:nacos2type:nacos2同时支持 K8s Service/Nacos/ZooKeeper 等

27、多种服务发现机制同时兼容 Nacos 1.x/2.x 订阅协议，经过大规模生产实践验证配合 Ingress 流量灰度能力，支撑微服务架构向云原生化平滑演进Higress 云原生网关：流量无损的变更Higress 云原生网关：流量无损的变更Higress 云原生网关：多语言扩展机制Sentinel Maintainer010203Sentinel 演进与发展Sentinel 2.0 服务治理能力演进OpenSergo 服务治理实践Sentinel 演进历程022-2023Sentinel Sentinel 在阿里巴巴在阿里巴巴集团内部迅速发展，

28、集团内部迅速发展，成为基础技术模块，成为基础技术模块，覆盖了所有的流量稳覆盖了所有的流量稳定性核心场景定性核心场景Sentinel Sentinel 正式正式开开源，社区迅速发源，社区迅速发展，不断扩充生态展，不断扩充生态与能力，逐步成为与能力，逐步成为最受欢迎的同类组最受欢迎的同类组件件SentinelSentinel 开始在多语开始在多语言的生态中探索，推出言的生态中探索，推出C+C+原生版本，同时针原生版本，同时针对对 Service Mesh Service Mesh 场景场景也推出了也推出了 EnvoyEnvoy 全局全局流控的支持流控的支持SentinelSentinel 推出推出

29、 GoGo 原生原生版本，并不断与版本，并不断与Dubbo/Dubbo/DaprDapr/MOSN/MOSN/斗鱼等斗鱼等社区进行合作，继续朝着社区进行合作，继续朝着云原生方向演进云原生方向演进SentinelSentinel 推出推出RustRust 原生版本，并原生版本，并基于此对基于此对 EnvoyEnvoy 集集成及成及 eBPFeBPF 层流控层流控的探索的探索?微服务治理重要性ConsumerProviderContainerGovernanceRegistryregisterregisterinvokeinvokegoverngoverngoverngovernsubscribe

30、subscribenotifynotifystartstart微服务四大件微服务四大件-提供者、消费者、注册中心、治理。提供者、消费者、注册中心、治理。核心作用核心作用:治理微服务领域中的各个组件治理微服务领域中的各个组件微服务治理提升微服务的：稳定性与效率Sentinel 品牌升级1.0:1.0:流量防护流量防护标准化云原生多语言全方位生态能力升级Sentinel 2.0：服务治理的标准实现原生对接 OpenSergo 流量治理标准云原生架构升级：local brain(SDK,Mesh)+micro brain(控制平面)针对微服务、云原生体系，全方位覆盖多语言异构化框架与组件生态能力升级

31、为流量治理与服务自愈，全方位保障服务稳定性与容错Sentinel 2.0 演进Sentinel 2.0 Overview服务隔离统一控制面（决策与治理中心）规则存储指标监控流量治理能力的标准实现API 模型标准化(nouveau model)规则配置标准化(OpenSergo 数据源)策略服务接口标准化(gRPC service)标准化流量治理与自愈WeightCalculator权重计算Router流量路由LoadBalancer负载均衡TrafficScheduler流量调度TrafficShapingController流量控制AdaptiveThrottler自适应流控策略Circui

32、tBreaker不稳定服务熔断基础指标统计指标统计扩展控制策略扩展调度策略扩展规则数据源扩展扩展机制自适应流控异常流量调度服务防抖流量路由流量染色流量控制服务熔断治理规则管理标准化(OpenSergo)全局指标汇聚与计算治理策略服务标准化(gRPC)治理策略预计算全局治理策略控制(如集群流控、全局维度的权重策略调整）Sentinel 2.0 流量治理OpenSergo 服务治理标准化规范/控制面实现/数据面OpenSergo 流量路由CRD推送按照制定的按照制定的headerheader进行流量路由进行流量路由基于基于IstioIstio VirtualServiceVirtualServic

33、e/DestinationRuleDestinationRule进行扩展进行扩展Sentinel 2.0&Dubbo TrafficRouting2023.022023.032023.06控制面与 Spec社区合作统一治理控制面全面升级，支持 Istio 服务网格Spec 支持全链路灰度各个微服务治理领域的生态落地，统一控制面、SpecSpec 共建控制面初步生产可用Spec 支持无损上下线、离群实例摘除控制面正式 GA 并提供dashboard支持微服务安全治理治理实现+Sentinel 2.0 流量治理能力 beta，支持流量路由、全链路灰度离群实例摘除能力落地Sentinel Go 2.

34、0 发布升级Envoy/eBPF+Sentinel 2.0 集成无损上下线能力落地Sentinel 2.0 流量治理品牌升级正式发布Sentinel 2.0&OpenSergo RoadmapSeataSeata:Connect Data&ApplicationsConnect Data&Applications为什么加入我们？阿里最核心的技术部门之一阿里业务增长最快的部门之一阿里技术影响力最大的部门之一招聘邮箱jimin.jmalibaba-分布式事务 Seata配置与服务管理 Nacos微服务框架 Dubbo SCA下一代网关 HigressService Mesh分布式消息队列 Rock

35、etMQ分布式链路追踪分布式应用托管 KubeVela云原生SRE服务治理Sentinel OpensergoServerless诚聘从TXC/GTS 到SeataSeata 社区最新进展Seata 社区未来规划TXC/GTSTXC/GTS PaaS 中间件集成层数据中间件，与 HSF、TDDL、MetaQ深度集成，在集团内广泛应用 日均百亿级别调用，标准3节点集群吞吐达近10w TPS 可用性/性能SLA 99.99%，毫秒级事务处理，全年无故障开发视角的应用架构DB一致性一致性通用性通用性复杂性复杂性接入成本接入成本应用框架低低低高数据中间件中高中低数据库高中高中TXC/GTSTXC/GT

36、STCCTCC SagaSagaATAT XAXAi id dmoneymoney11000-100ididmoneymoney21000+100服务A Aconsumer服务BproviderproviderDBDBRPC/restRPC/restTransaction ManagerTransactionCoordinatorResourceManagers(RM)ResourceManagers(RM)ResourceManagertimeoutTXC/GTSTXC/GTSTXC/GTSTXC/GTS阿里微服务开源最佳实践阿里微服务开源最佳实践Seata 对于市面上主流的关系数据库，RP

37、C框架做了广泛的支持，同时被许多第三方社区做了主动和被动集成。支持 Java、Golang、PHP、Python 多语言.目前 Seata 开源产品已被上千家企业在业务系统中应用，金融企业纷纷试点。SkywalkingSkywalkingShardingsphereShardingsphereMybatisMybatis-PlusPlusSpring Cloud AlibabaSpring Cloud AlibabaDubboDubboNacosNacosE Eururekeka aMySQLMySQLOracleOraclePostgreSQLPostgreSQLTiDBTiDBApollo

38、ApolloJRaftJRaftRedisRedisETCDETCDgRPCgRPCMotanMotansofasofaConsulConsulzookeeperzookeeperOceanOceanBaseBaseSEATA SEATA ：Simple Extensible Autonomous Transaction ArchitectureSimple Extensible Autonomous Transaction Architecture一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服

39、务。易用的分布式事务服务。SeataSeata 社区社区SeataSeata的生态的生态场景1：中航信航旅纵横项目中航信作为 Seata 最早的天使用户，在 Seata 0.2 版本就将 Seata 引入了航旅纵横项目的核心业务中，例如解决机票和优惠券业务的数据一致性问题。大幅度提升了开发的效率，减少了数据不一致造成的资损，提升了前端用户的体验。场景2：滴滴出行二轮车事业部滴滴在 Seata 0.6.1 版本就将 Seata 引入到了二轮车事业部的各个业务中，用于解决小蓝单车、电动车、资产等业务流程的数据一致性问题，解决了数据不一致造成的长期困扰，减少了内部资产的资损，优化了外部用户的使用体验

40、。场景3：美团基础架构美团基础架构团队基于开源 Seata 项目封装了内部分布式事务 Swan 项目，作为美团内部各业务解决分布式事务问题的组件。场景4：盒马小镇盒马小镇游戏互动中通过 Seata 控制偷花的流程，开发周期从 20d 下降至 5d，大幅度减少了开发的成本。SeataSeata 案例案例TCCATTCCATSagaTCCATSagaXAAT0.1v0.4v0.1v0.9v1.1SeataSeata的演进的演进性能TCCTCCSeataSeata分布式事务隔离性业务改造成本SeataSeata 最新进展最新进展 支持oracle和postgresql 多主键。支持 Dubbo 3

41、和 Spring Boot 3 支持 JDK 17 支持 ARM64 镜像 支持多注册模型 扩展了多种SQL语法的支持 支持 native-image 支持 redis lua 存储模式DBDBRedisRedisRaftRaftmysqlmysqloracleoraclepgsqlpgsqltidbtidbOBOBSSSSRPCRPCDubboDubbogRPCgRPCsofasofaSpringSpringhttphttpmotanmotanMQMQRocketMQRocketMQJMSJMSXAXAmockmock serverservertestContainertestContain

42、ernacosnacossofasofazkzketcdetcdserviceCombserviceCombpolarispolarisapolloapolloconsulconsuleurekaeurekaGTSGTSJavaJavaJDKJDKspringspringgolanggolangphpphppythonpythonjsjsdaprdaprAPIAPISeata 2.x存储/协议/特性第三方生态解决方案多语言生态研发效能/用户体验APMAPMskywalkingskywalkingprometheusprometheusLTSLTSSQLSQLSagaSaganamesrvnam

43、esrvSeataSeata 2.x2.x 规划规划SeataSeata 官微官微01项目背景02架构与功能03社区介绍04功能演示项目背景1距离产生了美，也产生了延时和费用多个应用共享同一个分布式存储的访问网络带宽计算弹性无限，数据弹性不足KubernetesDevOpsMicro Service/Service MeshEnterprise ApplicationsInnovationGitlabJenkinsGitOpsEDASIJEEAIBlockchainIoTC+Spring CloudServerless ApplicationGeneAI AppsBig Data Apps数据

44、密集型应用对存储访问性能提出高要求零节点，免运维按使用量计费，Pay for Application rather than infrastructure秒级弹性扩容，无限容量强隔离，高安全标准化Kubernetes接口Container Scheduling and OrchestrationContainer Scheduling and Orchestration统一集群管理（集群控制面）PODPOD自建K8S客户IDC自建高性能存储POD高速通道专线ACK容器集群裸金属PODECIPODECSPOD公共云即开即用的容器弹性能力可以很好做自建IDC的弹性能力补充。但是如何将自建存储与云上

45、弹性资源对接，则变成混合云客户使用阿里云的门槛。阿里云弹性扩缩容架构与功能2面向应用的数据抽象：零侵入，无需关心应用改造，数据版本，加速，安全等工作。可扩展的数据引擎插件：支持可编程和无代码的扩展能力。通用数据加速：将数据分布式缓存技术与自动弹性(Autoscaling)，可迁移(Portability)，可观测(Observability)，亲和性调度（Scheduling）能力相结合，提供更好的加速能力混合云数据访问：支持无缝对接用户自建存储。运行时平台无关：可以支持原生、边缘、Serverless K8s集群等多样化环境。对云原生”计算任务使用数据的过程”抽象,提出了弹性数据集Datas

46、et的概念，并围绕其构建面向混合云和Serverless场景数据编排系统。AccessAccelerateDay-2 Orchestration and ManagementDatasetKubernetesServerless KubernetesIoT/Edge.FluidAbstractOrchestrateAccelerateManageRuntime PluginsGPluggable数据集抽象apiVersion:data.fluid.io/v1alpha1kind:Datasetmetadata:name:imagenetspec:mounts:-mountPoint:s3:/i

47、magenet/trainname:train-mountPoint:pvc:/cephname:validationnodeAffinity:required:-nodeSelectorTerms:-matchExpressions:-key:GPUoperator:In values:-truefeatures:filesSize：smalls3cephIn GPU nodes 统一的顶层统一的顶层数据集数据集模型模型描述描述Optimization可扩展的数据引擎插件Runtime抽象DatasetRuntimeRuntime PluginsG.cacheRuntimethinRunti

48、meData OperationRuntimeProfilePodPodEnd UserJindoJindoAlluxioAlluxioJuicefsJuicefsGoosefsGoosefsThinThin:ossfsossfs-profileprofileDataset/ThinRuntimeDataset/ThinRuntimeCluster AdminStorageStorage ProvidersProvidersDocker Image通用FUSE接口访问异构存储apiVersion:v1kind:Podmetadata:name:resnet50labels:fluid.io/d

49、ataset.preferred.sched:imagenetspec:containers:-name:trainimage:resnet50volumeMounts:-mountPath:/dataname:imagenetvolumes:-name:imagenetpersistentVolumeClaim:claimName:imagenetclientKubernetesSchedulerFluid SchedulerPluginFluid RuntimeJindoFSJindoFSN1N2N310G Cached5G CachedPod1.Create Pod 2.Order th

50、e nodes by the cache capabilities 3.Start pod in N1Dataset NameP1P2缓存数据位置感知调度调度策略支持强制和非强制两种模式调度策略支持强制和非强制两种模式非强制模式下，数据缓存条件不满足的情况下，不影响非强制模式下，数据缓存条件不满足的情况下，不影响PodPod调度调度调度策略优先本地，优先同可用区调度策略优先本地，优先同可用区P3，非强制模式可选vSwitch可用区1vSwitch可用区2手动弹性伸缩手动弹性伸缩根据指标自动弹性伸缩根据指标自动弹性伸缩定时弹性伸缩定时弹性伸缩 丰富实用的丰富实用的弹性弹性策略策略缓存数据弹性伸缩

51、缓存数据弹性伸缩Serverless模式J数据接口注入、缓存弹性控制、应用生命周期管理支持所有缓存组件运行在支持所有缓存组件运行在ECIECI上上支持支持ECIECI的本地盘和内存缓存的本地盘和内存缓存弹性伸缩分布式缓存弹性伸缩分布式缓存功能演示3K ube api serverE C IP odE C IP odE C IP odE C IP od并行启动200个ECI弹性容器实例 Pod，每个ECI Pod读取存储在JuiceFS中的一个约10GB的文件。模拟AI推理场景下弹性扩容时机器学习模型的从JuiceFS加载过程比较通过Fluid访问JuiceFS和通过Fluid加速JuiceFS

52、两种方案：（1）数据读取性能差异（2）资源成本差异K ube api serverE C IP odE C IP odE C IP odE C IP odF luid C ache L ayer进行数据预热；并行启动200个ECI弹性容器实例 Pod，每个ECI Pod从分布式缓存中读取存储在JuiceFS中的一个约10GB的文件。模拟AI推理场景下弹性扩容时机器学习模型的加载过程比较通过Fluid访问JuiceFS和通过Fluid加速JuiceFS两种方案：（1）数据读取性能差异（2）资源成本差异10个ECI弹性容器实例（规格:vCPUs 24/Mem 96.0GiB）200个ECI弹性容器

53、实例(规格:vCPUs 4/Mem 8.0GiB)社区发展4系统开源情况 82,000 lines of code,written in Go and yaml.1359 commits,1309 PRs,656 Github topic discussion 1100+Github标星关注,393 forks,8 releases since Aug.2020 https:/ 技术委员会:Currently 5 maintainers 贡献者分布:近300位 contributors 来自：微服务x容器开源MeetupTHANKS微服务x容器开源MeetupOCM：定制你自己的k8s多集群管

54、理工具箱邱见Senior Principal Software Engineer RedHat2023/2/25CNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupMotivationC NC F 2021 调查报告调查报告显示大多数公司使用2-10个集群，同时使用的集群数量有增长的趋势。CNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupMotivationsC NC F 2021 调查报告使用namespace来隔离各个团队的使用是最流行的，其次是给每个团队分配单独的集群。CNCF X 阿里巴巴KubeMeet微服务x容器开源Meetup管理多个k8s集群需要m

55、onitoringDeploy applicationsNetworking accessNetworking accessService meshConfig managementCluster inventoryschedulingManifest distributionTools managementThis is where ocm sitsCNCF X 阿里巴巴KubeMeet微服务x容器开源Meetup什么是O pen C luster Management0.10.0 is released on 17th F eb.!简化混合云环境下多k8s集群的管理-Hub-spoke 架

56、构-基础的集群注册，调度和资源分发AP I-核心组件和一组任意搭配的管理插件-插件的生命周期管理，跨集群通讯-一套集成库使管理工具更方便跑在多集群环境中https:/open-cluster-management.io/CNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupIstio addonhttps:/ X 阿里巴巴KubeMeet微服务x容器开源Meetup为Argo CD提供集群注册和调度能力CNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupDemoCNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupO ngoing work更好的插件管理插

57、件滚动升级和金丝雀发布更简单的插件开发方式多集群调度亲和和反亲和，灵活的负载分布策略第三方服务提供打分机制的通用机制更多插件，更多集成Argocd Pull modelArgo workflowKnativeOLMCNCF X 阿里巴巴KubeMeet微服务x容器开源MeetupG et InvolvedGitHubhttps:/ meetings https:/ management,Scheduling,Automated operation,etc.koordinator.shkoordinator.shKubernetes任务调度PodPodPodQoS 感知调度/重调度差异化SLO策

58、略PodPodPodPod裸金属实例PodPodPodPodPodPodPodPod虚拟机实例工作负载统一编排、混部多样化工作负载010203Kubernetes 应用观测的特点和痛点Kubernetes 应用观测实践方案目前社区前沿技术方向Gartner“Top Strategic Technology Trends 2023”在业务功能、应用程序、基础设施和运营(I&O)团队之间以高度编排和集成的方法应用可观察数据，以实现从行动到反应的最短延迟和业务决策的主动规划。软件系统可被观测的一种属性软件系统可被观测的一种属性结果结果：吞吐率，响应时间，成功率（黄金三指标）过程过程：日志、指标、事件

59、、环境、链路周边周边：服务配置，资源配置，拓扑架构体系体系：上下游，业务设置洞察故障洞察故障分析性能分析性能更快决策更快决策与监控概念的差异与监控概念的差异WordPress ChartWordPress Chart1.1.分散的监控数据处理链路分散的监控数据处理链路(状态，日志，指标，追踪状态，日志，指标，追踪)；2.2.从基础设施到业务应用的全链路关联；从基础设施到业务应用的全链路关联；3.3.不同开发语言的复杂生态；不同开发语言的复杂生态；4.4.如何支撑业务开发者更轻松的决策；如何支撑业务开发者更轻松的决策；O Observability Pipelinebservability Pi

60、pelineAgentAgentCollectLogs/Metrics/TracesLogs/Metrics/TracesTransformGatewayGatewayAggregationRewriteETL ToolsETL ToolsStore&AnalyzeStore&AnalyzeStoreData warehouseData warehouseAnalyzeAnalyzeReportReportViewDashboardDashboardAlert全栈声明式可观测管理全栈声明式可观测管理ETL ToolsETL ToolsKubeVela 项目实践基于基于 eBPF eBPF 无侵

61、入的观测，语言无关的无侵入的观测，语言无关的 Tracing&ProfilingTracing&Profiling交互式大盘设计，聚合交互式大盘设计，聚合 Events,Metrics,StatusEvents,Metrics,Status，融合，融合 Kubernetes Kubernetes 管理经验管理经验One Service for All MetricsOne Service for All Metrics统一可视化技术栈，以统一可视化技术栈，以 Grafana Grafana 为可视化的核心（数据聚合）。为可视化的核心（数据聚合）。ECSECS、云服务中间件、云服务中间件、Kub

62、ernetes Kubernetes 工作负载，工作负载，APM APM 观测数据统一集成。观测数据统一集成。围绕着围绕着 Kubernetes Kubernetes 应用观测特点，沉淀应用观测特点，沉淀 Kubernetes Kubernetes 的故障排查经验构造交互式可视化平台。的故障排查经验构造交互式可视化平台。Kubernetes 命名空间洞察大盘，直观发现故障Kubernetes 资源基础洞察交互Deployment 等观测大盘-整合Metric Events Metadata和Logs010203什么是OpenKruise？OpenKruise是如何提升Pod生命周期管理能力？社

63、区发展与规划01https:/ https:/ 基于基于 KubernetesKubernetes 的扩展应用管理套的的扩展应用管理套的官方文档：官方文档：https:/openkruise.io/zh/docs/任意纯净的任意纯净的 Kubernetes Kubernetes 集群中集群中OpenKruiseOpenKruiseCloneSetAdvancedStatefulSetSidecarSetAdvancedDaemonSetOperation Capabilities饿了么UC神马电商业务中间件应用Mesh容器运维容器安全容器基础网络组件基础存储组件容器重启镜像预热数据库应用容器启

64、动/退出顺序管理OpenKruise 是阿里巴巴应用部署和管理的基座02什么是Pod生命周期管理？PodPod生命周生命周期期AlwaysOnFailureNever容器重启策略容器重启策略PostStartPreStop容器容器 LifecycleLifecycleStartup ProbeLiveness ProbeReadiness Probe容器容器 ProbeProbeContainersReadyReadyInitializedPodScheduledPod ConditionPod Condition大规模场景对Pod生命周期管理提出了新的要求控制控制效率效率大规模集群快速部署应

65、用高峰期极致弹性Pod中容器启动/退出顺序Job Sidear容器退出业务发布中流量正常防止容器大规模重启任何升级都会导致Pod重建不能保证Pod中容器启动/退出顺序Job Sidecar容器无法退出Deployment 发布与 LoadBalancer 无法联动Liveness Probe 没有全局控制Pod生命周期管理能力Kubernetes-Pod维度的不可变基础设施Deployment（nginx）Replicas v1Template:v1Pod:v1Pod:v1Replicas v2Template:v2Pod:v2重建升级Pod重建流程复杂，拉镜像耗时，无预热情况下新拉镜像需要几

66、分钟；Pod IP 变化、存储清空，新起 Pod 应用进程需要重新预热；Stop容器释放cni网络释放pv/pvcschedulerbinder-nodesandboxPv/cniInitcontainerApp container核心能力1原地升级CloneSet（nginx）Pod-1Sandbox（网络、存储）nginx v1nginx v2Pod-2Sandbox（网络、存储）nginx v1logtail原地升级原地升级:节省了调度调度的耗时，Pod 的位置、资源都不发生变化节省了分配网络分配网络的耗时，Pod 还使用原有的IP节省了分配、挂载远程分配、挂载远程盘的耗时，Pod 还使

67、用原有的 PV（且都是已经在 Node 上挂载好的）节省了大部分拉取镜像大部分拉取镜像的耗时，因为 Node 上已经存在了应用的旧镜像，当拉取新版本镜像时只需要下载少数的几层 layer原地升级 Pod 中某个容器时，其他容器保保持正常运行持正常运行，网络、存储均不受影响容器维度的管控能力增强 独立升级Sidecar容器webserver1.单独升级Sidecar容器，并且Pod一直ReadyOpenKruise控制器第一批次第二批次第三批次第N批次日志目录Logtail v1Logtail v22.分批灰度Sidecar容器Ingress3.升级Sidecar对用户是无感的核心能力2容器退出

68、顺序控制Kubelet并发逻辑执行PreStopStop容器执行PreStopStop容器Main容器Envoy容器Kubelet并发退出Pod中多个容器，Sidecar容器有可能早于Main容器退出，导致服务异常触发场景（删除Pod）发布、驱逐、缩容K8S官方方案（Kubelet代码改动过大，一直搁置）2018年社区有提出相关Proposal，Sidecar先于Main容器启动，晚于Main容器退出社区常用方案（定制化，不通用）Sidecar 容器配置等待时间 Main容器与Sidecar容器共享目录，实现退出逻辑社区首个通用容器退出优先级能力Kubelet并发逻辑执行PreStopStop

69、容器Kruise定制脚本Stop容器Main容器Envoy容器Kruise Daemon1.通过CRI探测Main容器是否退出Kruise定制脚本Stop容器LogAgent容器2.探测Main容器退出后，再执行Sidecar退出逻辑容器按照顺序退出：Main-LogAgent-Envoy开启方式：Pod.annotationskruise.io/container-exit-priority=“log-agent”:1,“envoy”:2mainJob类应用Logtail因无法感知到main容器已经退出，导致logtail容器无法退出，进而job应用无法完成logtailmainlogtai

70、lmainlogtail已退出运行中核心能力3Job Sidecar退出能力通用的Job Sidecar退出能力OpenKruise执行PreStopStop容器mainlogtailKruise Daemonmainlogtailmainlogtail1.发现main容器已经退出2.触发StopSidecar容器命令3.通过CRI停止Sidecar容器Job类应用已退出运行中开启方式：EnvKRUISE_TERMINATE_SIDECAR_WHEN_JOB_EXIT=True核心能力4增强的Liveness Probe能力KubeletAppRestartingAppRunningLiven

71、ess Probe:FailureLiveness Probe:Success社区原生Liveness Probe不间断的探测容器健康状态异常，立即重启不足：没有全局视角，极端情况会一次性重启所有的容器，导致业务异常OpenKruise 提供的全局Liveness Probe能力开启方式核心能力5Pod Lifecycle（优雅上下线）LoadBalancer 控制器Backend工作负载控制器第一批第二批第N批1.分批发布（正常）2.同步Backend（失败）Backend依然记录的是老的IP地址LoadBabancer同步Backend失败，并不能阻塞或通知控制器停止发布Pod生命周期Cr

72、eateUpdateDeleteLoadBalancer 控制器Backend3.上下线OpenKruise 控制器1.变更前打标2.监测到变更标，进行上下线操作4.创建/更新/删除 PodOpenKruise 支持Pod优雅上下线工作负载：CloneSet、Advanced StatefulSet、Advanced DaemonSet PreNormal Updating PreDelete03无侵入的渐进式发布系统Kruise Rollout云原生游戏最佳实践OpenKruiseGameOperator灰度和隔离系统ControllerMeshhttps:/ Star：3.6kContri

73、butor：120规划：2022-2023 年 CNCF Sandbox-Incubation双周周会（周四晚19点30）业界用户：国内：阿里巴巴、蚂蚁、携程、苏宁、OPPO、小米、斗鱼TV、有赞、Boss直聘、申通、小红书等 25+登记企业用户国外：LinkedIn、Lyft、Bringg、Arkane Systems、Spectro Cloud等 5+登记企业用户010203问题背景KubeVela+kruise rollout 灵活可扩展的发布工作流Demo1.问题背景平台团队在实现应用发布会遇到了哪些挑战平台团队在实现应用发布会遇到了哪些挑战通常用来卡住发布进度的就绪性探针是以 pod

74、为粒度，侧重于容器维度的健康检查。更多时候需要对应用的整体 SLA/SLO 做评估，从而决策是否继续推进发布。所谓“无人值守”核心是通过自动化的流程化检查步骤，辅助运维人员来做判断。就绪性探针应用整体的SLO/SLA平台团队在实现应用发布会遇到了哪些挑战平台团队在实现应用发布会遇到了哪些挑战通过 MaxSurge 和MaxUnavailable 等参数控制工作负载在发布过程中的面相终态的发布形式。nowantcanarycanary-demodemo-v1v1-defaultdefaultstep1step2step3人工审核暂停 1h对应用进行分分批次的渐进式发布平台团队在实现应用发布会遇到

75、了哪些挑战平台团队在实现应用发布会遇到了哪些挑战step1step2step3流量调节副本调节10%请求到新版本运维用户工作负载 vs 渐进式发布实例升级：升级、回滚分批控制流量调节：新旧版本 Service流量比例/权重控制流程控制：管理 Pod、流量批次进度metrics 指标检查外置 hook 钩子人工核验渐进式发布发布过程中需要做到哪些事情发布过程中需要做到哪些事情2.KubeVela+kruise rollout 灵活可扩展的发布工作流ApplicationApplication ModelModel 应用交付模型应用交付模型描述描述ApplicationThe higher lev

76、el The higher level abstraction to model a abstraction to model a full functional full functional microservice unit.microservice unit.ComponentT The main workload to run such as web services,jobs,databases.TraitOperational Operational auxiliariesauxiliariesthat help the component to work,like scalin

77、g,storage,gateway.VSKubernetesKubernetes 资源示例资源示例应用工作流应用工作流：编排和衔接：编排和衔接 任意任意 交付动作交付动作WorkflowStepDefinitionWorkflowStepDefinition钉钉通知HttphookMetricscheckLogcheckHumanaudit.Kruise Rollout or Argo rollout or FlaggerArgoArgo RolloutRolloutFlaggerFlaggerKruiseKruise rolloutrollout简介Argo rollout 本质上是一种 工

78、 作 负 载，在 原 生deployment 增加了更加丰富的 rollout strategy旁 路 式 的 作 用 机 制，flagger CR referecne 到一个已经存在的deployment 上面旁 路 式 的 作 用 机 制，flagger CR referecne 到一个已经存在的deployment 上面分批发布支持支持支持流量调节支持istioingrsstraefik支 持istioingresstraefik支 持ingress，以 及gateway API发布过程中metrics 检查支持 prometheus datdog.支持 prometheus datdo

79、g.不支持发布过程中 HPA支持不支持支持扩展性需要修改代码需要修改代码需要修改代码存量业务迁移通过cli工具基于已有deployment 生成 CR无需迁移无需迁移资源消耗无需 double 资源发 布 中 需 要 基 于 用 户deployment copy 一个相同deployment，存在 double资源无需 double 资源发布过程中发布通知支持支持不支持KubeVela应用工作流来支撑Rollout operatormanagereplicas/trafficHelm/OAM/Helm/OAM/PaasPaasApiApi-ServerServerControllerContr

80、ollerManagerManagerK8S MasterK8S MasterWorkloadWorkload PausePause minReadySecondminReadySecond StrategyStrategy KruiseKruise RolloutRolloutV1V1V2V2User/ClientUser/ClientIngress/GatewayIngress/GatewayService CanaryService CanaryServiceService1.1.应用发布应用发布3.3.动态调整工动态调整工作负载参数作负载参数外部访问外部访问UsersUsersTest

81、erTester20%20%80%80%4.4.控制流量控制流量2.1 2.1 触发触发RolloutRollout控控制制DeploymentDeploymentStatefulSetStatefulSetKruiseKruise CloneSetCloneSetOthersOthersKruise Rollout 工作机制2.22.2 PausePause住住WorkloadWorkload滚动升级滚动升级升级20%的实例和10%流量检查监控指标v1v1v1v1v2v1Rolloutingressserviceservice10%全量升级v1v1ingressservice100%v1RolloutcheckupdateupdateManageReplicas/traffic.Pods ReadySuccessFailAuditsuspendhook应用灰度发布工作流3.DemoDemo1.Addon 插件体系拉起可观测性组件+网关+kruise rollout trait2.应用升级 v2 等待检查指标五分钟，成功后全量发布。3.应用继续升级到错误版本 v3，等待检查指标五分钟后失败。