Dubbo 3.0 服务治理最佳实践|学习笔记(一)

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,182元/月
云原生网关 MSE Higress,422元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 快速学习 Dubbo 3.0 服务治理最佳实践

开发者学堂课程【Dubbo 3.0服务治理最佳实践Dubbo 3.0 服务治理最佳实践】学习笔记,与课程紧密联系,让用户快速学习知识。  

课程地址:https://developer.aliyun.com/learning/course/967/detail/14888


Dubbo 3.0 服务治理最佳实践


内容介绍:

一、 Dubbo3 新特性介绍

二、 Dubbo3 在阿里云MSE上的实践

三、 Demo

四、钉钉 Dubbo3.0 实践与云原生网关内部落地案例

 

一、Dubbo3 新特性介绍

1、Dubbo3 元原生/易用性

云原生时代的微服务发展趋势

(1)KBS成为资源调度的事实标准,Mesh化逐渐接受(Mesh成为主流)

(2)底层基础设施易变,云上微服务多元化

(3)端上应用对后台服务的访问呈爆发性增长

以上趋势的存在对Dubbo提出了更高的要求,首先用户如何在KPS更方便的部署和调用Dubbo服务是必须要解决的问题。要解决这个问题,统一的协议和数据交换的格式是必须的前提。

其次,Mesh化的流行带来了多元化的问题,其原生的Dubbo和Mesh化的Dubbo是如何共存,在多元禅理下应如何支持,微服务规模的增长会给整个Dubbo架构带来更大的挑战,无论是注册中心等组件还是客户端都会更多的数据和调用量。因此,如何在保证稳定的前提下,提供更高效的服务,是Dubbo引进的重中之重。以上这些云原生时代下带来的挑战促成了Dubbo发展到下一代新协议,以及KPS基础架构的支持以及多元和微服务规模化增强等方面的趋势。

2、Dubbo3.0概览

(1)全新服务发现模型

Dubbo3.0从应用模型入手,优化存储结构。对起于原生主流的设计模型,避免在模型上带来一些互通的问题。并且新模型在数据的组织上高度压缩,能够有效的提高性能和集成的可操作性。

(2)下一代RPC协议、Triple协议

这是一个基于HTTP/2的Triple协议,完全兼容gRPC开发性的新协议;由于是基于HTTP/2设计,因此具有极高的网关友好性和穿透性。完全兼容gRPC协议是天然的,在多元互通方面具有的优势。

(3)统一流量治理模型

提出云原生流量治理,提出了一套的覆盖传统的SDK部署、Mesh化部署, VM虚拟部署、Container容器部署产品的统一治理规则,致使一份规则治理大多数产品,大大的降低了流量治理的成本,使得易购体系下的全局流量治理变成了可能。

(4)Service Mesh

Dubbo3将提供接入Service Mesh的解决方案,提出了Mesh产品下,面向Mesh产品,Dubbo3提出两种接入方式,一种是SDK模式,部署模型和当前的Service Mesh主流的部署产品完全一样,并且Dubbo将对自己进行授身,评定掉与Mesh相同的治理功能,仅保留新的gRPC能力。第二种是Proxyless Mesh的模式,Dubbo将接替Sidecar的工作职责,主动与工作面进行通信,基于Dubbo3统一的规则,应用于云原生流量治理功能

业务收益

11132.png

1、性能稳定性

Dubbo3着力关注大规模集群体部署的产品,通过优化数据存储方式来降低单机的资源损耗,同时可以在对应对超大规模集群水平扩容时,保证整个集群的稳定性。另外在Dubbo3提出的融性集群的概念,在一定程度上,有效的保证和提高全链路总体可靠性和资源利用率。

2、云原生

Dubbo3代表着Dubbo全面拥抱云原生里程碑的一个版本,当前Dubbo在国内外有基数巨大的用户群体,随着云原生时代的到来,这些用户在上云的需求非常的强烈,Dubbo3将提供完整可靠的解决方案,以及迁移路径和最佳实践,来帮助企业实现云原生转型,享受到云原生带来的红利。

具体来说,从业务应用的应用视角来看,如果我们升级到Dubbo3,我们能获得哪些收益呢?

首先在性能与资源利用率方面,Dubbo3能大幅度降低框架带来的额外资源的消耗,提升系统整体的一个利用率。

从单机角度上分析,Dubbo3能节约50%的内存占用。从集群视角上看,Dubbo3能支持百万实力的大规模集群为未来更大规模的业务扩容打下基础。

同时Dubbo3对Actual Stream等通信模型的支持,在一些业务产品下也带来整体吞吐量的大幅度提升,其次,Dubbo3给业务架构升级带来了更多的可能性,比如:Dubbo原来的协议,是在一定程度上束缚微服务接入的方式,举个例子:比如移动端,前端业务要接入Dubbo的后端服务,需要经过网关的协议转换,再比如Dubbo制置使request、response模式的通信,使得一些需要有视传输入或反项通信的产品无法获得更好的支持。最后Dubbo3给业务侧云原生升级带来了解决方案。

