架構(gòu)：第七章：基于Dubbo+Zookeeper項(xiàng)目架構(gòu)

Dubbo:

簡(jiǎn)單的介紹一下Dubbo？(Dubbo是什么)

dubbo就是個(gè)服務(wù)調(diào)用的東東。

為什么怎么說呢？

因?yàn)镈ubbo是由阿里開源的一個(gè)RPC分布式框架

那么RPC是什么呢？

就是不同的應(yīng)用部署到不同的服務(wù)器上，應(yīng)用之間想要調(diào)用沒有辦法直接調(diào)用，因?yàn)椴辉谝粋€(gè)內(nèi)存空間，需要通過網(wǎng)絡(luò)通訊來調(diào)用，或者傳達(dá)調(diào)用的數(shù)據(jù)。而且RPC會(huì)將遠(yuǎn)程調(diào)用的細(xì)節(jié)隱藏起來，讓調(diào)用遠(yuǎn)程服務(wù)像調(diào)用本地服務(wù)一樣簡(jiǎn)單。

dubbo的架構(gòu)有哪些？

主要有五個(gè)角色/核心組件，分為是Container（容器）、Provider（服務(wù)的提供方）、Registry（注冊(cè)中心）、Consumer（服務(wù)的消費(fèi)方）、Monitor（監(jiān)控中心）。

       

 

     

容器：

主要負(fù)責(zé)啟動(dòng)、加載、運(yùn)行服務(wù)提供者；

1.服務(wù)提供者在啟動(dòng)時(shí)：向注冊(cè)中心注冊(cè)自己提供的服務(wù)；服務(wù)消費(fèi)者向注冊(cè)中心訂閱自己的服務(wù)；

2.注冊(cè)中心返回服務(wù)提供者列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送變更數(shù)據(jù)給消費(fèi)者；

3.對(duì)于服務(wù)消費(fèi)者，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另外一臺(tái)調(diào)用；

4.服務(wù)消費(fèi)者和提供者，在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間，定時(shí)每分鐘發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心；

注冊(cè)中心：

注冊(cè)中心只負(fù)責(zé)地址的注冊(cè)和查找，相當(dāng)于我們的目錄服務(wù)，只有在容器啟動(dòng)時(shí)，服務(wù)提供者和調(diào)用者與注冊(cè)中心交互，整個(gè)過程，注冊(cè)中心不參與數(shù)據(jù)傳輸，不轉(zhuǎn)發(fā)請(qǐng)求，壓力較小 （“兩不一小”）；

注冊(cè)中心宕機(jī)問題：

    注冊(cè)中心會(huì)部署集群

1.如果集群中的任意一臺(tái)宕機(jī)之后，將自動(dòng)切換到另外一臺(tái)，不會(huì)影響已運(yùn)行的提供者和消費(fèi)者；

2.如果集群中所有注冊(cè)中心全部宕機(jī)之后，服務(wù)提供者和服務(wù)消費(fèi)者仍能通過本地緩存通訊；   

3.數(shù)據(jù)庫宕機(jī)后，注冊(cè)中心仍能通過緩存提供服務(wù)列表查詢，但不能注冊(cè)新服務(wù)；

監(jiān)控中心：

監(jiān)控中心負(fù)責(zé)統(tǒng)計(jì)各服務(wù)調(diào)用次數(shù)、調(diào)用時(shí)間等，統(tǒng)計(jì)先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務(wù)器，并以報(bào)表展示

監(jiān)控中心宕機(jī)不影響使用，只是丟失部分的采樣數(shù)據(jù)；

dubbo-admin可以通過監(jiān)控中心的可視化界面，進(jìn)行禁止服務(wù)和截止消費(fèi)者（大量惡意訪問的ip）；

服務(wù)提供者：

1.服務(wù)提供者出現(xiàn)宕機(jī)，如果任意一臺(tái)宕機(jī)，由于服務(wù)提供者沒有狀態(tài)，不影響使用；

2.如果所有的服務(wù)提供者全部宕機(jī)之后，服務(wù)消費(fèi)者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復(fù)；

3.服務(wù)提供者出現(xiàn)變更，比如增加新的機(jī)器部署，注冊(cè)中心基于長(zhǎng)連接將推送服務(wù)提供者信息給消費(fèi)者；

Dubbo在項(xiàng)目中怎么用的？

1.dubbo在項(xiàng)目中主要用來實(shí)現(xiàn)不同系統(tǒng)之間的服務(wù)調(diào)用。

2.由于項(xiàng)目是按照不同的功能分了不同的系統(tǒng)，按照三層架構(gòu)又分了不同的服務(wù)，其中

3.三層架構(gòu)中的控制層作為服務(wù)的消費(fèi)方，業(yè)務(wù)層和持久層共同作為服務(wù)的發(fā)布方。

這樣的架構(gòu)實(shí)現(xiàn)了系統(tǒng)的服務(wù)化，提高了開發(fā)效率，實(shí)現(xiàn)了業(yè)務(wù)的解耦。

3．Dubbo都支持什么協(xié)議？這些協(xié)議有什么不同點(diǎn)？項(xiàng)目使用的是什么協(xié)議？

Dubbo支持Dubbo協(xié)議、RMI協(xié)議、hessian協(xié)議、Http協(xié)議等

    Dubbo協(xié)議：缺省協(xié)議、采用了單一長(zhǎng)連接和NIO異步通訊、使用線程池并發(fā)處理請(qǐng)求，能減少握手和加大并發(fā)效率、采用的是Hession二進(jìn)制序列化、性能較好，推薦使用。  

