Dubbo入门学习总结（一）

       前言：经历了一年多的学习，将之前记录在手机/记事本上的笔记在这里进行汇总，回顾，总结。

相比duboo 和spirng boot，一直讨论的比较多，但是个人体会吧，相比spring boot，duboo只是其中rpc调用的一个框架，关注点在于rpc调用，而spring boot 集服务治理、服务管理、配置中心等等微服务扩充方向都有扩展，有点类似于一站式解决方案都提供好了。
接触duboo时间也不长，爬过的坑却不少，为了防止以后忘记，也留下一点个人的学习经历，进入正题吧。（自从公司断了QQ直接登录后，CSDN改版了！，这段落空行根本不会修改了，看着好不顺眼，只能使用这个已编排好的格式放在这个框里面）

    项目采用duboox 各依赖包版本

     duboo版本 2.8.4

     duboo集成spring版本 3.2.9

     在主工程pom文件依赖dubbo-parent

    com.alibaba
    dubbo-parent
    2.8.4

    其他依赖版本如下:

     包含redis/mybatis/activemq/zookeeper/log4j/spirng等中间件、基础框架的版本。

     
        
        UTF-8
        UTF-8
        UTF-8
        
        1.8
        1.8
        1.8

        
        2.8.4
        
        3.4.6
        0.1

        
        4.12
        1.3
        1.10.19
        1.16.0

        
        
        3.4.2
        1.3.1
        
        5.1.41
        
        8.0.41

        
        20160810
        2.3

        
        1.8.9
        
        5.14.4
        
        3.2.9.RELEASE
        
        2.0

        
        2.2.3

        1.1.0.Final
        5.4.1.Final
        3.0.0  

  哇,这CSDN改版的文本编辑器完全不会用啊...换行折腾好久，用得蛋碎.

PS:【现在dubbo官网重新开始维护了,并且修复了其中的一些坑,然后支持了最新的spirng4等框架做了升级，想使用新版本的同学可以使用最新版本。】

  工程结构

---xxx-parent
   ----service1-parent
        -----service1-module1
             ----src
             ----pom
        -----service1-module2
             ----src
             ----pom
        -----service1-module3
             ----src
             ----pom // 服务自己依赖 + 依赖业务线base 包依赖
        -----service1-module-base
             ----src
             ----pom //服务base包共有依赖 但是不可与父工程的 依赖冲突
        -----pom
-------service2-parent
        -----service2-module1
        -----service2-module2
        -----service2-module-base
        -----pom 
-------service3-parent
        -----service3-module1
        -----pom //业务线 自己的依赖 但是不可与父工程的 依赖冲突
-------pom.xml //项目公共依赖 例如:log4j、json、spring、duboo等基础依赖及其版本加入到父工程的依赖之中。

     这种模式形成过程

     最初只有1个parent，管理了所有的依赖包版本与服务module。大致如下：

        公共-base
        业务线1-服务1
        业务线1-服务2
        .......
        ......
        业务线2-服务1
        业务线2-服务3
        .......
        ........
        业务线13-服务1
        ........

 这样做的结果就是非常惨烈的，在共同开发的时候都得修改这个文件，新增删除每一个服务，并且由于服务依赖的第三方包版本不同，

都尝试修改父工程，或自己工程的依赖项。后来服务太多了，维护这个module节点都非常的困难。所以采用了现有的目录结构。

   工程创建

      父parent    pom工程，公共依赖。

      业务线parent pom工程，服务线公共依赖。

      服务 pom jar工程，服务自己的依赖。

     大致建立过程与网上许多入门相同，不再赘述。

    【这么创建的好处，就是方便维护】

    【关于duboo的两方包API共有model问题，由于刚开始接触不深，最终没有采用双方包版本放在共有仓库的办法，而是从服务端拷贝api和model来进行调用，实际上可能会诱发很多问题】

      

   开发过程

     开发过程，按照给的模板，duboo是遍历src/main/resources下的xml文件，所以最终的服务目录结构大致如下：

  ----service1-module1
        ----src
            ----main
                ----java
                    ----com
                        ----....//package 包及类java文件
                ----resources
                    ----mybatis
                        config.xml
                        mapper.xml
                    ----META-INF
                        ----spring
                            mq.xml
                            redis.xml
                            application-context.xml
                            dubbo-consumer.xml
                            duboo-provider.xml
                    application.properites
                    xxx.properites
                    jdbc.properites
                    log4j2.xml
                    .........//等配置文件
        pom //工程 pom文件

   在开发中需要注意的地方

关于bean的注入,采用的是注解的方式 而不是 xml注入的方式，各有好处吧。
注解实现：看代码方便，一目了然。
接口包名:com.hesiyuan.业务名.服务名.api 作为接口申明
实现包名:com.hesiyuan.业务名.服务名.api.impl  类名 xxxServiceImpl 采用@Service("服务名") 注解
xml实现：可以删除注入的bean 从而控制是否注入该类 ，所有的bean都在xml中可以查看到等等好处（实际生产上是绝对不需要用xml来控制是否注入和启用新旧版本的bean的，会带来麻烦）

 

消费端 xml配置

消费者端配置参数，几个重要点。
1.connections 服务间连接数  //后续我会专门写一篇文章说明这参数什么时候会对性能有影响。 对性能要求不高 或者TCP传输无卡顿没达到上限 建议值 1
2.check 启动时检测有提供者  //是否zookeeper上能找到能提供服务的应用启着 如果不能确定服务启动顺序,建议flase
3.id 等于@service注解 的别名
4.retries 重试次数建议
5. scope 分本地调用 或 远程调用 




    
    
        

    服务者端 xml配置

 

服务者端配置参数，几个重要点。
1. name 协议名 只用过duboo 和dubbox支持的rest协议
2. port 端口
3. 线程数 默认200
4. version 一般为三位 0.0.1 或者1.2.11这样
5. timeout 客户端 服务端都可以设定，客户端优先，但是最好尽量在服务端设定其自己的参数（毕竟更了解自己☺）
6. ref 注入bean的别名 
7. executes 并发数 //这是个坑...并发数是在调用是,当前线程运行的时的线程数大于这个数,拒绝请求,但是2.8的duboo这个判断是非线程安全的。最新dubbo修复了该问题。详见另外一篇文章



 

    注册中心配置