近年来，微服务非常的流行，那么为什么是它？简单介绍一下。
为什么是微服务？
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
听明白了吗？反正我是不明白。对于一家稍微大点的公司来说，肯定会有N个系统，每个系统都有自己的功能与职责划分，并且这些系统会通过一些中间件(消息发送系统)进行消息的交互。那么按照传统的项目构造方式，A系统需要调用B系统，B系统调用C系统，
C可能又调用B系统，对于业务复杂点的公司，这很正常。那么如果哪天B系统改了某个功能，A系统就得跟着改变，然后一起上线；又或者使用的这些消息中间件突然发了一个新版本，所有用到消息中间件的系统都得去升级这些消息中间件的版本，这样所带来的
成本是非常大的。可能A系统这版本啥需求都没有，但是由于B的改动，也需要去找开发留守上线，浪费人力资源。
那么微服务是个啥样的概念呢？每个消息中间件单独为一个服务，而不是以jar包的形式存在，A、B、C系统之间的交互可以通过rpc的方式实现。著名的dubbo框架就是实现了rpc，那么rpc是什么？
什么是rpc
1、概念
RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的，本质上编写的调用代码基本相同。
说白了就是调用远程方法跟调用本地方法似的。
2、功能目标
RPC 的主要功能目标是让构建分布式计算（应用）更容易，在提供强大的远程调用能力时不损失本地调用的语义简洁性。为实现该目标，RPC 框架需提供一种透明调用机制让使用者不必显式的区分本地调用和远程调用。
3、rpc架构
架构图如下：
这里 user 就是 client 端，当 user 想发起一个远程调用时，它实际是通过本地调用 user-stub。user-stub 负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的 RPCRuntime 实例传输到远端的实例。远端 RPCRuntime 实例收到请求后交给 server-stub 进行解码后发起本地端调用，调用结果再返回给 user 端。
上面的图是个粗粒度的，下面来个细粒度的架构图：
RPC 服务方通过 RpcServer 去导出（export）远程接口方法，而客户方通过 RpcClient 去引入（import）远程接口方法。客户方像调用本地方法一样去调用远程接口方法，RPC 框架提供接口的代理实现，实际的调用将委托给代理RpcProxy 。代理封装调用信息并将调用转交给RpcInvoker 去实际执行。在客户端的RpcInvoker 通过连接器RpcConnector 去维持与服务端的通道RpcChannel，并使用RpcProtocol 执行协议编码（encode）并将编码后的请求消息通过通道发送给服务方。RPC 服务端接收器 RpcAcceptor 接收客户端的调用请求，同样使用RpcProtocol 执行协议解码（decode）。解码后的调用信息传递给RpcProcessor 去控制处理调用过程，最后再委托调用给RpcInvoker 去实际执行并返回调用结果。
各组件解释：
spring cloud深入学习(一)-----什么是微服务？什么是rpc？
原文：https://www.cnblogs.com/alimayun/p/10817139.html