tencent / phxrpc Goto Github PK

按照中文详细编译手册安装，发现文档已经过时了，protobuf在googlecode的地址已经失效了，而且github上的protobuf现在不带gtest了，需要自己安装了，自动安装脚本需要同步更新下

下面尝试三种生成方式(全部都在 WORKDIR=~/dev-workspace/wx/phxrpc 下执行)：

1. third_party/protobuf/bin/protoc -Ithird_party/protobuf/include -I./phxrpc/rpc --cpp_out=. ./phxrpc/rpc/phxrpc.proto

最后生成的结果在 $WORKDIR 里面，与cpp_out参数指定的目标一致，然后phxrpc.pb.h的namespace为protobuf_phxrpc_2eproto

2. third_party/protobuf/bin/protoc -Ithird_party/protobuf/include -I./phxrpc/rpc --cpp_out=./phxrpc/rpc ./phxrpc/rpc/phxrpc.proto

最后生成的结果在 $WORKDIR/phxrpc/rpc 里面，与cpp_out参数指定的目标一致，然后phxrpc.pb.h的namespace为protobuf_phxrpc_2eproto

3. third_party/protobuf/bin/protoc -Ithird_party/protobuf/include -I. --cpp_out=. ./phxrpc/rpc/phxrpc.proto

最后生成的结果在 $WORKDIR/phxrpc/rpc 里面，与cpp_out参数指定的目标不一致 ，然后 phxrpc.pb.h的namespace为 protobuf_phxrpc_2frpc_2fphxrpc_2eproto

第三种就是官方提供的生成pb.cc的方式，这种方式生成的代码，在另外一个proto文件引用才是正常的，可视为什么呢？

开发者, 您好!
请问有没有做容错呢? 如何做的呢?

谢谢

RPC的连接建立协议、以及通信序列报文的格式。

一个服务处理不同的请求　如何绑定在一起呀SearchServiceImpl :: Notify这里面吗？

bool HshaServerIO :: AddAcceptedFd(int accepted_fd) {
std::lock_guardstd::mutex lock(queue_mutex_);
if (accepted_fd_list_.size() > MAX_ACCEPT_QUEUE_LENGTH) {
return false;
}
accepted_fd_list_.push(accepted_fd);

if (static_cast<int>(hsha_server_stat_->io_read_request_qps_) < 5000
        && static_cast<int>(hsha_server_stat_->accept_qps_) < 5000) {

    scheduler_->NotifyEpoll();  /*即便qps超过阀值，不进行NotifyEpoll在UThreadEpollScheduler中依然会进行HandlerAcceptedFd回调检测AcceptList*/
}

return true;

}

因为在**UThreadEpollScheduler::Run()中超时Pipe还是会进行一次handler_accepted_fd_func_调用，即便没有NotifyEpoll操作，不知道我的立即是否正确，请解释下，谢谢。

每次rpc调用都要新开一个进程吗？如何想要自行调用函数的话，每个函数有个OptMap类型的参数，这个类的定义找不到。难道每次调用都要把参数传进main函数，然后再转化成某个函数调用？

in file uthread_context_system.cpp, we have a function called UThreadFuncWrapper. I'm confused why we pass high bits and low bits of this pointer rather than passing the whole this pointer into the wrapper. Is there any concern about that?

Thanks for your reply.

void UThreadContextSystem :: Make(UThreadFunc_t func, void * args) {
    func_ = func;
    args_ = args;
    getcontext(&context_);
    context_.uc_stack.ss_sp = stack_.top();
    context_.uc_stack.ss_size = stack_.size();
    context_.uc_stack.ss_flags = 0;
    context_.uc_link = GetMainContext();
    uintptr_t ptr = (uintptr_t)this;
    makecontext(&context_, (void (*)(void))UThreadContextSystem::UThreadFuncWrapper, 
            2, (uint32_t)ptr, (uint32_t)(ptr >> 32)); // we split `this` pointer into two parts
}

void UThreadContextSystem :: UThreadFuncWrapper(uint32_t low32, uint32_t high32) {
    uintptr_t ptr = (uintptr_t)low32 | ((uintptr_t) high32 << 32); // then we put it together again
    UThreadContextSystem * uc = (UThreadContextSystem *)ptr;
    uc->func_(uc->args_);
    if (uc->callback_ != nullptr) {
        uc->callback_();
    }
}

xxx_client.cpp之类的文件并没有。 比如SearchClient 压根就没有了。 之前的代码在client_template.cpp中注释掉了。

