Thrift第五课 应用模式以及运行异常

1 简单应答模式

结构模型

1）调用RPC接口的过程中，参数是请求的结构信息，返回值是服务器的反馈信息

2）对于服务器的告警信息和系统公告信息，客户端需要定时发送查询的RPC接口，然后在RPC的接口返值

中携带反馈信息

局限性

测试代码

short sThriftPort = 0;

std::string strThriftIP;

CSystemConfig::GetInstance().GetThriftServiceInfo(strThriftIP, sThriftPort);

boost::shared_ptr<UploadMessageServiceHandler> handler(new UploadMessageServiceHandler());

boost::shared_ptr<TProcessor> processor(new UploadMessageServiceProcessor(handler));

boost::shared_ptr<TServerTransport> serverTransport(new TServerSocket(sThriftPort));

boost::shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory());

boost::shared_ptr<TProtocolFactory> protocolFactory(new TBinaryProtocolFactory());

boost::shared_ptr<ThreadManager> threadManager = ThreadManager::newSimpleThreadManager(10);

boost::shared_ptr<BoostThreadFactory> threadFactory(new BoostThreadFactory());

threadManager->threadFactory(threadFactory);

threadManager->start();

TThreadPoolServer server(processor, serverTransport, transportFactory, protocolFactory, threadManager);

server.serve();

Windows下将PosixThreadFactory换成PlatformThreadFactory
Linux下将BoostThreadFactory换成PosixThreadFactory

在上述的服务器端进行客户端请求的监听，存在如下的问题

1 服务器端只有等待客户端的连接，等待客户端的请求发送，然后把应答的消息返回到客户端，如果服务器端想主动发送消息

给客户端，在当前的这种框架下是不可能实现的，必须调整当前的thrift的框架逻辑.

2 当客户端没有正常关闭套接字，服务器端会一直等待客户端的请求，没有机制确保服务器端知道客户端已经丢弃当前的连接。

这种没有客户端发送心跳确保在线的机制，是否能够满足生产的需求，有待商榷

3 客户端一般都是在NAT环境之后，所以客户端无法开启端口对服务器的推送消息进行接收，只有在客户端主动连接服务器，

保持连接的通道，可以进行双向通道的通信

4 服务器端不会主动关闭连接，关闭连接都是由客户端进行的，如果有恶意的连接，耗尽所有的线程，导致拒绝服务的风险

2 服务器模式

客户端也是服务器，需要启动端口进行监听服务器端消息的推送

局限性

客户端需要开放端口进行监听，如果客户端部署在私有的网络，通过NAT连接到公网的服务器，这一点目前单纯依赖thrift框架无法实现

3 双向通道模式

结构模型

双向通道确实可以让服务器端直接推送告警和系统公告信息给客户端，但是thrift在这种应用结构中，不允许调用的RPC接口有任何的返回值，就类似于UDP的邮件的投递，服务器端的反馈信息需要通过用RPC

发送给客户端客户端以一种类似回调的方式来获取到反馈的信息

局限性

发送的请求，需要在回调函数中得到反馈信息，对于是否执行成功，客户端需要等待

C#客户端异常剖析

1）未将对象引用设置到对象的实例 原因：无法连接Thrift服务器

2）无法将数据写入传输连接（远程主机强迫关闭了一个现有的连接） 原因：Thrift服务器崩溃或者重启，连接中断

3）应用服务跟客户端的代码不一致：调用的目标发生了异常（无法将数据写入传输连接: 你的主机中的软件中止了一个已建立的连接） 

C++接收代码

类：class TDispatchProcessor : public TProcessor

函数：

  virtual bool process(boost::shared_ptr<protocol::TProtocol> in,

                       boost::shared_ptr<protocol::TProtocol> out,

                       void* connectionContext) {

    std::string fname;

    protocol::TMessageType mtype;

    int32_t seqid;

    in->readMessageBegin(fname, mtype, seqid);

    if (mtype != protocol::T_CALL && mtype != protocol::T_ONEWAY) {

      GlobalOutput.printf("received invalid message type %d from client",

                          mtype);

      return false;

    }

    return dispatchCall(in.get(), out.get(), fname, seqid, connectionContext);

  }

WireShark抓包可以看到发送的服务接口，在服务器端可以看到接收到的RPC接口，但是发送出去的接口在限制词thrift中无法看到，只能通过限制端口来看到所有的报文信息，可以通过报文的长度来知道是哪个接口

https://www.cnblogs.com/xiaosuiba/p/4122459.html

https://blog.csdn.net/qq_27989757/article/details/50761051

文章描述了Thrift双向通信的基本机制

https://blog.csdn.net/lwwl12/article/details/77449550

oneway修饰符意味着客户端发送一个请求，但是没有监听任何的返回信息，所以oneway方法必须是void类型。没有oneway修饰的函数，在调用函数的时候，会一直阻塞在函数的调用中，等待另一方的返回结果，这种是同步情况，会导致客户端阻塞，切记！！