叮！不加班完成远程调用开发的姿势

序

最近在对复杂系统进行功能拆分（在函数调用层面，将软件实例进行进程级的一个功能切割，也就是把一个复杂系统里的各个功能规整解耦合成子系统然后再把这个子系统拆出来）,

程序进行功能拆分解耦合成各种小型服务化功能，通常会使用一个独立子服务+二进制api接口封装库方式来进行交互。
当独立子系统拆分后，原有的在本进程调用的普通函数接口，就需要改造成一个远程调用服务，来进行跨进程调用（甚至类似分布式系统，将这个子系统部署在其它主机）。

这过程中就无法回避跨进程间交互进行参数传递和返回值获取了。(这是非常模式化的一件事，而且也很繁琐)
主要麻烦的地方在于，本身函数传参只是一行代码就能搞定的事，改造成RPC（Remote Procedure Call)远程调用之后，会混入类似各种套接字创建，发送接收,数据校验等交互上的麻烦事。

那么有没有一种方法来非常简单的把远程调用传参和获取返回值这个步骤给自动化？（主要是懒，还有这样就能早点下班）

此处拒绝高大上的各种RPC框架,以及复杂通信协议,只考虑函数级调用的远程服务实现,所有api接口均为二进制接口(因为本身就是本地微服务,没必要再磊一个复杂的通信协议栈上去)

graph TB
    caller-->|Rpc调用|funcC
    subgraph 本机
        caller-->|Rpc调用|funcB
        subgraph 本进程
            caller-->|函数调用|funcA
        end
        subgraph 服务进程
            funcB
        end
    end
    subgraph 远程主机
    funcC
    end

Refrence

库以及demo实现:https://github.com/Vladivostoks/EzRpc

所以偷懒的姿势是？

开始之前，先比较一下，确保方案大方向能够实施。

函数调用和rpc对比

函数调用可视为四步：

1. 找到对于函数入口
2. 参数入栈
3. 函数执行并得到一个返回值.
4. 返回值返回

作为类比,整个RPC过程即要做成：

1. 向服务端发起对应的功能调用请求 -> 调用约定
2. 调用端发送服务调用参数,服务端接收调用参数 -> 参数入栈
3. 入栈参数展开，并调用真正的服务函数 -> 函数执行
4. 将真正的服务函数返回值返回 -> 返回值返回

实现以上步骤，就能够实现一个函数代理。

对于手工设计这些rpc步骤实现，是没有问题的，但我们这边但目标是，只要是能够代码自动完成的，那就坚决不手动去做。

最终效果呈现

对于模式化的代码生成，c++的模版是不二选择。
希望的是最终本进程进行远程调用一个函数就和在本地进行调用函数一样。(甚至是代码形式上的一样)
调用端+服务端整个框架压缩到10句以下

发送端:

1. 首先按照通信方式生成一个支持对应通信方式的RpcStack对象，这个对象负责和实际执行端进行数据收发交互。
2. 将这个RpcStack对象以及对端需要执行的动作(后简称调用约定)注入到函数代理对象中
3. 像一个正常函数一样调用它并获取返回值，通过异常捕获的方式捕获通信过程中可能产生的错误。

using rpc_type = enum{
    k_func1_t = 0,
    k_func2_t = 1,
    k_func3_t = 2,
};

int main(int argc,char *argv[])
{
    int a = 0;
    struct data{
        char data[20];
    }b;
    float c = 1.0f;
    bool d = true;
    int ret = 0;

/**********************以下为rpc函数代理的创建和调用过程*********************/
    /**
     * 发送端如果调用一个函数「int func(int a, struct data b, float c, bool d);」
     * 首先,创建一个代理仿函数，模版参数为<返回值类型>,注入的是通信栈和被调用函数的约定符号,
     * 约定符号此处为一个枚举k_func_t,也可以是其它的类型
     */
    ez_rpc::RpcStack stack = ez_rpc::RpcStack("test.socket");
    ez_rpc::RpcCallProxy<int> proxy_func(stack,k_func_t);

    /**
     * 然后按照正常函数调用方式调用即可,需要捕获抛出的异常(通信过程中的异常)
     */
    try{
        ret = proxy_func(a,b,c,d);
    }catch(ez_rpc::rpc_err_t err) {
        RPC_DBG("proxy rpc fun failed,err"<<err);
    }
/**********************以上为rpc函数代理的创建和调用过程*********************/

    return 0;
}

