NetCore Netty 框架 BT.Netty.RPC 系列随讲 —（前序） REST API 与 RPC 经典网络基础服务架构

        在服务体系架构内，我们所知道的，有两种请求模型: http 请求模型，以及 rpc 请求模型。因此，在一个互联网请求模型架构上，都是这两种的请求模型的向互组合.

 

下面给出两种常见的互联网经典基础架构图：

 

  一：外：http  内：rpc                                                                        二：外：http 内： http

 

                                     

 

下面讲讲这两种网络架构的优缺点： 这里只发表我个人的看法。如果各位大神，如果有其他看法的话，那么也可随意留言：

 

共同点： http 主外，http 主外有个两个最大的优点

 

    1：对于前端框架的易用性和对异构系统的对接性更较强. 也就是说http 的跨平台性跟跨协作方面来的更  加合适, 原因为啥：原因 就是大部分同学都知道http 协议嘛。

 

     2：对于http 来说，外部的客户数量是不可控的，http 的短链接，就很好的解决这方面服务的线程资源占用的问题。 http 原本初衷就是一次请求，一个线程，一次会话的模型。 而 rpc ，则是长连接模型。客户端不活动，也会占用服务的tcp  线程连接数。

 

两张图的不同之处在于：

 

图一：内部服务集群采用rpc,   图二内部集群采用http。 这两者都有存在大厂中在， 问题仁者见仁，智者见智 

 

内部采用rpc的优点：效率高，传输快. 而rpc 为什么会效率高，传输快： 这就讲下rpc 与http 本质上的区别：

 

 http协议是应用层协议，http协议位于tcp/ip协议栈的应用层。基于http协议的客户/服务器模式的信息交换过程，分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。

 

而 rpc(remote procedure call protocol) 远过程调用协议,在osi网络通信模型中，rpc跨越了传输层和应用层。rpc信息协议由两个不同结构组成：调用信息和答复信息. 因此 在rpc 的协议包一般情况下都是自己定义，自己封装，封包。正是因为rpc 穿越了osi 的 传输层与应用层，使得它的效率更高，传输更快，也是正是应为rpc 的 协议包可以*定义，

 

因此，它的网络传输载请求单位体积就可以变得非常小, 并不像http协议包臃肿肥大。但是也正因为如此，rpc 本质的维护成本以及开发成本来的更高。从另外个角度讲，http 的对于公司角度而言：服务的迭代以及开发成本来的更加快捷，方便。

 

    个人在内部局域网内服务群集方面也是采用 http ( 考虑到公司的开发协作成本方面，还有老服务遗留下来的历史原因）。  但是.netcore netty 还是一个非常棒的实现rpc 底层框架。因此还是值得我们去发现。