在服务体系架构内，我们所知道的，有两种请求模型: 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 底层框架。因此还是值得我们去发现。