dubbo註冊中心掛掉後，dubbo會立即掛掉嗎？搞個環境，test

1、安裝jdk
2、安裝nohup（yum install coreutils 可以讓zookeeper在後臺執行）
3、安裝zookeeper
4、dubbo client server 分別配置zookeeper
5、在zookeeper後臺檢視dubbo的providers 和consumers
6、kill掉zookeeper
7、test結果
8、dubbo原理

首先uname -a檢視linux系統是64位的

Linux xhf_cloud 2.6.32-696.10.2.el6.x86_64 #1 SMP Tue Sep 12 14:33:29 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
 

1、jdk安裝
centos6安裝jdk8 （很詳細傻瓜式linux安裝jdk8以及配置環境變數）:
https://tecadmin.net/install-java-8-on-centos-rhel-and-fedora/#
2、zookeeper安裝
http://linuxsogood.org/1478.html （可以搭建單機的或者偽叢集的都可以,但是dubbo必須使用zookeeper叢集, 版本zookeeper 3.5.3beta）
3、啟動zookeeper
分別啟動三個zookeeper節點
nohup /usr/local/zookeeper1/bin/zkServer.sh start >> /data/zookeeper/1/logs/zookeeper1.logs 2>&1 &

nohup /usr/local/zookeeper2/bin/zkServer.sh start >> /data/zookeeper/2/logs/zookeeper2.logs 2>&1 &

nohup /usr/local/zookeeper3/bin/zkServer.sh start >> /data/zookeeper/3/logs/zookeeper3.logs 2>&1 &

5、在zookeeper後臺檢視dubbo的providers 和consumers
ls / ：檢視根目錄
可以每一層的通過/來檢視
ls /dubbo/hf.dubbo.service.ServiceMethod/providers : 檢視提供者
ls /dubbo/hf.dubbo.service.ServiceMethod/consumers :檢視消費者(ip已用*號代替)

[dubbo%3A%2F%2F169.**4.**.**%3A10181%2Fhf.dubbo.service.ServiceMethod%3Fanyhost%3Dtrue%26application%3Ddubbo-serviced-demo%26dubbo%3D2.5.3%26interface%3Dhf.dubbo.service.ServiceMethod%26methods%3DdelProject%26pid%3D10120%26side%3Dprovider%26timestamp%3D1513696064119]
[consumer%3A%2F%2F169.**.**.**%2Fhf.dubbo.service.ServiceMethod%3Fapplication%3Ddubbo-client-demo%26category%3Dconsumers%26check%3Dfalse%26dubbo%3D2.5.3%26interface%3Dhf.dubbo.service.ServiceMethod%26methods%3DdelProject%26pid%3D5888%26side%3Dconsumer%26timestamp%3D1513697163082]

啟動dubbo providers端(程式碼中的main函式)後, 啟動consumers端, 可以看到呼叫成功:

呼叫遠端service已經完畢,專案id是:66
呼叫遠端service已經完畢,專案id是:66
呼叫遠端service已經完畢,專案id是:66
呼叫遠端service已經完畢,專案id是:66
呼叫遠端service已經完畢,專案id是:66

6、kill掉zookeeper
kill 8639 8761 8692
kill掉全部的zookeeper節點, 此時看到我們的後臺, consumers仍然可以呼叫providers成功, 但是會報錯,如下

呼叫遠端service已經完畢,專案id是:66
WARN  - ClientCnxn                 - Session 0x2001487c62c0000 for server www.codingfuns.com/108.61.160.203:2182, unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused: no further information
    at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
    at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
    at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
    at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
INFO  - ClientCnxn                 - Opening socket connection to server www.codingfuns.com/108.61.160.203:2182. Will not attempt to authenticate using SASL (unknown error)

7、test結果
觀察一段時間, 就會發現, 大概10min左右, consumers就呼叫同provider了,從中我們發現, 當zookeeper down掉後, dubbo服務並沒有立即停掉, 這是為什麼呢? 與dubbo的原理有關,可以檢視dubbo的原始碼, 大概意思是:

提供者斷開時，此時consumer只有這個provider提供服務，則不可以遠端呼叫；註冊中心斷開時，消費者還可以通過本地快取的provider列表進行通訊，但是不能進行新服務的註冊與訂閱。

8、dubbo原理
1) 序列化與反序列化
java序列化不多解釋了，dubbo中物件的傳輸是以二進位制流的方式，提供了dubbo、java、json、hessian、nativejava多種序列化支援。

public ObjectOutput serialize(URL url, OutputStream out) throws IOException { 
        return new GenericObjectOutput(out); 
    } 
public ObjectInput deserialize(URL url, InputStream is) throws IOException { 
        return new GenericObjectInput(is); 
} 

2）編碼解碼
NIO中的資料傳輸是通過快取器ByteBuffer進行讀寫，而Netty使用的是ChannelBuffer快取器。Dubbo在使用Netty通訊時，沒有直接使用ChannelBuffer資料結構，而是使用Request、Response，而NIO不能識別此資料結構，所以需要編碼和解碼，所以需要編碼和解碼，這個過程可以說是快取器ChannelBuffer與物件之間的轉化。
3)dubbo中消費者、提供者、註冊中心聯通性。
dubbo有四種註冊中心(multicast zookeeper redis simple)推薦用zookeeper, 這裡也只是說dubbo和zookeeper的原理.
如下圖所示:

3.1）三者之間是長連線，provider、consumers一般只是初始化時與註冊中心互動或者服務變更時。

3.2）provider斷開後，consumers會馬上檢測斷開事件，並且關閉與provider之間的連線。

註冊中心也會檢測到斷開事件，並且馬上斷開連線，通過ondisconnect方法消除消費者註冊中心的所有服務。

可以檢視一下zookeeper節點，provider已經不存在，而consumers節點為空。

[zk: localhost:2181(CONNECTED) 0] ls /dubbo/hf.dubbo.service.ServiceMethod/consumers
[]

3.3）註冊中心通知consumers重新比對provider列表，c**onsumers也會多次重連provider、provider也會重複註冊。或由心跳機制探測後重連註冊中心（心跳機制是為了防止發生意外斷線而consumers無法檢測FIN事件，從而無法重新連線**，也無法感知註冊中心是否真存活）

3.4）註冊中心斷開後，provider與consumers會馬上檢測到斷開事件，並且關閉與註冊中心的連線，由心跳機制完成重連註冊中心。
provider與consumers會收集所有註冊的服務與所有訂閱的服務到失敗列表，進行重新註冊與訂閱。

3.5）提供者斷開時，此時consumer只有這個provider提供服務，則不可以遠端呼叫；註冊中心斷開時，消費者還可以通過本地快取的provider列表進行通訊，但是不能進行新服務的註冊與訂閱。

3.6) 當provider、consumers、註冊中心之間無法檢測中斷開事件時（如：網路斷線、網路抖動等），可以通過心跳機制探測連線是否可用，若不可用，提供者端執行斷開連線操作、消費者端執行重連操作、註冊中心也會進行服務的銷燬操作。

總結:
不要想著一下子全都搞懂，一下子全都搞懂本身就是不對的。知識需要碰撞，以及“日久生情”。