云原生架构与应用专场

RPC WEB 服务发现 全链路流量 追踪管控 丰富可观测 生态 认证鉴权 01Rest协议支持 02可观测体系 03NativeImage原生支持 04其他 • • • • • • • 01为什么需要服务治理 02OpenSergo微服务治理标准与实践 03Sentinel2.0自适应限流 为什么需要服务治理 现代微服务架构的挑战 企业实施微服务的挑战 微服务&微服务治理 微服务治理范围 业界微服务治理存在的问题 为什么是OpenSergo OpenSergo领域&生态 OpenSergo服务治理架构体系 OpenSergo流量路由 OpenSergo流量路由 OpenSergo流量防护与容错 OpenSergo治理标准-流量防护与容错 OpenSergoRoadmap OpenSergo社区共建 Sentinel演进历程 2012-2017 2018 2019 2020 2021-2022 2023 ? Sentinel在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的流量稳定性核心场景 Sentinel正式开源，社区迅速发展，不断扩充生态与能力，逐步成为最受欢迎的同类组件 Sentinel开始在多语言的生态中探索，推出C++原生版 本，同时针对ServiceMesh场景也推出了Envoy全局流控的支持 Sentinel推出Go原生版本，并不断与Dubbo/Dapr/MOSN/斗鱼等社区进行合作，继续朝着云原生方向演进 Sentinel推出Rust原生版本，并基于此对Envoy集成及eBPF层流控的探索 Sentinel品牌升级 原生对接OpenSergo流量治理标准云原生架构升级：localbrain(SDK, Mesh)+microbrain(控制平面) 标准化云原生 1.0: 流量防护 多语言全方位生态 能力升级 针对微服务、云原生体系，全方位覆盖多语言异构化框架与组件生态 能力升级为流量治理与服务自愈，全方位保障服务稳定性与容错 Sentinel2.0：服务治理的标准实现 Sentinel2.0演进 Sentinel2.0Overview 治理规则管理标准化(OpenSergo)治理策略服务标准化(gRPC) 全局指标汇聚与计算治理策略预计算全局治理策略控制(如集群流控、全局维度的权重策略调整） 指标监控 统一控制面（决策与治理中心） 规则存储 API模型标准化(nouveaumodel) 规则配置标准化(OpenSergo数据源) 策略服务接口标准化 (gRPCservice)标准化 流量流量 路由染色 服务服务 隔离防抖 自适服务流量异常 熔断 应 调度 流控控制流量 规则数据源扩展 控制策略扩展 调度策略扩展 指标统计扩展 扩展机制 TrafficShapingController流量控制 AdaptiveThrottler自适应流控策略 CircuitBreaker不稳定服务熔断 WeightCalculator权重计算 Router流量路由 LoadBalancer负载均衡 流量治理与自愈 TrafficScheduler流量调度 基础指标统计 Sentinel2.0流量治理 • • • • • • •• •• • OpenSergo官方微信公众号： ContactUS https://opensergo.io •MSE微服务引擎https://www.aliyun.com/product/aliware/mse 01seata简介 02Seata的可观测实践 03总结与展望 业务趋于复杂、规模不断扩大 seata简介 为什么需要seata？ 单库容量、性能瓶颈，向多库、多表 架构演进 单一本地事务多库多表分布式事务 seata管理 分库分表场景下的分布式事务 单体应用分布式应用 seata简介 为什么需要seata？ 单一本地事务跨服务的分布式事务 seata管理 跨服务场景下的分布式事务 组件架构 seata简介 TransactionCoordinator（TC） 事务协调器，维护全局事务的运行状态， 负责协调并驱动全局事务的提交或回滚。 TransactionManager（TM） 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议，TM定义全局事务的边界。 ResourceManager（RM） 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。RM负责定义分支事务的边界和行为。 一个标准的分布式事务链路场景 seata简介 业务逻辑 用户请求交易服务 交易服务锁定库存交易服务创建账单账单服务进行扣款 事务链路 Business（TM）开启分布式事务，获取全局XID XID在微服务调用链路的上下文中传播，Storage(RM)、Account(RM)、Order(RM)执行本地事务，并向TCregister、report分支事务 Business（TM）向TC发起针对此XID的全局事务 commit/rollback TC调度此XID下的各个RM：Order、Account、Storage服务按序commit/rollback 为什么需要可观测？ Seata的可观测实践 •还能存储历史量化数据， 便于事务量化、资源评 估。 •可观测能力一方面能提供 可视化大盘，直观反应系 统、事务等状况； •可选择性针对耗时高、资 源消耗量大的业务链路优 化； •可观测能力可帮助我们直 观分析异常链路，快速定 位、解决问题； •seata在解决了用户易用、分布式事务一致性等问题时，需要多次消息交互；尤其随着微服务调用链路复杂度上升，必须引入可观测能力以作为观察、分析事务链路的依据。 1.分布式事务消息链路较复杂 2.故障排查难定位，性能优化无从下手 3.可视化、数据可量化 可观测能力概览 Seata的可观测实践 可观测维度 seata期望的能力 技术选型参考 Metrics •功能层面：可按业务分组隔离，采集事务总量、耗时等重要指标•性能层面：高度量性能，插件按需加载•架构层面：减少第三方依赖，服务端、客户端能够采用统一的架构，减少技术复杂度•兼容性层面：至少兼容Prometheus生态 •Prometheus：指标存储和查询等 领域有着业界领先的地位 •OpenTelemetry：可观测数据采集和规范的事实标准。但自身并不负责数据的存储，展示和分析 Tracing •功能层面：全链路追踪分布式事务生命周期，反应分布式事务执行性能 消耗 •易用性方面：对使用seata的用户而言简单易接入 •SkyWalking：利用Java的Agent探针技术，效率高，简单易用。 Logging •功能层面：记录服务端、客户端全部生命周期信息•易用性层面：能根据XID快速匹配全局事务对应链路日志 - Metrics Seata的可观测实践 1.Seata作为一个被集成的数据一致性框架，Metrics模块将尽可能少的使用第三方依赖以降低发生冲突的风险 Seata可观测模块的设计思路 Metrics模块将竭力争取更高的度量性能和更低的资源开销，尽可能降低开启后带来的副作用 配置时，Metrics是否激活、数据如何发布，取决于对应的配置；开启配置则 自动启用，并默认将度量数据通过prometheusexporter的形式发布 不使用Spring，使用SPI(ServiceProviderInterface)加载扩展 Seata的可观测实践 Metrics模块设计 seata-metrics-core：Metrics核心模块，根据配置 组织（加载）1个Registry和N个Exporter； Seata-metrics-api：定义了Meter指标接口，Registry指标注册中心接口； seata-metrics-exporter-prometheus：内置的prometheus-exporter实现； seata-metrics-registry-compact：内置的Registry实现，并轻量级实现了Gauge、Counter、Summay、Timer指标； Metrics Seata的可观测实践 指标体系 Meter类型 描述 Gauge 单一最新值度量器 Counter 单一累加度量器，可增可减 Summary 多Measurement输出计数器，将输出total(合计)、count(计数)和tps(合计/时间间隔)，无单位 Timer 多Measurement输出计时器，将输出total(合计)、count(计数)、max(最大)和average(合计/计数)，支持微秒为单位累计 Metrics指标-TC Seata的可观测实践 Metrics指标-TM Seata的可观测实践 Metrics指标-RM Seata的可观测实践 Seata的可观测实践 Metrics观测效果 Tracing 分布式事务可观测 1.引入seata后，对业务性能会带来多大损耗？主要时间消耗在什么地方？如何针对性的优化业务逻辑？ seata为什么需要Tracing？ seata的所有消息记录都通过日志持久化落盘，但对不了解seata的用户而言，日志非常不友好。能否通过接入Tracing，提升事务链路排查效率？ 对于新手用户，可通过Tracing记录，快速了解seata的工作原理，降低seata使用门槛。 Seata的可观测实践 Tracing SkyWalking是一站式APM领域的的佼佼者，所以早在2019年，seata社区就向SkyWalking社区提出了使用其 可观测能力的诉求，并在2021年，两个社区合作，将seata的Tracing可观测进一步提升： 1.Seata的性能可被更好的观测 2.分布式事务执行过程有痕迹 3.定位问题的提效 Seata的可观测实践 seata的Tracing效果 业务场景描述图服务调用链路图 Seata的可观测实践 Logging Seata的可观测实践 数据可视化监控告警日志存储日志采集 日志格式设计 Logging这一块其实承担了可观测几个维度中兜底的角色。 可读性强、结构化清晰、重点运行时信息透出、可扩展性好等 日志格式 Seata的可观测实践 线程池规范命名 方法全类名可追溯 重点运行时信息透 出 •消息格式可扩展 总结与展望 metrics •总结：基本实现分布式事务的可量化、可观测 •展望：更细粒度的指标、更广阔的生态 tracing •总结：分布式事务全链路的可追溯 •展望：根据xid追溯事务链路，异常链路根因快速定位 logging •总结：结构化的日志格式 •展望：日志可观测体系演进 01诞生背景 02发展历程 03未来展望 诞生背景 • • 阶段一：Higress的诞生 • • • 阶段二：Higress支持优酷Nginx网关迁移 • • • 阶段二：Higress支持优酷Nginx网关迁移（续） 阶段二：Higress在流量网关与微服务网关的融合探索 阶段二：Higress支持阿里中间件“三位一体”战役，推出商业化产品 • • 阶段三：Higress推出业内首个商业化Wasm插件市场 • • • • 阶段三：Higress支持NginxIngressAnnotation平滑转换 阶段三：Higress支持HTTP转Dubbo 未来展望 • • • • • • • • • • • • • • • • • • • 未来展望 • • • • • • • • • • • • • • • • • • • 欢迎一起共建下一代云原生