不论是由于底层的基础设施的升级带动业务的升级的被动变化还是业务为解决痛点进行的主动升级。无论是哪种方式,业务都需要升级到云原生,在这个过程中,Dubbo给出了云原生的解决方案,帮助业务产品快速的接入云原生。

二、Dubbo3 在阿里云 MSE 上的实践

1、微服务在云原生下的挑战

11957.png

从三方面来讲解:

在效率方面,应用如何具备白天流量高峰期的发布的能力以及云边端一体化开发部署的能力以及如何降低服务治理体系强依赖SDK升级的成本并且K8s下应用IP的不确定会导致服务治理规则的失效。

在稳定性方面,业务高可用及多可用区部署,同城以及异地容灾,业务多活的述求,微服务需要更加安全、更加可信的调用治理的能力。

2、在成本方面,如何降低应用迁移上云的成本,应用如何具备极致、灵活弹性的能力。

3、服务治理的区分

(1) 开发态Dev

服务云信息

服务契约管理

服务测试

服务Mock

开发环境隔离

端云互联

(2) 运营态Ops

发布态

l 无损下线

l 无损上线

l 金丝雀发布

l A/B Test

l 全链路灰度

安全态Sec

l 服务鉴权

l 漏洞防护

l 配置鉴权

高可用

l 离群实例摘除

l 限流降级

l 同AZ优先路由

就近容灾路由

服务契约

服务对于用户来说是无侵入的,服务契约的能力是其他治理能力的原材料。用户只需将应用接入MSC后就能具备完整地服务契约。举个例子:

应用详情(demo-frontend)-服务列表
当应用接入MSE后将会具备完整的服务契约的能力,当前的类型、方法、路径以及描述的信息。当接口实现Swag的注解后,是无缝的接受Swag的注解。

1、无损上线

MSE抽象应用启动流程模型

12499.png

首先是应用初始化,第二阶段是提前建联的阶段,将会做Redis连接池以及数据库的连接池的提前连接。

第三阶段是服务注册,做Dubbo/SC服务延迟暴露的能力以及服务并发订阅、注册的能力来提高应用的启动速度,特别是当服务规模比较大的情况下。

第四阶段是readiness检查的阶段,开源默认的K8s readiness检查和Spring Cloud/Dubbo体系没有打通,但是MSE提供支持,从而打通K8s的生命周期。下个阶段就是正式流量的进入。小流量预热的阶段,在这一过程中,流量需要缓慢增加,但Dubbo 2.7.4.1以下版本存在服务预热不生效问题,Serene quarter不具备这样的能力,同时在Fastjson/Jetty低版本没有开启并行类加载,可以通过agent能力开启了并行类加载的能力。在这一过程中,存在JVM JIT编译问题引起cpu飙高,在这一过程也进行了优化。同时作日志异步化等问题。最后阶段是正常的流量进入。所有以上这些抽象以及能力,总结为应用的无损上线能力。

2、无损下线:白天大流量下发布依然丝般顺滑

无损下线解决的问题:可以解决白天大流量下的发布,并保证依然如丝般顺滑的能力。

在微服务下线以及上线过程中做一些增强,比如像主动通知、提前注销,以及客户端主动刷新等能力。

(1)安全变更

安全变更三板斧

l 可灰度

l 可监控

l 可回滚

故障应急1-5-10原则

l 1分钟发现

l 5分钟定位

l 10分钟恢复

(2)安全生产:全链路金丝雀发布

提供金丝雀的最佳实践

第一步:新建灰度Deployment,部署新版本的镜像,打上新版本的标签

第二步:配置针对新版本的标签路由规则,类似于满足一些条件进入新版本的规则流量中及进入Deployment中。

第三步:验证新版本的小流量的成功,扩大灰度比例。

第四步:若调整比例后验证成功,点击发布完成删除流量规则,同时把灰度版本的流量比例调整为100%,若验证失败,点击回滚删除流量规则,同时将正常版本的流量比例调整为100%

第五步:若验证成功,把正常的Deployment副本数调整到0或删除该Deployment ;若验证失败,把灰度的Deployment副本数调整到0或删除该Deployment

提供了一整套基于标签的全链路金丝雀发布的治理能力,提供了两种灰度规则:

l 按流量百分比路由

l 按请求特征路由;如httpheader,Dubbode方法参数或者

Dubbo RTC contest融带的标

4、我们打通微服务网关。

5、离群实例摘除:单点故障自愈

13564.png

场景一:某应用发布,灰度几台机器,由于代码逻辑写的有问题,造成线程池满,客户端调用失败。

场景二:某应用运行过程中,某几台机器由于磁盘满,或者是宿主机资源争抢导致load很高,客户端出现调用超时。

6、当我们应用的某台机器出现了单点异常,我们的应用会适时地发现并摘除单点异常。会对故障节点进行剔除,从而实现单点故障的能力。

