RPCWEB服务发现流量管控可观测认证鉴权丰富生态全链路追踪 010203Rest协议支持可观测体系NativeImage原生支持04其他 ••• •••• 010203为什么需要服务治理OpenSergo微服务治理标准与实践Sentinel2.0自适应限流 为什么需要服务治理 现代微服务架构的挑战 企业实施微服务的挑战 微服务&微服务治理 微服务治理范围 业界微服务治理存在的问题 为什么是OpenSergo OpenSergo领域&生态 OpenSergo服务治理架构体系 OpenSergo流量路由 OpenSergo流量路由 OpenSergo流量防护与容错 OpenSergo治理标准-流量防护与容错 OpenSergoRoadmap OpenSergo社区共建 Sentinel演进历程2012-20172018201920202021-20222023Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的流量稳定性核心场景Sentinel 正式开源，社区迅速发展，不断扩充生态与能力，逐步成为最受欢迎的同类组件Sentinel开始在多语言的生态中探索，推出C++ 原生版本，同时针对Service Mesh 场景也推出了Envoy全局流控的支持Sentinel推出Go原生版本，并不断与Dubbo/Dapr/MOSN/斗鱼等社区进行合作，继续朝着云原生方向演进Sentinel推出Rust原生版本，并基于此对Envoy集成及eBPF层流控的探索? Sentinel品牌升级1.0:流量防护标准化云原生多语言全方位生态能力升级Sentinel2.0：服务治理的标准实现原生对接OpenSergo流量治理标准云原生架构升级：localbrain(SDK,Mesh)+microbrain(控制平面)针对微服务、云原生体系，全方位覆盖多语言异构化框架与组件生态能力升级为流量治理与服务自愈，全方位保障服务稳定性与容错 Sentinel2.0演进 Sentinel2.0Overview服务隔离统一控制面（决策与治理中心）规则存储指标监控流量治理能力的标准实现API模型标准化(nouveaumodel)规则配置标准化(OpenSergo数据源)策略服务接口标准化(gRPCservice)标准化流量治理与自愈WeightCalculator权重计算Router流量路由LoadBalancer负载均衡TrafficScheduler流量调度TrafficShapingController流量控制AdaptiveThrottler自适应流控策略CircuitBreaker不稳定服务熔断基础指标统计指标统计扩展控制策略扩展调度策略扩展规则数据源扩展扩展机制自适应流控异常流量调度服务防抖流量路由流量染色流量控制服务熔断治理规则管理标准化(OpenSergo)全局指标汇聚与计算治理策略服务标准化(gRPC)治理策略预计算全局治理策略控制(如集群流控、全局维度的权重策略调整） •••••••••••Sentinel2.0流量治理 ContactUS•OpenSergo:https://opensergo.io•MSE微服务引擎:https://www.aliyun.com/product/aliware/mseOpenSergo官方微信公众号： 010203seata简介Seata的可观测实践总结与展望 为什么需要seata？seata简介业务趋于复杂、规模不断扩大单库容量、性能瓶颈，向多库、多表架构演进单一本地事务多库多表分布式事务seata管理分库分表场景下的分布式事务 为什么需要seata？seata简介单体应用分布式应用单一本地事务跨服务的分布式事务seata管理跨服务场景下的分布式事务 组件架构seata简介事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。Transaction Coordinator（TC）控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议，TM定义全局事务的边界。Transaction Manager（TM）控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。RM负责定义分支事务的边界和行为。Resource Manager（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快速匹配全局事务对应链路日志- MetricsSeata的可观测实践Seata可观测模块的设计思路1.Seata作为一个被集成的数据一致性框架，Metrics模块将尽可能少的使用第三方依赖以降低发生冲突的风险Metrics模块将竭力争取更高的度量性能和更低的资源开销，尽可能降低开启后带来的副作用配置时，Metrics是否激活、数据如何发布，取决于对应的配置；开启配置则自动启用，并默认将度量数据通过prometheusexporter的形式发布不使用Spring，使用SPI(Service Provider Interface)加载扩展 Metrics模块设计Seata的可观测实践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指标； MetricsSeata的可观测实践指标体系Meter类型描述Gauge单一最新值度量器Counter单一累加度量器，可增可减Summary多Measurement输出计数器，将输出total(合计)、count(计数)和tps(合计/时间间隔)，无单位Timer多Measurement输出计时器，将输出total(合计)、count(计数)、max(最大)和average(合计/计数)，支持微秒为单位累计 Metrics指标-TCSeata的可观测实践 Metrics指标-TMSeata的可观测实践 Metrics指标-RMSeata的可观测实践 Metrics观测效果Seata的可观测实践 Tracing分布式事务可观测seata为什么需要Tracing？1.引入seata后，对业务性能会带来多大损耗？主要时间消耗在什么地方？如何针对性的优化业务逻辑？seata的所有消息记录都通过日志持久化落盘，但对不了解seata的用户而言，日志非常不友好。能否通过接入Tracing，提升事务链路排查效率？对于新手用户，可通过Tracing记录，快速了解seata的工作原理，降低seata使用门槛。 TracingSeata的可观测实践SkyWalking是一站式APM领域的的佼佼者，所以早在2019年，seata社区就向SkyWalking社区提出了使用其可观测能力的诉求，并在2021年，两个社区合作，将seata的Tracing可观测进一步提升：1.Seata的性能可被更好的观测2.分布式事务执行过程有痕迹3.定位问题的提效 seata的Tracing效果Seata的可观测实践业务场景描述图服务调用链路图 Seata的可观测实践 LoggingSeata的可观测实践可读性强、结构化清晰、重点运行时信息透出、可扩展性好等数据可视化监控告警日志存储日志采集日志格式设计Logging这一块其实承担了可观测几个维度中兜底的角色。 日志格式Seata的可观测实践线程池规范命名方法全类名可追溯重点运行时信息透出•消息格式可扩展 总结与展望metrics•总结：基本实现分布式事务的可量化、可观测•展望：更细粒度的指标、更广阔的生态tracing•总结：分布式事务全链路的可追溯•展望：根据xid追溯事务链路，异常链路根因快速定位logging•总结：结构化的日志格式•展望：日志可观测体系演进 010203诞生背景发展历程未来展望 诞生背景•• 阶段一：Higress的诞生••• 阶段二：Higress支持优酷Nginx网关迁移••• 阶段二：Higress支持优酷Nginx网关迁移（续） 阶段二：Higress在流量网关与微服务网关的融合探索 阶段二：Higress支持阿里中间件“三位一体”战役，推出商业化产品•• 阶段三：Higress推出业内首个商业化Wasm插件市场•••• 阶段三：Higress支持NginxIngressAnnotation平滑转换 阶段三：Higress支持HTTP转Dubbo 未来展望••••••••••••••••••• 未来展望••••••••••••••••••• 欢迎一起共建下一代云原生网关 010203游戏云原生趋势游戏云原生化的困境与解法游戏云原生化的案例解析 增效降本成为游戏行业主旋律，云原生技术红利释放大有可为用户隐私保护，游戏防沉迷、游戏版号的不确定性等。游戏买量智能化分层、自然量减少、靠技术手段增长行业竞争加剧，用户对高品质游戏的需求，精品化是必然趋势2022年中国游戏市场收入下降10.33%，行业寻找新的增长点市场饱和后疫情时代，互联网行业用户时长减少，付费用户随之减少后疫情时代隐私保护增长方式游戏精品化云原生技术DevOps敏捷基础设施容器和编排微服务化CICD 路由分发服务游戏服DbgateMySqlRedis数据层数据库服务SLBdispatchgate游戏服务gameAPI路由平台交互服务订单multiSLSKafkaDataX游戏数据平台FlinkDataworksMCHologresBI数据集成数据应用离线计算实时计算CDNOS