一、互联网架构演变

在这里插入图片描述

1.1 RPC架构

RPC 架构是指在 MVC 架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用。

RPC：Remote Procedure Call，远程过程调用。他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
代表技术： Thrift (Facebook 开发的系统内部各语言之间协调通讯的 RPC 框架，带有强大的代码生成引擎，支持跨语言、多平台调用的)、Hessian (基于HTTP协议的 RPC 框架，提供 RMI 功能，且采用二进制协议的轻量级框架) 等等。
优点：应用直接调用服务，服务之间是隔离的。
缺点：服务过多时，管理成本高昂。服务治理，服务注册、发现，服务容错，服务跟踪，服务网关，IP暴露等都是此架构无法避免的问题。

1.2 SOA架构

SOA：Service oriented Architecture，面向服务架构；ESB：Enterparise Service Bus，企业服务总线，服务中介，主要是提供了一个服务于服务之间的交互。
ESB 的功能：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
代表技术： Mule (Java 为核心的消息框架和整合平台，提供服务中介、数据转换、消息路由、服务创建和托管等功能)、 WSO2 (开源的服务总线，提供了 SOA 基础设施的搭建，内置数据服务支持，服务角色管理等功能)。

1.3 微服务架构

微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。微服务就是一个轻量级的服务治理方案。
微服务架构在某种程度上是面向服务的架构 SOA 继续发展的产物。对比 SOA 架构，使用注册中心代替 ESB 服务总线。注册中心相比服务总线来说，更加轻量级。
代表技术： Dubbo (SOA时代的产物)、SpringCloud (微服务时代的产物)

1.4 SOA vs 微服务

在这里插入图片描述

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

回到目录…

二、RPC 基本概念

2.1 RPC 协议

RPC (Remote Procedure Call Protocol)：远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC 采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

2.2 RPC 框架

在单机时代一台电脑运行多个进程，进程之间无法通讯，显然这会浪费很多资源，因此后来出现 IPC(Inter-process communication：单机中运行的进程之间的相互通信)，这样就能允许进程之间进行通讯，比如在一台计算机中的A进程写了一个吃饭的方法，那在以前如果在B进程中也要有一个吃饭的方法，必须要在B进程中进行创建，但有了 RPC 后B只需要调用A进程的程序即可完成，再到后来网络时代的出现，大家电脑都连起来，这时可不可以调用其他电脑上的进程呢，当然可以，这样 RPC 框架就出现了。严格意义上来讲：Unix 的生态系统中 RPC 可以在同一台电脑上不同进程进行，也可以在不同电脑上进行；而在 windows 里面同一台电脑上不同进程间的通讯还可以采用 LPC(本地访问)。综上：RPC 或 LPC 是上层建筑，IPC 是底层基础。

RPC框架有很多：比如 JAVA RMI 、 Thrift 、 Dubbo 、 grpc 等。

2.3 RPC 运行流程

在这里插入图片描述

首先，要解决通讯的问题。主要是通过在客户端和服务器之间建立 TCP 连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。

第二，要解决寻址的问题。A 服务器上的应用怎么告诉底层的 RPC 框架，如何连接到 B 服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于 Web 服务协议栈的 RPC，就要提供一个 endpoint URI，或者是从 UDDI(一种目录服务，通过该目录服务进行服务注册与搜索) 服务上查找。如果是 RMI 调用的话，还需要一个 RMI Registry 来注册服务的地址。

第三，要进行序列化或编组。当 A 服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如 TCP 传递到 B 服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，通过寻址和传输将序列化的二进制发送给 B 服务器。

第四，B 服务器收到请求后，需要对参数进行反序列化，恢复为内存中的表达方式，然后找到对应的方法进行本地调用，然后得到返回值。

第五，返回值还要发送回服务器 A 上的应用，也要经过序列化的方式发送，服务器 A 接到后，再反序列化，恢复为内存中的表达方式，交给 A 服务器上的应用。

2.4 RPC vs HTTP

RPC 是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。所以 RPC 的实现可以通过不同的协议去实现，比如 HTTP、RMI 等。

RPC 是一种概念，可以通过 HTTP 来实现，也可以通过 Socket 自己实现一套协议。
HTTP 接口：信息初期的一种通信手段；优点就是简单、直接、开发方便，利用现成的 HTTP 协议进行传输。
RPC 框架：不需要复杂的三次握手，在子系统较多、接口非常多的大型网站下，减少了网络开销。
HTTP 接口：服务端必须位于 HTTP 容器里，受限于 HTTP 协议，需要带 HTTP 请求头，导致传输起来效率或者说安全性不如 RPC。
RPC 框架：它要保证传输的两端都要用 Java 实现，且两边需要有相同的对象类型和代理接口，不需要容器，但加大了编程的难度。
Java 中最基本的 RMI 技术，它是 java 原生的应用层分布式技术。在传输性能方面，RMI 的性能是优于 HTTP 的。
RPC 框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。