feihui

在完成核心逻辑/非核心逻辑拆分 ( 分级 ) 后，在技术评审、代码管理、容量评估、日常巡检& 监控告警、故障演练 & 应急处理，都更聚焦： 技术评审方面：对方案上涉及核心服务的需求，可以驱动有意识地思

先上前后的架构图： before after 正如前文列举的原因： 不同的链路有不同的资源消耗 -- 例如管理端以 TPS 为主，资源消耗往往大批成量；用户端以 RT 为主，资源消耗基本短少精简； 不

缘起 近期在 CR 代码的时候，愈发感觉对代码和服务的掌控越来越弱，细想下，这种感觉源自核心链路代码和非核心链路代码混合在一起 -- 混乱的关系无法预估表现、有限的精力容易顾己失彼。 在哪 窘境： 核

最近新上一个服务，莫名频繁 OOM，好在启动参数配置 HeapDumpOnOutOfMemoryError，用 MAT 打开 hprof 文件，点击 Leak Suspects Report，有如下信

阳光明媚的一天，突然收到告警，监控发现实例突发 long GC： 随机查看一个 POD，存在突发高量分配，而随后顺利回收： 查看日志输出java.lang.OutOfMemoryError: Java

今天早上小伙伴反馈某个服务调用超时率比较明显，对应的服务发现出现 ClientAbortException，检查监控惊讶发现有好几个 POD 的内存使用率已经顶天了： 查看其中的一个 POD GC：

之前有位小伙伴期望在不改代码的情况下优化 elasticsearch 查询，( 简化 ) 查询语句如下： Profile 该查询语句有如下： 从上图中可以看到 PointRangeQuery。