• 資料釋出與訂閱（配置中心）
• 負載均衡
• 命名服務(Naming Service)
• 分散式通知/協調
• 叢集管理與Master選舉
• 分散式鎖
• 分散式佇列

一些線上系統在執行中，需要在不停止程式的情況下能夠動態調整某一個變數的值並且能夠及時生效。特別是當部署了多臺應用伺服器的時候，需要能夠做到在一臺機器上修改配置檔案，然後在同步到所有應用伺服器。這時候使用ZooKeeper來實現就很合適了。

ZooKeeper是一個高可用的分散式資料管理與系統協調框架。基於對Paxos演算法的實現，使該框架保證了分散式環境中資料的強一致性，也正是基於這樣的特性，使得ZooKeeper解決很多分散式問題。網上對ZK的應用場景也有不少介紹，本文將結合作者身邊的專案例子，系統地對ZK的應用場景進行一個分門歸類的介紹。

值得注意的是，ZK並非天生就是為這些應用場景設計的，都是後來眾多開發者根據其框架的特性，利用其提供的一系列API介面（或者稱為原語集），摸索出來的典型使用方法。因此，也非常歡迎讀者分享你在ZK使用上的奇技淫巧。

ZooKeeper典型應用場景一覽資料釋出與訂閱（配置中心）

釋出與訂閱模型，即所謂的配置中心，顧名思義就是釋出者將資料釋出到ZK節點上，供訂閱者動態獲取資料，實現配置資訊的集中式管理和動態更新。例如全域性的配置資訊，服務式服務框架的服務地址列表等就非常適合使用。

• 應用中用到的一些配置資訊放到ZK上進行集中管理。這類場景通常是這樣：應用在啟動的時候會主動來獲取一次配置，同時，在節點上註冊一個Watcher，這樣一來，以後每次配置有更新的時候，都會實時通知到訂閱的客戶端，從來達到獲取最新配置資訊的目的。
  
• 分散式搜尋服務中，索引的元資訊和伺服器叢集機器的節點狀態存放在ZK的一些指定節點，供各個客戶端訂閱使用。
  
• 分散式日誌收集系統。這個系統的核心工作是收集分佈在不同機器的日誌。收集器通常是按照應用來分配收集任務單元，因此需要在ZK上建立一個以應用名作為path的節點P，並將這個應用的所有機器ip，以子節點的形式註冊到節點P上，這樣一來就能夠實現機器變動的時候，能夠實時通知到收集器調整任務分配。
  
• 系統中有些資訊需要動態獲取，並且還會存在人工手動去修改這個資訊的發問。通常是暴露出介面，例如JMX介面，來獲取一些執行時的資訊。引入ZK之後，就不用自己實現一套方案了，只要將這些資訊存放到指定的ZK節點上即可。
  
  

注意：在上面提到的應用場景中，有個預設前提是：資料量很小，但是資料更新可能會比較快的場景。

負載均衡

這裡說的負載均衡是指軟負載均衡。在分散式環境中，為了保證高可用性，通常同一個應用或同一個服務的提供方都會部署多份，達到對等服務。而消費者就須要在這些對等的伺服器中選擇一個來執行相關的業務邏輯，其中比較典型的是訊息中介軟體中的生產者，消費者負載均衡。

訊息中介軟體中釋出者和訂閱者的負載均衡，linkedin開源的KafkaMQ和阿里開源的metaq都是通過zookeeper來做到生產者、消費者的負載均衡。這裡以metaq為例如講下：

• 生產者負載均衡：metaq傳送訊息的時候，生產者在傳送訊息的時候必須選擇一臺broker上的一個分割槽來發送訊息，因此metaq在執行過程中，會把所有broker和對應的分割槽資訊全部註冊到ZK指定節點上，預設的策略是一個依次輪詢的過程，生產者在通過ZK獲取分割槽列表之後，會按照brokerId和partition的順序排列組織成一個有序的分割槽列表，傳送的時候按照從頭到尾迴圈往復的方式選擇一個分割槽來發送訊息。
  

