RPC浅谈

RPC

• RPC(Remote Procedure Call)
• 广义上的RPC
• RPC（架构）框架
• RPC框架原理
• PRC架构组件
• PRC架构调用过程
• 常见的RPC框架及分类
• 常见的RPC 框架的比较
• RPC协议
• MVC架构、RPC架构、SOA架构、微服务架构区别
• 单体架构
• MVC(Model View Controller)
• 多服务架构
• RPC(Remote Procedure Call)远程过程调用
• SOA(Service Oriented Architecture)面向服务架构
• 微服务架构(轻量级的服务治理方案)

RPC(Remote Procedure Call)

远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
个人觉得单纯的讲RPC 是没有意义的。 RPC应该被分为广义上的RPC ,RPC框架，RPC协议（后2个暂且称之为狭义的RPC）

广义上的RPC

所谓广义RPC 根据定义 通过网络调用远程计算机上的服务即可称之为RPC 。所以任何符合该说明的都应该属于RPC。包括常见的web服务个人觉得其实也可以理解为RPC.

RPC（架构）框架

RPC框架原理

PRC架构组件

一个完整的RPC架构里面包含了四个核心的组件，分别是Client，Client Stub，Server以及Server Stub，这个Stub可以理解为存根。

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

来源：CSDN

作者：意亦逸

链接：https://blog.csdn.net/soulonlyhlh/article/details/104129508