协程的栈大小不要写死为64k，让业务层可配置。

默认的client每次call的时候都会去生成新的socket，没有实现tcp长连接。

1. UThreadRuntime类中的 void UThreadRuntime :: UThreadDoneCallback() 是否考虑对执行完成
   的 ContextSlot 剔除出 context_list_ 数组,这样可以加快没有完成的 UThreadContext 被选中的几率，
   比如通过例子 test_uthread(test_uthread.cpp)来执行，在
   for(; ! runtime.IsAllDone(); ) {
   int seq = random() % count;
   runtime.Resume( args[ seq ].id );
   }
   这段代码中,最后一个没有执行完成的UThreadContext 可能要随机被选中，需要空转很多次才能选中。
2. UThreadRuntime::IsAllDone(),这个函数建议直接返回 unfinished_item_count_即可,这样就能立即
   获取到队列中没有执行完成总数。
3. 执行完成的任务立即剔除出执行数组，那创建函数
   int UThreadRuntime :: Create(UThreadFunc_t func, void * args) 也可以简化很多,不用去抢占执行完成的坑了

目前这个产品是只支持Linux平台，是否有跨平台支持的开发计划？

您好，phx团队，有个问题想请教一下，phxrpc框架需要下载protobuf编译，我的服务端程序是用c++调用python，执行一个包含tensorflow的脚本，可是在执行过程中，出现
[libprotobuf ERROR google/protobuf/descriptor_database.cc:58] File already exists in database: google/protobuf/timestamp.proto [libprotobuf FATAL google/protobuf/descriptor.cc:1401] CHECK failed: generated_database_->Add(encoded_file_descriptor, size): terminate called after throwing an instance of 'google::protobuf::FatalException' what(): CHECK failed: generated_database_->Add(encoded_file_descriptor, size):
这是什么问题，有什么解决办法吗？
在补嵌入phxrpc框架，c++调用python，执行tensorflow脚本是ok的，tensorflow1.4.0（protobuf3.4.0） python3.5.3 phxrpc编译时，protobuf版本是3.4.0

我看之前的分享是用svrkit 做rpc的，如：

微信后台主要使用C++。后台服务使用Svrkit框架搭建，服务之间通过同步RPC进行通讯。

Svrkit是另一个广硏后台就已经存在的高性能RPC框架，当时尚未广泛使用，但在微信后台却大放异彩。作为微信后台基础设施中最重要的一部分，Svrkit这几年一直不断在进化。我们使用Svrkit构建了数以千计的服务模块，提供数万个服务接口，每天RPC调用次数达几十万亿次。

于是我们开始尝试使用一种新的CGI架构——Logicsvr。
Logicsvr基于Svrkit框架。将Svrkit框架和CGI逻辑通过静态编译生成可直接使用HTTP访问的Logicsvr。

每个Logicsvr都是一个独立的二进制程序，可以分开部署、独立上线。时至今日，微信后台有数十个Logicsvr，提供了数百个CGI服务，部署在数千台服务器上，每日客户端访问量几千亿次。

Svrkit——Client/Server自动代码生成框架:10分钟搭建内部服务器

被破坏的协程不要core掉，改成删除该协程上下文，返回调度器。

phxrpc如何做到服务自动发现和故障切换的，目前了解到只有静态加载配置一种方式

如题，不应该通过计算定期或者超时事件最小触发时间而动态进行设置吗？
无就绪事件而有定时器来时，4ms会有延迟处理；
无就绪事件也无定时器来时，4MS触发的往下执行没有必要。

Search函数 -q后面参数和Notify -m后面参数该写什么

RT

希望能加上。

一个进程只能通过phxrpc给另外唯一一个进程发送数据？

个人认为这个RPC几个做的漂亮的地方：

1. IO流的处理
2. IO处理创新性的使用UThread，但仅限于socket -> data_flow(worker)之间

想问下， 有考虑Worker本身就是UThreadScheduler驱动吗？ 实际业务开发往往是Worker线程调用其他服务接口RT不可控导致 服务本身处理能力低下。这种异步IO，同步Worker解决不了这种问题。

worker能否改成是 UThread epoll 驱动的，而不是data_flow的队列消费驱动， 这样每个Worker线程都是一个UthreadScheduler，类似libco的思路， 便于Worker 在调用其他服务的时候使用 Uthread

Thks.

