一、RPC

　　RPC（Remote Process Call），即远程服务调用，被广泛地应用在很多企业应用中，是早期主要的服务治理方案，其流程较为简单，客户端consumer携带参数发送RPC请求到服务提供方provider，provider根据参数路由到具体函数，方法，并将执行获得的结果返回，至此一次RPC调用完成。

　　随着业务的发展，大数据时代的到来，服务提供方的压力也日益增大，单机应用的处理能力无论在软件，硬件上都受到限制，provider也不可能一直无限扩容，即使扩容，也存在着很多问题，即服务的路由，和Consumer的负载均衡问题。因此，分布式服务架构应运而生，RPC发展到一定阶段思考的变革，成为了分布式服务，云计算的计算机基础。

在RPC框架中主要有三个角色：Provider、Consumer和Registry。如下图所示：

节点角色说明，这边看起来，跟其他的服务注册与发现框架原理差不多（如 Eureka、Consul）：

Service（provider）: 暴露服务的服务提供方。

Client（consumer）: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

RPC指的是项目之间的调用。RPC是把单体项目做了粗粒度的拆分，而微服务把单体项目拆分的更零碎。

因为RPC是独立系统之间的调用，所以不太注重事务的一致性

1.1 RPC调用流程

RPC（Remote Procedure Call）远程过程调用，即一个节点通过网络调用的方式来请求另一个节点提供的服务的过程，也可以简单的理解为client访问server上提供的函数。

他的基本调用流程如下：

上面是一次完整的RPC调用流程（这边指的是同步调用情况下），步骤顺序如下：

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

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

无论是何种类型的数据，最终都需要转换成二进制流在网络上进行传输，数据的发送方需要将对象转换为二进制流，而数据的接收方则需要把二进制流再恢复为对象。

二、SOA

　　由于简单的RPC调用已经不能随着时代发展满足需求，因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈，业务希望自己的服务是分布式部署的，请求是分流的，对数据的操作是能读写分离的，同时能屏蔽许多复杂需要自己编写的底层服务，借助已有的公共服务，去快速的构建自己的应用，降低人力开发维护的成本和提高应用交付的效率，基因此，基于分布式服务思想的SOA（Service-Oriented Architecture）成了新的受追捧的架构。常见的SOA服务调用流程图如下：　

三、微服务

严格来说微服务属于RPC的一种，但是广义上的RPC指的是项目之间的调用

3.1.什么是微服务

1) Martin Fowler论文对微服务的阐述(中文版)

2) 对单一应用进行拆分

3) 每一个独立的应用都有一个独立的进程

4) 拥有自己独立的数据库

5) 微服务化的核心就是讲传统的一站式应用，根据业务拆分成一个一个的服务,彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务处理一件事,从技术角度就是一种小而独立的处理过程,类似进程的概念,能够自行单独启动或销毁,拥有自己的数据库。

3.2.微服务与微服务架构

1 ）微服务架构

1) 类似于eclipse工具里面用maven开发的一个个独立的module,具体是使用springboot开发的一个小模块,一个模块就做一件功能。

2) 强调是整体，每一个个体完成一个具体的任务或者功能，把一个个的个体拼接起来，组成一个整体并对外暴露服务。

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