深度剖析RPC框架设计

深度剖析RPC框架设计-mikechen的互联网架构

RPC在分布式领域是非常重要的核心组件,大家熟知的dubbo就是其中的典型代表,今天来剖析RPC核心设计@mikechen

RPC的简介

随着互联网的发展,网站应用的规模不断扩大,常规的垂直应用架构已无法应对,分布式服务架构以及流动计算架构势在必行。

单体应用时代只有内外网通信,并没有服务间通信的诉求,随着单机服务性能下降,进入多服务分布式的时代后Rpc 框架才应运而生。

  • 单一应用架构
  • 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。
  • 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
  • 垂直应用架构
  • 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。
  • 此时,用于加速前端页面开发的 Web框架(MVC) 是关键。
  • 分布式服务架构
  • 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。
  • 此时,用于提高业务复用及整合的 分布式服务框架(RPC),提供统一的服务是关键。

RPC ,Remote Procedure Call ,字面意思是远程过程调用,主要是解决服务间连接及数据交互。

通信Rpc犹如生活中电网基建一样,是分布式服务的基础组成部分,一个传输电能,一个传输数据。

下面我们围绕RPC通信框架,从如何实现这个角度做一个剖析,以及每个环节能做什么?

深度剖析RPC框架设计-mikechen的互联网架构

 

RPC通信方式设计

通信的底层是TCP/IP,在Java中网络传输通常使用Netty 或 Mina 的多路复用模型作为网络通信的底层。

通信底层当然还有一些优化方式,具体在优知学院架构师系列课程里面会涉及。

1.多传输协议支持

为什么要支持多种传输协议呢?在业务中,通常会遇到各种问题,比如:

  • 跨网络、机房问题
  • 跨语言问题
  • 长连接还是短连接
  • 传输安全
  • 传输性能

使用Http协议,虽然灵活便于管理、可以跨语言,但是明文、性能很差。通常适用于较低并发、异构系统对接、对外网关等。

使用Dubbo 传输协议,性能高、长连接,但目前跨语言做的还不够,单条大文件/数据传输可能会形成网络瓶颈。

Rmi ,性能较差,短连接,但对于单次大数据量传输却比较好,其他的还有Websocket 、Https、Thrift TTransport等,传输协议各有优缺点,所以支持多传输协议是有必要的。

2.多数据压缩/序列化支持

为什么要支持多序列化支持,主要考虑两个方面

  • 跨语言/异构平台间交互
  • 性能方面考虑

这个其实跟传输协议是搭配的,比如RMI 通常都是使用了标准的二进制序列化。

目前有Protobuff、Dubbo 序列化、Hessian 、Java原生、Soap文本序列化、Http的表单序列化、Json、Thrift的TCompactProtocol等,同样各有优缺点,需要设计成可扩展的方式。

 

RPC服务寻址

消费者如何知道提供者,并且知道当前是否存活,是设计RPC 框架需要考虑的第二大问题。

1.多样的注册中心支持

不同的业务系统,对于服务间一致性要求并不同,这里有一个CAP权衡问题。

另外还要考虑是否推送提供者的变动、注册中心自身的安全问题、跨语言平台等因素。

比如:

  • Zookeeper,支持强一致并能通过Wacher机制主动进行通知,但可用性并不能完全保证
  • Consul ,通过Http方式满足服务发现,没有语言限制,但通知实时性比ZK Wacher略差

所以注册中心也需要做成插件化的可扩展方式。

2.多算法负载均衡、路由和多维度流量控制

负载均衡目的是为了最优使用同一服务间的资源使用,具体到设计中,需要考虑机器情况、服务的负载情况等。

算法主要有随机、轮询、活跃情况、一致性Hash等。

在生产环境中能通过界面化的方式提供动态的更改权重、路由等规则,实现服务动态权重、熔断、限流、灰度、多版本等功能。

3.容错机制

考虑容错机制是系统完整性的一部分,failover、failfast、failback、failsafe 、forking、Broadcast …等,通常和负载均衡搭配。

 

让业务更方便的使用

支持普通配置的同时,支持集成到Spring等主流框架使用。

配置的方式也有很多种,比如支持XML、注解、YAML、Properties、Json配置等。

可跟踪

可以进行依赖分析,数据的调用统计,并能图形、数据化将其显示出来。

可跟踪需要解决这几个问题:

  1. 服务调用链路或依赖关系
  2. 调用次数及时间,提供容量/机器预算基准数据
  3. 预警

实现上可以兼容现有成型的APM链路跟踪,也是设计的考虑因素之一。

 

其他

从架构的角度要考虑到设计模式的使用,比如常用的责任链、代理模式等。

容器化,Kubernetes 支持等。

深度剖析RPC框架设计-mikechen的互联网架构

最后

正如前面说的,Rpc 框架相当于电网基建,是分布式系统的基础,如果不具备可靠、高性能、高并发、使用简易等特点,就很难满足日益增长的服务治理的需要。

实现RPC调用可能比较简单,但实现Rpc框架不仅需要深厚技术功底,也需要提供接地气、灵活的使用方式。

以上!

阅读mikechen的互联网架构●更多技术文章合集

关注mikechen的互联网架构公众号,回复【架构】即可获取以上18大系列99万字《mikechen的互联网架构●技术文章合集》

评论交流
    说说你的看法