1. Common configuration of dubbo
< dubbo:service /> Service configuration is used to expose a service and define the meta information of the service. A service can be exposed by multiple protocols, and a service can also be registered with multiple registries. eg、<dubbo:service ref="demoService" interface="com.unj.dubbotest.provider.DemoService" /> < dubbo:reference /> refers to the service configuration, which is used to create a remote service proxy, and a reference can point to multiple registries. eg、<dubbo:reference id="demoService" interface="com.unj.dubbotest.provider.DemoService" /> < dubbo:protocol /> Protocol configuration, used to configure the protocol information for providing services. The protocol is specified by the provider and passively accepted by the consumer. eg、<dubbo:protocol name="dubbo" port="20880" /> < dubbo:application /> Application configuration, used to configure the current application information, whether the application is a provider or a consumer. eg、<dubbo:application name="xixi_provider" /> <dubbo:application name="hehe_consumer" /> < dubbo:module /> Module configuration, used to configure the current module information, optional. < dubbo:registry /> Registry center configuration, used to configure information about connecting to the registry. eg、<dubbo:registry address="zookeeper://192.168.2.249:2181" /> < dubbo:monitor /> Monitoring center configuration, used to configure information about connecting to the monitoring center, optional. < dubbo:provider /> The default value of the provider. When a certain property of ProtocolConfig and ServiceConfig is not configured, this default value is used, which is optional. < dubbo:consumer /> The default configuration of the consumer. When a property of ReferenceConfig is not configured, this default value is used, which is optional. < dubbo:method /> method configuration, which is used to specify method-level configuration information in ServiceConfig and ReferenceConfig. < dubbo:argument /> is used to specify method parameter configuration.
2. Service call timeout setting
In the above figure, timeout is used as an example to show the search order of the configuration. Other retries, loadbalance, and actives are similar.
The method level takes precedence, the interface level comes second, and the global configuration takes precedence.
If the level is the same, the consumer takes priority, and the provider takes second.
The configuration of the service provider is passed to the consumer through the registration center through the URL.
It is recommended to set the timeout by the service provider, because the service provider knows how long a method takes to execute. If a consumer references multiple services at the same time, it does not need to care about the timeout setting of each service.
In theory, the non-service identifier configuration of ReferenceConfig can be configured by default in ConsumerConfig, ServiceConfig, and ProviderConfig.
3. Check
at startup. By default, Dubbo will check whether the dependent services are available at startup. When it is unavailable, it will throw an exception to prevent Spring initialization from completing, so that problems can be found early when going online. The default check=true.
If your Spring container is lazy loaded, or the service is delayed through API programming, please turn off check. Otherwise, when the service is temporarily unavailable, an exception will be thrown and a null reference will be obtained. If check=false, the reference will always be returned. When the service is restored, it can be automatically connected.
The check can be turned off by check="false". For example, when testing, some services do not care, or there is a circular dependency, and one party must start it first.
1. Turn off the startup check of a service: (Error when there is no provider) < dubbo:reference interface ="com.foo.BarService" check ="false" /> 2. Turn off the startup check of all services: (no provider reports an error) Written on the side of defining the service consumer <dubbo:consumer check="false" /> 3. Check when the registration center is turned off: (Error when registration and subscription fails) <dubbo:registry check="false" />
引用缺省是延迟初始化的，只有引用被注入到其它Bean，或被getBean()获取，才会初始化。
如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：
<dubbo:reference interface="com.foo.BarService" init="true" />
四、订阅
1、问题
为方便开发测试，经常会在线下共用一个所有服务可用的注册中心，这时，如果一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。
2、解决方案
可以让服务提供者开发方，只订阅服务(开发的服务可能依赖其它服务)，而不注册正在开发的服务，通过直连测试正在开发的服务。
禁用注册配置： <dubbo:registry address="10.20.153.10:9090" register="false" /> 或者： <dubbo:registry address="10.20.153.10:9090?register=false" />
五、回声测试(测试服务是否可用)
回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。
所有服务自动实现EchoService接口，只需将任意服务引用强制转型为EchoService，即可使用。
eg、<dubbo:reference id="memberService" interface="com.xxx.MemberService" /> MemberService memberService = ctx.getBean("memberService"); // 远程服务引用 EchoService echoService = (EchoService) memberService; // 强制转型为EchoService String status = echoService.$echo("OK"); // 回声测试可用性 assert(status.equals("OK"))
六、延迟连接
延迟连接，用于减少长连接数，当有调用发起时，再创建长连接。
只对使用长连接的dubbo协议生效。
<dubbo:protocol name="dubbo" lazy="true" />
七、令牌验证
防止消费者绕过注册中心访问提供者，在注册中心控制权限，以决定要不要下发令牌给消费者，注册中心可灵活改变授权方式，而不需修改或升级提供者
1、全局设置开启令牌验证： <!--随机token令牌，使用UUID生成--> <dubbo:provider interface="com.foo.BarService" token="true" /> <!--固定token令牌，相当于密码--> <dubbo:provider interface="com.foo.BarService" token="123456" /> 2、服务级别设置开启令牌验证： <!--随机token令牌，使用UUID生成--> <dubbo:service interface="com.foo.BarService" token="true" /> <!--固定token令牌，相当于密码--> <dubbo:service interface="com.foo.BarService" token="123456" /> 3、协议级别设置开启令牌验证： <!--随机token令牌，使用UUID生成--> <dubbo:protocol name="dubbo" token="true" /> <!--固定token令牌，相当于密码--> <dubbo:protocol name="dubbo" token="123456" />
八、日志适配
缺省自动查找：log4j、slf4j、jcl、jdk
可以通过以下方式配置日志输出策略：dubbo:application logger="log4j"/>
访问日志：
如果你想记录每一次请求信息，可开启访问日志，类似于apache的访问日志。此日志量比较大，请注意磁盘容量。
将访问日志输出到当前应用的log4j日志：
<dubbo:protocol accesslog="true" />
将访问日志输出到指定文件：
<dubbo:protocol accesslog="http://10.20.160.198/wiki/display/dubbo/foo/bar.log" />
九、配置Dubbo缓存文件
配置方法如下：
<dubbo:registryfile=”${user.home}/output/dubbo.cache” />
Note:
The path to the file, the application can adjust as needed to ensure that this file will not be cleared during the publishing process. If there are multiple application processes, be careful not to use the same file to avoid content being overwritten.
This file will be cached:
The registry's list
service provider list
With this configuration, when the application restarts and the Dubbo registry is unavailable, the application will read the service provider list information from this cache file to further ensure application reliability.