摘要：调用方（服务消费者）能使应用像调用本地方法（内部接口）一样调用远程的（过程或）服务，而不用封装参数名和参数值等操作。
目录
[TOC]
RPC 框架
微服务架构中，服务之间同步调用是通过 RPC 来实现的，服务间的异步处理、应用解耦要通过 MQ来实现。
远程过程调用：在分布式系统中，应用调用不同服务器上另一个应用的方法。如，服务A 调用 服务B 中方法。
有两种实现方式：
- 服务B 对外暴露 Restful 接口，服务A通过 HTTP 请求调用 B 的接口。两个不同服务器上提供的方法不在同一个内存空间，通过网络编程才能传递参数、接收结果。
- 优点：可读性好、而且HTTP请求可以通过各种防火墙。
- 缺点：效率低、封装调用复杂。当存在大量的服务间调用时，这些缺点变得更为突出。
- RPC：RPC（
Remote Procedure Call） ：调用方（服务消费者）能使应用像调用本地方法（内部接口）一样调用远程的（过程或）服务，而不用封装参数名和参数值等操作。- 其调用协议通常包含：底层通信传输协议（TCP还是UDP）、序列化协议。
- 优点：效率高、十分易用。服务A 调用 服务B 的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。
RPC 和 RESTful 的区别
微服务和 RESTful 的区别：微服务是一种架构模式，而 RESTful API 是符合REST设计风格的 Web API。
- 两者根本不具备可比性。
- 有些微服务虽然是基于 RPC 来构建的，但是 RPC 本身又可以用 RESTful 来实现。
RPC 和 RESTful 的区别：
- RESTful API 接口：符合REST设计风格的 Web API。
- RPC（远程过程调用）：是一种远程通信协议。RPC 协议有两种主流的实现 ：
- 基于 HTTP 的：代表是 gRPC。如果一个 RPC 是基于 HTTP 的，并且 HTTP 的 API 设计是符合 REST 设计风格的，那么就可以说这个 RPC 是基于 RESTful 的。
- 基于 TCP 的：代表是 Dubbo。优点：
RESTful 接口
RESTful API 接口：符合REST设计风格的 Web API。
- 不遵守 REST 的一般就是简单描述为 Web 服务。
REST 设计风格
REST（Representational State Transfer）资源表现层状态转化：符合REST原则、规范、设计风格的架构。
- 资源（
Resources）：就是网络上的一个信息实体。如，一段文本、一张图片、一首歌曲、一种服务。
- 可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
- 表现层（
Representation）：资源具体呈现出来的外在表现形式。
- 比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；
- 图片可以用JPG格式表现，也可以用PNG格式表现。
- URI只代表资源的实体，不代表它的形式。
- 严格地说，有些网址最后的”.html”后缀名是不必要的，因为这个后缀名表示格式，属于”表现层”范畴，而URI应该只代表”资源”的位置。
- 状态转化（
State Transfer）：访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。
- 互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。
- 因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生”状态转化”（State Transfer）。
- 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。
- 分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
综合以上，RESTfu l架构是：
- 每一个URI代表一种资源；
- 客户端和服务器之间，传递这种资源的某种表现层；
- 客户端通过四个HTTP动词，对服务器端资源进行操作，实现”表现层状态转化”。
常用 RPC 框架
- Dubbo 框架：由阿里巴巴开源的分布式服务化治理框架，会通过RPC请求方式访问。还提供了一些其他开箱即用的功能、如智能负载均衡。是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战。
- Spring-cloud-alibaba-dubbo是基于SpringCloudAlibaba技术栈对dubbo技术的一种封装，目的在于实现基于RPC的服务调用。
- 高效的网络传输：基于 TCP 协议，采用单一长连接和 NIO 异步通讯方式，减少了频繁建立和断开连接的开销，提升了系统的并发处理能力，适用于高并发、小数据量的服务调用场景。
- 丰富的服务治理功能：支持服务注册与发现、负载均衡、集群容错等功能，方便构建复杂的分布式系统。
- 高度可扩展：支持多种协议（如 Dubbo 协议、HTTP 协议等）、多种序列化方式和多种集群容错策略，可以根据实际需求进行灵活配置。
- 应用场景：主要用于 Java 语言构建的分布式系统，特别是大型互联网企业的微服务架构中。
- Spring Cloud 系列框架合集：基于HTTP（s）的RETS服务构建服务体系的。能够帮助构建一整套完整的微服务架构技术生态链。是目前国内使用最广泛的微服务框架。Spring Cloud 微服务架构是由多个组件一起组成的，各个组件的交互流程。
- gRPC 协议：由 Google 开源的高性能、通用的 RPC 框架，基于 HTTP/2 协议标准设计。
- NIO 框架：非常火
- Tars 协议：腾讯开源的高性能 RPC 框架 Tars 所使用的协议，提供了服务开发、部署、监控等一站式解决方案。
- Netty：
gRPC 协议
NIO 框架
NIO（Non-blocking I/O）：非阻塞 I/O。
-
分布式系统中，服务有可能分布在网络中的各个节点中。因此，服务之间的调用对分布式系统来说，就显得尤为重要。
-
为了满足高并发下网络请求，引入了 NIO 的概念。
NIO 原理
使用阻塞 I/O 处理多个连接：
- 以前编写网络调用程序时，都会在客户端创建一个 Socket，通过这个 Socket 连接到服务端。
- 服务端根据这个 Socket 创建一个 Thread，用来发出请求。客户端在发起调用以后，需要等待服务端处理完成，才能继续后面的操作。这样线程会出现等待的状态。
- 如果客户端请求数越多，服务端创建的处理线程也会越多，JVM 处理如此多的线程并不是一件容易的事。
为了解决上述的问题，推出了 NIO 的概念。
其中，Selector 机制（多路复用器）就是 NIO 的核心。原理是：
- 当每次客户端请求时，会创建一个 Socket Channel，并将其注册到 Selector 上。
- 然后，Selector 关注服务端 IO 读写事件，此时客户端并不用等待 IO 事件完成，可以继续做接下来的工作。
- 一旦，服务端完成了 IO 读写操作，Selector 会接到通知，同时告诉客户端 IO 操作已经完成。
- 接到通知的客户端，就可以通过 SocketChannel 获取需要的数据了。
AIO 异步
上面描述的过程有点异步的意思，不过，Selector 实现的并不是真正意义上的异步操作。
- 因为 Selector 需要通过线程阻塞的方式监听 IO 事件变更，只是这种方式没有让客户端等待，是 Selector 在等待 IO 返回，并且通知客户端去获取数据。
- 真正“异步 IO”（AIO）。
Netty
Netty 是一个异步的、基于事件驱动的网络应用框架，可以用来开发高性能服务端和客户端。
Netty 作为 NIO 的实现，适用于服务器/客户端通讯的场景，以及针对于 TCP 协议下的高并发应用。
对于开发者来说，它具有以下特点：
- 对 NIO 进行封装，开发者不需要关注 NIO 的底层原理，只需要调用 Netty 组件就能够完成工作。
- 对网络调用透明，从 Socket 建立 TCP 连接到网络异常的处理都做了包装。
- 对数据处理灵活， Netty 支持多种序列化框架，通过“ChannelHandler”机制，可以自定义“编/解码器”。
- 对性能调优友好，Netty 提供了线程池模式以及 Buffer 的重用机制（对象池化），不需要构建复杂的多线程模型和操作队列。
对于高性能的 RPC 框架，Netty 作为异步通信框架，几乎成为必备品。
- 例如，Dubbo 框架中通信组件，
- 还有 RocketMQ 中生产者和消费者的通信，都使用了 Netty。
基本架构
原理
从一个简单的例子开始
Netty 是针对 NIO 的实现，在 NIO 封装，网络调用，数据处理以及性能优化等方面都有不俗的表现。
从客户端访问服务端的代码来看看 Netty 是如何运作的。再一次介绍代码中调用的组件以及组件的工作原理。
假设有一个客户端去调用一个服务端，假设服务端叫做 EchoServer，客户端叫做 EchoClient，用 Netty 架构实现代码如下。