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

代码随想录知识星球介绍
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

  1. Thrift：thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务。
  2. 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的轮询，就可以接入成千上万个客户端连接。】



  • 异步IO
    • 数据就绪后，客户端不需要发送内核指令从内核空间读取数据，而是系统会异步把这个数据直接拷贝到用户空间，应用程序只需要直接使用该数据即可；

Netty —— 高性能通信框架

Netty提供了上述三种Reactor模型的支持，我们可以通过Netty封装好的API来快速完成不同Reactor模型的开发，这也是为什么大家都选择Netty的原因之一，除此之外，Netty相比于NIO原生API，它有以下特点：

  • 提供了高效的I/O模型、线程模型和时间处理机制
  • 提供了非常简单易用的API
  • 对数据协议和序列化提供了很好的支持
  • 稳定性，Netty修复了JDK NIO较多的问题
  • 可扩展性在同类型的框架中都是做的非常好的
  • 性能层面的优化
    • 对象池复用
    • 零拷贝技术
posted @ 2024-08-13 23:20  哆啦**  阅读(68)  评论(0)  编辑  收藏  举报