• 消費負載均衡：

  在消費過程中，一個消費者會消費一個或多個分割槽中的訊息，但是一個分割槽只會由一個消費者來消費。MetaQ的消費策略是：

  • 每個分割槽針對同一個group只掛載一個消費者。
  • 如果同一個group的消費者數目大於分割槽數目，則多出來的消費者將不參與消費。
  • 如果同一個group的消費者數目小於分割槽數目，則有部分消費者需要額外承擔消費任務。
    
  在某個消費者故障或者重啟等情況下，其他消費者會感知到這一變化（通過 zookeeper watch消費者列表），然後重新進行負載均衡，保證所有的分割槽都有消費者進行消費。
  
  

命名服務(Naming Service)

命名服務也是分散式系統中比較常見的一類場景。在分散式系統中，通過使用命名服務，客戶端應用能夠根據指定名字來獲取資源或服務的地址，提供者等資訊。被命名的實體通常可以是叢集中的機器，提供的服務地址，遠端物件等等——這些我們都可以統稱他們為名字（Name）。其中較為常見的就是一些分散式服務框架中的服務地址列表。通過呼叫ZK提供的建立節點的API，能夠很容易建立一個全域性唯一的path，這個path就可以作為一個名稱。

阿里巴巴集團開源的分佈式服務框架Dubbo中使用ZooKeeper來作為其命名服務，維護全域性的服務地址列表，點選這裡檢視Dubbo開源專案。在Dubbo實現中：

服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的釋出。

服務消費者啟動的時候，訂閱/dubbo/${serviceName}/providers目錄下的提供者URL地址， 並向/dubbo/${serviceName} /consumers目錄下寫入自己的URL地址。

注意，所有向ZK上註冊的地址都是臨時節點，這樣就能夠保證服務提供者和消費者能夠自動感應資源的變化。

另外，Dubbo還有針對服務粒度的監控，方法是訂閱/dubbo/${serviceName}目錄下所有提供者和消費者的資訊。

分散式通知/協調

ZooKeeper中特有watcher註冊與非同步通知機制，能夠很好的實現分散式環境下不同系統之間的通知與協調，實現對資料變更的實時處理。使用方法通常是不同系統都對ZK上同一個znode進行註冊，監聽znode的變化（包括znode本身內容及子節點的），其中一個系統update了znode，那麼另一個系統能夠收到通知，並作出相應處理

• 另一種心跳檢測機制：檢測系統和被檢測系統之間並不直接關聯起來，而是通過zk上某個節點關聯，大大減少系統耦合。
  
• 另一種系統排程模式：某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工作。管理人員在控制檯作的一些操作，實際上是修改了ZK上某些節點的狀態，而ZK就把這些變化通知給他們註冊Watcher的客戶端，即推送系統，於是，作出相應的推送任務。
  
• 另一種工作彙報模式：一些類似於任務分發系統，子任務啟動後，到zk來註冊一個臨時節點，並且定時將自己的進度進行彙報（將進度寫回這個臨時節點），這樣任務管理者就能夠實時知道任務進度。 總之，使用zookeeper來進行分散式通知和協調能夠大大降低系統之間的耦合
  
  

叢集管理與Master選舉

• 叢集機器監控：這通常用於那種對叢集中機器狀態，機器線上率有較高要求的場景，能夠快速對叢集中機器變化作出響應。這樣的場景中，往往有一個監控系統，實時檢測叢集機器是否存活。過去的做法通常是：監控系統通過某種手段（比如ping）定時檢測每個機器，或者每個機器自己定時向監控系統彙報“我還活著”。 這種做法可行，但是存在兩個比較明顯的問題：

  • 叢集中機器有變動的時候，牽連修改的東西比較多。
  • 有一定的延時。
    

  利用ZooKeeper有兩個特性，就可以實時另一種叢集機器存活性監控系統：

  • 客戶端在節點 x 上註冊一個Watcher，那麼如果 x?的子節點變化了，會通知該客戶端。
  • 建立EPHEMERAL型別的節點，一旦客戶端和伺服器的會話結束或過期，那麼該節點就會消失。
    
  例如，監控系統在 /clusterServers 節點上註冊一個Watcher，以後每動態加機器，那麼就往 /clusterServers 下建立一個 EPHEMERAL型別的節點：/clusterServers/{hostname}. 這樣，監控系統就能夠實時知道機器的增減情況，至於後續處理就是監控系統的業務了。
  

