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