Edward_LF的博客

现在代码调用的角度看一下RPC调用的过程：（就是我们的RPC框架怎么支持RPC调用的）首先，我们在使用框架的时候，框架体现出3个模块：提供服务的节点先启动， 和ZK创建会话（session），然后在里面维护了一个RPC方法的map表，想发布服务会调用notifyservice函数，把发布服务的对象和RPC方法写到map表，然后通过ZKclient把这些服务和方法都注册在ZK上，放在相应的znode节点上，可以看一下图右边的根目录形式的写法。然后RPC服务的提供者就会去启动网络服务， 采用的是muduo库，设

服务发布方（RpcProvider）在zookeeper发布服务；消费者在zookeeper查找服务。我们完善rpcprovider.cc启动RPC服务，向zookeeper上注册服务（服务节点+方法节点+方法ip和port）1.2、编译项目OK！RPC服务提供方向zookeeper注册服务OK的！在明确已经安装该库的情况下出现上述错误，可能是这个库目录并没有加入到该环境变量中，解决办法如下：更改配置文件：一般安装目录在：将该目录加入到共享库的配置文件中：这里RPC的provider服务提

RPC服务的提供端，要在RPC节点服务启动之前，要把自己所发布的服务向zk上注册，zk在项目中作为服务配置中心，UserSevice作为永久性节点，下面挂着method临时节点（Login、Register等），这些临时节点中存储的是ip + portRPC调用者在调用服务时，需要知道该服务在哪台主机上运行，在zk上查找！我们在src的include下创建头文件：zookeeperutil.h1.2、zookeeperutil.cc我们在src下创建文件zookeeperutil.cc：flags参数

当我们客户端想要调用去rpc服务的时候，会拿RPC服务的名字和方法名字组成一个znode的节点路径，在服务配置中心上去查找一下，这个节点是否存在，如果存在，ip地址和端口号获取了，发起RPC方法的请求，如果找不到，就不用发起RPC请求了。而watcher机制相当于通知，回调机制， 客户端通过zk的API可以添加一个watcher，观察器，监听事件类型，针对UsersService这个节点的变化，维护一个map表，键就是节点的名字，值就是节点的内容。我们的客户端可以向zk的一个父节点添加一个watcher，如

服务的动态注册和发现，为了支持高并发，OrderService被部署了4份，每个客户端都保存了一份服务提供者的列表，但这个列表是静态的（在配置文件中写死的），如果服务的提供者发生了变化，例如有些机器down了，或者又新增了OrderService的实例，客户端根本不知道，想要得到最新的服务提供者的URL列表，必须手工更新配置文件，很不方便。问题 : 客户端和服务提供者的紧耦合左边的图表示一些RPC的调用方，它们怎么知道这些RPC服务在哪里呢，它们在本地有配置文件，每个调用方都维持一个配置文件，怎么更新统一

就是zookeeper存储数据的方式。我们刚才启动了服务端，现在我们再启动客户端：zk客户端常用命令：ls（查看有什么节点）、get（获取节点详细信息）、create（创建节点）、set（修改节点的值）、delete（删除节点）注意：get命令：重点关注两个字段：这个zookeeper节点上没有存数据，第一行就是空：ephemeralOwner表示是永久性节点还是临时性节点；create：注意： 创建sl3必须保证它的前面的节点sl、sl2都是存在的！set：修改节点的值delete： 删除节

1、官网上下载 zookeeper-3.4.10.tar.gz，拖进Ubuntu中2、执行3、4、5、6、打开配置文件我们知道zk的数据是怎么组织的 - 通过znode节点，这些节点上的数据最终存储在磁盘上的。我们在zookeeper-3.4.10下创建data文件夹专门存放数据。然后在zoo.cfg的目录修改data的地址：zk的默认端口号是2181。7、zkCli.sh： 客户端zkServer.sh： 服务器8、启动zkServer9、启动了。10、zookeeper是

之前发起一个RPC的调用请求，需要知道请求的RPC服务在哪个机器上，之前我们直接在调用时，将RPC服务提供者的ip和port给出来了！但是，实际上，我们使用一个RPC服务时，并不知道RPC服务在哪一个机器上运行的；所以我们在分布式通信系统中中，需要一个服务配置中心，也就是分布式网络系统中，所有提供RPC服务的节点都需要向配置中心注册一下，注册我的ip地址+port+提供的服务！RPC调用的时候查找一下即可！ZooKeeper提供一个分布式锁，（锁是在同一个进程中线程间互斥用的，临界区代码段只能有一个线程调

