zabbix源碼安裝

❶ linux下怎麼安裝Go開發環境

一、Go安裝使用

1、下載Go源碼包
https://storage.googleapis.com/golang/go1.6.3.linux-amd64.tar.gz

上傳到/usr/local/src目錄下

2、編譯安裝Go到/usr/local
tar zxvf go1.6.3.linux-amd64.tar.gz -C /usr/local/

#註：必須使用root賬戶或者使用sudo來解壓縮Go源碼包

3、設置PATH環境變數，添加/usr/local/go/bin到環境變數
export PATH=$PATH:/usr/local/go/bin

4、安裝到自定義位置

Go二進制文件默認安裝到/usr/local/go，但是可以安裝Go工具到不同的位置，可以自行定義，只需要設置正確的環境變數。

例如，安裝Go到家目錄下，必須添加環境變數到$HOME/.profile
export GOROOT=$HOME/go

export PATH=$PATH:$GOROOT/bin

註：安裝Go到其他目錄時，GOROOT必須設置為環境變數

5、檢查是否正確安裝程序

通過設置一個工作區和建立一個簡單的程序，檢查是否正確安裝了一個簡單的程序。創建一個目錄包含您的工作空間，例如/data/work，並設置GOPATH環境變數指向的位置。
export GOPATH=/data/work

#如果不存在/data/work,需要新建

然後，在你的工作內創建src/github.com/user/hello，如果使用github，可以使用自己的用戶名代替user，在hello目錄下，新建hello.go
# cat hello.go
package main
import "fmt"
func main {
fmt.Printf("hello,world!\n")
}

#使用go編譯hello.go
go install github.com/user/hello

#上面的命令講名叫hello（or hello.exe）的程序放到你的工作區內，執行下面命令，會得到輸出結果。
$GOPATH/bin/hello

hello,world!

#當出現hello,world!表明Go已經安裝成功可以工作。

二、Go工作區介紹

1、機構組織代碼概述

Go語言程序通常將所有的代碼保存在一個工作區中。

工作區包含許多版本控制庫（由Git管理）。

每個存儲庫包含一個或多個包。

每個包由一個或多個在一個目錄中的源文件組成。

一個包的目錄的路徑決定其導入路徑。

註：同於其他的編程環境中，每一個項目都有一個獨立的工作區且工作區是緊密聯系在一起的版本控制庫。

2、工作區介紹

工作區是一個目錄層次結構，它的根目錄有三個目錄：

src 包含Go源文件

pkg 包含對象和包

bin 包含可執行命令
Go工具創建源碼包並安裝二進制文件到pkg和bin目錄下
src目錄通常包含多個版本控制庫（如Git或Mercurial），跟蹤一個或多個源包的開發。
下面展示一個好的工作區的例子：
bin/
hello # command executable
outyet # command executable
pkg/
linux_amd64/
github.com/golang/example/
stringutil.a # package object
src/
github.com/golang/example/
.git/ # Git repository metadata
hello/
hello.go # command source
outyet/
main.go # command source
main_test.go # test source
stringutil/
reverse.go # package source
reverse_test.go # test source
golang.org/x/image/
.git/ # Git repository metadata
bmp/
reader.go # package source
writer.go # package source
... (many more repositories and packages omitted) ...

上面的屬性圖展示了一個包含兩個存儲庫（example和image）的工作區，example 存儲庫包含兩個命令（hello，outyet），image庫包含bmp包和幾個其他的包。

一個典型的工作區包含包含許多軟體包和命令的多個源庫。大多數程序員將所有的源代碼和依賴關系保存在一個工作區中

3、GOPATH環境變數設置

GOPATH環境變數指定工作區的位置。它很可能是唯一的環境變數，代碼開發時需要設置。

開始，創建一個工作區目錄並設置相應的gopath。您的工作區可以位於任何你喜歡的地方，但我們將在這個文檔中使用/data/work。請注意，這不能是您的「Go安裝」路徑相同。
mkdir -p /data/work

