从 RPC 到服务化框架设计

本文详细梳理了从RPC基本框架到服务化框架设计的知识点,包括RPC的基本结构、重点、常见框架,以及服务治理的核心能力,如服务注册与发现、负载均衡、服务容错策略。介绍了Dubbo、gRPC、Thrift等服务治理型和跨语言调用型RPC框架,并探讨了微服务框架中服务监控、Tracing、配置中心和自动化运维的重要性。
摘要由CSDN通过智能技术生成

从 RPC 到服务化框架设计

目前互联网系统都是微服务化,那么就需要 RPC 调用,因此本文梳理了从 RPC 基本框架协议到整个服务化框架体系建设中所包含的知识点,重点在于 RPC 框架 和 服务治理能力的梳理,本文定位于一个科普性质的文章,在于让大家了解一个全貌。

这篇文章首发在我微信公众号【后端系统和架构】中,点击这里可以去往公众号查看原文链接,如果对你有帮助,欢迎前往关注,更加方便快捷的接收最新优质文章

一、RPC 基本框架

1-1、RPC 基本框架

理解 RPC

RPC 的概念就是远程过程调用。我们本地的函数调用,就是 A 方法调 B 方法,然后得到调用欧冠结果,RPC 就是让你像本地函数调用一样进行跨服务之间的函数调用。互联网发展到现在,我们都在讲微服务,服务都拆分为微服务了,那么相关依赖的调用,就会变成跨服务之间的调用,而他们之间的通信方式就是依靠 RPC。

RPC 基础结构(RPC 协议)

Nelson 的论文 Implementing Remote Procedure Calls 告诉我们, RPC 协议包括 5 个部分:

  1. Client
  2. Client-stub
  3. RPCRuntime
  4. Server-stub
  5. Server

在这里插入图片描述

当 Client 发起一个远程调用时,它实际上是调用本地的 Stub。本地 stub 负责将调用的接口、方法和参数,通过约定的协议规范进行编码,并通过本地的 RPCRuntime 进行传输,然后将数据包发送到网络上传输出去。当 Server 端的 RPCRuntime 收到请求后,交给 Server-Stub 进行解码,然后调用 Server 端的函数或者方法,执行完毕就开始返回结果,Server-Stub 将返回结果编码后,发送给 Client,Client 端的 RPCRuntime 收到结果,发给 Client-Stub 解码得到结果,返回给 Client。

这里面分了三个层次:

  • 对于客户端和服务端,都和原来本地调用一样,只需要关注自身的业务逻辑。
  • 对于 Stub 层,处理双方约定好的语法、语义、封装、解封装。
  • 对于 RPCRuntime,主要处理高性能的传输,以及网络的错误和异常。

1-2、RPC 框架的重点

从 RPC 基础结构中,我们总结出 RPC 框架的重点,包括 4 部分,如下:

1-2-1、数据序列化

序列化就是将数据结构或对象转换成二进制的过程,也就是编码的过程,序列化后数据才方便进行网络传输;反序列化就是在序列化过程中所生成的二进制转换成数据结构或者对象的过程,将二进制转换为对象后业务才好进行后续的逻辑处理。

常见的序列化协议如下:

  • ProtoBuf(IDL)
  • JSON
  • XML
  • Hessian2 (JAVA 系)

常见的 RPC 框架如 gRPC、Thrift、Dubbo、RPCX 、Motan 等会支持上述协议中的大部分,尤其是 ProtoBuf 和 JSON 。目前从性能上和使用广泛度上来看,现在一般推荐使用 ProtoBuf,当然很多自研的框架里面他们也会自己实现他们自己的序列化协议。

1-2-2、网络传输(网络通信)

在数据被序列化为二进制后就可以行网络传输了,网络传输就是我们的数据怎么传输到对方服务器上,目前来说,常见的通信传输方式包括 :TCP、UDP、HTTP(HTTP2.0)、QUIC 协议,TCP 是大部分框架都会默认支持的,额外这里要说明一下,RPCX 支持 QUIC 而 gRPC 支持 HTTP2.0。

QUIC(Quick UDP Internet Connection)是谷歌制定的一种互联网传输层协议,它基于UDP传输层协议,同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性,可以有效减少连接与传输延迟,更好地应对当前传输层与应用层的挑战。QUIC在应用程序层面就能实现不同的拥塞控制算法,不需要操作系统和内核支持,这相比于传统的TCP协议,拥有了更好的改造灵活性,非常适合在TCP协议优化遇到瓶颈的业务。

1-2-3、RPC 调用方式

网络传输只是数据传输非常基础的一方面,从业务上来看,我们发起一次 RPC 调用,那么还需要 RPC 的调用方式,包括如下三大类:

  • 同步 RPC:最常用的服务调用方式,发起调用请求后同步等待结果,符合我们开发的一贯认知和习惯。开发简单、容易维护、容易理解。

  • 异步 RPC:客户端发起服务调用之后,不同步等待响应,而是注册监听器或者回调函数,待接收到响应之后发起异步回调,驱动业务流程继续执行,实现起来相对复杂,但是高并发场景下性能会更好。

  • 并行 RPC:并行服务调用,一次 I/O 操作,可以发起批量调用,这个并行的批量请求一般是通过协程来实现,然后同步等待响应;

    • 这里需要注意࿰
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值