dubbo使用记录

dubbo架构设计：

主要围绕服务发布，服务引用，服务注册三个基本功能展开。

由于是rpc服务治理框架，需要抽象服务做为领域模型，使架构能够高度抽象统一。这个领域对象就是invoker，即代表一个服务。

有了invoker领域模型后，我们希望能够管理invoker的生命周期，这个就是Protocal。就像spring一样，bean作为基本领域模型，ApplicationContext上层容器作为其生命周期管理的组件。

最后，即然是rpc调用就涉及到对调用方法及入参的封装，这个封装对象为invocation。

为了使服务调用方能够透明化，就像调用本地方法一样，因此需要生成一个当前引用的业务接口的代理类。代理类的目标对象为invoker，而invoker代表了可调用的远程服务。

生成代理类有javassist字节码或者jdk动态代理。javassist性能比jdk动态代码要好，因为javassist是基于字节码增强，而jdk动态代码是继承业务接口最终要用反射调用业务方法。

invoker根据调用服务失败的行为有FailoverClusterInvoker，FailFastClusterInvoker等。内部封装了调用远程服务的逻辑，涉及LoadBalance（随机或者循环），Router（选择一个服务）。

网络会成为很多情况下的瓶颈，指单个服务提供者。

  传统服务发布与调用，如webservice，http等方式，很难做到动态不重启的情况下加机器。dubbo可以做到这一点。

  dubbo的核心：服务发布，服务消费，服务注册。

  dubbo的目标是使服务发布方与服务费方发布或使用服务的时候就像使用本地服务一样，透明化。高可用等也是设计目标。

  invoker是dubbo中的领域，其实就是一个代理，是一个服务的抽象，调用方调用服务及服务发布方发布服务时都会产生invoker实例。

  invoker内部包含实际服务对象引用，就是一个代理，最终调用的服务就是调用这个引用的某个方法。有jassist或者jdk动态代理。

  protocal则是管理invoker的生命周期，创建及销毁。protocal有dubbo，rmi等。

  Cluster在某个服务有多台机子时存在，用于负载均衡，失效转移等。

  Expoter用于存储具体服务与invoker的映射。

  dubbo发布服务实际上做了两件事情：

  1.将服务注册在注册中心

  2.启动socket监听本地服务调用

  dubbo使用时注意事项：

  注册中心使用zookeper，可以填写集群zookeeper机子集合。

  配置服务调用失败时策略，failover或者failFast等。

  配置服务调用超时重试时间，针对failover。

  dubbo协议默认使用netty和hessian序列化。

  项目中需要慎用超时重试，非幂等业务慎用。并且如果一个业务操作本身需要耗费30秒以上，这时就要小心设置超时时间。最坏的情况是超时时间timeout小于业务操作时间，这时业务操作不断超时，重试3次，如果请求过多最终会消耗完dubbo服务线程。这种情况下最终服务端调用次数为：业务请求数*3