export GOPATH=/data/work

為了方便。添加工作區的bin到PATH中
export PATH=$PATH:$GOPATH/bin

4、導入路徑

一個導入路徑是唯一標識一個包的字元串。一個包的導入路徑對應於它在工作區內或遠程存儲庫中的位置。

從標准庫的軟體包中給出了短的導入路徑等。對於您自己的包，您必須選擇不可能和未來添加到標准庫或其他外部庫的基礎路徑沖突的路徑。

注意，你不需要將你的代碼發布到一個遠程存儲庫之前，你可以建立它。這只是一個很好的習慣來組織你的代碼，如果你有一天會出版它。在實踐中，你可以選擇任何任意的路徑名稱，只要它是唯一的標准庫和更大的去生態系統。

我們將使用github.com/user作為我們的基本路徑。在您的工作區中創建一個目錄，以保持源代碼：
mkdir -p $GOPATH/src/github.com/user

5、第一個項目

編譯並運行一個簡單的程序，首先選擇一個包的路徑（我們將使用github.com/user/hello）和創建在您的工作區相應的軟體包目錄：
mkdir $GOPATH/src/github.com/user/hello

創建名叫hello.go的文件，上面創建過，此處略過。
cd $GOPATH/src/github.com/user/hello
go install
$GOPATH/bin/hello

或者：
hello

如果你使用的是一個源代碼管理系統，現在是一個很好的時間來初始化一個存儲庫，添加文件，並提交你的第一次更改。再次，這一步是可選的：您不需要使用源代碼管理來寫代碼。
cd $GOPATH/src/github.com/user/hello

git init

Initialized empty Git repository in /data/work/src/github.com/user/hello/.git/

git add hello.go

git commit -m "first commit"

[master (root-commit) bbfb477] first commit

6、first library

mkdir $GOPATH/src/github.com/user/stringutil

下一步，在目錄下創建一個名為reverse.go文件中有下列內容：
// Package stringutil contains utility functions for working with strings.

package stringutil

// Reverse returns its argument string reversed rune-wise left to right.

func Reverse(s string) string {

r := []rune(s)

for i, j := 0, len(r)-1; i < len(r)/2; i, j = i+1, j-1 {

r[i], r[j] = r[j], r[i]

}

return string(r)

}

使用go build測試包的編譯
$ go build github.com/user/stringutil

如果當前位置源碼包目錄，只需要：
go build

上面操作並不會產生一個輸出文件，必須使用go install，把包和對象輸出到工作去的pkg目錄內

確認stringutil包創建完成後，修改原始hello.go，使用stringutil包：
package main

import (

"fmt"

"github.com/user/stringutil"

)

func main() {

fmt.Printf(stringutil.Reverse("\n !oG ,olleH"))

}

無論使用go安裝包還是二進制文件，所有相關的依賴都會自動安裝。所以當你安裝hello程序時：
$ go install github.com/user/hello

對應的stringutil包會自動安裝好。

執行新的hello程序，可以看到消息已經被反轉
# hello

Hello, Go!

完成上面操作之後，工作區應該為：
├── bin

│ └── hello # command executable

├── pkg

│ └── linux_amd64 # this will reflect your OS and architecture

│ └── github.com

│ └── user

│ └── stringutil.a # package object

└── src

└── github.com

└── user

├── hello

│ └── hello.go # command source

└── stringutil

└── reverse.go # package source

注意：go install會把庫文件stringutil.a放到pkg/linux_amd64下邊（目錄結構跟源代碼結構一樣）。這樣可以go命令可以直接找到對應的包對象，避免不必要的重復編譯。linux_amd64是為了根據操作系統和你的系統架構交叉編譯。

所有Go可執行程序都通過靜態方式鏈接在一起，所以在運行時是不需要相關的包對象（庫）。

7、包命令

所有的Go源代碼都以下面的語句開始：
package name

其中name就是包引用默認的名稱，一個包中的所有文件必須使用同一個包名，可執行命令必須是main。

