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

版权声明:本文由廖念波原创文章,转载请注明出处: 
文章原文链接:https://www.qcloud.com/community/article/147

来源:腾云阁 https://www.qcloud.com/community

为什么要用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信息就不会散落在代码和各种配置文件里了。
谈谈后台服务的RPC和路由管理

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

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

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

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

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

结语

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

上一篇:Jquery ajax ajaxStart()和ajaxStop()加载前的优雅表现


下一篇:HDU 1896 Stones (优先队列)