【Java手写RPC框架系列-1】—— 基础知识准备：RPC+Netty

news/2024/11/17 9:06:22/文章来源:https://www.cnblogs.com/P201821440041/p/18357932

代码随想录知识星球介绍
https://articles.zsxq.com/id_m76jd72243bi.html
基于Netty手写实现RPC
https://www.cnblogs.com/mic112/p/15565795.html

项目背景与介绍

RPC：
- 远程过程调用协议：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样；
- 要点
  - RPC是协议
  - 网络协议或者网络IO模型对其透明；RPC客户端认为自己在调用本地对象；不关心传输层协议
  - 信息格式透明：参数以某种信息格式传递给网络上另一台计算机，信息格式是怎么构成的，调用者不关心
  - 跨语言能力：不清楚远程服务器的应用程序是使用什么语言运行；对调用方来说，无论服务器方使用什么语言，本次调用都应该成功；返回值也应该按照调用方程序语言所能理解的形式进行描述。
常用RPC技术或框架
- 应用级
- 远程通信协议：RMI、Socket、SOAP（HTTP XML）、REST（HTTP JSON）
- 通信框架：MINA和Netty
目的：仿照市场主流的RPC框架设计思想，使用java手动实现一个高性能、高可用性的RPC框架

业内主流RPC

Thrift：thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。
Dubbo：Dubbo是一个分布式服务框架，以及SOA治理方案。其功能主要包括：高性能NIO通讯及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与降级等。 Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架，Dubbo自2011年开源后，已被许多非阿里系公司使用。

基础需求

场景：
服务端B：有一个用户表
1.UserService 里有一个功能： getUserByUserId(Integer id)
2.UserServiceImpl 实现了UserService接口和方法
客户端A：
- 调用getUserByUserId方法，内部传一个Id给服务端，服务端查询到User对象返回给客户端
实现过程：
- 客户端A
  - 调用getUserByUserId方法时，内部将调用信息处理后发送给服务端B，告诉B我要获取User
  - 外部调用方法，内部进行其它的处理——这种场景我们可以使用动态代理的方式，改写原本方法的处理逻辑。比如，当我们正常调用getUserByUserId方法，代码逻辑是去数据库中找user，但是在当前远程调用的场景下肯定不能走这样的逻辑；我们通过动态代理的方式，绕过【去数据库查询】这原始的逻辑，改成封装信息发送到B中请求调用服务
- 服务器B：
  - 监听A请求，接收A的调用信息，并根据信息得到A想调用的服务与方法
  - 根据信息找到对应的服务，进行调用后将结果发送回给A
- A和B之间通信
  - Java的Socket网络编程通信
  - 为了方便A,B直接对信息进行处理，将请求信息和返回信息封装成统一的消息格式

网络IO通信

传统BIO模式/同步阻塞IO：客户端向服务端发起一个数据读取请求，客户端在收到服务端返回数据之前，一直处于阻塞状态，直到服务端返回数据后完成本次会话。
- 一个连接一个线程
- 客户端有连接请求时，服务器端启动一个线程进行处理
- 适合场景：HTTP请求
- 阻塞点：
  - 服务端接收客户端连接时的阻塞；
  - 客户端和服务端IO通信时，数据未就绪情况下阻塞；
NIO/非阻塞IO：客户端向服务端发起请求时，如果服务端的数据未就绪的情况下，客户端请求不会被阻塞，而是直接返回。
- 客户端只能通过轮询的方式来获得请求结果
- NIO仍然有一个弊端，就是轮询过程中会有很多空轮询，而这个轮询会存在大量的系统调用（发起内核指令从网卡缓冲区中加载数据，用户空间到内核空间的切换），随着连接数量的增加，会导致性能问题。
多路复用机制
- 单个进程监视多个文件描述符（fd）
- 一旦某个描述符就绪（一般是读就绪或写就绪），能够通知程序进行相应的读写操作
- 常见多路复用方式：
  - 【select】：进程可以通过把一个或者多个fd传递给select系统调用，进程会阻塞在select操作上，这样select可以帮我们检测多个fd是否处于就绪状态，这个模式有两个缺点
    - 当前进程需要线性轮询所有的fd，也就是监听的fd越多，性能开销越大
    - 在单个进程中能打开的fd是有限制的，默认是1024
  - 【poll】：
  - 【epoll】：inux还提供了epoll的系统调用，epoll是基于事件驱动方式来代替顺序扫描，因此性能相对来说更高
    - 当被监听的fd中，有fd就绪时，会告知当前进程具体哪一个fd就绪，那么当前进程只需要去从指定的fd上读取数据即可，另外，epoll所能支持的fd上线是操作系统的最大文件句柄，这个数字要远远大于1024

什么是fd：在linux中，内核把所有的外部设备都当成是一个文件来操作，对一个文件的读写会调用内核提供的系统命令，返回一个fd(文件描述符)。而对于一个socket的读写也会有相应的文件描述符，成为socketfd。

【使用NIO的api来完成多路复用机制，实现伪异步IO。】
【Netty的I/O模型是基于非阻塞IO实现的，底层依赖的是JDK NIO框架的多路复用器Selector来实现。一个多路复用器Selector可以同时轮询多个Channel，采用epoll模式后，只需要一个线程负责Selector的轮询，就可以接入成千上万个客户端连接。】