一個二進制文件下所有的包名不需要唯一，但是引用路徑必須唯一

8、測試

Go自帶了一個輕量級的測試框架，由go test和testing包組成。

可以通過新建xx_test.go寫一個測試，其中包含若干個TestXXX函數。測試框架會自動執行這些函數；如果函數中包含tError或t.Fail, 對應的測試會被判為失敗。

添加一個針對stringutil的測試文件$GOPATH/src/github.com/user/stringutil/reverse_test.go，包含以下內容：
package stringutil

import "testing"

func TestReverse(t *testing.T) {

cases := []struct {

in, want string

}{

{"Hello, world", "dlrow ,olleH"},

{"Hello, 世界", "界世,olleH"},

{"", ""},

}

for _, c := range cases {

got := Reverse(c.in)

if got != c.want {

t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want)

}

}

}

#通過go test測試
# go test github.com/user/stringutil

ok github.com/user/stringutil 0.002s

#同樣的，在包文件夾下可以忽略路徑而直接執行go test
[root@zabbix stringutil]# go test

PASS

ok github.com/user/stringutil 0.002s

9、遠程包

包的引用路徑用來描述如何通過版本控制系統獲取包的源代碼。go工具通過引用路徑自動從遠程代碼倉庫獲取包文件。比如本文中用的例子也對應的保存在github.com/golang/example下。go可以通過包的代碼倉庫的url直接獲取、生成、安裝對應的包。
[root@zabbix ~]# go get github.com/golang/example/hello

[root@zabbix ~]# $GOPATH/bin/hello

Hello, Go examples!

如果工作區中不存在對應的包，go會將對應的包放到GOPATH環境變數指明的工作區下。（如果包已經存在，go跳過代碼拉去而直接執行go install）
建議詳細看一下http://www.linuxprobe.com/set-go-env.html這個，有圖文

❷ 配置zabbix時zabbix_server [24834]: /etc/zabbix/zabbix_server.conf.d: [2]No such file or directory

默認Zabbix配置文件會自動生成到/etc下面的，如果沒有，就有可能默認安裝到其他目錄了，如/opt下面。
具體參考配置教程
1、zabbix server端的配置在進行源碼安裝zabbix時已經配置好了，具體要配置的參數如下：
ListenPort=10051
server服務的監聽埠，默認是10051
DBHost=localhost 資料庫IP地址
DBName=zabbix 資料庫名稱
DBUser=zabbix 資料庫用戶名
DBPassword=zabbix 資料庫密碼
DBPort=3306 資料庫埠，默認是3306
ListenIP=127.0.0.1,192.168.10.10
zabbix server ip地址復制代碼
vim /etc/zabbix/zabbix_server.conf
ListenPort=10051DBHost=localhost 資料庫ip地址
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix
DBPort=3306
ListenIP=127.0.0.1,192.168.10.10
zabbix server ip地址復制代碼剛剛開始需要關注的是這些，後面再補充。
還有個：zabbix運行腳本存放路徑，這個也在/etc/zabbix/zabbix_server.conf
配置文件里配置，默認地址是：AlertScriptsPath=${datadir}/zabbix/alertscripts
zabbix_agent 客戶端配置，服務端在源碼安裝時已經進行了，批量部署的話不建議客戶端使用源碼安裝，推薦使用rpm包安裝，可以使用zabbix官方提供的rpm路徑：
repo.zabbix.com/zabbix/3.0/修改Agent配置文件 zabbix agent的配置很簡單，只需要修改zabbix agent配置文件中的Server、ServerActive和Hostname這三項即可。
其中Server、ServerActive是zabbix server伺服器的IP地址，Hostname是被監控端的IP地址，如下：復制代碼#
sed -i "s/Server\=127.0.0.1/Server\=127.0.0.1,192.168.30.130/g" /etc/zabbix/zabbix_agentd.conf
# sed -i "s/ServerActive\=127.0.0.1/ServerActive\=192.168.30.130:10051/g" /etc/zabbix/zabbix_agentd.conf
# sed -i "s#tmp/zabbix_agentd.log#var/log/zabbix/zabbix_agentd.log#g" /etc/zabbix/zabbix_agentd.conf
# sed -i "#UnsafeUserParameters=0#aUnsafeUserParameters=1\n" /etc/zabbix/zabbix_agentd.conf
復制代碼拷貝 Agent 啟動腳本復制代碼
# mkdir /var/log/zabbix
# chown zabbix.zabbix /var/log/zabbix # cp misc/init.d/fedora/core/zabbix_agentd /etc/init.d/
# chmod 755/etc/init.d/zabbix_agentd # sed -i "s#BASEDIR=/usr/local
#BASEDIR=/usr/#g" /etc/init.d/zabbix_agentd
復制代碼設置Agent開機啟動
# chkconfig zabbix_agentd on
# servicezabbix_agentdstart在Server端使用以下命令測試是否能連接到Agent端：[root@localhost ~]# /usr/local/zabbix/bin/zabbix_get -s 192.168.217.139 -p 10050 -k "system.uptime"17340

