BIO和RPC

原生JDK网络编程BIO

服务端提供IP和监听端口，客户端通过连接操作想服务端监听的地址发起连接请求，通过三次握手连接，如果连接成功建立，双方就可以通过套接字进行通信。
传统的同步阻塞模型开发中，ServerSocket（服务端必须有）负责绑定IP地址，启动监听端口；Socket（客户端必须有，服务端可以有）负责发起连接操作。连接成功后，双方通过输入和输出流进行同步阻塞式通信。
传统BIO通信模型：采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理没处理完成后，通过输出流返回应答给客户端，线程销毁。即典型的一请求一应答模型。

点击这里查看示例。

缺陷：缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈正比关系，Java中的线程也是比较宝贵的系统资源，线程数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统最终无法处理更多的请求。

伪异步I/O模型：为了改进这种一连接一线程的模型，我们可以使用线程池来管理这些线程，实现1个或多个线程处理N个客户端的模型（但是底层还是使用的同步阻塞I/O）。

缺陷：限制了线程数量（maximumPoolSize），如果发生读取数据较慢时（比如数据量大、网络传输慢等），大量并发的情况下，其他接入的消息，只能一直等待。

那么BIO是不是就没有用了呢？

BIO应用-RPC框架

为什么要有RPC？

背景
一个应用一台机器，将所有功能都写在一起。
随着我们业务的发展，我们需要提升性能了，我们会怎么做？

升级
将不同的业务功能放到不同线程里来实现异步提升性能。
但是业务越来越复杂，业务量越来越大，单个应用或者一台机器的资源是肯定背负不起的，这个时候，我们会怎么做？

再升级
将核心业务抽取出来，作为独立的服务，放到其他服务器上或者形成集群。这个时候就会请出RPC，系统变为分布式的架构。

为什么说千万级流量分布式、微服务架构必备的RPC框架？和LocalCall的代码进行比较，引入RPC框架对我们现有的代码影响最小，同时又可以帮我们实现架构上的扩展。现在的开源rpc框架，有什么？dubbo，grpc等等 。
当服务越来越多，各种RPC之间的调用会越来越复杂，这个时候我们会引入中间件，比如说MQ、缓存，同时架构上整体往微服务去迁移，引入了各种比如容器技术docker，DevOps等等。不管怎样，RPC总是会占有一席之地。

什么是RPC？

RPC：Remote Procedure Call，远程过程调用协议。它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

Client：消费方。
Server：服务方。
Stub：存根。这里是一种模拟对象。
ClientStub：客户端存根。用来模拟服务端和Client交互。
ServerStub：服务端存根。用来模拟客户端和Server交互。
封包（Marshalling）：Stub将方法名和参数打包。
解包（UnMarshalling）:Stub将包解码成方法名和参数。

一次完整的RPC同步调用流程☆

1. 消费方本地调用客户端存根
2. 客户端存根对请求参数进行封包并通过网络发送到服务端
3. 服务端收到消息后，交给服务端存根进行解包
4. 服务端存根根据解包结果调用本地服务方
5. 本地服务方执行并将结果返回给服务方存根
6. 服务方存根将返回结果封包成消息并发送至客户端
7. 客户端收到消息后，交给客户端存根进行解包
8. 客户端存根将解包结果返回给消费方

RPC框架的目标就是要中间步骤都封装起来，让我们进行远程方法调用的时候感觉到就像在本地调用一样。