初识zookeeper和Dubbo

       很多互联网公司的后台服务都是使用zookeeper+dubbo， zookeeper作为注册中心可以动态的添加或删除节点， dubbo实现了RPC访问。  

       一般的部署方式： 有3台以上设置部署相同的zookeeper，实现集群功能。 即使其中一台宕机，zookeeper仍然能正常运行； 同一个dubbo服务部署在多台设备上（提高并发性能）。

       zookeeper：https://zookeeper.apache.org

       dubbo：http://dubbo.io

      zookeeper分为单机模式和集群模式， 一般生产环境都是集群方式， 好处是一台集群宕机后，其它机器能及时顶替， 所谓的集群方式就是至少部署到3台机器上, 多个zookeeper实例中只有一个主服务(有且只有一个Leader)，其它是从服务（即Slave，被主服务调度）。

PS： zookeeper还提供了分布式锁功能， 可应用于抢单/秒杀等功能。

   下载zookeeper压缩包并运行其脚本打开或关闭服务。

standalone方式：

           

下载dubbo源码并修改demo配置文件，添加注册中心地址。

    <!-- <dubbo:registry address="multicast://224.5.6.7:1234?unicast=false"/> -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />

    <!-- <dubbo:registry address="multicast://224.5.6.7:1234?unicast=false"/> -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181" />

zookeeper伪集群方式：

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/Users/gaorui/Documents/Server/zookeeper-3.4.10_node3/data
clientPort=2181  #可变
dataLogDir=/Users/gaorui/Documents/Server/zookeeper-3.4.10_node3/log
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

 注意： clientPort是对外参数， 在单机伪集群方式下是可变的， 在多台机器部署时可以是默认的2181
 server.*这个数字实在dataDir目录下myid文件的内容， 创建方式：

touch myid
echo "1" > myid

     这里有坑，如果在图形化界面创建文件会因为权限问题无法打开myid文件。

按照说明：http://zookeeper.apache.org/doc/trunk/zookeeperStarted.html#sc_RunningReplicatedZooKeeper

         在本机上拷贝3份zookeeper代码， 并按照上面说明设置zoo.cfg和myid文件，并分别执行zkServer.sh start; 这样在一台电脑上就启动个zookeeper伪集群。

      修改dubbo配置文件注册中心为zookeeper集群方式 

    <!-- <dubbo:registry address="multicast://224.5.6.7:1234?unicast=false"/> -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183" />

    <!-- <dubbo:registry address="multicast://224.5.6.7:1234?unicast=false"/> -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183" />

        先运行dubbo demo的Provider，即向zookeeper注册dubbo服务； 然后运行Consumer，实现RPC访问。

      从dubbo示例代码看出， 生产者/消费者之间通过接口交互， API的函数实现对使用者透明， 让我想起了“面向接口编程”的思想。 

     公司/团队可以创建maven私服， 在私服内维护接口类jar， 保证使用者和开发者能够同步代码。

     就像上面例子中的sayHello函数， 消费者(调用方)不知道是哪个服务实现了它。