❸ 從 0 到 1：全面理解 RPC 遠程調用

作者 | python編程時光

責編 | 胡巍巍

什麼是RPC呢？網路給出的解釋是這樣的：「RPC（Remote Procere Call Protocol）——遠程過程調用協議，它是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議」。

這個概念聽起來還是比較抽象，沒關系，繼續往後看，後面概念性的東西，我會講得足夠清楚，讓你完全掌握 RPC 的基礎內容。

在 OpenStack 里的進程間通信方式主要有兩種，一種是基於HTTP協議的RESTFul API方式，另一種則是RPC調用。

那麼這兩種方式在應用場景上有何區別呢？

有使用經驗的人，就會知道：

首先，給你提兩個問題，帶著這兩個問題再往下看：

1、RPC 和 REST 區別是什麼？2、為什麼要採用RPC呢？

首先，第一個問題：RPC 和 REST 區別是什麼？

你一定會覺得這個問題很奇怪，是的，包括我，但是你在網路上一搜，會發現類似對比的文章比比皆是，我在想可能很多初學者由於基礎不牢固，才會將不相乾的二者拿出來對比吧。既然是這樣，那為了讓你更加了解陌生的RPC，就從你熟悉得不能再熟悉的 REST 入手吧。

01、所屬類別不同

REST，是Representational State Transfer 的簡寫，中文描述表述性狀態傳遞（是指某個瞬間狀態的資源數據的快照，包括資源數據的內容、表述格式(XML、JSON)等信息。）

REST 是一種軟體架構風格。這種風格的典型應用，就是HTTP。其因為簡單、擴展性強的特點而廣頃肢受開發者的青睞。

而RPC 呢，是 Remote Procere Call Protocol 的簡寫，中文描述是遠程過程調用，它可以實現客戶端像調用本地服務(方法)一樣調用伺服器的服務(方法)。

而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的，按理說它和REST不是一個層面意義上的東西，不應該放在一起討論，但是誰讓REST這么流行呢，它是目前最流行的一套互聯網應用程序的API設計標准，某種意義下，我們說 REST 可以其實就是指代 HTTP 協議。

02、使用方式不同

03、面向對象不同

從設計上來看，RPC，所謂的遠程過程調用 ，是面向方法的 ，REST：所謂的 Representational state transfer ，是面向資源的，除此之外，還有一種叫做 SOA，所謂的面向服務的架構，它是面向消息的，這個接觸不多，就不多說了。

04、序列化協議不同

介面調用通常包含兩個部分，序列化和通信協議。

通信協議，上面已經提及了，REST 是 基於 HTTP 協議，而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的。

常見的序列化協議，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是渣歷 JSON-RPC，或者 XML-RPC。

通過以上幾點，我們知道了 REST 和 RPC 之間有很明顯的差異。