• Master選舉則是zookeeper中最為經典的應用場景了。 在分散式環境中，相同的業務應用分佈在不同的機器上，有些業務邏輯（例如一些耗時的計算，網路I/O處理），往往只需要讓整個叢集中的某一臺機器進行執行，其餘機器可以共享這個結果，這樣可以大大減少重複勞動，提高效能，於是這個master選舉便是這種場景下的碰到的主要問題。

  利用ZooKeeper的強一致性，能夠保證在分散式高併發情況下節點建立的全域性唯一性，即：同時有多個客戶端請求建立 /currentMaster 節點，最終一定只有一個客戶端請求能夠建立成功。利用這個特性，就能很輕易的在分散式環境中進行叢集選取了。

  另外，這種場景演化一下，就是動態Master選舉。這就要用到?EPHEMERAL_SEQUENTIAL型別節點的特性了。

  上文中提到，所有客戶端建立請求，最終只有一個能夠建立成功。在這裡稍微變化下，就是允許所有請求都能夠建立成功，但是得有個建立順序，於是所有的請求最終在ZK上建立結果的一種可能情況是這樣： /currentMaster/{sessionId}-1 ,?/currentMaster/{sessionId}-2 ,?/currentMaster/{sessionId}-3 ….. 每次選取序列號最小的那個機器作為Master，如果這個機器掛了，由於他建立的節點會馬上小時，那麼之後最小的那個機器就是Master了。

  在搜尋系統中，如果叢集中每個機器都生成一份全量索引，不僅耗時，而且不能保證彼此之間索引資料一致。因此讓叢集中的Master來進行全量索引的生成，然後同步到叢集中其它機器。另外，Master選舉的容災措施是，可以隨時進行手動指定master，就是說應用在zk在無法獲取master資訊時，可以通過比如http方式，向一個地方獲取master。

  在Hbase中，也是使用ZooKeeper來實現動態HMaster的選舉。在Hbase實現中，會在ZK上儲存一些ROOT表的地址和HMaster的地址，HRegionServer也會把自己以臨時節點（Ephemeral）的方式註冊到Zookeeper中，使得HMaster可以隨時感知到各個HRegionServer的存活狀態，同時，一旦HMaster出現問題，會重新選舉出一個HMaster來執行，從而避免了HMaster的單點問題
  
  

分散式鎖

分散式鎖，這個主要得益於ZooKeeper為我們保證了資料的強一致性。鎖服務可以分為兩類，一個是保持獨佔，另一個是控制時序。

• 所謂保持獨佔，就是所有試圖來獲取這個鎖的客戶端，最終只有一個可以成功獲得這把鎖。通常的做法是把zk上的一個znode看作是一把鎖，通過create znode的方式來實現。所有客戶端都去建立 /distribute_lock 節點，最終成功建立的那個客戶端也即擁有了這把鎖。
  
• 控制時序，就是所有檢視來獲取這個鎖的客戶端，最終都是會被安排執行，只是有個全域性時序了。做法和上面基本類似，只是這裡/distribute_lock 已經預先存在，客戶端在它下面建立臨時有序節點（這個可以通過節點的屬性控制：CreateMode.EPHEMERAL_SEQUENTIAL來指定）。Zk的父節點（/distribute_lock）維持一份sequence,保證子節點建立的時序性，從而也形成了每個客戶端的全域性時序。
  
  

分散式佇列

佇列方面，簡單地講有兩種，一種是常規的先進先出佇列，另一種是要等到佇列成員聚齊之後的才統一按序執行。對於第一種先進先出佇列，和分散式鎖服務中的控制時序場景基本原理一致，這裡不再贅述。

第二種佇列其實是在FIFO佇列的基礎上作了一個增強。通常可以在 /queue 這個znode下預先建立一個/queue/num 節點，並且賦值為n（或者直接給/queue賦值n），表示佇列大小，之後每次有佇列成員加入後，就判斷下是否已經到達佇列大小，決定是否可以開始執行了。這種用法的典型場景是，分散式環境中，一個大任務Task A，需要在很多子任務完成（或條件就緒）情況下才能進行。這個時候，凡是其中一個子任務完成（就緒），那麼就去 /taskList 下建立自己的臨時時序節點 （CreateMode.EPHEMERAL_SEQUENTIAL），當 /taskList 發現自己下面的子節點滿足指定個數，就可以進行下一步按序進行處理了。