接收端:

1. 得到请求，拿到通信链路，然后接收对端给过来的约定符号，看看要调用哪个方法
2. 找到调用的方法，并注入到这个微形的rpc调用模版中
3. 由模版中完成方法调用和返回值返回，一把梭

using rpc_type = enum{
    k_func_t = 0,
};

struct data{
    char data[20];
};

/**
 * 这是需要被代理函数的本地
 */
int func(int a, struct data b, float c, bool d)
{
    //...
    return ret;
}

int main(int argc,char *argv[])
{
    /**
     * 构造一个表,表里对应的是调用符号和调用方法之间的关系，调用方法可以是普通函数，也可以是对象的成员函数，也可以是闭包（仿函数）
     */
    static std::map<rpc_type,auto> rpc_table={
        {k_func1_t, func)}
        {k_func2_t, func)}
        {k_func3_t, func)}
    };

    while(1)
    {
#if 1
/**********************以下为服务端rpc实际函数的查询和调用过程*********************/
       /**
        * 直接点,三句话,搞定整个服务端主流程
        */
        ez_rpc::RpcStack stack = AcceptRequest("test.socket");
        const rpc_type& symbol = ez_rpc::getArgs<0>(ez_rpc::RpcArgs<rpc_type>(stack));

        ez_rpc::rpcBind rpc_bind(stack)(rpc_table[symbol]);
/**********************以上为服务端rpc实际函数的查询和调用过程*********************/
#else
       /**
        * 展开描述一下，效果和上面是一样的
        * 接收端但stack应该是收到对端请求后生成的，比如accept，这里生成的stack后面用来接收参数
        * 拿到stack之后，先把调用符号接收了,严谨一点的话需要确保symbol在合理范围内
        */
        ez_rpc::RpcStack stack = AcceptRequest("test.socket");
        ez_rpc::RpcArgs<rpc_type> args(stack);
        const rpc_type& symbol = ez_rpc::getArgs<0>(args);

       /**
        * 然后通过这个symbol找到对应本地需要调用的方法
        */
        auto func = rpc_table[symbol];

       /**
        * 最后把这个方法注入进这个微形的rpc调用模版
        */
        ez_rpc::rpcBind rpc_bind(func);

       /**
        * 并把协议栈也注入进去，完成调用,整个参数接收过程以及调用返回都封装到rpc_bind中完成
        * 返回的是rpc框架的调用结果，可以不用管
        */
        rpc_bind(stack);
#endif
    }

    return 0;
}

rpc模版封装

发送端代理模版封装

发送端需要做的事情相对简单，就是发送调用约定,发送参数然后接收返回值。
发送和接收都是模式化的步骤，区别仅在于不同参数（返回值）类型，其要发送的字节数是不同的。

因为和普通的函数调用一样，代理接口一样需要传参数，所以对于每个参数的发送字节数，我们只需要将它们丢进去，由模版推倒类型后调用对应的发送接口就好了。

另外为了提高效率，其必然都是常量引用传递的，或者指针也一样（当然不是指针值本身）,不使用值传递。

返回值需要单独在模版中声明，这个暂时没有办法推倒。

具体实现

1. 发送调用约定及返回值接收没有什么特别的，主要描述一下个数可变类型不固定的参数压栈的模版方法。此处使用变参模版进行递归进行实现。

// function 1
template<class ... __ARGS>
bool pushStack(__ARGS... args) {
    return true;
}

// function 2
template<class __THIS_ARG,class ... __ARGS>
bool pushStack(__THIS_ARG* first_arg,__ARGS... args) {

    bool ret = pushStack(args...);
    
    ret &= stack_.pushStack(first_arg,sizeof(__THIS_ARG));

    return ret;
}