然後第二個問題：為什麼要採用RPC呢？

那到底為何要使用 RPC，單純的依靠RESTful API不可以嗎？為什麼要搞這么多復雜的協議，渣渣表示真的學不過來了。

關於這一點，以下幾點僅是我的個人猜想，僅供交流哈：

說了這么多，我們該如何選擇這兩者呢？我總結了如下兩點，供你參考：

「遠程調用」意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個地方（分布到各個伺服器），調用者只想要函數運算的結果，卻不需要實現函數的具體細節。

光說不練嘴把式，接下來，我將分別用三種不同的方式全面地讓你搞明白 rpc 遠程調用是如何實現的。

01、基於 xml-rpc

Python實現 rpc，可以使用標准庫里的 SimpleXMLRPCServer，它是基於XML-RPC 協議的。

有了這個模塊，開如乎搜啟一個 rpc server，就變得相當簡單了。執行以下代碼：

有了 rpc server，接下來就是 rpc client，由於我們上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 這個庫。

然後，我們通過 server_proxy 對象就可以遠程調用之前的rpc server的函數了。

SimpleXMLRPCServer是一個單線程的伺服器。這意味著，如果幾個客戶端同時發出多個請求，其它的請求就必須等待第一個請求完成以後才能繼續。

若非要使用 SimpleXMLRPCServer 實現多線程並發，其實也不難。只要將代碼改成如下即可。

02、基於json-rpc

SimpleXMLRPCServer 是基於 xml-rpc 實現的遠程調用，上面我們也提到 除了 xml-rpc 之外，還有 json-rpc 協議。

那 python 如何實現基於 json-rpc 協議呢？

答案是很多，很多web框架其自身都自己實現了json-rpc，但我們要獨立這些框架之外，要尋求一種較為干凈的解決方案，我查找到的選擇有兩種

第一種是 jsonrpclib

第二種是 python-jsonrpc

先來看第一種 jsonrpclib

它與 Python 標准庫的 SimpleXMLRPCServer 很類似（因為它的類名就叫做 SimpleJSONRPCServer ，不明真相的人真以為它們是親兄弟）。或許可以說，jsonrpclib 就是仿照 SimpleXMLRPCServer 標准庫來進行編寫的。

它的導入與 SimpleXMLRPCServer 略有不同，因為SimpleJSONRPCServer分布在jsonrpclib庫中。

服務端

客戶端

再來看第二種python-jsonrpc，寫起來貌似有些復雜。

服務端

客戶端

調用過程如下

還記得上面我提到過的 zabbix API，因為我有接觸過，所以也拎出來講講。zabbix API 也是基於 json-rpc 2.0協議實現的。

因為內容較多，這里只帶大家打個，zabbix 是如何調用的：直接指明要調用 zabbix server 的哪個方法，要傳給這個方法的參數有哪些。

03、基於 zerorpc

以上介紹的兩種rpc遠程調用方式，如果你足夠細心，可以發現他們都是http+rpc 兩種協議結合實現的。

接下來，我們要介紹的這種（zerorpc），就不再使用走 http 了。

zerorpc 這個第三方庫，它是基於TCP協議、 ZeroMQ 和 MessagePack的，速度相對快，響應時間短，並發高。zerorpc 和 pyjsonrpc 一樣，需要額外安裝，雖然SimpleXMLRPCServer不需要額外安裝，但是SimpleXMLRPCServer性能相對差一些。

調用過程如下

客戶端除了可以使用zerorpc框架實現代碼調用之外，它還支持使用「命令行」的方式調用。

客戶端可以使用命令行，那服務端是不是也可以呢？

是的，通過 Github 上的文檔幾個 demo 可以體驗到這個第三方庫做真的是優秀。

比如我們可以用下面這個命令，創建一個rpc server，後面這個 time Python 標准庫中的 time 模塊，zerorpc 會將 time 注冊綁定以供client調用。

經過了上面的學習，我們已經學會了如何使用多種方式實現rpc遠程調用。