　　Zookeeper是hadoop的一個子專案，雖然源自hadoop，但是我發現zookeeper脫離hadoop的範疇開發分散式框架的運用越來越多。今天我想談談zookeeper，本文不談如何使用zookeeper，而是zookeeper到底有哪些實際的運用，哪些型別的應用能發揮zookeeper的優勢，最後談談zookeeper對分散式網站架構能產生怎樣的作用。

　　Zookeeper是針對大型分散式系統的高可靠的協調系統。由這個定義我們知道zookeeper是個協調系統，作用的物件是分散式系統。為什麼分散式系統需要一個協調系統了？理由如下：

　　開發分散式系統是件很困難的事情，其中的困難主要體現在分散式系統的“部分失敗”。“部分失敗”是指資訊在網路的兩個節點之間傳送時候，如果網路出了故障，傳送者無法知道接收者是否收到了這個資訊，而且這種故障的原因很複雜，接收者可能在出現網路錯誤之前已經收到了資訊，也可能沒有收到，又或接收者的程序死掉了。傳送者能夠獲得真實情況的唯一辦法就是重新連線到接收者，詢問接收者錯誤的原因，這就是分散式系統開發裡的“部分失敗”問題。

　　Zookeeper就是解決分散式系統“部分失敗”的框架。Zookeeper不是讓分散式系統避免“部分失敗”問題，而是讓分散式系統當碰到部分失敗時候，可以正確的處理此類的問題，讓分散式系統能正常的執行。

　　下面我要講講zookeeper的實際運用場景：

　　場景一：有一組伺服器向客戶端提供某種服務（例如：我前面做的分散式網站的服務端，就是由四臺伺服器組成的叢集，向前端叢集提供服務），我們希望客戶端每次請求服務端都可以找到服務端叢集中某一臺伺服器，這樣服務端就可以向客戶端提供客戶端所需的服務。對於這種場景，我們的程式中一定有一份這組伺服器的列表，每次客戶端請求時候，都是從這份列表裡讀取這份伺服器列表。那麼這分列表顯然不能儲存在一臺單節點的伺服器上，否則這個節點掛掉了，整個叢集都會發生故障，我們希望這份列表時高可用的。高可用的解決方案是：這份列表是分散式儲存的，它是由儲存這份列表的伺服器共同管理的，如果儲存列表裡的某臺伺服器壞掉了，其他伺服器馬上可以替代壞掉的伺服器，並且可以把壞掉的伺服器從列表裡刪除掉，讓故障伺服器退出整個叢集的執行，而這一切的操作又不會由故障的伺服器來操作，而是叢集里正常的伺服器來完成。這是一種主動的分散式資料結構，能夠在外部情況發生變化時候主動修改資料項狀態的資料機構。Zookeeper框架提供了這種服務。這種服務名字就是：統一命名服務，它和javaEE裡的JNDI服務很像。

　　場景二：分散式鎖服務。當分散式系統操作資料，例如：讀取資料、分析資料、最後修改資料。在分散式系統裡這些操作可能會分散到叢集裡不同的節點上，那麼這時候就存在資料操作過程中一致性的問題，如果不一致，我們將會得到一個錯誤的運算結果，在單一程序的程式裡，一致性的問題很好解決，但是到了分散式系統就比較困難，因為分散式系統裡不同伺服器的運算都是在獨立的程序裡，運算的中間結果和過程還要通過網路進行傳遞，那麼想做到資料操作一致性要困難的多。Zookeeper提供了一個鎖服務解決了這樣的問題，能讓我們在做分散式資料運算時候，保證資料操作的一致性。

　　場景三：配置管理。在分散式系統裡，我們會把一個服務應用分別部署到n臺伺服器上，這些伺服器的配置檔案是相同的（例如：我設計的分散式網站框架裡，服務端就有4臺伺服器，4臺伺服器上的程式都是一樣，配置檔案都是一樣），如果配置檔案的配置選項發生變化，那麼我們就得一個個去改這些配置檔案，如果我們需要改的伺服器比較少，這些操作還不是太麻煩，如果我們分散式的伺服器特別多，比如某些大型網際網路公司的hadoop叢集有數千臺伺服器，那麼更改配置選項就是一件麻煩而且危險的事情。這時候zookeeper就可以派上用場了，我們可以把zookeeper當成一個高可用的配置儲存器，把這樣的事情交給zookeeper進行管理，我們將叢集的配置檔案拷貝到zookeeper的檔案系統的某個節點上，然後用zookeeper監控所有分散式系統裡配置檔案的狀態，一旦發現有配置檔案發生了變化，每臺伺服器都會收到zookeeper的通知，讓每臺伺服器同步zookeeper裡的配置檔案，zookeeper服務也會保證同步操作原子性，確保每個伺服器的配置檔案都能被正確的更新。

