通過前面兩篇文章的介紹，相信讀者已經可以將apache thrift應用到實際工作中，並且理解了為什麼apache thrift的效能要比大多數rpc框架優秀。但如果您使用過apache thrift，那麼相信您會發現它的一些不足（或者說是所有單純的rpc框架的不足）：
顯然以上這些問題，單純使用apache thrift（或者單純的某一款rpc框架）是無法解決的；使用人工的方式就更不要想解決了。如果您的相關系統只有2-3個，又或者每個系統的服務節點數量也不多（例如5、6個），那麼以上這些問題還不太明顯。但是隨著您的系統越來越大，系統間協作越來越複雜，那麼這些問題就會凸現出來，甚至成為影響您架構擴容的顯著問題。
解決這個問題的方式，阿里的做法是在眾多系統的rpc通訊的上層再架一層專門進行rpc通訊的協調管理，稱之為服務治理框架（dubbo框架，目前這個框架已經開源，在後面的文章中，我會花比較大的篇幅進行介紹。和dubbo框架類似的還有taobao的hsf）。事實上現在的軟體架構中，都是使用相似的「服務治理」思想，來解決這個問題的。如下圖所示：
當服務提供者能夠向外部系統提供呼叫服務時（無論這個呼叫服務是基於rpc的還是基於http的，一般來說前者居多），它會首先向「服務管理元件」註冊這個服務，包括服務名、訪問許可權、優先順序、版本、引數、真實訪路徑、有效時間等等基本資訊。
當某乙個服務使用者需要呼叫服務時，首先會向「服務管理元件」詢問服務的基本資訊。當然「服務管理元件」還會驗證服務使用者是否有許可權進行呼叫、是否符合呼叫的前置條件等等過濾。最終「服務管理元件」將真實的服務提供者所在位置返回給服務使用者。
服務使用者拿到真實服務提供者的基本資訊、呼叫許可權後，再向真實的服務提供者發出呼叫請求，進行正式的業務呼叫過程。
在服務治理的思想中，包含幾個重要元素：
為了更深入理解服務治理框架的作用、工作原理，下面我們就以apache thrift為服務治理框架基礎技術，來實現乙個簡單的服務治理框架。為了保證快速實現，我們使用zookeeper作為服務管理元件的基礎技術（如果您不清楚zookeeper的相關技術點，可以參考我另外的幾篇文章《hadoop系列：zookeeper（1）——zookeeper單點和集群安裝》、《hadoop系列：zookeeper（2）——zookeeper核心原理（選舉）》、《hadoop系列：zookeeper（3）——zookeeper核心原理（事件）》）。下圖為簡單的工作原理：
zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，是hadoop和hbase的重要元件。這裡我們使用zookeeper共享「已註冊的服務」。為了保證所有服務提供者都能夠向zookeeper註冊提供的服務，我們需要在zookeeper上確定乙個 服務提供者和服務使用者 協商一致的「服務描述格式」。
要設計這個「服務描述格式」，首先就要清楚zookeeper是如何記錄資訊的。由於我在其他文章中，已經詳細講解過zookeeper的資訊記錄方式了，所以這裡就只進行一些關鍵要素的講解：
那麼按照zookeeper的這些工作特點，我們對「服務描述格式」的結構進行了如下圖所示的設計：
apache thrift的基本使用這裡就不再贅述了，如果您對apache thrift的基本使用還不清楚，請檢視前文。對於apache thrift的使用，在我們這個自行設計的服務治理框架中，要解決的重要問題，就是保證做到新增乙個服務時，不需要重新改變idl定義，不需要重新生成**。
這個問題主要的解決思路就是將apache thrift的介面定義進行泛化，即這個介面不呼叫具體的業務，而只給出呼叫者需要呼叫的介面名稱（包括引數），然後在伺服器端，以反射的進行具體服務的呼叫。idl檔案進行如下的定義：
# 這個結構體定義了服務呼叫者的請求資訊
struct request
# 這個結構體，定義了服務提供者的返回資訊
struct reponse
# 異常描述定義，當服務提供者處理過程出現異常時，向服務呼叫者返回
exception serviceexception
# 這個列舉結構，描述各種服務提供者的響應**
enum rescode
# 這個列舉結構，描述各種服務提供者的異常種類
enum exccode
# 這是經過泛化後的apache thrift介面
service diyframeworkservice
基於zookeeper的服務管理器，最重要的就是zookeeper中的目錄結構如何設計的問題，這個問題在前文中已經講得比較清楚，無須贅述了；為跨語言準備的idl描述檔案，以及為什麼這樣設計idl描述也已經在上文中講清楚了；那麼對於服務呼叫者來說，最主要的就是兩步呼叫過程：先查詢zookeeper服務管理器，找到要呼叫的服務位址，然後請求具體服務，基本上是比較簡單的，無需花很長的篇幅說明設計思路；
那麼要說清楚整個「服務治理」框架的設計思路，最主要的還是說清楚服務提供者的設計思路。因為基本上所有業務過程、事件監聽呼叫，都發生在服務提供者這一端。
下圖表達了服務提供者的軟體結構設計思路：
從上圖可以看到，整個服務端的設計分為三層：
這裡我們提供的示例設計，是為了讓各位讀者了解「服務治理」的基本設計原理。我們目前介紹的示例如果要應用到實際工作中，那麼還需要按照讀者自己的業務特點進行調整、修改甚至是重新設計。對於這個示例提供的功能來說，我們提供一些簡單的，具有代表意義的就可以了：
以上兩種類簡圖和附帶的說明，已經把示例工程中重要的設計詳情進行了描述。當然工程中還有其他類，但是它們主要還是起輔助作用。例如工具類：jsonutils、dateutils；自定義異常：bizexception；響應**：responsecode；應用程式啟動類：mainprocessor；這些我們將在下文具體**中進行講解。
golang學習之rpc例項
rpc 遠端過程呼叫 可以像呼叫本地程式一樣呼叫遠端服務，rpc分為http方式和tcp連線方式，使用http的rpc呼叫如下 首先是server端 正在監聽8888埠 然後是client端 rpc client project main.go package main import fmt net...
對python呼叫RPC介面的例項詳解
要呼叫rpc介面，python提供了乙個框架grpc，這是google開源的 程式設計客棧 basic python.html 需要安裝的python包如下 1.grpc安裝 pip install grpcio 2.grpc的python protobuf相關的編譯工具 pip install g...
RPC通訊 定義RPC介面
1，生成空的idl檔案 使用vs2013自帶的命令列，定位到專案資料夾下，執行 uuidgen i oidlfile.idl 注意 o和idlfile.idl之間沒有空格。這樣會生成乙個idlfile.idl檔案，其中帶有uuid，和乙個預設介面。如 uuid 2639b681 859a 40dc ...