看了半天，EpollNotifier::Func只是读这个标志管道的读端，并没有与runtime_里的任务协程对象有什么关系，不太明白它的作用是啥？谢谢

RT 谢谢

这里我有个疑问，如果rpc接口返回的数据结构十分复杂，比如以前是http接口返回的是一个json字符串，这个json字符串很长，并且其中的某些字段内容经常变化。这时候改造成rpc接口，用pb来描述接口返回值的话，pb的定义会很复杂繁琐，并且pb的字段最好只增加不减少，针对这种场景，你们在实际使用过程中，有没有遇到，以及是如何处理的呢。

ucontext做了很多不必要的事情，只需要保存6个寄存器以及栈即可实现协程切换的需求。

phxrpc 中Makefile 怎么转 phxsql中Makefile.define
phxbinlogsvr/framework/proto/phxbinlogsvr.proto phxbinlogsvr/framework/proto/Makefile.define phxbinlogsvr/framework/rpccomm/Makefile.define phxbinlogsvr/framework/phxrpc/client/Makefile.define phxbinlogsvr/framework/phxrpc/svr/Makefile.define phxbinlogsvr/framework/phxrpc/tools/Makefile.define

bool UThreadEpollScheduler::Run() 中
业务线程开启协程时，epoll_wait可能会被业务fd唤醒，但handler_new_request_func_被注册，
就会被调用处理新请求，Worker::HandlerNewRequestFunc()函数中貌似是阻塞取io线程的消息的，这样的话业务中的其他协程就会暂时挂起，影响性能。
PS：从性能测试看，短连接、长连接的性能差距蛮大的，有没有考虑cache 协程的方案？
即：进程启动后就开启N个IO协程，当accept到连接时使用缓存的协程等待读，读取完数据不销毁协程；业务协程同理。

Would you like to replace any double quotes by angle brackets around file names for include statements?

支持双向通信吗？

用的是protobuf-3.4.1，编译的时候发现

search.pb.cc:126:13: error: ‘phxrpc::protobuf_phxrpc_2frpc_2fphxrpc_2eproto’ has not been declared
::phxrpc::protobuf_phxrpc_2frpc_2fphxrpc_2eproto::InitDefaults();
^
search.pb.cc: In function ‘void search::protobuf_search_2eproto::{anonymous}::AddDescriptorsImpl()’:
search.pb.cc:163:13: error: ‘phxrpc::protobuf_phxrpc_2frpc_2fphxrpc_2eproto’ has not been declared
::phxrpc::protobuf_phxrpc_2frpc_2fphxrpc_2eproto::AddDescriptors();

An extra null pointer check is not needed in the destructor for the class "OptMap".

OS: Ubuntu18.04 64bit
GCC: 8.0
Boost: 1.66

由于使用到的boost::context下的类和函数已经转移到boost::context::detail下,并且有的函数参数发生变化,需要进行更改plugin_boost/network下的uthread_context_boost.h和uthread_context_boost.cpp,之后可以成功编译,但是未进行测试.
代码中中文注释部分为修改的地方.
其中uthread_context_boost.h改为:

#pragma once

#include <unistd.h>
#include <functional>
#include <assert.h>
#include <boost/context/all.hpp>
#include "phxrpc/network.h"
// 添加
using boost::context::detail::fcontext_t;
using boost::context::detail::transfer_t;

namespace phxrpc {

class UThreadContextBoostInit {
public:
    UThreadContextBoostInit();
};

class UThreadContextBoost : public UThreadContext {
public:
    UThreadContextBoost(size_t stack_size, UThreadFunc_t func, void * args, 
            UThreadDoneCallback_t callback, const bool need_stack_protect);
    ~UThreadContextBoost();

    static UThreadContext * DoCreate(size_t stack_size, 
            UThreadFunc_t func, void * args, UThreadDoneCallback_t callback,
            const bool need_stack_protect);

    void Make(UThreadFunc_t func, void * args) override;
    bool Resume() override;
    bool Yield() override;

    fcontext_t & GetMainContext();

private:
    // 参数从intptr_t变为transfer_t
    static void UThreadFuncWrapper(transfer_t ptr);

    fcontext_t context_;
    UThreadFunc_t func_;
    void * args_;
    UThreadStackMemory stack_;
    UThreadDoneCallback_t callback_;
};

} //namespace phxrpc

uthread_context_boost.cpp改为:

#include <unistd.h>
#include <functional>
#include <assert.h>
#include <boost/context/all.hpp>