图中画圆圈的是我们实现的mprpc框架，这个框架是给别人使用的，把本地的服务发布成远程的RPC服务，框架里最重要的两个成员就是RpcProvider和RpcChannel，他们在运行的过程中会有很多正常的输出信息和错误的信息，我们不可能都cout它们到屏幕上，因为运行时间长了，屏幕上输出的信息特别多，如果万一有什么问题，我们也不好定位，真正用起来的话不方便。所以，一般出问题，我们最直接的方式就是看日志！！！日志可以记录正常软件运行过程中出现的信息和错误的信息，当我们定位问题，就打开相应的日志去查看，查找。假

框架需要用到RpcController的地方：RPC服务的调用方的调用步骤：之前我们认为RPC的请求一定是成功的，无论调用成功或者失败，RPC服务提供方都有回复！实际上，这个RPC请求不一定是成功的！当我们用代理对象stub调用GetFriendList方法的时候，最终都是转到channel的CallMethod方法里面，CallMethod就是做我们RPC请求的序列化，网络发送，接收响应，反序列化。才体现RPC的调用和响应完成了，然后我们才调用response.result().errcode(

我们在之前演示了登录。现在我们演示一下注册：分布式框架现在已经编译成一个静态库libmprpc.a了，我们不用动它了！我们只在用户使用端example中开发程序：我们打开user.proto，新增 注册register的相关代码：保存。打开终端，执行命令将user.proto重新生成C++代码文件：接下来我们打开userservice.cc新增发布这个方法（register）可以看到UserServiceRpc中有Login方法和Register两种方法：注意： 我们写的是框架，业务你怎么做都可以！

OK的，生成了静态库libmprpc.o、rpc服务提供者provider、rpc服务调用者consumer我们打开2个终端：程序测试OK的！老师这里的返回响应有问题！采用gdb调试：我们在116行打断点调试！此时停在116行！只有一个“\n”，不正确！不使用string构造了，直接反序列化！...

UserServiceRpc_Stub::Login需要传入4个参数：RPC调用方Closure* done没有什么用处，直接传入一个空即可！2、完善mprpcchannel.h3、完善mprpcchannel.cc现在我们是已知RPC的服务提供者的服务器ip和port，直连即可，直接进行点对点通信！（比较简单）后面我们需要去服务配置中心zooKeeper配置，发现服务所在的RPC提供者的服务器！4、调用示意图OK的！...

caller就是rpc服务调用者，按照提供rpc服务的那一方(callee)提供的proto协议，发起调用。UserServiceRpc_Stub是给rpc服务调用方使用的。UserServiceRpc_Stub没有默认构造函数；有参构造函数接收RpcChannel；因此想构造一个UserServiceRpc_Stub需要给出RpcChannel。当然UserServiceRpc_Stub里面也有Login方法！里面Login那些方法最终都是调用channel的CallMethod方法。（其他rpc

NotifyService生成了一张map表，存储了rpc服务方通过NotifyService利用框架发布了对象和方法！接下来考虑右边的黄色部分，从网络上接收到信息，怎么反序列化rpc请求，根据请求的rpc方法，调用相应的rpc方法！在OnMessage函数中处理：rpc的请求是短连接的，请求一次完了，服务端返回rpc的方法的响应，就主动关闭连接了。2、rpcprovider.cc的OnMessage在框架内部，RpcProvider和RpcConsumer协商好之间通信用的protobuf数据类型，

用户在RpcProvider发布一个rpc服务，可以提供给别人进行远程调用！callee：用分布式网络框架可以将本地服务发布成rpc服务；caller：作为一个rpc的调用者，要去调用和访问远端（可以在不同的机器上）发布的rpc的方法；绿色部分就是在负责网络的收发数据！mprpc现在已经完成了一部分功能。在rpc结构中，没有绝对的rpc服务器和rpc客户端，提供rpc方法就可以成为rpc服务器，请求rpc方法就可以称作rpc客户端！任何一个分布式节点都可能成为一个rpc服务器，也可能调用其他的rpc服务

前面我们将mprpcapplication方法写了，也把操作配置文件类mprpcconfig写好了，可以从配置文件中读取配置；现在需要启动网络服务了，在它上面发布rpc方法，供别人远程调用，涉及到高并发的请求调用！这里直接用muduo库！作为一个服务器，首先需要集成TcpServer！2、完善rpcprovider.cc3、更改src的CMakeLists.txt编译测试因为muduo库是静态库，因此我们不能将项目生成动态库，需要生成静态库!OK的！OK的！端口127?这里写错了

我们先把之前的项目代码工程编译好，然后进入bin里面，执行./provider之前编的代码OK了！接下来，我们开始写配置文件！我们在src的include中创建头文件：mprpcconfig.h2、完善mprpcapplication.h3、完善mprpcapplication.cc4、mprpcconfig.cc我们在src下创建文件mprpcconfig.cc5、test.conf我们在bin下创建一个配置文件：test.conf编译测试编译OK！测试OK！unord

我们打开userservice.cc中，查看主函数：这个Init函数需要用户传一个命令行参数我们希望这么去写 ，从读取相关的网络服务器以及相关的配置中心的IP地址和端口号。我们打开mprpcapplication.cc。我们要读参数，使用getopt函数：函数调用正确，命令行参数所带的值就在全局参数中...

首先完善mprpc目录下的CMakeLists.txt2、src下的CMakeLists.txt然后我们在src底下增加一个CMakeLists.txt3、callee下的CMakeLists.txt4、编译项目OK！

在上一节，我们完成了如何把本地服务发布成RPC服务。但是作为一个rpc发布方，也是一个服务器程序，需要运行起来，不断的接收远程的连接！下面接着说：我们打开example下callee下的userservice.cc：我们现在书写主函数我们希望实现后的mprpc框架，可以这么使用：可以调用多次，生成多个远程RPC服务：如果可以这么使用的话，想把本地业务变成远程服务就很简单了：我们接下来将往这个方向去设计框架：我们实现框架的代码存放在src中；我们在src下再创一个文件夹：include；用来存放头

我们开发的是一个框架类，侧重于给上层应用提供一个方便的方法，将上层应用的本地方法快速的部署成一个rpc方法，框架本身不做任何业务的，业务属于应用层面，框架属于平台层面！example文件夹作为我们框架项目的使用实例，在example文件夹下创建callee和caller两个文件夹。（example中的代码就相当于是 业务代码）我在callee创建一个文件：userservice.cc现在我们的需求： 有没有这样一个框架，把这个UserService这个类生成的Login方法直接变成一个RPC远程方法？让在

关于protobuf的安装配置在之前的博客。接下来我们打开Ubuntu下的vscode；下图是我的项目代码工程，我们在test创建protobuf文件夹，然后在protobuf文件下创建main.cc和test.proto进行我们的实践。proto文件就是protobuf的配置文件！proto文件就是protobuf的配置文件！我们先在test.proto定义消息类型（message)注意：里面的类型都是谷歌protobuf定义的类型，和C++的类型相似我们用bytes定义字符串类型，多字节存储，处理的

