谈谈后台服务的 RPC 和路由管理

为什么要用RPC和路由管理

RPC的概念其实出现已经很久了,记得笔者读大学的时候,接触到RPC的概念,总觉得不重要,多此一举:

  1. 我掌握好socket通信这个利器和tcp/ip协议族原理,什么功能不能实现?
  2. RPC就跟本地函数调用一样写代码,确实开发效率比较高;我自己把socket相关函数好好封装一下,让代码复用起来,开发效率也很高。
  3. 不懂或者不关注网络通信底层原理,光会函数调来调去,这样的程序员太没有出息了!

后来,笔者开始带团队,亲身经历了一些团队协作和IT服务运营过程中的故事,才发现RPC非常关键。这里分享我经历过的很早以前的两个故事。

故事一:有一个基础模块A,被非常多的其他模块远程调用,模块A的门户提供协议文档、API、调用示例代码,每当有人来申请使用,模块A负责人就会给调用方一组接口机的IP,调用方可以给这些IP发网络请求。

重视可用性的有追求的调用方,通常在拿到IP后,会把IP写在配置文件里,并且自己在代码里实现一定的容错逻辑:如果某个IP请求连续失败多少次,就一段时间内不要给它发请求了。这个容错逻辑做好可不简单,涉及到很多细节。

大多数的调用方,是把IP写死在代码里,简单的轮询请求这些IP。

如果模块A的某台接口机死机了,或者网络局部故障导致某些接口机不可达,很多调用方就会跳起来:你们怎么回事?你们的服务水平怎么这么差!

如果机房裁撤,一些机器IP要下架,模块A负责任会非常头疼:

  1. 首先不知道有哪些人在请求这个IP。读者说:傻啊,抓包看一下不就知道有哪些调用方了?但是要知道有的请求不是持续的,是不定期的访问一下模块A。
  2. 模块A的负责人要大范围的邮件通知调用方改路由(通常要改代码编译发布),过一段时间后,抓包看还有哪些调用方没有改,再挨个敦促修改路由
  3. 有时候某个IP下架了,过了几天,突然有个调用方跳起来:我们还在用呢!我们是写死IP的,代码找不到了,只能拿二进制可执行文件“硬”改

故事二: 一个团队里,通常有很多技术能力、服务意识和责任心都非常强的同事,他们的工作产出质量非常高,每个远程调用都有次数和成功率的上报(简单的说就是上报到一个监控系统,可以通过监控系统web界面查看曲线图),请求报文中的一些重要但不强校验的字段也都认真填写(例如染色标记),所以他们负责的模块,如果出现异常,很容易通过监控系统和日志监控到,并能快速定位到问题。

但是,也有一些同事责任心和能力不那么突出,重要的监控上报缺失、请求包里一些重要的字段没有填写。有时候服务的故障有异常了很久,被用户投诉才发现,事故报告里总是会出现这样的改进措施:增加对xxx的监控上报,增强服务运营意识。

类似的事故通常会反复出现,管理干部就会拉起一次运动式的梳理和整顿,但过一段时间,肯还会出现。

通过这两个事故可见:如果没有很好的实现RPC和路由管理,IT系统服务质量会过度的依赖人的意识,而这个通常成本非常高、效果也不好。

毫秒服务引擎(msec, 取英文名Mass Service Engine in Cluster的首字母组合)是腾讯一个开源框架,其创作冲动和构建经验,来自QQ后台团队超过10年的运营思考。RPC和路由管理是毫秒服务引擎设计的重要考量点。

毫秒引擎里是怎么做的?

首先,毫秒引擎将每个服务部署在哪些IP上这些信息集中管理起来,即使是调用外部的非标准服务(我们叫异构服务),也需要将该外部服务的接口IP配置到毫秒引擎管理系统里。这样涉及到的IP信息就不会散落在代码和各种配置文件里了。

服务之间的调用,统一采用CallMethod()函数的方式,避免代码千奇百怪;按服务名字调用和接口名调用

RPC背后的路由算法对于单机故障、网络局部波动等异常,自动容错。简单的说,路由算法按一定的规则轮转的选择被调用模块的接口机,并统计过去一段时间的调用成功率、时延信息,根据这些信息调整该接口机被选择到的比例。如果某个接口机故障了,那么就不会发送请求给它,从而实现自动容错。

毫秒引擎框架本身,在RPC执行的时候,就上报了很多基础属性和日志,这样保证了服务监控和告警等运营措施不依赖与人的意识。下图是叫做getMP3List这样一个RPC调用的请求数和成功数,这些是不需要业务开发者工作就自动上报。

每个请求有唯一ID来标识,通过该ID,毫秒引擎可以在框图中直观的呈现该请求经过的模块、模块间的RPC名字等信息,这个同样不需要业务开发者的工作就自动实现:

结语

互联网服务的后台,硬件通常是由大量的廉价机器组成;软件架构通常采取大系统小做、分而治之的思想。这就决定了业务逻辑涉及到大量的网路IO,同时单机故障、网络局部故障是运营的常态。那么,RPC和路由管理就显得尤其重要了。毫秒服务引擎为此提供了一个完整的解决方案。详细的可以见腾讯云服务市场毫秒服务引擎官网,或者微信公众号:msec-engine

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏竹清助手

如何理解一个高度抽象化的架构风格本质

REST本身是一个高度抽象化的架构风格,因而总是很难对它有一个比较深入且印象深刻的理解。写这篇文章的目的,是自己对学习REST的一个总结,也希望可以通过这篇文章...

883
来自专栏全华班

springcloud学习手册-什么是springcloud?

导读 | springcloud 概念 springboot框架。 了解springcloud前先简单了解一下springboot框架。 springboot是...

3585
来自专栏Linyb极客之路

这些优秀的 Spring Cloud 开源软件,你知道几个?

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线...

626
来自专栏华章科技

果断收藏!六大主流大数据采集平台架构分析

随着大数据越来越被重视,数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台:

693
来自专栏钱塘大数据

【推荐收藏】六大主流大数据采集平台架构分析

随着大数据越来越被重视,数据采集的挑战变的尤为突出。今天为大家介绍几款数据采集平台:Apache Flume Fluentd Logstash Chukwa S...

1794
来自专栏Linyb极客之路

Spring Boot最佳实践

642
来自专栏美团技术团队

境外业务性能优化实践

前言 性能问题简介 应用性能是产品用户体验的基石,性能优化的终极目标是优化用户体验。当我们谈及性能,最直观能想到的一个词是“快”,Strangeloop在对众多...

40810
来自专栏Java技术

Java程序员,你一定需要了解的六款大数据采集平台

亲爱的小伙伴,抽点时间帮忙投一下票,选一下您目前所处的阶段,以便后期推出更多对您有帮助的文章和内容哦!

722
来自专栏前端架构

透析SOA、RPC、SOAP、REST、ICE、ESB模型发展史

最初的程序全是单机程序,没有网络,没有RPC,更没有RESTful。程序猿写的东西孤独运行在单机上。

1173
来自专栏全华班

springcloud学习手册-什么是springcloud?

了解springcloud前先简单了解一下springboot框架。

22511

扫码关注云+社区