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 底层框架。所以仍是值得咱们去发现。