dubbo一些高级属性的梳理

 

注册中心的好处在于不必知道每个微服务的地址，所有微服务自动注册，注册中心负责查找分发

 

消费端，服务端，注册中心是长链接---注册中心用长链接来检测心跳

消费端把调用时间存储在本地内存，每隔一分钟发送给注册端，服务端爸调用次数记录在内存，每隔一分钟发送给注册中心

 

dubbo的也可以设置线程池大小，拒绝策略---类似tomcat

 

直连提供者是在消费端的接口处配置要直连的服务提供端地址

<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />

 

服务端注册的时候可以设置为静态服务---不由注册中心自动删除

 

大数据用短链接协议，小数据高并发用长链接协议

服务端先定义协议

<dubbo:protocol name="dubbo" port="20880" />---长协议，传输方式：NIO异步传输 序列化：Hessian二进制序列化 

    <dubbo:protocol name="rmi" port="1099" />---短协议，传输方式：同步传输 序列化：Java标准二进制序列化 

 

然后具体到每个接口的协议选择-----通信协议的选择一般根据数据大小，并发量选择长链接的还是短链接的协议

 <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />

    <!-- 使用rmi协议暴露服务 -->

    <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" /> 

 

同理多注册中心也是，而且消费引用端也可指明不同注册中心

 

version和group一样是为了区分引用

 

group有另外一个用处就是merger合并结果，可以指明这个接口（方法）哪些组可以合并结果

 

 

cache在消费引用端配置缓存策略

lru 基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。

threadlocal 当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。

jcache 与 JSR107 集成，可以桥接各种缓存实现。

 

<dubbo:reference interface="com.foo.BarService" cache="lru" />

 

 

 

回声测试

 

用于试探调用过程的联通性，排除业务接口本身代码的影响

 

所有服务自动实现 EchoService 接口，只需将任意服务引用强制转型为 EchoService，即可使用。

 

// 远程服务引用

MemberService memberService = ctx.getBean("memberService"); 

 

EchoService echoService = (EchoService) memberService; // 强制转型为EchoService

 

// 回声测试可用性

String status = echoService.$echo("OK"); 

 

assert(status.equals("OK"));

 

 

隐式参数

 

类似cookie把参数放在全局的上下文中，当前调用完成即清空，每调用一次重新设置一次

id---host+方法名，在被调用放获取

 

 

调用方：

RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐式将这些参数发送到服务器端，类似cookie，用于框架集成，不建议常规业务使用

xxxService.xxx(); // 远程调用

 

 

 

 

被调用方：

public class XxxServiceImpl implements XxxService {

 

    public void xxx() {

        // 获取客户端隐式传入的参数，用于框架集成，不建议常规业务使用

        String index = RpcContext.getContext().getAttachment("index"); 

    }

}

 

 

 

本地调用---针对既是消费端又是服务端的情况，自己消费自己的服务 

 

   

参看：

https://blog.csdn.net/ywb201314/article/details/80917196

 

 

服务方用什么协议。在哪个端口暴露服务

消费方用什么协议获取服务。在哪个端口暴露自己的服务

》》

既是消费方又是服务方，协议名获取服务，端口上暴露服务

 

<dubbo:protocol name="协议名" port="端口" />

 

 

 

executes   服务端的并发数

 

actives    消费端的并发数

 

accepts  服务端链接数控制

 

connections   消费端连接数控制

 

 

 

每个10分钟导出一份dump

 

<dubbo:application ...>

    <dubbo:parameter key="dump.directory" value="/tmp" />

</dubbo:application>