7、服务降级:保护重点业务、降级非重点业务

13748.png

场景一:业务高峰期,发现下游的服务提供者遇到性能瓶颈,甚至影响业务时。对部分的服务消费者进行降级操作,让不重要的业务方不进行真实地调用,直接返回Mock的结果,将宝贵的下游服务提供者资源保留给重要的业务调用方使用。从而提升整体服务的稳定性。

场豪二:一些非关键的服务不非常稳定 ,希望在调用异常时候能直接使用降级的结果,从而保证整体业务的顺畅。服务运机和服务降级的区别:焰断保护的是服务消费者,降级保护的是服务提供者

比如:评价服务,在调用服务时,当出现下游抖动时,可以对评价服务直接返回降级的数据,从而保证登录服务的稳定性。

5、服务鉴权:保护你的敏感业务

MSE服务鉴权支持以下四个方式:

l 规则优先级:方法级别>应用

l 鉴权方式:白名单(允许调用),黑名单(拒绝调用)

l 签名校验

审计日志

相关文章
|
Java 数据库连接
什么是双亲委派?如何打破双亲委派?
什么是双亲委派?如何打破双亲委派?
322 0
|
11月前
|
人工智能 数据库 自然语言处理
拥抱Data+AI|DMS+AnalyticDB助力钉钉AI助理,轻松玩转智能问数
「拥抱Data+AI」系列文章由阿里云瑶池数据库推出,基于真实客户案例,展示Data+AI行业解决方案。本文通过钉钉AI助理的实际应用,探讨如何利用阿里云Data+AI解决方案实现智能问数服务,使每个人都能拥有专属数据分析师,显著提升数据查询和分析效率。点击阅读详情。
拥抱Data+AI|DMS+AnalyticDB助力钉钉AI助理,轻松玩转智能问数
|
存储 人工智能 算法
数据结构与算法细节篇之最短路径问题:Dijkstra和Floyd算法详细描述,java语言实现。
这篇文章详细介绍了Dijkstra和Floyd算法,这两种算法分别用于解决单源和多源最短路径问题,并且提供了Java语言的实现代码。
798 3
数据结构与算法细节篇之最短路径问题:Dijkstra和Floyd算法详细描述,java语言实现。
|
人工智能 自然语言处理 前端开发
SpringBoot + 通义千问 + 自定义React组件:支持EventStream数据解析的技术实践
【10月更文挑战第7天】在现代Web开发中,集成多种技术栈以实现复杂的功能需求已成为常态。本文将详细介绍如何使用SpringBoot作为后端框架,结合阿里巴巴的通义千问(一个强大的自然语言处理服务),并通过自定义React组件来支持服务器发送事件(SSE, Server-Sent Events)的EventStream数据解析。这一组合不仅能够实现高效的实时通信,还能利用AI技术提升用户体验。
956 2
|
存储 负载均衡 Cloud Native
支持 gRPC 长链接,深度解读 Nacos 2.0 架构设计及新模型
Nacos 在阿里巴巴起源于 2008 年五彩石项目,该项目完成了微服务拆分和业务中台建设,随着云计算和开源环境的兴起,2018 年我们深刻感受到开源软件行业的影响,因此决定将 Nacos 开源,输出阿里十年关于服务发现和配管管理的沉淀,推动微服务行业发展,加速企业数字化转型。
支持 gRPC 长链接,深度解读 Nacos 2.0 架构设计及新模型
|
关系型数据库 MySQL 分布式数据库
云原生数据库PolarDB MySQL版深度评测报告
作为一名开发人员,在日常工作中频繁与数据库打交道,对于数据库的性能、灵活性和易用性有着极高的要求。此次,我有幸对阿里云自主研发的云原生数据库PolarDB MySQL版进行了深入评测,旨在了解其是否能够满足现代应用的高性能、高可用性和弹性扩展需求。
317 4
|
JSON 移动开发 算法
从JDK8飞升到JDK17,再到未来的JDK21
2022年,Spring6和 SpringBoot3都推出了,在此之前,Java社区很坚挺,一直是"新版任你发,我用Java 8",不管新版本怎么出,很少有人愿意升级。 这一次,Spring 直接来了个大招,SpringBoot3和Spring6的最低依赖就是JDK17!跨过 JDK 8-16,直接升级到 JDK 17。那么为什么是 JDK 17呢?
30262 24
从JDK8飞升到JDK17,再到未来的JDK21
|
NoSQL Redis
Redis——单机迁移cluster集群如何快速迁移
Redis——单机迁移cluster集群如何快速迁移
431 0
|
存储 负载均衡 Dubbo
Dubbo阶段性总结及3.0新特性
该文章是对Dubbo技术的一次总结,包括对Dubbo框架的整体架构、服务提供者发布注册原理、SPI机制、服务消费者订阅原理、服务调用原理、线程池模型、负载均衡机制、服务容错机制等内容的回顾,并简要介绍了Dubbo 3.0的新特性。
Dubbo阶段性总结及3.0新特性