Dubbo

1、Dubbo的失效时间和尝试次数在哪设置，服务降级

DEFAULT_RETRIES    默认重试次数    2

DEFAULT_TIMEOUT    请求执行默认超时时间  1s

DEFAULT_CORE_THREADS  默认核心线程数       0

DEFAULT_THREADS  线程池默认线程数   200

超时时间

<dubbo:service interface="com.yz.dubbo.api.IUserService" ref="userService1" timeout="1000"></dubbo:service>

<dubbo:service interface="com.yz.dubbo.api.IUserService" ref="userService1" >

    <dubbo:method name="getUser" timeout="2000"></dubbo:method>

</dubbo:service>

<dubbo:provider timeout="3000"></dubbo:provider>

启动检查

<dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false"></dubbo:reference>

<dubbo:registry address="zookeeper://127.0.0.1:2181" check="false"></dubbo:registry>

重试次数

<dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" retries="3"></dubbo:reference>

多版本

<dubbo:service interface="com.yz.dubbo.api.IUserService" ref="userService1" version="1.0.0"></dubbo:service>

<dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" version="1.0.0"></dubbo:reference>

 

什么是服务降级
 

        服务降级，当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

 

2、怎么解决dubbo事务问题

事务补偿机制

事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。

基于消息的最终一致性     

在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。

如果真正需要的是实时的一致性，那么即使采用事务补偿机制，也无法达到实时的一致性。即很可能在两个业务服务调用中间，客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下，我们不得不考虑需要在数据库表增加业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。

 

3、Dubbo和springCloud的区别

最大的区别：Dubbo底层是使用Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。而SpringCloud是基于Http协议+rest接口调用远程过程的通信，相对来说，Http请求会有更大的报文，占的带宽也会更多。但是REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。

dubbo由于是二进制的传输，占用带宽会更少

springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研

 

4、dubbo和传统tomcat服务有什么区别？

tomcat 是 web 服务器，提供 http 服务，当 tomcat 收到浏览器发送的 http 请求时，根据 url 查询对应的 servlet 处理请求，然后发送 http 响应。

dubbo 是 rpc 框架，提供 dubbo 服务，当 provider 收到 consumer 发送的请求后，解析请求，找到对应的接口服务类（原始接口服务类的外面裹着代理和一系列 filter），处理请求，发送响应。

相同点：
tomcat 是 http 服务器，基于 tcp 协议，dubbo 框架支持多种协议（dubbo, hessian 等），常用的 dubbo 协议也是基于 tcp 协议。即 dubbo 的 consumer 和 provider 首先要建立 tcp 连接，然后才能发送数据。

不同点：
（1）http 客户端如何发送请求？首先建立 tcp 连接，然后发送 http 请求报文，接着等待 http 响应报文，http 报文都是明文字符串。
dubbo 客户端如何发送请求呢？正常情况下，provider 会暴露服务，consumer 去 refer 服务获得代理，然后通过代理调用服务，这里有很长的一个调用栈，底层也是 consumer 发送 request，等待 provider 的 response，但是这里的 request 和 response 都是序列化的 java 对象。
（2）http 客户端发送请求，必然会收到对应的 http 响应，而 dubbo consumer 发送请求时可以设置为 oneway，即不需要响应，则 dubbo provider 不会发送响应，请求也可以设置为同步或者异步，不管同步还是异步都是有响应的。

dubbo provider 如何根据请求定位到具体的服务实现类，调用栈如下图：

主要是根据 serviceKey 查找 exporter。