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修饰的函数，在调用函数的时候，会一直阻塞在函数的调用中，等待另外一方的返回结果，这种是同步状况，会致使客户端阻塞，切记！！