Dubbo——配置
一、配置原则
JVM 启动 -D 参数优先，这样可以使用户在部署和启动时进行参数重写，比如在启动时需改变协议的端口。
XML 次之，如果在 XML 中有配置，则 dubbo.properties 中的相应配置项无效。
Properties 最后，相当于缺省值，只有 XML 没有配置时，dubbo.properties 的相应配置项才会生效，通常用于共享公共配置，比如应用名。
二、启动检查
默认情况下，dubbo将检查服务提供者在启动时是否可用。当Spring完全初始化不可用时，它将抛出一个异常以防止Spring完成初始化，以便在发布应用程序(默认设置)之前尽早发现问题：check=true.
你可以关掉检查check=false...例如，有些服务在运行测试时不关心它，或者由于循环依赖关系，必须首先启动测试。
此外，如果Springbean是延迟加载的，或者使用API编程延迟引用服务，则关闭检查，否则服务将在服务暂时不可用时抛出异常，然后获得一个空引用。如果您配置check=false，你可以得到一个推荐信。还原服务后，服务可以自动重新连接。
2.1 使用Spring配置文件
禁用服务的启动检查(在没有提供提供程序时抛出一些异常/错误)：
<dubbo:reference interface = "com.foo.BarService" check = "false" />
禁用所有服务的启动检查(未提供时抛出一些异常/错误)：
<dubbo:consumer check = "false" />
禁用注册中心启动检查(注册订阅失败错误)：
<dubbo:registry check="false" />
2.2 使用dubbo.properties
dubbo.reference.com.foo.BarService.check = false dubbo.reference.check = false dubbo.consumer.check = false dubbo.registry.check = false
2.3 使用-d参数
java -Ddubbo.reference.com.foo.BarService.check = false java -Ddubbo.reference.check = false java -Ddubbo.consumer.check = false java -Ddubbo.registry.check = false
三、超时时间
由于网络或服务端不可靠，会导致调用出现一种不确定的中间状态（超时）。为了避免超时导致客户端资源（线程）挂起耗尽，必须设置超时时间。（默认1秒）
3.1 dubbo消费端
全局超时配置 <dubbo:consumer timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:reference interface="com.foo.BarService" timeout="2000"> <dubbo:method name="sayHello" timeout="3000" /> </dubbo:reference>
3.2 dubbo服务端
全局超时配置 <dubbo:provider timeout="5000" /> 指定接口以及特定方法超时配置 <dubbo:provider interface="com.foo.BarService" timeout="2000"> <dubbo:method name="sayHello" timeout="3000" /> </dubbo:provider>
3.3 配置原则
3.3.1 dubbo推荐在Provider上尽量多配置Consumer端属性：
1、作服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，等等
2、在Provider配置后，Consumer不配置则会使用Provider的配置值，即Provider配置可以作为Consumer的缺省值。否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的
3.3.2 配置覆盖规则
1、方法级配置别优于接口级别，即小Scope优先
2、Consumer端配置 优于 Provider配置 优于 全局配置，
3、 最后是Dubbo Hard Code的配置
四、重试次数
当出现故障时，重试另一台服务器(默认)。通常用于幂等操作，但重试会导致更长的延迟。重试的时间可以通过retries =2(第一次除外)
配置：
<dubbo:service retries="2" />
或：
<dubbo:reference retries="2" />
或：
<dubbo:reference> <dubbo:method name="findFoo" retries="2" /> </dubbo:reference>
幂等和非幂等区别：https://www.cnblogs.com/lzc978/p/10386122.html
五、版本号
当接口实现不兼容升级时，可以使用版本号转换。不同版本的服务不相互引用。（灰度发布）
可以按照以下步骤进行版本迁移：
- 在低压阶段，升级到提供程序的一半到新版本。
- 然后将所有消费者升级到新版本。
- 然后将其余的一半提供程序升级到新版本。
5.1 服务提供者配置的旧版本：
<dubbo:service interface="com.foo.BarService" version="1.0.0" />
5.2 新版本的服务提供者配置：
<dubbo:service interface="com.foo.BarService" version="2.0.0" />
5.3 服务使用者配置的旧版本：
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
5.4 新版本的服务使用者配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
5.5 如果不需要区分版本，可以按以下方式配置：
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
六、本地存根
当使用RPC时，客户端通常只使用接口，但有时客户端也希望在客户机中执行部分逻辑。例如：执行ThreadLocalcache，验证参数，在调用失败时返回模拟数据，等等。
为了解决这个问题，您可以在api中配置存根，以便当客户端生成代理实例时，它将代理传递给Stub通过构造函数，然后可以在存根实现代码中实现您的逻辑。
6.1 在Spring配置文件中配置如下：
<dubbo:service interface="com.foo.BarService" stub="true" />
或
<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />
6.2 提供Stub实现
package com.foo; public class BarServiceStub implements BarService { private final BarService barService; // The real remote proxy object is passed in through the constructor public BarServiceStub(BarService barService){ this.barService = barService; } public String sayHello(String name) { // The following code is executed on the client. You can do local ThreadLocal caching on the client side, or verify parameters, etc. try { return barService.sayHello(name); } catch (Exception e) { // You can return the mock data. return "MockData"; } } }
-
Stub必须有一个可以传递代理的构造函数。
-
BarServiceStub实现BarService，它有一个在远程BarService实例中传递的构造函数
