后端程序员日常
Posted herongweiV
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了后端程序员日常相关的知识,希望对你有一定的参考价值。
大家好,我是贺同学。
这几周有点小忙,最近发生的几次新闻热点,比如前几天的娱乐大瓜,还有昨天的江苏常州地震都触发了服务器报警。
部门是强业务相关,热点新闻导致短时间搜索量激增,请求达到服务器造成压力瞬间增大,就有可能引起服务器报警。
服务报警了就需要及时去排查维护,要是能简单排查解决那还好,如果不太好定位问题各种排查好了解决问题又到很晚了。
日常排查 case
对于一名日常和服务器打交道的后端程序员来说,排查线上 case 解决问题这些可以说是家常便饭了。
昨天下班回到家刚坐下,准备洗个水果吃,屁股还没坐热工作群里面开始疯狂弹出消息。
一看不出所料,果然线上服务器报警了,赶紧登上监控平台是哪台服务器,业务后台有上百台服务器,定位到江苏地区服务器报警。
然后登上对应的机器,排查开始,到底是某个请求报警,还是上下游服务器请求异常,还是某个线下测试异常。
各种排查几分钟过去了,群里各种艾特,还没头绪,着实头大,此时,群里有人反馈江苏地震上热搜了,看到这,里面想到可能是请求量瞬间暴涨。
发现果然,这不就是是江苏的机器报警啊,排查对应日志,根据关键字按指定时间排序输出统计一下 top query。
正要排查具体 case 的时候,终端中文乱码,关键时刻掉链子,立马设置终端编码 gbk 。
一查,果然,全网前十个查询词有八个都是江苏地震相关,日志十几分钟突然暴增几十万条查询。
定位问题了,排查不是人为干扰,只能先观察一段时间,等热搜下去了,在看情况而定。
几分钟过去了,看监控平台没问题,热搜下去了,ok,报警也恢复正常了,没问题,在群里反馈一下,应该差不多了,在观察一下,应该正常了。
长舒一口气,看一下表,尼玛,12点了。
透过现象看本质
这样的事情发生多次,自己也会去思考,像这种流量大和突发性高,这就带来了两个核心的需求:
1、可扩展:如何抗住这样的流量,针对这个需求,是否考虑构建分布式搜索引擎,支持横向扩展;并且针对业务特点进一步做优化,让搜索的效率更高。
2、快速响应,流量越大,单位时间内的流量价值就越大,出现问题的损失也就越大,如何做到快速响应变得非常关键。
3、针对以上需求,搜索系统就应该支持自动部署和快速扩容以应对突发流量,索引数据从导入、处理到上线服务会经过层层验证,同时还有监控体系,包括监控探针及时发现线上的问题。
4、单体拆分,微服务架构,现在微服务比较火,但是否架构就一定要转呢?微服务不是银弹。
有时候一些历史遗留原因,有些重要的服务承担的功能比较多,不太好拆分,依赖的上下游比较多,不像微服务一样可以每个模块专注自己模块的功能,这种就需要具体业务具体分析了。
今天的唠嗑就到这里了。
有可能我说的都是错的。
我是小贺,我们下期再见。
·················END·················
你好,我是 herongwei,一个精神小伙&鹅厂程序猿,热爱编程,热爱生活,热爱分享,在平凡的人生中追求一点不平凡,欢迎关注,一起加油,点击下方名片,了解更多。
以上是关于后端程序员日常的主要内容,如果未能解决你的问题,请参考以下文章