网站建设与制作考试题,学校网站免费html模板,小学老师在哪个网站做ppt,网站的连接二维码怎么做在单体应用时#xff0c;一次服务调用发生在同一台机器上的同一个进程内部#xff0c;也就是说调用发生在本机内部#xff0c;因此也被叫作本地方法调用。在进行服务化拆分之后#xff0c;服务提供者和服务消费者运行在两台不同物理机上的不同进程内#xff0c;它们之间的… 在单体应用时一次服务调用发生在同一台机器上的同一个进程内部也就是说调用发生在本机内部因此也被叫作本地方法调用。在进行服务化拆分之后服务提供者和服务消费者运行在两台不同物理机上的不同进程内它们之间的调用相比于本地方法调用可称之为远程方法调用简称RPCRemote Procedure Call那么RPC调用是如何实现的呢 在介绍RPC调用的原理之前先来想象一下一次电话通话的过程。首先呼叫者A通过查询号码簿找到被呼叫者B的电话号码然后拨打B的电话。B接到来电提示时如果方便接听的话就会接听如果不方便接听的话A就得一直等待。当等待超过一段时间后电话会因超时被挂断这个时候A需要再次拨打电话一直等到B空闲的时候才能接听。 RPC调用的原理与此类似我习惯把服务消费者叫作 客户端服务提供者叫作 服务端两者通常位于网络上两个不同的地址要完成一次RPC调用就必须先建立网络连接。建立连接后双方还必须按照某种约定的协议进行网络通信这个协议就是通信协议。双方能够正常通信后服务端接收到请求时需要以某种方式进行处理处理成功后把请求结果返回给客户端。为了减少传输的数据大小还要对数据进行压缩也就是对数据进行序列化。 上面就是RPC调用的过程由此可见想要完成调用你需要解决四个问题 客户端和服务端如何建立网络连接 服务端如何处理请求 数据传输采用什么协议 数据该如何序列化和反序列化 客户端和服务端如何建立网络连接 根据我的实践经验客户端和服务端之间基于TCP协议建立网络连接最常用的途径有两种。 1. HTTP通信 HTTP通信是基于应用层HTTP协议的而HTTP协议又是基于传输层TCP协议的。一次HTTP通信过程就是发起一次HTTP调用而一次HTTP调用就会建立一个TCP连接经历一次下图所示的“ 三次握手”的过程来建立连接。 三次握手过程详解 第一次握手 1、【客户端】向【服务端】发送连接请求报文标记ACK1 SYN1客户端序列号seqx客户端进入等待状态。 第二次握手 1、【服务端】收到请求报文将收到的报文缓存起来缓存客户端seqx 3、【服务端】向【客户端】发送确认报文生成一个【服务端】seqy标记ACK1SYN1【服务端】自己的序列号seqy确认序列号ACK_Numberx1发送给【客户端】 第三次握手 1、【客户端】收到服务端发送的确认报文将收到的报文存起来缓存【服务端】seqy 2、【客户端】发送确认报文给【服务端】标记ACK1SYN0【客户端】自己的序列号seqx1确认序列号ACK_Numbery1 3、【客户端】、【服务端】都会进入ESTABLISHED (连接已建立状态) 完成请求后再经历一次“四次挥手”的过程来断开连接。 四次挥手过程详解 第一次挥手 1、【客户端】向【服务端】发送释放连接报文并停止发送数据主动关闭 TCP 连接 2、标记FIN1【客户端序列号】seqx该序号等于前面已经传送过去的数据的最后一个字节的序号加1 3、这时客户端 FIN—WAIT-1 (终止等待1)状态等待服务端确认 第二次挥手 1、【服务端】收到释放连接报文将收到的报文缓存起来缓存【客户端】seqx 2、【服务端】向【客户端】发出确认释放报文标记ACK1【服务端序列号】seqy确认序列号ACK_Numbera1 a为【服务端】前面已经传送过的数据的最后一个字节的序号 3、此时【服务端】进入CLOSE—WAIT(关闭等待)状态 4、此时TCP服务器进程应该通知上层的应用进程因为【客户端】到【服务端】这个方向的连接就释放了这时TCP处于半关闭状态即【客户端】已经没有数据要发了但【服务端】若发送数据【客户端】仍要接受也就是说从【服务端】到【客户端】这个方向的连接并没有关闭这个状态可能会持续一些时间。 第三次挥手 1、【客户端】收到【服务端】确认报文并缓存起来 2、此时【客户端】进入FIN—WAIT(终止等待2)状态等待【服务端】发起释放连接报文 3、如果【服务端】没有数据要发送给【客户端】了【服务端】的应用进程就会通知TCP释放连接 4、此时【服务端】向【客户端】发送释放连接报文标记FIN1确认序列号ACK_Numbera1(与第二次挥手的确认号一致)【服务端序号】seqz1(z为半关闭状态发送的数据的最后一个字节的序号) 5、此时【服务端】进入最后确认状态等待【客户端】确认 第四次挥手 1、【客户端】收到【服务端】释放连接请求必须发出确认 2、【客户端】向【服务端】发送确认报文标记ACK1确认号序列号ACK_Numbez11【客户端序号】seqx1(x为第一次挥手的seq) 3、此时【客户端】进入等待状态必须经过时间等待计时器设置的时间2倍MSL(报文最大生存时间)后【客户端】才进入CLOSED状态MSL叫做最长报文寿命RFC建议设为2分钟实际应用中是30秒。在这2倍MSL期间【客户端】进入TIME—WAIT状态后要经过4分钟才能进入到CLOSED状态。 4、【服务端】只要收到了【客户端】的确认后就进入了CLOSED状态 5、当【客户端】和【服务端】都进入CLOSED状态后连接就完全释放了 2. Socket通信 Socket通信是基于TCP/IP协议的封装建立一次Socket连接至少需要一对套接字其中一个运行于客户端称为ClientSocket 另一个运行于服务器端称为ServerSocket 。就像下图所描述的Socket通信的过程分为四个步骤服务器监听、客户端请求、连接确认、数据传输。 服务器监听ServerSocket通过调用bind()函数绑定某个具体端口然后调用listen()函数实时监控网络状态等待客户端的连接请求。 客户端请求ClientSocket调用connect()函数向ServerSocket绑定的地址和端口发起连接请求。 服务端连接确认当ServerSocket监听到或者接收到ClientSocket的连接请求时调用accept()函数响应ClientSocket的请求同客户端建立连接。 数据传输当ClientSocket和ServerSocket建立连接后ClientSocket调用send()函数ServerSocket调用receive()函数ServerSocket处理完请求后调用send()函数ClientSocket调用receive()函数就可以得到得到返回结果。 直接理解可能有点抽象你可以把这个过程套入前面我举的“打电话”的例子可以方便你理解Socket通信过程。 当客户端和服务端建立网络连接后就可以发起请求了。但网络不一定总是可靠的经常会遇到网络闪断、连接超时、服务端宕机等各种异常通常的处理手段有两种。 链路存活检测客户端需要定时地发送心跳检测消息一般是通过ping请求给服务端如果服务端连续n次心跳检测或者超过规定的时间都没有回复消息则认为此时链路已经失效这个时候客户端就需要重新与服务端建立连接。 断连重试通常有多种情况会导致连接断开比如客户端主动关闭、服务端宕机或者网络故障等。这个时候客户端就需要与服务端重新建立连接但一般不能立刻完成重连而是要等待固定的间隔后再发起重连避免服务端的连接回收不及时而客户端瞬间重连的请求太多而把服务端的连接数占满。 服务端如何处理请求 假设这时候客户端和服务端已经建立了网络连接服务端又该如何处理客户端的请求呢通常来讲有三种处理方式。 同步阻塞方式BIO客户端每发一次请求服务端就生成一个线程去处理。当客户端同时发起的请求很多时服务端需要创建很多的线程去处理每一个请求如果达到了系统最大的线程数瓶颈新来的请求就没法处理了。 同步非阻塞方式 (NIO)客户端每发一次请求服务端并不是每次都创建一个新线程来处理而是通过I/O多路复用技术进行处理。就是把多个I/O的阻塞复用到同一个select的阻塞上从而使系统在单线程的情况下可以同时处理多个客户端请求。这种方式的优势是开销小不用为每个请求创建一个线程可以节省系统开销。 异步非阻塞方式AIO客户端只需要发起一个I/O操作然后立即返回等I/O操作真正完成以后客户端会得到I/O操作完成的通知此时客户端只需要对数据进行处理就好了不需要进行实际的I/O读写操作因为真正的I/O读取或者写入操作已经由内核完成了。这种方式的优势是客户端无需等待不存在阻塞等待问题。 从前面的描述可以看出来不同的处理方式适用于不同的业务场景 BIO适用于连接数比较小的业务场景这样的话不至于系统中没有可用线程去处理请求。这种方式写的程序也比较简单直观易于理解。 NIO适用于连接数比较多并且请求消耗比较轻的业务场景比如聊天服务器。这种方式相比BIO相对来说编程比较复杂。 AIO适用于连接数比较多而且请求消耗比较重的业务场景比如涉及I/O操作的图片服务器。这种方式相比另外两种编程难度最大程序也不易于理解。 上面两个问题就是“通信框架”要解决的问题你可以基于现有的Socket通信在服务消费者和服务提供者之间建立网络连接然后在服务提供者一侧基于BIO、NIO和AIO三种方式中的任意一种实现服务端请求处理最后再花费一些精力去解决服务消费者和服务提供者之间的网络可靠性问题。这种方式对于Socket网络编程、多线程编程知识都要求比较高感兴趣的话可以尝试自己实现一个通信框架。 但我建议最为稳妥的方式是使用成熟的开源方案比如Netty、MINA等它们都是经过业界大规模应用后被充分论证是很可靠的方案。 假设客户端和服务端的连接已经建立了服务端也能正确地处理请求了接下来完成一次正常地RPC调用还需要解决两个问题即数据传输采用什么协议以及数据该如何序列化和反序列化。 数据传输采用什么协议 首先来看第一个问题数据传输采用什么协议 最常用的有HTTP协议它是一种开放的协议各大网站的服务器和浏览器之间的数据传输大都采用了这种协议。还有一些定制的私有协议比如阿里巴巴开源的Dubbo协议也可以用于服务端和客户端之间的数据传输。无论是开放的还是私有的协议都必须定义一个“契约”以便服务消费者和服务提供者之间能够达成共识。服务消费者按照契约对传输的数据进行编码然后通过网络传输过去服务提供者从网络上接收到数据后按照契约对传输的数据进行解码然后处理请求再把处理后的结果进行编码通过网络传输返回给服务消费者服务消费者再对返回的结果进行解码最终得到服务提供者处理后的返回值。 通常协议契约包括两个部分消息头和消息体。其中消息头存放的是协议的公共字段以及用户扩展字段消息体存放的是传输数据的具体内容。 以HTTP协议为例主要分为消息头和消息体两部分其中消息头中存放的是协议的公共字段比如Server代表是服务端服务器类型、Content-Length代表返回数据的长度、Content-Type代表返回数据的类型消息体中存放的是具体的返回结果这里就是一段HTML网页代码。 数据该如何序列化和反序列化 再看第二个问题数据该如何序列化和反序列化。 一般数据在网络中进行传输前都要先在发送方一端对数据进行编码经过网络传输到达另一端后再对数据进行解码这个过程就是序列化和反序列化。 为什么要对数据进行序列化和反序列化呢要知道网络传输的耗时一方面取决于网络带宽的大小另一方面取决于数据传输量。要想加快网络传输要么提高带宽要么减小数据传输量而对数据进行编码的主要目的就是减小数据传输量。比如一部高清电影原始大小为30GB如果经过特殊编码格式处理可以减小到3GB同样是100MB/s的网速下载时间可以从300s减小到30s。 常用的序列化方式分为两类文本类如XML/JSON等二进制类如PB/Thrift等而具体采用哪种序列化方式主要取决于三个方面的因素。 支持数据结构类型的丰富度。数据结构种类支持的越多越好这样的话对于使用者来说在编程时更加友好有些序列化框架如Hessian 2.0还支持复杂的数据结构比如Map、List等。 跨语言支持。序列化方式是否支持跨语言也是一个很重要的因素否则使用的场景就比较局限比如Java序列化只支持Java语言就不能用于跨语言的服务调用了。 性能。主要看两点一个是序列化后的压缩比一个是序列化的速度。以常用的PB序列化和JSON序列化协议为例来对比分析PB序列化的压缩比和速度都要比JSON序列化高很多所以对性能和存储空间要求比较高的系统选用PB序列化更合适而JSON序列化虽然性能要差一些但可读性更好更适合对外部提供服务。 总结 今天我们一起了解服务调用需要解决的几个问题 通信框架。它主要解决客户端和服务端如何建立连接、管理连接以及服务端如何处理请求的问题。 通信协议。它主要解决客户端和服务端采用哪种数据传输协议的问题。 序列化和反序列化。它主要解决客户端和服务端采用哪种数据编解码的问题。 这三个部分就组成了一个完整的RPC调用框架通信框架提供了基础的通信能力通信协议描述了通信契约而序列化和反序列化则用于数据的编/解码。一个通信框架可以适配多种通信协议也可以采用多种序列化和反序列化的格式比如服务化框架Dubbo不仅支持Dubbo协议还支持RMI协议、HTTP协议等而且还支持多种序列化和反序列化格式比如JSON、Hession 2.0以及Java序列化等。 本文由 mdnice 多平台发布