主要應(yīng)用于傳入傳出參數(shù)數(shù)據(jù)包較?。ńㄗh小于100K），消費(fèi)者比提供者個(gè)數(shù)多，由于是單一連接，因?yàn)楸M量不要傳輸大文件。

    RMI協(xié)議：采用JDK標(biāo)準(zhǔn)的RMI協(xié)議（基于TCP協(xié)議）、堵塞式短連接、JDK標(biāo)準(zhǔn)序列化方式、同步通訊。適用于消費(fèi)者和提供者個(gè)數(shù)差不多的，可傳文件。測(cè)試發(fā)現(xiàn)偶爾會(huì)連接失敗，需要重建Stub。

    Hessian協(xié)議：采用http通訊，采用Servlet暴露服務(wù)，多連接短連接的同步傳輸方式，采用hessian的二進(jìn)制序列化，適合提供者比消費(fèi)者多。

    項(xiàng)目中使用的是默認(rèn)Dubbo協(xié)議（其他兩種簡(jiǎn)單的知道就行），因?yàn)轫?xiàng)目的特點(diǎn)主要是并發(fā)大、消費(fèi)者要比提供者多。
Zookeeper:

簡(jiǎn)單介紹一下zookeeper?

1.Zookeeper是Apache Hadoop的一個(gè)子項(xiàng)目，作為分布式協(xié)調(diào)作用（類似于我們的大腦），樹形的目錄結(jié)構(gòu)，支持變更操作，同時(shí)也是Dubbo官方推薦的注冊(cè)中心。

2.Zookeeper之所以能用來作為dubbo的注冊(cè)中心來使用，主要是應(yīng)用到dubbo的命名功能。3.在SOA架構(gòu)、集群和分布式環(huán)境下，子項(xiàng)目之間的調(diào)用關(guān)系會(huì)變得越來越復(fù)雜，因?yàn)樾枰粋€(gè)服務(wù)器專門給我們管理服務(wù)的信息和調(diào)節(jié)、管理這些服務(wù)，讓我們的側(cè)重點(diǎn)放在項(xiàng)目中的業(yè)務(wù)上，因?yàn)閦ookeeper的命名功能就可以充當(dāng)這樣一個(gè)服務(wù)器。

項(xiàng)目中主要用zookeeper作為Dubbo的注冊(cè)中心，集中管理所有服務(wù)的URL；同時(shí)集中的管理集群的配置。

Zookeeper的實(shí)現(xiàn)原理？（工作原理）

Zookeeper會(huì)維護(hù)一個(gè)類似于標(biāo)準(zhǔn)的文件系統(tǒng)的具有層次關(guān)系的數(shù)據(jù)結(jié)構(gòu)。這個(gè)文件系統(tǒng)中每個(gè)子目錄項(xiàng)都被稱為znode節(jié)點(diǎn)，這個(gè)znode節(jié)點(diǎn)也可以有子節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都可以存儲(chǔ)數(shù)據(jù)，客戶端也可以對(duì)這些node節(jié)點(diǎn)進(jìn)行g(shù)etChildren，getData,exists方法，同時(shí)也可以在znode tree路徑上設(shè)置watch（類似于監(jiān)聽），當(dāng)watch路徑上發(fā)生節(jié)點(diǎn)create、delete、update的時(shí)候，會(huì)通知到client。client可以得到通知后，再獲取數(shù)據(jù)，執(zhí)行業(yè)務(wù)邏輯操作。Zookeeper 的作用主要是用來維護(hù)和監(jiān)控存儲(chǔ)的node節(jié)點(diǎn)上這些數(shù)據(jù)的狀態(tài)變化，通過監(jiān)控這些數(shù)據(jù)狀態(tài)的變化，從而達(dá)到基于數(shù)據(jù)的集群管理。

為什么要用zookeeper作為dubbo的注冊(cè)中心？能選擇其他的嗎？

Zookeeper的數(shù)據(jù)模型是由一系列的Znode數(shù)據(jù)節(jié)點(diǎn)組成，和文件系統(tǒng)類似。

zookeeper的數(shù)據(jù)全部存儲(chǔ)在內(nèi)存中，性能高；

zookeeper也支持集群，實(shí)現(xiàn)了高可用；

同時(shí)基于zookeeper的特性，也支持事件監(jiān)聽（服務(wù)的暴露方發(fā)生變化，可以進(jìn)行推送），所以zookeeper適合作為dubbo的注冊(cè)中心區(qū)使用。

redis、Simple也可以作為dubbo的注冊(cè)中心來使用。

Redis:

用key-value（Hash）來存儲(chǔ)數(shù)據(jù)

主key:服務(wù)器名和類型

Map中的key：url地址

Map中的value：過期時(shí)間，判斷臟數(shù)據(jù)，臟數(shù)據(jù)由監(jiān)控中心刪除（要求服務(wù)器時(shí)間必須相同）

利用redis中的Publish/Subscribe事件通知數(shù)據(jù)變更

總之，redis作為注冊(cè)中心來使用的話，支持集群，性能高，但是要求所有服務(wù)器的時(shí)間必須同步，要求較高。（redis作為注冊(cè)中心來使用，有的公司也在采用）

Simple：

本身就是一個(gè)普通的dubbo服務(wù)，能減少第三方依賴，不支持集群，不適合生產(chǎn)環(huán)境。

項(xiàng)目中主要用zookeeper做了什么？（作用）

作為注冊(cè)中心用；

主要是在服務(wù)器上搭建zookeeper，其次在spring管理的dubbo的配置文件中配置（暴露方和消費(fèi)方都需要配置）