客户端是ApiClient，这里的MyClient继承自ApiClient
这些就是我们刚才客户端远程调用的stub代码啦，当然，我们没有自动生成stub，也没有要求客户端跟服务端共用接口之类。实际上，我们认为完全没有必要做接口约束，大部分项目的服务接口很少，并且要求灵活多变
stub就是类似于，刚才那个MyController实现IAbc接口，然后客户端根据服务端元数据自动在内存里面生成一个stub类并编译，这个类实现了IAbc接口。
客户端直接操作接口，还以为在调用服务端 的函数呢
其实stub代码内部，就是封装了 这里的InvokeAsync这些代码，等同于自动生成这些代码，包括gRPC、Thrift等都是这么干的
框架解析这个RPC框架，封包协议就是刚才的SRMP，负载数据也就是协议是json
当需要高速传输的时候，参数用Byte[]，它就会直接传输，不经json序列化，这是多年经验得到的灵活性与性能的最佳结合点
2.1 人人都有一个自己的高性能网络库网络库核心代码：
我们一开始就是让Tcp/Udp可以混合使用，网络库设计于2005年，应该要比现如今绝大部分网络框架要老。服务端清一色采用 Server+Session 的方式。
网络库的几个精髓文件
其中比较重要的一个，里面实现了 Open/Close/Send/Receive 系列封装，Tcp/Udp略有不同，重载就好了。打开关闭比较简单，就不讲了
所有对象，不管客户端服务端，都实现ISocket。然后客户端Client，服务端Server+Session。tcp+udp同时支持并不难，因为它们都基于Socket。
目前无状态无会话的通信架构，做不到高性能。我们就是依靠长连接以及合并小包，实现超高吞吐量
一般灵活性和高性能都是互相矛盾的
2.2 高性能设计要点第一要点：同步发送，因为要做发送队列、拆分、合并，等等，异步发送大大增加了复杂度。大家如果将来遇到诡异的40ms延迟，非常可能就是tcp的nodelay作怪，可以设为true解决
第二要点：IOCP，高吞吐率的服务端，一定是异步接收，而不是多线程同步。当然，可以指定若干个线程去select，也就是Linux里面常见的poll，那个不在这里讨论，Windows极少人这么干，大量资料表明，iocp更厉害。
SAEA是.net/.netcore当下最流行的网络架构，我们可以通俗理解为，把这个缓冲区送给操作系统内核，待会有数据到来的时候，直接放在里面，这样子就减少了一次内核态到用户态的拷贝过程。
我们测试4.5Gbps，除以8，大概是 540M字节，这个拷贝成本极高
第三要点：零拷贝ZeroCopy，这也是netty的核心优势。iocp是为了减少内核态到用户态的拷贝，zerocopy进一步把这个数据交给用户层，不用拷贝了。
数据处理，我们采用了链式管道，
这些都是管道的编码器
第四要点：合并小包，NoDelay=false，允许tcp合并小包，MTU=1500，除了头部，一般是1472