　　場景四：為分散式系統提供故障修復的功能。叢集管理是很困難的，在分散式系統里加入了zookeeper服務，能讓我們很容易的對叢集進行管理。叢集管理最麻煩的事情就是節點故障管理，zookeeper可以讓叢集選出一個健康的節點作為master，master節點會知道當前叢集的每臺伺服器的執行狀況，一旦某個節點發生故障，master會把這個情況通知給叢集其他伺服器，從而重新分配不同節點的計算任務。Zookeeper不僅可以發現故障，也會對有故障的伺服器進行甄別，看故障伺服器是什麼樣的故障，如果該故障可以修復，zookeeper可以自動修復或者告訴系統管理員錯誤的原因讓管理員迅速定位問題，修復節點的故障。大家也許還會有個疑問，master故障了，那怎麼辦了？zookeeper也考慮到了這點，zookeeper內部有一個“選舉領導者的演算法”，master可以動態選擇，當master故障時候，zookeeper能馬上選出新的master對叢集進行管理。

　　下面我要講講zookeeper的特點：

1. zookeeper是一個精簡的檔案系統。這點它和hadoop有點像，但是zookeeper這個檔案系統是管理小檔案的，而hadoop是管理超大檔案的。
2. zookeeper提供了豐富的“構件”，這些構件可以實現很多協調資料結構和協議的操作。例如：分散式佇列、分散式鎖以及一組同級節點的“領導者選舉”演算法。
3. zookeeper是高可用的，它本身的穩定性是相當之好，分散式叢集完全可以依賴zookeeper叢集的管理，利用zookeeper避免分散式系統的單點故障的問題。
4. zookeeper採用了鬆耦合的互動模式。這點在zookeeper提供分散式鎖上表現最為明顯，zookeeper可以被用作一個約會機制，讓參入的程序不在了解其他程序的（或網路）的情況下能夠彼此發現並進行互動，參入的各方甚至不必同時存在，只要在zookeeper留下一條訊息，在該程序結束後，另外一個程序還可以讀取這條資訊，從而解耦了各個節點之間的關係。
5. zookeeper為叢集提供了一個共享儲存庫，叢集可以從這裡集中讀寫共享的資訊，避免了每個節點的共享操作程式設計，減輕了分散式系統的開發難度。
6. zookeeper的設計採用的是觀察者的設計模式，zookeeper主要是負責儲存和管理大家關心的資料，然後接受觀察者的註冊，一旦這些資料的狀態發生變化，Zookeeper 就將負責通知已經在 Zookeeper 上註冊的那些觀察者做出相應的反應，從而實現叢集中類似 Master/Slave 管理模式。

　　由此可見zookeeper很利於分散式系統開發，它能讓分散式系統更加健壯和高效。

　　前不久我參加了部門的hadoop興趣小組，測試環境的hadoop、mapreduce、hive及hbase都是我來安裝的，安裝hbase時候安裝要預先安裝zookeeper，最早我是在四臺伺服器上都安裝了zookeeper，但是同事說安裝四臺和安裝三臺是一回事，這是因為zookeeper要求半數以上的機器可用，zookeeper才能提供服務，所以3臺的半數以上就是2臺了，4臺的半數以上也是兩臺，因此裝了三臺伺服器完全可以達到4臺伺服器的效果，這個問題說明zookeeper進行安裝的時候通常選擇奇數臺伺服器。在學習hadoop的過程中，我感覺zookeeper是最難理解的一個子專案，原因倒不是它技術負責，而是它的應用方向很讓我困惑，所以我有關hadoop技術第一篇文章就從zookeeper開始，也不講具體技術實現，而從zookeeper的應用場景講起，理解了zookeeper應用的領域，我想再學習zookeeper就會更加事半功倍。