// function 3
template<class __THIS_ARG,class ... __ARGS>
bool pushStack(const __THIS_ARG& first_arg,__ARGS... args) {
    /*和上面的function2一样，惜字如金可以这样写*/
    return pushStack(args...) & stack_.pushStack(&first_arg,sizeof(__THIS_ARG)); 
}

变参模版递归以及参数类型萃取

里面涉及了两个很有趣的概念,变参模版的递归以及参数类型萃取。

1. 变参数模版递归,首先形如:

pushStack(a,b,c,d);

的调用方式，都会匹配进function2或者function3,并且__THIS_ARG&或者__THIS_ARG*会匹配上decltype(a)(也就是a的实际数据类型)
而后，在pushStack中出发递归调用:

pushStack(b,c,d);

同理，在这一层处理数据b的类型。
最终会递归到

pushStack();

此时根据c++模版的SFINAE机制，最终会匹配到function1:

template<class ... __ARGS>
bool pushStack(__ARGS... args) {
    return true;
}

从而结束递归。

2. 参数类型萃取
   在前面我们提到另外为了提高效率，其必然都是常量引用传递的，或者指针也一样（当然不是指针值本身）,不使用值传递。
   而在模版函数中，我们希望发送的是这个指针指向数据的类型而不是指针类型,因此在此处也涉及到了参数萃取.
   拿形参为指针类型举例:

long long a = 0;

pushStack(&a);

如果模版函数写为

template<class __THIS_ARG,class ... __ARGS>
bool pushStack(__THIS_ARG first_arg,__ARGS... args) {

    bool ret = pushStack(args...);
    
    ret &= stack_.pushStack(first_arg,sizeof(__THIS_ARG));

    return ret;
}

那么__THIS_ARG类型推倒出来的类型为long long *,显然后面的sizeof会出现问题。
因此，此处的模版函数为

template<class __THIS_ARG,class ... __ARGS>
bool pushStack(__THIS_ARG* first_arg,__ARGS... args);

使用long long *去匹配__THIS_ARG*,因为把long long萃取到了__THIS_ARG中。
函数萃取在服务端还有更多的应用。

2. 有了前面的操作之后，对于发送端来说，最大的问题就解决了，当然我们还需要stack_对象负责完成底层通信，另外我们希望能像函数一样调用这个代理方法。
   这个简单，直接拿一个代理类封装一下，并实现operator()就好了,这样每个RpcCallProxy对象就是一个仿函数（或者理解为闭包)。

template<class RET>
class RpcCallProxy {
private:
   /* ... */
public:
    template<class ... __ARGS>
    RET operator()(__ARGS... args) {
        RET ret;
        /* 调用约定 */
        if(!stack_.pushStack(symbol_,sizeof(symbol_)))
        {
            throw k_rpc_func_not_found;
        }

        /* 参数压栈 */
        if(!pushStack(args...))
        {
            throw k_rpc_param_push_failed;
        }

        /* 返回值返回 */
        if(!stack_.getReturn(&ret,sizeof(RET)))
        {
            throw k_rpc_ret_get_failed;
        }

        return ret;
    }
};

operator()是一个成员函数同时也是一个模版函数，其形参的模版类型列表也是自动推导，返回值需要模版声明。

服务端代理模版封装

服务端设计

接收端的流程需要对应发送端，需要：

1. 获取调用约定，明白客户端需要调用什么函数方法
2. 获取客户端压栈的调用实参
3. 调用本地方法，并得到返回值
4. 返回值返回

其中关键的有两步，就是上面的2和3；接收对端压栈的实际参数，并调用本地函数。
实际上第二步的过程，可以依赖第三步中本地函数声明来自动化。
下面我们拆开依次实现上面两个步骤。

实参接收

实参接收模版类

假设我们已经知道了本地的形参列表，那么应该如何去依次接收这个列表里的参数？
和发送端类似，依然是使用递归，只不过这次使用模版类递归

为何发送的时候使用模版函数递归，而接收的时候使用类模版递归？

主要原因是接收端是延迟调用，数据并不是接收一个就使用一个，而是全部接收完再进行调用。
而发送端是解析一个数据就处理一个数据。

正常的情况，就是写成下面这样:

/**
 * 参数栈模版类声明
 */
template <class ... __ARGS_TYPE>
class RpcArgs;

/**
 * 空模版特化声明，此为递归的结束条件
 */
template <>
class RpcArgs <> {
private:
    RpcStack& stack_;

public:
    RpcArgs(RpcStack& stack):stack_(stack) {}
    virtual ~RpcArgs() {}
};

/**
 * 单参数接收模版特化声明，用来接收单个参数
 */
template <class __THIS_TYPE, class ... __ARGS_TYPE>
class RpcArgs <__THIS_TYPE, __ARGS_TYPE ...> : public RpcArgs<__ARGS_TYPE ...> {
private:
    //接收参数的通信栈封装
    RpcStack& stack_;
    //这个变量就是栈中某一个参数存储的位置
    __THIS_TYPE value_; 
public:
    //构成栈的关键就是递归继承
    RpcArgs(RpcStack& stack) : RpcArgs<__ARGS_TYPE ...>(stack),
                               stack_(stack)
    {
        stack_.popStack(&value_,sizeof(__THIS_TYPE));
    }
    virtual ~RpcArgs() {}
    //输出栈中当前位置的参数
    __THIS_TYPE getValue()
    {
        return value_;
    }
};

假如有一个参数列表为RpcArgs<int, long long, bool, short>的模版，
那么首先它会适配class RpcArgs <__THIS_TYPE, __ARGS_TYPE ...>, 这里的__THIS_TYPE就是int, 而__ARGS_TYPE ...就是long long, bool, short,
而它的继承的父类声明为public RpcArgs<long long, bool, short>
那么这个int就提取出来了，然后我们在构造函数里调用通信栈去接收这个参数就行啦。
同时，父类又会继续展开下去，依次对参数完成接收。

一直到 template <> class RpcArgs <>结束递归。

RpcArgs<int, long long, bool, short>声明的对象最后得到的就是一个函数栈,箭头表示栈生长方向:
<======== <============ <======= <=========
｜–int–｜--long long–｜--bool–｜--short–｜

特别注意！因为类初始化的顺序，父类总是优先于子类初始化，所以参数列表中，short是最先接收的，而int是最后接收的。

有趣的是，如果是以压栈形式进行函数调用，参数的压栈顺序也是从右到左的，果然并不是巧合

实参展开，接口调用

在得到RpcArgs<int, long long, bool, short>对象之后，应该怎么去把这个参数栈展开输入到我们想调用的函数呢？

很早之前考虑这个rpc函数代理模版实现的时候，就卡在这一步，调用本地函数涉及到压栈参数展开以及传入本地函数???

这让我一度以为这是c做不到,直到看到了std::thread构造函数调用方法，这才发现其实早有
类似问题 *c - How do I expand a tuple into variadic template function’s arguments?* 的解决方法,而RpcArgs也是参考std::tuple原理设计的。

魔法来了！

参考了std::tuple的参数展开，我们按照类似的步骤设计以下代码:

参数展开如下:

//progress1
template<class __ARGS, std::size_t... I>
ret_t do_call(__ARGS& args,std::index_sequence<I...>) const {
    return proxy_func_(getArgs<I>(args)...);
}

//progress2
ret_t do_call(RpcArgs<__ARGS_TYPE...>& args) const {
    return do_call(args, std::make_index_sequence<args_size<RpcArgs<__ARGS_TYPE...>>::value>());
}

其中，proxy_func_为我们真正想要调用的"函数",ret_t为proxy_func_的返回值类型,__ARGS_TYPE...为proxy_func_的参数列表。

这俩放后面说，函数加引号是因为它也可以是一个仿函数（functor）或者在其它一些语言里又叫闭包。

整个过程其实就是progress2静态重载了progress1,拆成两步的原因依然是参数萃取。(这里萃取的是__ARGS_TYPE...的个数)
其中的参数展开的关键步骤是getArgs<I>(args)...

em。。。先观察一下相对好理解的progress2:

1. args_size<T>::value用来获取类型T的模版参数个数，这里T = RpcArgs<__ARGS_TYPE...>，也就是说获取的是__ARGS_TYPE...的个数
2. std::make_index_sequence<N>()用来生成一个类型为std::index_sequence<I...>的参数。
   • 打个比方比较容易说明std::make_index_sequence<4>()的结果为std::index_sequence<0,1,2,3>
   • 因为这俩模版类，因此需要c++14以上标准才能支持编译

然后就到了progress1:

1. 乍一看这个函数声明ret_t do_call(__ARGS& args,std::index_sequence<I...>) const感觉不太对劲，实际上完整的应该是ret_t do_call(__ARGS& args,std::index_sequence<I...> use_less) const，因为后面的这个use_less实际在函数内是用不到的（这边取useless也是为了表示这玩意没用），所以只剩下类型声明。

2. 关键来了return proxy_func_(getArgs<I>(args)...);,我们想要调用的函数是proxy_func_,getArgs<I>(args)...为c++11语法糖,参数包扩展。

   • 如果<I...> = <0,1,2,3> ,那么proxy_func_(getArgs<I>(args)...)就变成了proxy_func_(getArgs<0>(args),getArgs<1>(args),getArgs<2>(args),getArgs<3>(args))

3. 所谓的getArgs<I>就是获取RpcArgs<Args...>中的第I个参数而已。

下面补上从参数栈中获取第i个参数的getArgs<I>实现:

template <int N, class ... __ARGS_TYPE>
struct element;

//if N > size assert error
template <int N>
struct element<N, RpcArgs<>> {
    static_assert(0 > N, "Index outside of argument stack!");
};

// find finnal 
template <class __THIS_TYPE, class ... __ARGS_TYPE>
struct element<0, RpcArgs<__THIS_TYPE, __ARGS_TYPE ...>>
{
    using value_t = __THIS_TYPE;
    using class_t = RpcArgs<__THIS_TYPE, __ARGS_TYPE ...>;
};

// Expand arguments
template <int N, class __THIS_TYPE, class ... __ARGS_TYPE>
struct element<N, RpcArgs<__THIS_TYPE, __ARGS_TYPE ...>> 
: public element<N - 1, RpcArgs<__ARGS_TYPE ...>> {
};

// Get argument with index of N 
template <int N, class ... __ARGS_TYPE>
auto getArgs(RpcArgs<__ARGS_TYPE ...>& args) {
    using __class_t = typename element<N, RpcArgs<__ARGS_TYPE ...>>::class_t;
    return ((__class_t &)args).getValue();
}

借助element对参数栈RpcArgs进行剥壳提取参数，依然是迭代和萃取，描述到此处应该已经能理解这种类似的模版元编程手法。
以上都是在编译期间由编译器完成推倒。

有了以上这些组件之后，我们再加亿点点封装！

把之前实现到do_call,getArgs,RpcArgs再组合一下成一个服务端代理类RpcServerProxy,实现如下：

template<class __RET_TYPE,class __FUN_TYPE,class ... __ARGS_TYPE>
class RpcServerProxy:public RpcServerProxyBase{
private: 
    // 绑定函数 
    __FUN_TYPE proxy_func_;
private: 
    template<class __ARGS, std::size_t... I>
    // 刚刚实现的do_call
    __RET_TYPE do_call(__ARGS& args,std::index_sequence<I...>);
    __RET_TYPE do_call(RpcArgs<__ARGS_TYPE...>& args);
public:
    RpcServerProxy(__FUN_TYPE bind_func):proxy_func_(bind_func) {};
    virtual ~RpcServerProxy() {};

    // 延迟调用接口，注入通信对象后，调用实际rpc流程
    rpc_err_t operator()(RpcStack& stack)
    {
        try{
            //接收参数
            RpcArgs<__ARGS_TYPE...> Args(stack);
            //调用服务
            const __RET_TYPE& ret = do_call(Args);
            //返回对端
            stack.popReturn(&ret,sizeof(__RET_TYPE));
        }catch(rpc_err_t err){
            return err;
        }

        return k_rpc_ok;
    }
};

