文档章节

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

偶素浅小浅
 偶素浅小浅
发布于 2016/11/05 14:48
字数 1754
阅读 25
收藏 0

版权声明:本文由廖念波原创文章,转载请注明出处: 
文章原文链接: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信息就不会散落在代码和各种配置文件里了。

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

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

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

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

结语

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

本文转载自:

偶素浅小浅
粉丝 8
博文 202
码字总数 0
作品 0
信阳
私信 提问
谈谈后台服务的灰度发布与监控

版权声明:本文由廖念波原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/149 来源:腾云阁 https://www.qcloud.com/community 为什么要有灰度发布与监控...

偶素浅小浅
2016/11/05
85
0
Tars 1.4.0 发布,高性能 RPC 开发框架

Tars 1.4.0 已发布,更新内容如下: tars-java:提供集成 spring cloud 的能力 修复 tarsnotify 在某些环境不能重启 Tars 这个名字取自于电影"星际穿越"中的机器人,它是基于名字服务使用 Ta...

淡漠悠然
2018/05/15
1K
1
服务框架及服务治理组件——业界调研

声明:主要内容来自公司内部 对业界的调研,不一定恰当、准确、实时。 表格文字较多,APP阅读体验较差 团队 服务相关组件方案 通信框架 监控 负载均衡路由 是否开源 腾讯 完全自研;BG内部自治...

高广超
2017/11/30
0
0
浅谈服务化架构

浅谈服务化架构 ShareCore2014-08-02550 阅读 架构 我在《可扩展架构设计的三个维度》一文里,谈到服务化架构(SOA)在保证系统扩展性上,是一个比较好的架构设计实践。也谈到了通过服务网关...

ShareCore
2014/08/02
0
0
新手看招:关闭Linux系统下不必要的服务

chkconfig --list 显示。 chkconfig [service] off 关闭其中一个服务。 守候进程名字功能对照表。 amd:自动安装NFS(网络文件系统)守侯进程。 apmd:高级电源管理。 Arpwatch:记录日志并构...

JavaGG
2009/05/08
513
0

没有更多内容

加载失败,请刷新页面

加载更多

为什么Netty的FastThreadLocal速度快

前言 最近在看netty源码的时候发现了一个叫FastThreadLocal的类,jdk本身自带了ThreadLocal类,所以可以大致想到此类比jdk自带的类速度更快,主要快在什么地方,以及为什么速度更快,下面做一...

ksfzhaohui
13分钟前
2
0
资治通鉴解析:无论什么条件,要挟权力做出承诺,都会被清算

电影《满城尽带黄金甲》里有句经典的名言“朕赐给你的,才是你的。朕不给你的,你不能抢。”之所以这段话有名,核心的就是,它揭示了这样一个权力心思:无论什么情况,权力的行使,都不愿意受...

太空堡垒185
18分钟前
1
0
CSS技巧之向下箭头

本文转载于:专业的前端网站➫CSS技巧之向下箭头 思路: 使用◇符号(可在输入法的软键盘找到该符号),使用定位选择位置,并隐藏溢出的上半部分 细点: 1.使用i标签的楷体属性把◇变大 2.给i...

前端老手
34分钟前
1
0
SpringCloud alibaba微服务之NACOS多环境配置整合

前言 伴随着spring cloud alibaba 登上主板以后,我就去了解下感觉还是蛮不错的。说实话第一次看见Nacos好长一段时间连读法都不知道...(/nɑ:kəʊs/)。按照官方的话说Nacos是:一个更易于...

攻城狮-飞牛
37分钟前
3
0
tcpdump

tcpdump -A -s0 port 21011 -i any (1)tcp: ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置,用来过滤数据报的类型 (2)-i eth1 : 只抓经过接口eth1的包 (3)-t : 不显...

mskk
42分钟前
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部