　　之所以今天要談談zookeeper，也是為我上一篇文章分散式網站框架的補充。雖然我設計網站架構是分散式結構，也做了簡單的故障處理機制，比如：心跳機制，但是對叢集的單點故障還是沒有辦法的，如果某一臺伺服器壞掉了，客戶端任然會嘗試連線這個伺服器，導致部分請求的阻塞，也會導致伺服器資源的浪費。不過我目前也不想去修改自己的框架，因為我總覺得在現有的服務上新增zookeeper服務會影響網站的效率，如果有獨立的伺服器叢集部署zookeeper還是值得考慮的，但是伺服器資源太寶貴了，這個可能性不大。幸好我們部門也發現了這樣的問題，我們部門將開發一個強大的遠端呼叫框架，將叢集管理和通訊管理這塊剝離出來，集中式提供高效可用的服務，等部門的遠端框架開發完畢，我們的網站加入新的服務，我想我們的網站將會更加穩定和高效。

 哈哈，講了這麼久估計有童鞋可能有點煩了，不是說應用zookeeper的例項嗎？怎麼還沒見到zookeeper的影子。彆著急，zookeeper馬上就要上場了。

　　還是以我前面部落格裡寫分散式網站講起，服務端系統我們可以當做服務提供者，前端系統當做服務呼叫者，提供者可以類比商戶，呼叫者可以類比客戶，商戶和客戶可以直接進行交易，這種直接交易方式非常原始甚至還會有風險，現代社會商戶和客戶直接的交易十分高效，高效的原因是因為有一個規範的大市場，商戶和客戶的交易在市場裡進行的，這樣交易會變得更加安全和高效，我設計的分散式框架最大的特點就是提供了一個類似市場的角色，它來管理服務提供者和服務呼叫者，我把這個功能模組稱為遠端呼叫管理元件。

　　遠端呼叫管理元件是本框架的核心，它的主要作用是接收服務端提供者的註冊的通知，該通知一般是介面以及該介面的實現類還有伺服器的ip地址，管理元件會將這些通知記錄下來，並且根據配置對這些服務程式進行分組和標記，註冊好的資訊管理元件會將這些資訊推送到服務呼叫者。遠端呼叫管理元件還包含心跳機制，這個心跳機制是針對服務提供者，通過心跳機制檢測服務提供者的健康狀況，管理元件不會檢測服務呼叫者的健康狀態，因為這個沒必要，因為本框架的使用還是呼叫者直接去請求提供者，邏輯上是沒必要關心呼叫者的狀態，這和bs架構裡瀏覽器一樣，我們不會去關心瀏覽器使用者是不是存在。服務提供者、服務呼叫者和遠端呼叫管理元件的關係如下圖所示：

　　遠端呼叫框架執行的過程是：當服務提供者啟動時候，它會將自己的ip地址和註冊的方法傳輸到遠端呼叫管理元件，管理元件接收到註冊資訊會將這些資訊儲存下來，儲存技術就是使用zookeeper，儲存成功後，管理元件會將成功通知傳回給服務提供者，同時管理元件還會通過心跳檢測服務提供者是否健康；當服務呼叫者啟動時候，它會向管理元件請求服務提供者資訊，管理元件接收到請求後會將相關資訊推送給服務呼叫者。在實際系統執行時候，服務呼叫者直接和服務提供者進行通訊互動了，通訊方式是netty，如果呼叫者和提供者有相關變化，都會先通知服務管理元件，服務管理元件會將相關變更資訊推送給相應的系統。

　　遠端呼叫管理元件主要是通過zookeeper實現，zookeeper擁有一個層次的名稱空間，它的模型是一個樹狀結構，樹狀結構是一個強大的資料型別，它幾乎能儲存所有不同的資料型別，我們通過zookeeper將這些資訊儲存起來，便於我們管理整個遠端呼叫框架，同時zookeeper還是高可靠的，這個我在前面zookeeper文章裡講到了，這樣就保證了整個遠端呼叫框架的穩定性，實際應用中我們會將元件編譯成一個jar包，不同的專案直接引用這個jar包，這樣管理元件服務端和服務的提供者和呼叫者就聯絡起來。至於提供者和呼叫者的通訊機制是直接進行，因為我們將通訊程式整合在jar包裡，只不過相應的管理機制抽取到外部服務端進行統一管理。

　　這就是我設計的遠端呼叫框架，可惜的是，這個構思我還沒有真正實現過，今天拿出來是想體現zookeeper的實際應用，為我後面講解zookeeper做鋪墊，至於是否可行，看以後有沒有機會開發個類似的系統，到時估計還有很多意想不到的問題要解決。