已经很接近完成了，不过美中不足的是，对于一个模版类，我们在使用的时候还需要声明模版具体类型，尤其是里面的返回值类型和形参列表，其在函数声明类型中均已包含，那么能不能再节省掉这部分的类型声明？

在实际体验中，因为有了RpcCallProxy和RpcArgs已经能够自动的发送参数和接收参数实际已完成大半重复的工作量，
但对于RpcServerProxy的使用，还不足够方便（冗长的模版参数列表）。
实际上由于函数声明的存在，我们还可以进一步进行封装，直接绑定外部函数声明，通过萃取函数声明中的返回值类型和形参列表来更进一步节省RpcArgs模版参数的声明和函数调用以及参数返回流程。

本地函数的形参&返回值萃取

剩下需要解决的就是:

1. 根据proxy_func_的类型__FUN_TYPE,推导参数列表__ARGS_TYPE...和返回值类型__RET_TYPE推导。
2. proxy_func_本身的类型规整，进行完备的考虑。

仿函数的引入大大的增加了复杂度，区别于一个函数指针，传入的仿函数对象，可能是左值，右值，或者是指针的情况,并且！还得考虑它们的生命周期和对应的管理者

函数指针类型

函数类型对标std::bind实现，支持闭包。
这带来了一点复杂度，即这个函数类型即可以是普通函数指针，也可以是一个闭包函数。(仿函数)

闭包不展开了,cpp里的闭包就是重载了()操作符的类，即实现operator()方法的类，即也支持匿名函数绑定到这个rpc框架中（可以实现自动接收远程参数并调用一个匿名函数）。
c++的匿名函数比较特殊，在无外部参数捕获的时候，它是一个函数指针，而在有外部参数捕获的时候，它是一个对象（仿函数）

因为这个类型即可能是函数指针，也可能是一个对象指针。(这也是为啥上一节描述对函数加了引号，因为其是广义上的函数,包含了仿函数这种对象)
所以在后面我们用一个类型func_t单独指代这个proxy_func_.

返回值类型萃取和绑定"函数"类型规整

返回值类型依然使用萃取的方式,对operator()进行特殊的处理,如果是对象，那么查询其operator()成员函数的返回值类型：

/**
 * @brief result type traits
 */
template <typename C>
struct result_traits : result_traits<decltype(&C::operator())> {};

template <typename T>
struct result_traits<T*> : result_traits<T> {};

/* check function */
template <typename R, typename... P>
struct result_traits<R(*)(P...)>{ typedef R type; };

/* check member function */
template <typename R, typename C, typename... P> 
struct result_traits<R(C::*)(P...)> { typedef R type; };

/* check const member function */
template <typename R, typename C, typename... P> 
struct result_traits<R(C::*)(P...) const> { typedef R type; };

写到这里，模版特化以及SFINAE用出了一种正则表达式的错觉.

函数类型直接使用#include <type_traits>库提供的std::decay进行类型退化(退化指把引用或者指针指向的类型萃取出来)

规整后：

template<class __FUN_TYPE,class ... __ARGS_TYPE>
class RpcServerProxy:public RpcServerProxyBase{
private: 
    // 绑定的函数类型和返回值类型
    using func_t = typename std::decay<__FUN_TYPE>::type;
    using ret_t  = typename result_traits<__FUN_TYPE>::type;

    // 绑定函数 
    func_t proxy_func_;

private: 
    template<class __ARGS, std::size_t... I>
    ret_t do_call(__ARGS& args,std::index_sequence<I...>) {
        return proxy_func_(getArgs<I>(args)...);
    }

    ret_t do_call(RpcArgs<__ARGS_TYPE...>& args) {
        return do_call(args,
                       std::make_index_sequence<args_size<RpcArgs<__ARGS_TYPE...>>::value>());
    }
public:
    RpcServerProxy(func_t bind_func):proxy_func_(bind_func) {};
    virtual ~RpcServerProxy() {};
    rpc_err_t operator()(RpcStack& stack) {
        try{
            /**
             * Receive Args in RpcArgs 
             * and input to process for bind funciton
             * return value
             */
            RpcArgs<__ARGS_TYPE...> Args(stack);

            const ret_t& ret = do_call(Args);
            stack.popReturn(&ret,sizeof(ret_t));
        }catch(rpc_err_t err){
            return err;
        }

        return k_rpc_ok;
    }
};

