RPC设计的示例分析
这篇文章主要介绍了RPC设计的示例分析,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让小编带着大家一起了解一下。
创新互联建站专业为企业提供恒山网站建设、恒山做网站、恒山网站设计、恒山网站制作等企业网站建设、网页设计与制作、恒山企业网站模板建站服务,十年恒山做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
前言
RPC全程远程方法调用,已经在各大小公司被广泛使用,种类也是很多比如:Dubbo,Spring cloud那一套,GRPC,Thrift,可能还有很多公司自研的等等;每个公司都可能根据自己的业务需求,场景选择自己合适的RPC框架;但大体的考察维度无非就这么几个:性能,可扩展性,跨平台,功能性,可监控,使用性;所以我们如果要设计一个RPC框架,可以从这几个角度去考虑。
性能
作为微服务中的核心组件,在一个系统中RPC的调用量往往是很高的,所以性能是一个很重要的考虑点;既然是远程调用,必然牵扯到网络连接,而I/O模型的选择直接影响到性能,网络的长连接短连接,序列化方式也都影响性能;
1.I/O模型
常见的Unix5种I/O模型分别是:阻塞I/O,非阻塞I/O,I/O复用(select,poll,epoll等支持I/O多路复用),信号驱动I/O,异步I/O;从早期的阻塞I/O方式只能创建大量的线程来保证每个用户互不影响,到现在广泛使用的I/O多路复用模型,再到异步I/O;从select模型到现在主流的epoll模型,性能有了质的升级;当然我们没必要自己去实现,可以直接使用网络通讯框架Netty,Mina等;
2.长连接短连接
短连接表示每次通讯完就关闭连接,而长连接通讯完继续保持连接,这样下次再通讯就不需要重新建立连接了,如果通讯频繁,很明显长连接性能更高;但是长连接需要做一些额外的工作,比如保活处理;另外就是如果客户端太多的话,服务器端是无法支撑的。
3.序列化方式
网络传输中的数据都需要经过序列化和反序列化处理,所以这一块的性能也很重要;常见的序列化包括:json和二进制方式,json常见的如fastjson,jackson等,二进制如protobuf,thrift ,kryo等;这个可以分别从序列化的性能,大小,以及使用方便性考虑;当然稳定性和安全性也需要考虑,比如fastjson频繁爆出安全漏洞;
4.协议
这里主要讲的是应用层协议,RPC一般都会自定义协议,当然也有直接使用现有协议的比如http协议;自定义协议可以自己掌控,协议可以做的很小很精简,当然解码和编码需要自己去实现;如果使用现有的http协议,相对来说整个协议包是比较大的,但是已经是一种规范了,很多东西可以直接拿来用,更加通用;
可扩展性
可扩展性可以从两个角度来看,一个是服务提供方和消费方的负载均衡策略;另一个就是用户可以对框架进行自定义扩展;
1.负载均衡
RPC的两个核心组件服务提供方和消费方,需要提供横向扩展的机制,用以达到更高的负责,比如Spring Cloud、Dubbo提供的注册中心,然后再结合容错机制达到负载均衡的效果,很容易达到横向扩展;
2.SPI机制
一个好的框架是支持用户自定义的,用户根据自己的需求实现自定义扩展;JDK提供了SPI机制,很常见的一个场景就是数据库驱动;另外Dubbo在此基础上提供了更加强大的SPI机制;这种扩展对RPC来说是多方面的,可以是底层的通讯框架扩展,序列化扩展,注册中心扩展,容错机制扩展,协议扩展等等;
跨平台
现在开发语言多种多样,如果能做成跨平台,当然是一大优势,但是可能往往为了跨平台,会在一些地方做权衡让步,当然难度也更大;所以我们在实现一个RPC时需要明确自己的定位,就是针对某一种语言的还是跨平台支持;常见的支持跨平台的RPC框架如GRPC,Thrift;
实现机制可以参考一下,都有自己的一套接口定义语言IDL然后通过不同的代码生成器,生成各种编程语言消费端和服务器端代码,来保证不同语言直接的相关通信。
功能性
作为一个RPC框架,除了最核心的通信模块,序列化模块之外,功能性模块也很重要,往往为开发者节省了大量的时间,开发者可能因为RPC的某个功能而选择用此框架;常见的功能包括:容错机制,负载均衡机制,同步异步调用,结果缓存,路由规则,服务降级,多版本,线程模型等;
1.容错机制
在错综复杂的网络环境中,远程调用失败再正常不过了,容错机制就显得非常有必要了,常见的容错机制比如:失败重试,快速失败,失败直接忽略,并行调用多个服务器只要一个成功即返回等;用户可以根据需求选择自己合适的容错方案;
2.负责均衡
上面提到服务提供方和消费方的可扩展性,消费方面对多个提供方的时候需要有一定的负载均衡策略,来保证系统的稳定性;常见的策略如:随机,轮询,最少活跃调用数,一致性hash等;
3.同步异步调用
常见的同步调用有些场景无法满足需求,比如同时需要调用多个远程方法,而这其中可能有些执行比较慢的;这时候异步调用就显得重要了,可以同时异步发送多个请求,等待时间就是响应最慢的请求;具体可以通过Future,CompletableFuture来实现;
4.结果缓存
缓存一直是性能的不二法宝,某些场景下可能对服务提供方响应的数据实时要求性并不高,这时候如果可以在服务提供端提供结果的缓存机制,那么在性能上是一个很大的提升;可以自己设计一个本地缓存,当然也可以直接整合第三方缓存框架比如ehcache,jcache等;
5.路由规则
服务提供方往往是很多的,用户可能有一些特殊的需求,可以按照自己定义个规则来做路由,比如我们经常做的灰度发布,结合RPC提供的路由规则来实现会很简单;此规则可能是条件表达式,脚本,标签等,我们设计的RPC框架需要有一个给用户定义规则的地方,比如通过注册中心来实时推送,另外还需要相关的引擎来处理规则,比如脚本引擎;
6.服务降级
系统的高可用性原则中,很重要的一条就是降级处理,在一些非核心的功能中,可以在出现超时/故障时或者直接设置为降级服务,给一个统一的响应,这样可以把宝贵的资源留给那些核心的功能;可以参考Dubbo的实现,向注册中心写入动态配置覆盖规则,从而实现实时降级处理;
7.多版本
接口升级时常有的事情,我们可能会为了兼容之前的版本绞尽脑汁,但有时候还是无能为力,这时候多版本就显得很重要了,可以让两个版本同时存在,等到合适的机会在慢慢升级;像dubbo这种服务的维度就是服务名+版本号,所以很好实现多版本;而Spring Cloud维度没有到版本号,可以通过路由规则去实现;
8.线程模型
在系统的高可用原则中,线程隔离是一条重要的原则,为什么要做隔离,可以拿Dubbo及其底层通信框架netty为例,netty作为通信框架本身是有自己的线程模型,如果业务处理线程直接使用底层的通信线程模型,这样就会出现因为业务阻塞而导致通信线程模型阻塞;这时Dubbo提供自己的线程模型就尤为重要,可以做到线程隔离,业务线程不影响通信线程;
当然作为一个RPC框架实现的功能可以很多,这里主要讲一些我们平常用的比较多的功能;
可监控
一个运行稳定的系统,没有一个专门的监控平台是不行的,当然RPC也不例外,常见的比如dubbo的monitor模块,Spring Cloud Admin等;对于一个RPC我们主要监控:服务提供者有哪些,服务消费者有哪些,以及它们的状态,最好还有一些统计功能比如一段时间内的调用量,成功率,失败率,平均响应时间,最大响应时间,最大并发量等等;
使用性
最后说一下,我们设计出来的框架最终还是要给用户使用的,所以用户是否可以方便的使用也是一个很重要的点,某些框架可能就是因为使用繁琐导致最终被弃用;比如注解的方式相比较xml的方式就简单不少;还有比如服务维度来说:dubbo维度是接口,而Spring cloud维度是应用,整体来看Spring cloud使用起来更加方便;当然简单的API,文档以及Demo对开发者来说也是必不可少的;
感谢你能够认真阅读完这篇文章,希望小编分享的“RPC设计的示例分析”这篇文章对大家有帮助,同时也希望大家多多支持创新互联,关注创新互联行业资讯频道,更多相关知识等着你来学习!
网站栏目:RPC设计的示例分析
当前链接:http://scyanting.com/article/gscseg.html