#include "uthread_context_boost.h"
#include "phxrpc/network.h"
using boost::context::detail::transfer_t;
using boost::context::detail::fcontext_t;
using boost::context::detail::jump_fcontext;
using boost::context::detail::make_fcontext;
namespace phxrpc {

UThreadContextBoostInit g_uthread_context_boost_init_;

UThreadContextBoostInit :: UThreadContextBoostInit() {
    UThreadContext::SetContextCreateFunc(UThreadContextBoost::DoCreate);
}

UThreadContextBoost :: UThreadContextBoost(size_t stack_size, UThreadFunc_t func, 
        void * args, UThreadDoneCallback_t callback, const bool need_stack_protect)
    : func_(func), args_(args), stack_(stack_size, need_stack_protect), callback_(callback) {
    Make(func, args);
}

UThreadContextBoost :: ~UThreadContextBoost() {
}

UThreadContext * UThreadContextBoost:: DoCreate(size_t stack_size, 
        UThreadFunc_t func, void * args, UThreadDoneCallback_t callback,
        const bool need_stack_protect) {
    return new UThreadContextBoost(stack_size, func, args, callback, need_stack_protect);
}

// 参数从intptr_t变为transfer_t
void UThreadContextBoost :: UThreadFuncWrapper(transfer_t ptr) {
    // 类型转换前将transfer_t取地址转为intptr_t
    UThreadContextBoost * uc = reinterpret_cast<UThreadContextBoost *>(intptr_t(&ptr));
    uc->func_(uc->args_);
    if (uc->callback_ != nullptr) {
        uc->callback_();
    }
    uc->Yield();
}
void UThreadContextBoost :: Make(UThreadFunc_t func, void * args) {
    func_ = func;
    args_ = args;
    void * stack_p = (void *)((char *)stack_.top() + stack_.size());
    context_ = make_fcontext(stack_p, stack_.size(), &UThreadFuncWrapper);
}

bool UThreadContextBoost :: Resume() {
    //boost::context::detail::jump_fcontext(&GetMainContext(), context_, reinterpret_cast<intptr_t>(this));
    //删除最后一个参数
    jump_fcontext(&GetMainContext(), context_);
    return true;
}

bool UThreadContextBoost :: Yield() {
    //boost::context::detail::jump_fcontext(&context_, GetMainContext(), 0);
   // 删除最后一个参数
    jump_fcontext(&context_, GetMainContext());

    return true;
}

fcontext_t & UThreadContextBoost :: GetMainContext() {
    static thread_local fcontext_t main_context;
    return main_context;
}

} //namespace phxrpc

char tmp_section[128] = { 0 };
snprintf(tmp_section, sizeof(tmp_section), "\n[%s]", section);

char tmp_key[128] = { 0 };
snprintf(tmp_key, sizeof(tmp_key), "\n%s", key);

如上配置类中关于,tmp_section的初始化格式，测试用于读取下面配置信息。

[Server]
BindIP = 127.0.0.1          //Server IP
Port = 16161                //Server Port
MaxThreads = 16             //Worker 线程数
IOThreadCount = 3           //IO线程数，针对业务请自行调节
PackageName = search        //Server 名字，用于自行实现的监控统计上报
MaxConnections = 800000     //最大并发连接数
MaxQueueLength = 20480      //IO队列最大长度
FastRejectThresholdMS = 20  //快速拒绝自适应调节阀值，建议保持默认20ms，不做修改

[ServerTimeout]
SocketTimeoutMS = 5000      //Server读写超时，Worker处理超时

因为tmp_section初始化为\n[%s]格式，如果[Server]section配置选没有\n在二行而是在首行则无法匹配，从而导致无法获取Server区块的配置信息。

http太浪费带宽了，还是用命令号+tcp比较合适。

几年前看看<<微信技术总监解读微信架构的秘密>>一片文章， 觉得Svrkit, LogicServer好厉害，能实现真正的微服务。
苦苦找寻基于服务端的优秀c++ rpc框架， 用过thrift可不支持protobuf， 觉得grpc使用http2协议用在外网还行。
昨晚还在想， 是不是自己用asio结合protobuf实现rpc。 今天早上在google上搜索 wechat server framework，终于找到phxrpc。
前一阵子， 心想微信的产品已经做到大爷大妈那里了， 微信的技术也不做点开源。 今天看到phxrpc，心情有点激动, 发了这个issues。

通过率的增长速度和下载速度可配置。