通過對比，zerorpc 可以說是脫穎而出，一支獨秀。

為此，我也做了一番思考：

OpenStack 組件繁多，在一個較大的集群內部每個組件內部通過rpc通信頻繁，如果都採用rpc直連調用的方式，連接數會非常地多，開銷大，若有些 server 是單線程的模式，超時會非常的嚴重。

OpenStack 是復雜的分布式集群架構，會有多個 rpc server 同時工作，假設有 server01，server02，server03 三個server，當 rpc client 要發出rpc請求時，發給哪個好呢？這是問題一。

你可能會說輪循或者隨機，這樣對大家都公平。這樣的話還會引出另一個問題，倘若請求剛好發到server01，而server01剛好不湊巧，可能由於機器或者其他因為導致服務沒在工作，那這個rpc消息可就直接失敗了呀。要知道做為一個集群，高可用是基本要求，如果出現剛剛那樣的情況其實是很尷尬的。這是問題二。

集群有可能根據實際需要擴充節點數量，如果使用直接調用，耦合度太高，不利於部署和生產。這是問題三。

引入消息中間件，可以很好的解決這些問題。

解決問題一：消息只有一份，接收者由AMQP的負載演算法決定，默認為在所有Receiver中均勻發送(round robin)。

解決問題二：有了消息中間件做緩沖站，client 可以任性隨意的發，server 都掛掉了？沒有關系，等 server 正常工作後，自己來消息中間件取就行了。

解決問題三：無論有多少節點，它們只要認識消息中間件這一個中介就足夠了。

既然講到了消息隊列，如果你之前沒有接觸過這塊內容，最好花幾分鍾的時間跟我好好過下關於消息隊列的幾個基礎概念。

首先，RPC只是定義了一個通信介面，其底層的實現可以各不相同，可以是 socket，也可以是今天要講的 AMQP。

AMQP(Advanced Message Queuing Protocol)是一種基於隊列的可靠消息服務協議，作為一種通信協議，AMQP同樣存在多個實現，如Apache Qpid，RabbitMQ等。

以下是 AMQP 中的幾個必知的概念：

Publisher：消息發布者

Queue：用來保存消息的存儲空間，消息沒有被receiver前，保存在隊列中。

Exchange：用來接收Publisher發出的消息，根據Routing key 轉發消息到對應的Message Queue中，至於轉到哪個隊列里，這個路由演算法又由exchange type決定的。

Exchange type：主要四種描述exchange的類型。

direct：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key = binding key

topic：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key 匹配 binding pattern. binding pattern是類似正則表達式的字元串，可以滿足復雜的路由條件。

fanout：消息路由到多有綁定到該exchange的隊列中。

binding ：binding是用來描述exchange和queue之間的關系的概念，一個exchang可以綁定多個隊列，這些關系由binding建立。前面說的binding key /binding pattern也是在binding中給出。

為了讓你明白這幾者的關系，我畫了一張模型圖。

關於AMQP，有幾下幾點值得注意：

前面鋪墊了那麼久，終於到了講真實應用的場景。在生產中RPC是如何應用的呢？

其他模型我不太清楚，在 OpenStack 中的應用模型是這樣的

至於為什麼要如此設計，前面我已經給出了自己的觀點。

接下來，就是源碼解讀 OpenStack ，看看其是如何通過rpc進行遠程調用的。如若你對此沒有興趣（我知道很多人對此都沒有興趣，所以不浪費大家時間），可以直接跳過這一節，進入下一節。

目前Openstack中有兩種RPC實現，一種是在oslo messaging,一種是在openstack.common.rpc。

openstack.common.rpc是舊的實現，oslo messaging是對openstack.common.rpc的重構。openstack.common.rpc在每個項目中都存在一份拷貝，oslo messaging即將這些公共代碼抽取出來，形成一個新的項目。oslo messaging也對RPC API 進行了重新設計，對多種 transport 做了進一步封裝，底層也是用到了kombu這個AMQP庫。（註：Kombu 是Python中的messaging庫。Kombu旨在通過為AMQ協議提供慣用的高級介面，使Python中的消息傳遞盡可能簡單，並為常見的消息傳遞問題提供經過驗證和測試的解決方案。）

