本節介紹
前面我們介紹了Dubbo的基本使用，并且是使用的zookeeper作為其注冊中心，但是Dubbo在注冊中心存儲的内容到底是什麼呢？是什麼樣的結構呢？是持久化節點還是臨時節點呢？帶着這些疑問，我們對Dubbo在zookeeper中存儲的内容一探究竟。
準備工作
其實我們在之前的zookeeper的系列部落格中《(3)zookeeper常用指令及節點屬性介紹》，我們已經介紹了zookeeper的常用指令，我們可以通過zkCli.sh連接配接上zookeeper，然後通過 ls、get 等指令檢視zookeeper的節點資訊。這裡給大家介紹一個好用的工具，就是zookeeper的eclipse插件，通過這個插件我們可以更清楚的去檢視zookeeper的各個節點的關系及内容。
在我們啟動Duubo服務之前，連接配接上zookeeper叢集的任意一台機器 192.168.74.4，可以看到隻有 /zookeeper、/test 這兩個節點。
開始測試
啟動一台服務提供者
然後我們啟動Dubbo服務提供者，然後再檢視節點資訊：
可以看到多了一個/dubbo節點，而/dubbo節點下面有一個子節點，/dubbo/com.wkp.service.simple.SimpleService，通過節點名稱我們可以看到是我們暴露的接口名稱，如果暴露多個接口的話/dubbo下面會有多個子節點；
/dubbo/com.wkp.service.simple.SimpleService下面又有兩個子節點，分别是configurators和providers，而provider就是我們的服務提供者的注冊資訊，
configurators節點的内容是目前機器的ip位址
providers下面有個子節點名稱為"dubbo%3A%2F%2F169.254.68.252%3A20880%2Fcom.wkp.service.simple.SimpleService%3Fanyhost%3Dtrue%26application%3Dsimple-provider%26dubbo%3D2.0.2%26generic%3Dfalse%26interface%3Dcom.wkp.service.simple.SimpleService%26methods%3DsayHello%2CgetUsers%26pid%3D152624%26retries%3D0%26side%3Dprovider%26timestamp%3D1542812445986"，這明顯是被encode過，我們進行一下decode，得到内容為"dubbo://169.254.68.252:20880/com.wkp.service.simple.SimpleService?anyhost=true&application=simple-provider&dubbo=2.0.2&generic=false&inter，我們可以看到服務提供者的ip，端口号，暴露的接口，接口中有哪些方法，應用名，時間戳等資訊，如果有多個服務提供者會有多個節點。當有消費者啟動時，會訂閱這些服務提供者清單，通過負載均衡機制去通路其中一個服務提供者，當服務提供者變更或者下線了，服務消費者會得到對應的通知。
再啟動一台服務提供者
然後，我們可以改變一下simple-provider.xml中<dubbo:protocol name="dubbo" port="20990"/>的端口，由20880改為20990，接着運作Provider類又啟動了一個服務者，我們再觀察一下zookeeper的節點如下：很明顯，providers下面多了一個節點，也就是新的服務提供者的資訊。
啟動消費者
通過上面的方式我們看到了服務提供者的注冊資訊，下面我們啟動服務消費者，然後再觀察zookeeper的節點資訊
我們發現，com.wkp.service.simple.SimpleService節點下多了兩個節點，分别是consumers（服務消費者清單）和routers（服務路由，節點内容為目前機器ip）
consumers下面的子節點内容我們可以進行解碼得到"consumer://169.254.68.252/com.wkp.service.simple.SimpleService?application=simple-consumer&category=consumers&check=false&dubbo=2.0.2&inter，裡面是服務消費者的ip，調用的服務接口，接口包含的方法，時間戳等相關資訊。
如果啟動多個消費者的話，consumers節點下會有多個子節點，跟多個服務提供者的情況類似。
持久化節點？臨時節點？
上面我們已經看到了Dubbo服務在zookeeper上存儲的資料内容及結構，但是這些節點是持久化節點，還是臨時節點呢？下面我們來通過實驗驗證一下：
首先我們把所有服務消費者關掉，觀察zookeeper節點資訊：我們發現consumers節點下的子節點消失了
然後我們把服務提供者全部關掉，再觀察一下zookeeper節點資訊的變化：providers下面的子節點也消失了
得出結論：
1、dubbo節點、dubbo下面的接口、接口下面的providers、consumers、configurators、routers都是持久化節點
2、providers和consumers下面的URL子節點是臨時節點，這個其實就是運用了zookeeper的臨時節點的特效，消費端訂閱服務提供者的URL：當某個服務提供者出現當機，則會從providers下面的臨時子節點中消失，這個時候會通知訂閱了這個服務的消費者自己已經挂掉了，你把你本地存儲的可用的服務提供者清單更新一下，不要再調用我了；當增加服務提供者時，providers下面會增加臨時子節點，這個時候會通知訂閱了這個服務的消費者新增了服務提供者，你把你本地存儲的可用的服務提供者清單進行更新，有新的服務提供者可供調用了。
因為我是在本地運作的，ip都是同一個，你可以自己搭建虛拟機，看看如果在不同機器上部署服務提供者、消費者的話，configurators和routers的内容，因為我都是在一台機器上的，是以兩者的内容都是"169.254.68.252"（也就是我的機器ip）。
ZooKeeper當機之後，consumer和provider還能否通信？
可以。消費者從ZK擷取provider位址清單後，會在本地緩存一份。當ZK注冊中心所有節點全部宕掉之後，消費者可以使用本地緩存的服務清單和provider進行通信。
ZK的意義在于為consumer和provider提供服務位址的釋出/訂閱服務，讓消費者及時感覺最新的服務清單，consumer真正調用provider是通過某種通信協定直接調用，并不依賴ZK。
是以當zookeeper當機之後，不會影響消費者調用服務提供者，影響的是zookeeper當機之後如果提供者有變動，增加或者減少，zk無法把變更通知推送給consumer，consumer會因為感覺不到變更時間，不去拉取最新的服務清單，導緻本地緩存的服務清單有可能過時的。