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亿败光了！
你点的每个“在看”，我都认真当成了喜欢