weixin_60208935的博客

将在服务端的方法都注册到znode节点上去，节点的内容储存该服务端的ip地址和端口（znode节点只存储简单的byte字节数组），当客户端访问的时候先访问服务注册中心，如果服务注册中心有相应的方法就get节点的内容，然后根据内容的ip与端口进行远程程序调用。通知回调机制，用来监听父节点中子节点的变化，如果有变化，会有zk主动的告知。zk服务端和服务端通过心跳包进行通信，证明服务方法还可以使用，当断开连接的时候，心跳包不再发送了就将服务注册中心上的相应方法节点自动删除。解除耦合，在本项目中起到。

再根据方法名字找到方法，通过服务类提供的GetRequestPrototype（）方法获得定义的request类和response类，再进行参数的ParseFromString就可以得到具体的参数了。因为stub桩类的方法具体实现就是内部的成员变量调用自己的成员方法，成员方法CallMethod是一个纯虚函数，需要多态的方法继承下来之后重写所以有了MprpcChannel。通过 -i 传的文件进行判断文件中的服务的ip与port和zk的ip和port。

历经九九八十一难才安装好这个muduo库，期间遇到了很多的问题,写下来记录一下希望之后看到的能避坑，不要走我的弯路。

本文记录一下在编写RPC项目时遇到的一些问题。写的时候不小心在头文件中多写了个类的构造函数的实现就导致我遇到函数重定义这样的错误。因为在头文件中定义了一个函数，在预处理时头文件展开，每个文件都有了一个该函数的定义，因为编译时是分隔的，所以到链接时，将所有文件关联在一起时，发现每个包含了该头文件的文件中有一个相同函数的声明，编译器就会报出重定义的错误。windows每行最后有个\r\n，linux每行最后有个\n.string的有参构造传char*这种char类型数组遇到\0就不再往后读了。

本文章从业务角度出发一步步构想出RPC框架所需要的东西。首先提供者和消费者都要有相应的proto文件来描述这个rpc服务，不然双方相当于都不知道对方发的是什么，要干什么。这里简单模拟一个登录的业务并设置相应的错误码和错误信息

本文主要解读RPC项目中的protobuf。为接下来项目的完成奠定重要的基础。//定义下面的描述，才能生成相应的service类和rpc方法描述。默认不生成}上面简单定义一个登录需求和退出需求，具体内部成员先不用在意。//这是一个一个常出错的地方，一定要记得设置。protubuf不支持所谓的rpc功能，它只是对rpc的一种描述。通过描述就可以做rpc请求所携带的参数的序列化和反序列化。

本文讲述源码中常见的getopt函数，并为本专栏的RPC项目用到时做准备。

本专栏RPC项目使用数据压缩编码方式为Protobuf。Protocol buffers 是一种语言中立，平台无关，可扩展的序列化数据的格式，可用于通信协议，数据存储等。Protocol buffers 在序列化数据方面，它是灵活的，高效的。相比于XML 来说，Protocol buffers 更加小巧，更加快速，更加简单。一旦定义了要处理的数据的数据结构之后，就可以利用 Protocol buffers 的代码生成工具生成相关的代码。甚至可以在无需重新部署程序的情况下更新数据结构。

caller服务器上调用callee服务器上的函数，将callee上的函数名以及需要的参数打包，通过网络的方式传输过去（此时的caller等待结果），callee上收到包之后将收到的包进行解包，通过信息找到对应的函数执行将结果打包然后通过网络传输给caller，caller收到包之后解包将结果return。