Dubbo文档
2020-10-29 10:35:01 0 举报
AI智能生成
Dubbo文档
作者其他创作
大纲/内容
服务治理
高可用
启动时检查
Dubbo 缺省会在启动时检查依赖的服务是否可用,不可用时会抛出异常,阻止 Spring 初始化完成,以便上线时,能及早发现问题,默认 check="true"。
可以通过 check="false" 关闭检查,比如,测试时,有些服务不关心,或者出现了循环依赖,必须有一方先启动。
另外,如果你的 Spring 容器是懒加载的,或者通过 API 编程延迟引用服务,请关闭 check,否则服务临时不可用时,会抛出异常,拿到 null 引用,如果 check="false",总是会返回引用,当服务恢复时,能自动连上。
另外,如果你的 Spring 容器是懒加载的,或者通过 API 编程延迟引用服务,请关闭 check,否则服务临时不可用时,会抛出异常,拿到 null 引用,如果 check="false",总是会返回引用,当服务恢复时,能自动连上。
配置
dubbo.reference.check=false,强制改变所有 reference 的 check 值,就算配置中有声明,也会被覆盖。
dubbo.consumer.check=false,是设置 check 的缺省值,如果配置中有显式的声明,如:<dubbo:reference check="true"/>,不会受影响。
dubbo.registry.check=false,前面两个都是指订阅成功,但提供者列表是否为空是否报错,如果注册订阅失败时,也允许启动,需使用此选项,将在后台定时重试。
三种配置方式
通过 spring 配置文件
关闭某个服务的启动时检查 (没有提供者时报错):
<dubbo:reference interface="com.foo.BarService" check="false" />
关闭所有服务的启动时检查 (没有提供者时报错):
<dubbo:consumer check="false" />
关闭注册中心启动时检查 (注册订阅失败时报错):
<dubbo:registry check="false" />
<dubbo:reference interface="com.foo.BarService" check="false" />
关闭所有服务的启动时检查 (没有提供者时报错):
<dubbo:consumer check="false" />
关闭注册中心启动时检查 (注册订阅失败时报错):
<dubbo:registry check="false" />
通过 dubbo.properties
dubbo.reference.com.foo.BarService.check=false
dubbo.reference.check=false
dubbo.consumer.check=false
dubbo.registry.check=false
dubbo.reference.check=false
dubbo.consumer.check=false
dubbo.registry.check=false
通过 -D 参数
java -Ddubbo.reference.com.foo.BarService.check=false
java -Ddubbo.reference.check=false
java -Ddubbo.consumer.check=false
java -Ddubbo.registry.check=false
java -Ddubbo.reference.check=false
java -Ddubbo.consumer.check=false
java -Ddubbo.registry.check=false
集群容错
在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。
集群容错模式
可以自行扩展集群容错策略
Failover Cluster
失败自动切换,当出现失败,重试其它服务器 [1]。通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)。
Failfast Cluster
快速失败,只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录。
Failsafe Cluster
失败安全,出现异常时,直接忽略。通常用于写入审计日志等操作。
Failback Cluster
失败自动恢复,后台记录失败请求,定时重发。通常用于消息通知操作。
Forking Cluster
并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数。
Broadcast Cluster
广播调用所有提供者,逐个调用,任意一台报错则报错 [2]。通常用于通知所有提供者更新缓存或日志等本地资源信息。
集群模式配置
本地伪装
本地伪装 [1] 通常用于服务降级,比如某验权服务,当服务提供方全部挂掉后,客户端不抛出异常,而是通过 Mock 数据返回授权失败。
使用
延迟暴露
如果你的服务需要预热时间,比如初始化缓存,等待相关资源就位等,可以使用 delay 进行延迟暴露。我们在 Dubbo 2.6.5 版本中对服务延迟暴露逻辑进行了细微的调整,将需要延迟暴露(delay > 0)服务的倒计时动作推迟到了 Spring 初始化完成后进行。你在使用 Dubbo 的过程中,并不会感知到此变化,因此请放心使用。
使用
并发控制
配置样例
连接控制
使用
延迟连接
延迟连接用于减少长连接数。当有调用发起时,再创建长连接。
配置
令牌验证
通过令牌验证在注册中心控制权限,以决定要不要下发令牌给消费者,可以防止消费者绕过注册中心访问提供者,另外通过注册中心可灵活改变授权方式,而不需修改或升级提供者
安全
使用
路由规则
路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用,过滤后的地址列表,将作为消费端最终发起RPC调用的备选地址。
条件路由。支持以服务或Consumer应用为粒度配置路由规则。
使用
标签路由。以Provider应用为粒度配置路由规则。
使用
配置规则
覆盖规则是Dubbo设计的在无需重启应用的情况下,动态调整RPC调用行为的一种能力。2.7.0版本开始,支持从服务和应用两个粒度来调整动态配置。
概览
请在服务治理控制台查看或修改覆盖规则。
规则详解
服务降级
使用
优雅停机
Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的,所以如果用户使用 kill -9 PID 等强制关闭指令,是不会执行优雅停机的,只有通过 kill PID 时,才会执行。
使用
线程dump
当业务线程池满时,我们需要知道线程都在等待哪些资源、条件,以找到系统的瓶颈点或异常点。dubbo通过Jstack自动导出线程堆栈来保留现场,方便排查问题
默认策略:
导出路径,user.home标识的用户主目录
导出间隔,最短间隔允许每隔10分钟导出一次
指定导出路径:
# dubbo.properties
dubbo.application.dump.directory=/tmp
<dubbo:application ...>
<dubbo:parameter key="dump.directory" value="/tmp" />
</dubbo:application>
默认策略:
导出路径,user.home标识的用户主目录
导出间隔,最短间隔允许每隔10分钟导出一次
指定导出路径:
# dubbo.properties
dubbo.application.dump.directory=/tmp
<dubbo:application ...>
<dubbo:parameter key="dump.directory" value="/tmp" />
</dubbo:application>
开启 TLS
使用
服务鉴权
类似支付之类的对安全性敏感的业务可能会有限制匿名调用的需求。在加固安全性方面,2.7.5 引入了基于AK/SK机制的认证鉴权机制,并且引入了鉴权服务中心,主要原理是消费端在请求需要鉴权的服务时,会通过SK、请求元数据、时间戳、参数等信息来生成对应的请求签名,通过Dubbo的Attahcment机制携带到对端进行验签,验签通过才进行业务逻辑处理。如下图所示:
具体的接入方式也并不复杂:
使用者需要在微服务站点上填写自己的应用信息,并为该应用生成唯一的证书凭证。
之后在管理站点上提交工单,申请某个敏感业务服务的使用权限,并由对应业务管理者进行审批,审批通过之后,会生成对应的AK/SK到鉴权服务中心。
导入该证书到对应的应用下,并且进行配置。配置方式也十分简单,以注解方式为例:
服务提供端,只需要设置service.auth为true,表示该服务的调用需要鉴权认证通过。param.sign为true表示需要对参数也进行校验。
@Service(parameters = {"service.auth","true","param.sign","true"})
public class AuthDemoServiceImpl implements AuthService {
}
服务消费端,只需要配置好对应的证书等信息即可,之后会自动地在对这些需要认证的接口发起调用前进行签名操作,通过与鉴权服务的交互,用户无需在代码中配置AK/SK这些敏感信息,并且在不重启应用的情况下刷新AK/SK,达到权限动态下发的目的。
该方案目前已经提交给Dubbo开源社区,并且完成了基本框架的合并,除了AK/SK的鉴权方式之外,通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。
具体的接入方式也并不复杂:
使用者需要在微服务站点上填写自己的应用信息,并为该应用生成唯一的证书凭证。
之后在管理站点上提交工单,申请某个敏感业务服务的使用权限,并由对应业务管理者进行审批,审批通过之后,会生成对应的AK/SK到鉴权服务中心。
导入该证书到对应的应用下,并且进行配置。配置方式也十分简单,以注解方式为例:
服务提供端,只需要设置service.auth为true,表示该服务的调用需要鉴权认证通过。param.sign为true表示需要对参数也进行校验。
@Service(parameters = {"service.auth","true","param.sign","true"})
public class AuthDemoServiceImpl implements AuthService {
}
服务消费端,只需要配置好对应的证书等信息即可,之后会自动地在对这些需要认证的接口发起调用前进行签名操作,通过与鉴权服务的交互,用户无需在代码中配置AK/SK这些敏感信息,并且在不重启应用的情况下刷新AK/SK,达到权限动态下发的目的。
该方案目前已经提交给Dubbo开源社区,并且完成了基本框架的合并,除了AK/SK的鉴权方式之外,通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。
消费端线程池模型
使用
高性能/性能调优
负载均衡
在集群负载均衡时,Dubbo 提供了多种均衡策略,缺省为 random 随机调用。
可以自行扩展负载均衡策略
负载均衡策略
Random LoadBalance
随机,按权重设置随机概率。
在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。
RoundRobin LoadBalance
轮询,按公约后的权重设置轮询比率。
存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。
LeastActive LoadBalance
最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance
一致性 Hash,相同参数的请求总是发到同一提供者。
当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。
算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
缺省只对第一个参数 Hash,如果要修改,请配置 <dubbo:parameter key="hash.arguments" value="0,1" />
缺省用 160 份虚拟节点,如果要修改,请配置 <dubbo:parameter key="hash.nodes" value="320" />
配置
线程模型
是否需要在netty/mina的网络io线程外开启另外个线程池去完成其它的任务。如果其它的任务比较重,建议开启。
配置
结果缓存
结果缓存 ,用于加速热门数据的访问速度,Dubbo 提供声明式缓存,以减少用户加缓存的工作量 。2.1.0 以上版本支持
缓存类型
lru 基于最近最少使用原则删除多余缓存,保持最热的数据被缓存。
threadlocal 当前线程缓存,比如一个页面渲染,用到很多 portal,每个 portal 都要去查用户信息,通过线程缓存,可以减少这种多余访问。
jcache 与 JSR107 集成,可以桥接各种缓存实现。
缓存类型可扩展
异步
耗时的请求可以使用异步
Consumer异步调用
从v2.7.0开始,Dubbo的所有异步编程接口开始以CompletableFuture为基础
基于 NIO 的非阻塞实现并行调用,客户端不需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小。
基于 NIO 的非阻塞实现并行调用,客户端不需要启动多线程即可完成并行调用多个远程服务,相对多线程开销较小。
example
使用RpcContext
重载服务接口
Provider异步执行
Provider端异步执行将阻塞的业务从Dubbo内部线程池切换到业务自定义线程,避免Dubbo线程池的过度占用,有助于避免不同服务间的互相影响。异步执行无益于节省资源或提升RPC响应性能,因为如果业务执行需要阻塞,则始终还是要有线程来负责执行。
定义CompletableFuture签名的接口
使用AsyncContext
参数回调
参数回调方式与调用本地 callback 或 listener 相同,只需要在 Spring 的配置文件中声明哪个参数是 callback 类型即可。Dubbo 将基于长连接生成反向代理,这样就可以从服务器端调用客户端逻辑 [1]。可以参考 dubbo 项目中的示例代码。
使用
事件通知
粘滞连接
ReferenceConfig 缓存
使用
netty4
provider端:
<dubbo:protocol server="netty4" />
或
<dubbo:provider server="netty4" />
consumer端:
<dubbo:consumer client="netty4" />
注意
provider端如需不同的协议使用不同的通信层框架,请配置多个protocol分别设置
consumer端请使用如下形式:
<dubbo:consumer client="netty">
<dubbo:reference />
</dubbo:consumer>
<dubbo:consumer client="netty4">
<dubbo:reference />
</dubbo:consumer>
接下来我们会继续完善:
性能测试指标及与netty3版本的性能测试对比,我们会提供一份参考数据
<dubbo:protocol server="netty4" />
或
<dubbo:provider server="netty4" />
consumer端:
<dubbo:consumer client="netty4" />
注意
provider端如需不同的协议使用不同的通信层框架,请配置多个protocol分别设置
consumer端请使用如下形式:
<dubbo:consumer client="netty">
<dubbo:reference />
</dubbo:consumer>
<dubbo:consumer client="netty4">
<dubbo:reference />
</dubbo:consumer>
接下来我们会继续完善:
性能测试指标及与netty3版本的性能测试对比,我们会提供一份参考数据
序列化
使用
基础服务
交互
直连
直连提供者
在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连,点对点直连方式,将以服务接口为单位,忽略注册中心的提供者列表,A 接口配置点对点,不影响 B 接口从注册中心获取列表。
配置
只订阅
为方便开发测试,经常会在线下共用一个所有服务可用的注册中心,这时,如果一个正在开发中的服务提供者注册,可能会影响消费者不能正常运行。
可以让服务提供者开发方,只订阅服务(开发的服务可能依赖其它服务),而不注册正在开发的服务,通过直连测试正在开发的服务。
可以让服务提供者开发方,只订阅服务(开发的服务可能依赖其它服务),而不注册正在开发的服务,通过直连测试正在开发的服务。
配置
只注册
配置
静态服务
配置
多协议
Dubbo 允许配置多协议,在不同服务上支持不同协议或者同一服务上同时支持多种协议。
不同服务不同协议
配置
多协议暴露服务
配置
多注册中心
Dubbo 支持同一服务向多注册中心同时注册,或者不同服务分别注册到不同的注册中心上去,甚至可以同时引用注册在不同注册中心上的同名服务。
注册中心是支持自定义扩展的。
多注册中心注册
不同服务使用不同注册中心
多注册中心引用
服务管理
服务分组
当一个接口有多种实现时,可以用 group 区分。
配置
多版本
配置
分组聚合
按组合并返回结果,比如菜单服务,接口一样,但有多种实现,用group区分,现在消费方需从每种group中调用一次返回结果,合并结果返回,这样就可以实现聚合菜单项。
可以自己拓展
配置
参数验证
参数验证功能 是基于 JSR303 实现的,用户只需标识 JSR303 标准的验证 annotation,并通过声明 filter 来实现验证 。
验证方式可扩展
配置
上下文信息
上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为 URL 的参数,参见 schema 配置参考手册 中的对应URL参数一列。
RpcContext 是一个 ThreadLocal 的临时状态记录器,当接收到 RPC 请求,或发起 RPC 请求时,RpcContext 的状态都会变化。比如:A 调 B,B 再调 C,则 B 机器上,在 B 调 C 之前,RpcContext 记录的是 A 调 B 的信息,在 B 调 C 之后,RpcContext 记录的是 B 调 C 的信息。
RpcContext 是一个 ThreadLocal 的临时状态记录器,当接收到 RPC 请求,或发起 RPC 请求时,RpcContext 的状态都会变化。比如:A 调 B,B 再调 C,则 B 机器上,在 B 调 C 之前,RpcContext 记录的是 A 调 B 的信息,在 B 调 C 之后,RpcContext 记录的是 B 调 C 的信息。
使用
隐式参数
可以通过 RpcContext 上的 setAttachment 和 getAttachment 在服务消费方和提供方之间进行参数的隐式传递。注意:path, group, version, dubbo, token, timeout 几个 key 是保留字段,请使用其它值。
使用
本地存根
远程服务后,客户端通常只剩下接口,而实现全在服务器端,但提供方有些时候想在客户端也执行部分逻辑,比如:做 ThreadLocal 缓存,提前验证参数,调用失败后伪造容错数据等等,此时就需要在 API 中带上 Stub,客户端生成 Proxy 实例,会把 Proxy 通过构造函数传给 Stub [1],然后把 Stub 暴露给用户,Stub 可以决定要不要去调 Proxy。
使用
主机绑定
使用
日志适配
使用
配置中心url简化
配置
IDL 定义服务
使用
框架使用,比如Mock,泛化,监控,日志打印,上下文等
泛化调用
泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况,参数及返回值中的所有 POJO 均用 Map 表示,通常用于框架集成,比如:实现一个通用的服务测试框架,可通过 GenericService 调用所有服务实现。
通过 Spring 使用泛化调用
通过 API 方式使用泛化调用
泛化实现
泛接口实现方式主要用于服务器端没有API接口及模型类元的情况,参数及返回值中的所有POJO均用Map表示,通常用于框架集成,比如:实现一个通用的远程服务Mock框架,可通过实现GenericService接口处理所有服务请求。
配置
回声测试
回声测试用于检测服务是否可用,回声测试按照正常请求流程执行,能够测试整个调用是否通畅,可用于监控。
使用
本地调用
使用
服务容器
服务容器是一个 standalone 的启动程序,因为后台服务不需要 Tomcat 或 JBoss 等 Web 容器的功能,如果硬要用 Web 容器去加载服务提供方,增加复杂性,也浪费资源。
服务容器只是一个简单的 Main 方法,并加载一个简单的 Spring 容器,用于暴露服务。
服务容器的加载内容可以扩展,内置了 spring, jetty, log4j 等加载,可通过容器扩展点进行扩展。配置配在 java 命令的 -D 参数或者 dubbo.properties 中。
服务容器只是一个简单的 Main 方法,并加载一个简单的 Spring 容器,用于暴露服务。
服务容器的加载内容可以扩展,内置了 spring, jetty, log4j 等加载,可通过容器扩展点进行扩展。配置配在 java 命令的 -D 参数或者 dubbo.properties 中。
容器类型
Spring Container
自动加载 META-INF/spring 目录下的所有 Spring 配置。
配置 spring 配置加载位置:
dubbo.spring.config=classpath*:META-INF/spring/*.xml
配置 spring 配置加载位置:
dubbo.spring.config=classpath*:META-INF/spring/*.xml
Jetty Container
启动一个内嵌 Jetty,用于汇报状态。
配置:
dubbo.jetty.port=8080:配置 jetty 启动端口
dubbo.jetty.directory=/foo/bar:配置可通过 jetty 直接访问的目录,用于存放静态文件
dubbo.jetty.page=log,status,system:配置显示的页面,缺省加载所有页面
配置:
dubbo.jetty.port=8080:配置 jetty 启动端口
dubbo.jetty.directory=/foo/bar:配置可通过 jetty 直接访问的目录,用于存放静态文件
dubbo.jetty.page=log,status,system:配置显示的页面,缺省加载所有页面
Log4j Container
自动配置 log4j 的配置,在多进程启动时,自动给日志文件按进程分目录。
配置:
dubbo.log4j.file=/foo/bar.log:配置日志文件路径
dubbo.log4j.level=WARN:配置日志级别
dubbo.log4j.subdirectory=20880:配置日志子目录,用于多进程启动,避免冲突
配置:
dubbo.log4j.file=/foo/bar.log:配置日志文件路径
dubbo.log4j.level=WARN:配置日志级别
dubbo.log4j.subdirectory=20880:配置日志子目录,用于多进程启动,避免冲突
容器启动
拓展
注册中心
Multicast 注册中心
zookeeper 注册中心
Nacos 注册中心
Redis 注册中心
Simple 注册中心
运维
Telnet
http://dubbo.apache.org/zh-cn/docs/user/references/qos.html
架构
配置
xml配置
服务端/提供者
dubbo:service
service是在provider的基础上给了很多默认值,用户使用时只需配置少量必需的值,大大降低学习成本。
dubbo:provider
provider是原始的服务提供方式:配置参数超级多,比较繁琐,学习成本大
dubbo:method
dubbo:argument
调用端/消费者
dubbo:reference
dubbo:consumer
dubbo:method
协议
dubbo:protocol
dubbo:parameter
注册中心
dubbo:registry
监控中心
dubbo:monitor
应用信息配置
dubbo:application
模块信息配置
dubbo:module
配置中心
dubbo:config-center
属性配置
优先级从高到低
JVM -D参数,当你部署或者启动应用时,它可以轻易地重写配置,比如,改变dubbo协议端口;
XML, XML中的当前配置会重写dubbo.properties中的;
如果在classpath下有超过一个dubbo.properties文件,比如,两个jar包都各自包含了dubbo.properties,dubbo将随机选择一个加载,并且打印错误日志。
Properties,默认配置,仅仅作用于以上两者没有配置时
如果在xml配置中有超过一个的tag,那么你可以使用‘id’进行区分。如果你不指定id,它将作用于所有tag。
dubbo.protocol.rmi.port=1099 相当于 <dubbo:protocol id="rmi" name="rmi" port="1099" />
dubbo.registry.china.address=10.20.153.10:9090 相当于 <dubbo:registry id="china" address="10.20.153.10:9090" />
dubbo.protocol.rmi.port=1099 相当于 <dubbo:protocol id="rmi" name="rmi" port="1099" />
dubbo.registry.china.address=10.20.153.10:9090 相当于 <dubbo:registry id="china" address="10.20.153.10:9090" />
如果 id没有在protocol中配置,将使用name作为默认属性。
API 配置
配置 API
注解 API
模型 API
org.apache.dubbo.common.URL
org.apache.dubbo.rpc.RpcException
org.apache.dubbo.rpc.RpcException
上下文 API
org.apache.dubbo.rpc.RpcContext
上下文信息
隐式参数
异步调用
服务API
org.apache.dubbo.rpc.service.GenericService
org.apache.dubbo.rpc.service.GenericException
org.apache.dubbo.rpc.service.GenericException
泛化调用
泛化实现
回声测试
注解配置
推荐使用
@Service
@Configuration
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.impl")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static public class ProviderConfiguration {
}
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.impl")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static public class ProviderConfiguration {
}
@Reference
@Configuration
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.action")
@PropertySource("classpath:/spring/dubbo-consumer.properties")
@ComponentScan(value = {"org.apache.dubbo.samples.simple.annotation.action"})
static public class ConsumerConfiguration {
}
@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.action")
@PropertySource("classpath:/spring/dubbo-consumer.properties")
@ComponentScan(value = {"org.apache.dubbo.samples.simple.annotation.action"})
static public class ConsumerConfiguration {
}
动态配置中心
配置中心(v2.7.0)在Dubbo中承担两个职责:
1. 外部化配置。启动配置的集中式存储 (简单理解为dubbo.properties的外部化存储)。
外部化配置目的之一是实现配置的集中式管理,这部分业界已经有很多成熟的专业配置系统如Apollo, Nacos等,Dubbo所做的主要是保证能配合这些系统正常工作。
1) 优先级
外部化配置默认较本地配置有更高的优先级,因此这里配置的内容会覆盖本地配置值,你也可通过以下选项调整配置中心的优先级:
-Ddubbo.config-center.highest-priority=false
-Ddubbo.config-center.highest-priority=false
2) 作用域
外部化配置有全局和应用两个级别,全局配置是所有应用共享的,应用级配置是由每个应用自己维护且只对自身可见的。
当前已支持的扩展实现有Zookeeper、Apollo。
当前已支持的扩展实现有Zookeeper、Apollo。
自己加载外部化配置
所谓Dubbo对配置中心的支持,本质上就是把.properties从远程拉取到本地,然后和本地的配置做一次融合。理论上只要Dubbo框架能拿到需要的配置就可以正常的启动,它并不关心这些配置是自己加载到的还是应用直接塞给它的,所以Dubbo还提供了以下API,让用户将自己组织好的配置塞给Dubbo框架(配置加载的过程是用户要完成的),这样Dubbo框架就不再直接和Apollo或Zookeeper做读取配置交互。
// 应用自行加载配置
Map<String, String> dubboConfigurations = new HashMap<>();
dubboConfigurations.put("dubbo.registry.address", "zookeeper://127.0.0.1:2181");
dubboConfigurations.put("dubbo.registry.simplified", "true");
//将组织好的配置塞给Dubbo框架
ConfigCenterConfig configCenter = new ConfigCenterConfig();
configCenter.setExternalConfig(dubboConfigurations);
Map<String, String> dubboConfigurations = new HashMap<>();
dubboConfigurations.put("dubbo.registry.address", "zookeeper://127.0.0.1:2181");
dubboConfigurations.put("dubbo.registry.simplified", "true");
//将组织好的配置塞给Dubbo框架
ConfigCenterConfig configCenter = new ConfigCenterConfig();
configCenter.setExternalConfig(dubboConfigurations);
2. 服务治理。服务治理规则的存储与通知。
Zookeeper
Apollo
所有的服务治理规则都是全局性的,默认从公共命名空间dubbo读取和订阅:
配置加载流程
自动加载环境变量
从2.7.3版本开始,Dubbo会自动从约定key中读取配置,并将配置以Key-Value的形式写入到URL中。
dubbo.labels
指定一些列配置到URL中的键值对,通常通过JVM -D或系统环境变量指定。
增加以下配置:
# JVM
-Ddubbo.labels = "tag1=value1; tag2=value2"
# 环境变量
DUBBO_LABELS = "tag1=value1; tag2=value2"
最终生成的URL会包含 tag1、tag2 两个 key: dubbo://xxx?tag1=value1&tag2=value2
增加以下配置:
# JVM
-Ddubbo.labels = "tag1=value1; tag2=value2"
# 环境变量
DUBBO_LABELS = "tag1=value1; tag2=value2"
最终生成的URL会包含 tag1、tag2 两个 key: dubbo://xxx?tag1=value1&tag2=value2
dubbo.env.keys
指定环境变量key值,Dubbo会尝试从环境变量加载每个 key
# JVM
-Ddubbo.env.keys = "DUBBO_TAG1, DUBBO_TAG2"
# 环境变量
DUBBO_ENV_KEYS = "DUBBO_TAG1, DUBBO_TAG2"
最终生成的URL会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: dubbo://xxx?DUBBO_TAG1=value1&DUBBO_TAG2=value2
# JVM
-Ddubbo.env.keys = "DUBBO_TAG1, DUBBO_TAG2"
# 环境变量
DUBBO_ENV_KEYS = "DUBBO_TAG1, DUBBO_TAG2"
最终生成的URL会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: dubbo://xxx?DUBBO_TAG1=value1&DUBBO_TAG2=value2
协议
dubbo://
缺省
适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
rmi://
hessian://
http://
webservice://
thrift://
memcached://
redis://
rest://
grpc://
0 条评论
下一页