dubbo实践以及原理分析

 

一：RPC---远程过程调用，java里也可以叫远程方法调用，只要能通过协议从一台服务器调用到另外一台服务器的服务信息的协议都叫RPC协议，因此 http、tcp、socket都是rpc协议。

二：Dubbo核心原理：

        dubbo默认长连接，使用tcp协议传输，dubbo中有许多Filter实现类，其中 ConsumerContextFilter 是消费端调用dubbo服务时调用invoke（），而 ContextFilter是提供端被调用dubbo服务时调用，（只有属于dubbo服务才会被调用，其他的方法是不会进拦截器的）。在dubbo从消费端调用提供端的方法时，会通过 RpcContext 来传递参数：

       2.1：隐式传参：

               RpcContext.getContext().setAttachment("user",user.toString());

               此方法只能传递一次，如从 A -->B ,B接收后，该变量里的参数会被清空，也应该被清空：

因此在多服务调用时，要多次设置参数。

    在提供端接收到参数后，会根据 RpcContext里面获取到的dubbo默认添加的参数（包含当前要调用当前系统的 类、方法、参数、参数类型、ip等等）进行反射的调用，就跟本地方法进行反射调用一样，从而实现调用功能。

三：自定义 filter:

        自定义 filter需要实现 Dubbo的Filter接口，同时还需要在 META-INF 目录下新建一个 dubbo 目录，然后 在里面新建 text文档，里面填写自己定义的dubbo 类名 即可：

四：实践中的问题：

        4.1：dubbo的重试机制带来的问题：

                描述：在dubbo调用过程中，从客户端的请求到达提供端这个过程中，如果对客户端和提供端都设置了 超时时间后，超时时间就会以客户端为准，同时，这个超时时间也只会作用于客服端，如果 请求从客户端发出后，此时在提供端被堵塞住了（俗称卡住了），此时客户端等待响应的时间超过设置的时间之后，就会报 TimeOut异常，但是此时 提供端的代码还是会继续执行，但是此时已经无法返回了，因此会产生提供端执行多次的问题：因为如果设置了超时时间以及重试次数之后就会进行重试，因此 提供端可能会被调用多次，此时就需要进行接口幂等性操作。

              4.1.1：幂等性含义：

                 HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

               4.1.2：幂等性解决重试机制带来的一系列问题。如果是查询操作无所谓，但是如果是更新等操作，需要对更新的东西有记录，防止多次操作。

             4.1.3：延长过期时间：如果客户端过期时间长于提供端的时间的话，此时轮训如果失败，那么提供端的也已经超时了，此时提供端的代码就不会继续执行下去，超时等配置都是以客户端为优先，如果客户端有，那么默认使用客户端的配置，如果客户端没配置，那么使用提供端提供的配置。

            4.1.4：不进行重试：但是这种方式其实也防止不住

总结：最好还是把客户端的超时时间设置的比提供端稍微久点：tcp连接耗时，此时就不需要幂等设计，否则就需要根据业务给出幂等性方案，防止系统重复调用。