關於oslo_messaging庫，主要提供了兩種獨立的API:

因為 notify 實現是太簡單了，所以這里我就不多說了，如果有人想要看這方面內容，可以收藏我的博客(http://python-online.cn) ，我會更新補充 notify 的內容。

OpenStack RPC 模塊提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 調用方法，發送和接收 RPC 請求。

rpc.call 和 .rpc.cast 從實現代碼上看，他們的區別很小，就是call調用時候會帶有wait_for_reply=True參數，而cast不帶。

要了解 rpc 的調用機制呢，首先要知道 oslo_messaging 的幾個概念主要方法有四個：

transport：RPC功能的底層實現方法，這里是rabbitmq的消息隊列的訪問路徑

transport 就是定義你如何訪連接消息中間件，比如你使用的是 Rabbitmq，那在 nova.conf中應該有一行transport_url的配置，可以很清楚地看出指定了 rabbitmq 為消息中間件，並配置了連接rabbitmq的user，passwd，主機，埠。

target用來表述 RPC 伺服器監聽topic，server名稱和server監聽的exchange，是否廣播fanout。

rpc server 要獲取消息，需要定義target，就像一個門牌號一樣。

rpc client 要發送消息，也需要有target，說明消息要發到哪去。

endpoints：是可供別人遠程調用的對象

RPC伺服器暴露出endpoint，每個 endpoint 包涵一系列的可被遠程客戶端通過 transport 調用的方法。直觀理解，可以參考nova-conctor創建rpc server的代碼，這邊的endpoints就是 nova/manager.py:ConctorManager

dispatcher：分發器，這是 rpc server 才有的概念

只有通過它 server 端才知道接收到的rpc請求，要交給誰處理，怎麼處理？

在client端，是這樣指定要調用哪個方法的。

而在server端，是如何知道要執行這個方法的呢？這就是dispatcher 要乾的事，它從 endpoint 里找到這個方法，然後執行，最後返回。

Serializer：在 python 對象和message(notification) 之間數據做序列化或是反序列化的基類。

主要方法有四個：

每個notification listener都和一個executor綁定，來控制收到的notification如何分配。默認情況下，使用的是blocking executor(具體特性參加executor一節）

模仿是一種很高效的學習方法，我這里根據 OpenStack 的調用方式，抽取出核心內容，寫成一個簡單的 demo，有對 OpenStack 感興趣的可以了解一下，大部分人也可以直接跳過這章節。

注意以下代碼不能直接運行，你還需要配置 rabbitmq 的連接方式，你可以寫在配置文件中，通過 get_transport 從cfg.CONF 中讀取，也可以直接將其寫成url的格式做成參數，傳給 get_transport 。而且還要nova或者其他openstack組件的環境中運行（因為需要有ctxt這個環境變數）

簡單的 rpc client

簡單的 rpc server

【End】

熱 文 推 薦

☞Facebook 發幣 Libra；谷歌十億美金為窮人造房；第四代樹莓派 Raspberry Pi 4 發布 | 開發者周刊

☞WebRTC 將一統實時音視頻天下？

☞小米崔寶秋：小米 AIoT 深度擁抱開源

☞華為在美研發機構 Futurewei 意欲分家？

☞老司機教你如何寫出沒人敢維護的代碼！

☞Python有哪些技術上的優點？比其他語言好在哪兒？

☞上不了北大「圖靈」、清華「姚班」，AI專業還能去哪上？

☞公鏈史記 | 從鴻蒙初辟到萬物生長的十年激盪……

☞邊緣計算容器化是否有必要？

☞馬雲曾經偶像，終於把阿里留下的1400億敗光了！

你點的每個「在看」，我都認真當成了喜歡