1.客户端(Client)，服务的调用方。
2.客户端存根(Client Stub)，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
3.服务端(Server)，真正的服务提供者。
4.服务端存根(Server Stub)，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

PRC架构调用过程

（图片来源：
(1) 客户端（client）以本地调用方式（即以接口的方式）调用服务；
(2) 客户端存根（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；
(3) 客户端通过sockets将消息发送到服务端；
(4) 服务端存根( server stub）收到消息后进行解码（将消息对象反序列化）；
(5) 服务端存根( server stub）根据解码结果调用本地的服务；
(6) 本地服务执行并将结果返回给服务端存根( server stub）；
(7) 服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）；
(8) 服务端（server）通过sockets将消息发送到客户端；
(9) 客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）；
(10) 客户端（client）得到最终结果。

RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来

常见的RPC框架及分类

1.从通信协议的层面，大致可以分为：
基于HTTP协议的（例如基于文本的SOAP（XML）、Rest（JSON），基于二进制Hessian（Binary））
基于TCP协议的（通常会借助Mina、Netty等高性能网络框架）

2.从不同的开发语言和平台层面，分为：
单种语言或平台特定支持的通信技术(例如Java平台的RMI、.NET平台Remoting)
支持跨平台通信的技术（例如HTTP Rest、Thrift等）
3.从调用过程来看，分为：
同步通信调用（同步RPC）
异步通信调用（MQ、异步RPC）

常用的RPC 框架（技术）（以下排名不分先后）
1.Netty
Netty框架不局限于RPC，更多的是作为一种网络协议的实现框架，比如HTTP，由于RPC需要高效的网络通信，就可能选择以Netty作为基础。
2.brpc
brpc是一个基于protobuf接口的RPC框架，在百度内部称为“baidu-rpc”，它囊括了百度内部所有RPC协议，并支持多种第三方协议。
3.Dubbo
Dubbo是Alibaba开发的一个RPC框架，远程接口基于Java Interface, 依托于Spring框架
4.gRPC
Google开发的高性能、通用的开源RPC框架，主要面向移动应用开发并基于HTTP2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。
5.Thrift
Thrift是Apache的一个项目(http://thrift.apache.org)，前身是Facebook开发的一个RPC框架，采用thrift作为IDL (Interface description language)。
6.jsonrpc
JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议。
7.RMI
此处讲的是Java中的RMI，而不是通用意义上的RMI
RMI使用的是JRMP（Java Remote Messageing Protocol）, JRMP是专门为java定制的通信协议，所以踏实纯java的分布式解决方案
8.Hessian
Hessian是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能。相比WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
9.motan
新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用
10.SpringCloud

常见的RPC 框架的比较

（个人使用不多经验不足，仅仅使用过1-2个，请各位自行百度，若有好的文章也烦请留言告知，后续进行补充）

RPC协议

（百度百科）
RPC协议
英文原义：Remote Procedure Call Protocol
中文释义：（RFC-1831）远程调用协议 ,最初由RFC-1050定义。
注解：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

远程过程调用（RPC）信息协议由两个不同结构组成：调用信息和答复信息。

RPC 调用信息主体形式如下：
struct call_body {
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;
opaque_auth verf;
1 parameter
2 parameter . . .
};

RPC答复信息形式如下：　
enum reply_stat stat {
MSG_ACCEPTED = 0,　
MSG_DENIED　 = 1　
};

MVC架构、RPC架构、SOA架构、微服务架构区别

（转自
https://blog.csdn.net/lmaosheng/article/details/88337678
http://www.pianshen.com/article/8405242110/）
在这里插入图片描述

单体架构

MVC(Model View Controller)

M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。
当业务规模很小时，将所有功能都部署在同一个进程中，通过双机或者前置负载均衡器实现负载分流。
此时，加速前端页面开发，分离前后台逻辑的mvc框架是关键。
代表技术：Struts2、springMVC、Spring、Mybatis 等等

多服务架构

RPC(Remote Procedure Call)远程过程调用

RPC（Remote Procedure Call）远程过程调用，他是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

此时，用于提高业务复用及拆分的 RPC 框架是关键。

SOA(Service Oriented Architecture)面向服务架构

ESB(Enterparise Service Bus)企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

ESB包含的功能如：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急。

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

服务生命周期管控和运行态的治理成为瓶颈。

此时，用于提高机器利用率的，提升服务质量的（资源调度和治理中心）SOA 服务治理是关键。

SOA架构特点：

1.系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】

2.系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

3.业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

微服务架构(轻量级的服务治理方案)

微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务其实就是一个轻量级的服务治理方案。

微服务架构是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的Restful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

随着敏捷开发、持续交付、DevOps 理论的发展和实践，以及基于 Docker 等轻量级容器部署应用和服务的成熟，微服务架构开始流行，逐渐成为应用架构的未来演进方向。通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队敏捷交付，应用的交付周期将缩短，运营成本也将大幅下降。

微服务架构特点：
1.通过服务实现组件化
开发者不再需要协调其它服务部署对本服务的影响。
2.按业务能力来划分服务和开发团队
开发者可以自由选择开发技术，提供 API 服务
3.去中心化
每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
4.基础设施自动化（devops、自动化部署）
把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理。

相比于SOA，微服务更加轻量，代表技术:dubbo SpringCloud
注册中心是企业服务总线的一个轻量级的替代方案，代表的注册中心有zookeeper,eureka

意亦逸

发布了21 篇原创文章 · 获赞 6 · 访问量 3万+

私信关注

RPC浅谈

RPC

RPC(Remote Procedure Call)

广义上的RPC

RPC（架构）框架

RPC框架原理

PRC架构组件