真的是最后一步了

由于c++的模版类的类型参数没法自动推导,到目前为止，我们封装的RpcServerProxy还只是一个模版对象。

那么只要用一个创建这个对象的函数对这个对象的创建过程进行一个封装，就不用对这个模版类模版列表进行手动声明了。

/* check lamda function */
template <typename R, typename C, typename... __ARGS_TYPE> 
auto bind(C lambda,R(C::*useless)(__ARGS_TYPE...) const)
    -> RpcServerProxy<decltype(lambda),__ARGS_TYPE...> {
    return RpcServerProxy<decltype(lambda),__ARGS_TYPE...>(std::forward<C>(lambda));
}

template <typename R, typename C, typename... __ARGS_TYPE> 
auto bind(C lambda,R(C::*useless)(__ARGS_TYPE...))
    -> RpcServerProxy<decltype(lambda),__ARGS_TYPE...> {
    return RpcServerProxy<decltype(lambda),__ARGS_TYPE...>(std::forward<C>(lambda));
}

template <typename C>
auto bind(C&& lambda) {
    return bind(std::forward<C>(lambda),decltype(&C::operator())());
}

/* check function */
template <typename R,  typename... __ARGS_TYPE> 
auto bind(R(*func)(__ARGS_TYPE...))
    -> RpcServerProxy<decltype(func),__ARGS_TYPE...> {
    return RpcServerProxy<decltype(func),__ARGS_TYPE...>(func);
}

最终达到的效果,使用bind构造一个RpcServerProxy对象,然后注入stack的时候，完成延迟调用：
单独声明了一个RpcServerProxyBase虚基类作为RpcServerProxy的抽象接口，可以用指针或者引用接住bind的返回结果。

ez_rpc::bind(
    [](bool c)->int {printf("Args From client=>%s\n",c?"true":"false");return 0;}
)(stack);

小结

实践已经检验这套封装还是可以有效提高效率降低加班时间，也算是达到了目的。

不过缺点也很明显,一堆模版类,让人连看的欲望都不会有,可读性为0。
好在使用的时候接口封装程度相对足够高，用起来比看起来简单，尤其是仿函数支持,使用过程中还是很重要的。

接口使用说明戳这里

仿函数支持

仿函数支持的目的是为了被调用函数既能获取远端传入信息，也可以获得本地传入的信息。
和标准库中std::bind的实现不同的是，在服务端，ez_rpc::bind并没有输入函数的实参，因而无法由函数实参推导形参模版列表，所有的形参模版列表均由函数声明中萃取。
因此也就没法简单的像std::bind使用占位符了。

因此我们使用类似匿名函数的外部捕获方案来获取本地的一些非全局信息输入方式。

graph TB
    subgraph 服务端
        本地参数-->|注入|仿函数
        仿函数-->|bind|RpcServerProxy
        accpet-->|远程参数|RpcServerProxy
    end
    subgraph 调用端
        caller-->|请求|accpet
    end

局限性

虽说方便了不少，不过局限性依然在：

1. 参数必须是pod类型(或描述为stardard layer标准布局)，毕竟这个需要跨进程使用。
2. 参数不能为数组，比如char[20]这种，毕竟模版只能推出一个字长的指针。(可以封装到结构体中推导结构体类型)
3. 参数size不能太大，不能搞个几兆的结构体，毕竟在这套模版里，对标函数调用，所有的实参还是保存在栈中（可以修改为保存在堆中解除这个限制）
4. 在发送端引入了c++的异常机制，需要额外注意异常安全(其实是去掉异常的，只要对端返回值放到调用端的形参中返回，只不过强迫症没这么处理)
5. 不像本地函数调用一样，能够支持不定长参数输入,输入和取出的参数个数必须保持一致(要求会不会太高了？)
   • 不定长参数函数比如printf，或者是一些声明3个参数的回调但是输入4个参数的情况（调用约定中，如果是由调用者清楚调用堆栈是可以这么做的）