分布式现在已经火过了（话说现在仍然很火，只是赶不上微服务的热度了），但是dubbo过时了吗？反正我认为没有，不然apache为何要接手维护这个框架呢，我没看错的话还是顶级项目呢。。没错，现在大家都在呼唤微服务了，springboot、springcloud，感觉不会这两个就不是一个好的程序员，没错，我一直都不觉得现在的自己有多么优秀，就是个渣渣，先把dubbo玩会了，再去考虑追求时尚嘛。当然我其实对于dubbo也是了解的不多，所以也就是写点东西，给自己以后看看的，万一忘记了可以很快想起来。

        首先，玩dubbo先得看看他的基本原理，请自行移到官网，讲的挺清楚的。我这里不写了，我就从搭建注册中心zk开始吧。没错，这个是推荐的注册中心，自己的也不是不可以用，但是我们这种渣渣还是听话点比较好。

        下载，解压（tar -zxvf）安转，没什么说的。然后，我们就该为它配置点东西了，注册中心嘛，注册的地址放在哪里呢，没错，其实它的配置也有，不过我建议还是在安装目录中加一个data目录放置注册地址，然后加一个log放置日志。之后进入到conf目录中，有个有意思的东西，zoo_sample.cfg,初看之下，这个不就是配置文件吗，没错，就是他，直接改？nono，这个其实我是例子或者说样板，或者说就是用来让你修改的文件，但是名字不能使用这个。所以自己复制一份，然后命名为zoo.cfg，现在就可以动手修改了，刚刚不是mikdir 了两个文件夹嘛，配置进去即可。不过dataDir是data的目录，自己再写一个dataLogDir的目录信息。其他的不用动，然后出来启动，ok，单机版zookeeper就启动了。集群其实就是复制，然后修改一下配置即可。

        然后搭建product（服务提供方），配置文件application（名字） -> registry（注册中心，刚刚搭建的，配置上地址和端口，声明zookeeper即可） ->protocol （本服务的地址和端口）-> service（暴露的服务，也就是接口），然后实现类的bean可以使用注解也可以在这里配置一个bean标签。ok，容器启动，没事可以看看日志，就可以看到dubbo的启动和注册的地址了。这里可以看到url就是host+ 端口 +　接口全路径，而在服务提供方又实现了此接口，根据id可以找到实现类，于是乎，服务方就完成了。它在注册的时候就会把自己所拥有的所有的方法列表一起上报。

        然后搭建consumer（服务消费方），同样的配置，同样是application->registry->reference(这个稍微说一下，这里需要注明接口 +id和提供方的ref一致+url就是服务方的host和端口)，这样就可以建立通讯了。

        (先不写了，感冒头疼。。歇一会。)

        好了，今天把最后一点写完，刚好自己写了几行代码，真的，就是几行，关于基于接口调用和基于接口实现类调用的两种方式 https://github.com/1581501186/BaseInterfaceWithNoImpl；

        如果说今天最大的收获，我一定会说就是最后的这几行代码。因为之前一直想不明白，配置的全部都是接口，url传递的也是接口（还有url是怎么传递的，为什么调用方法，传递的是url，这些都是哪里配置的，我也终于想通了，原来消费端和生产端都是代理，生产端也是通过代理内部拼接url，消费端同样是拼接url，数据传输全部通过pojo，所以也只有pojo实现序列化接口就可以了），那么到底是怎么反射创建对象的呢，总不能创建接口吧。然后折腾了一下午，终于，把这几行代码写完了就明白了。也明白了为何框架都有一堆的handler了。代理，没错，都是动态代理的缘故。有意思。

        没了，反正就当做笔记，自己看得懂就可以了。。。以后我技术更进一步，我会开始分享，现在的文章基本上都是为了记笔记。

    注意：1、dubbo的使用，数据交互是通过pojo封装对象信息传输的，也就是消费方调用什么方法，在服务方调用计算完成之后，以pojo封装之后传递的，这样cpu的压力在服务方。

    2、dubbo的pojo需要在tcp协议传输，所以序列化接口必须实现，不然后续的object流是读不出来的。

    3、dubbo的url中，路径可以理解成就是实现类的全路径，后续通过反射创建对象，而url的参数就是方法名和方法的参数，这样就可以在交互中定位到类和方法了，然后后续的过程就不用解释了。