Ubuntu打开vscode，我的项目名称为 mprpc。项目工程目录如下：bin：可执行文件 build：项目编译文件lib：项目库文件（该框架最终编译成一个库文件）src：源文件test：测试代码example：框架代码使用范例CMakeLists.txt：顶层的cmake文件README.md：项目自述文件autobuild.sh：一键编译脚本...

github源代码下载地址：https://github.com/google/protobuf，或者私信我获取安装包protobuf-master.zip（博客资源中也有）1、解压压缩包：unzip protobuf-master.zip2、进入解压后的文件夹：cd protobuf-master3、安装所需工具：sudo apt-get install autoconf automake libtool curl make g++ unzip4、自动生成configure配置文件：./autoge

根据上一篇博客《单机，集群和分布式》的举的例子。我们最终合理地通过对大型软件的合理划分，划分成不同模块，按需求（硬件需求，高并发需求）进行分布式，一台机器上的模块不能单独构成聊天系统，所有机器上的模块构成一个聊天系统。即不同进程，不同机器上模块的调用。分布式的通信： 构建一个服务器系统，由很多不同的模块组成，这些模块进行了独立的部署，模块和模块之间的通信，这个模块调用另一个模块的方法，这就是分布式通信主要解决的问题。也叫做RPC通信。分布式好，但是我们也要解决一些问题！我们分布式通信框架需要解决的问题就是：

集群： 每一台服务器独立运行一个工程的所有模块。分布式： 一个工程拆分了很多模块，每一个模块独立部署运行在一个服务器主机上，所有服务器协同工作共同提供服务，每一台服务器称作分布式的一个节点，根据节点的并发要求，对一个节点可以再做节点模块集群部署。我们以服务聊天器为例子，来讲解单机，集群，分布式。聊天服务器取名为server。把用户管理，好友管理，群组管理，消息管理，后台管理等模块构成我们的聊天服务器。每个模块都包含了很多特定的业务。特定的业务：用户管理模块有用户登录，用户注册，用户注销，用户退出等功能业务

- 集群和分布式概念以及原理 - RPC远程过程调用原理以及实现 - Protobuf数据序列化和反序列化协议 - ZooKeeper分布式一致性协调服务应用以及编程（有很多分布式节点的机器，我不知道哪台机器上有哪些服务，我去哪里找这些服务？用ZooKeeper，服务注册中心） - muduo网络库编程 - conf配置文件读取 - 异步日志 - CMake构建项目集成编译环境 - github管理项目...