【极简监控】不吹不黑：你的系统该用“极简监控”还是“重型 APM”？一文划定选型边界

目录零、前言一、绝对统治区传统的纯单体 Java 应用二、降维打击区“伪微服务”、私有化部署与“研发兼职运维”毒舌一下到底什么是“伪微服务”戳破那些掩耳盗铃的诡辩三、灵活游击区核心微服务大盘下的“边缘单体服务”四、越界红线什么时候必须老老实实上“重型监控”五、结语看菜吃饭量体裁衣六、相关零、前言在本专栏 《极简模式下单体Java应用的监控落地思路》 中我们展示了一系列“不用额外部署、不花一分钱运维成本”的排障黑科技如 Glowroot、JavaMelody、Script Console、log-viewer 等。随着文章的发布不少读者在后台惊呼过瘾的同时也抛出了一个极具探讨价值的架构问题“博主这套极简体系看起来确实爽但它是不是万能的银弹现实中很多系统是微服务或者混合架构这套体系的适用边界到底在哪里”这是一个顶级的好问题。高级架构师眼里没有“好坏”只有“取舍Trade-off”和“边界”。今天我们就来扯下各种技术概念的包装根据真实的机器规模、业务形态和团队现状聊聊这套“极简监控”到底在哪些场景下是降维打击又在哪些场景下必须让位给“重型监控”。为了方便读者快速理解我们将最终的决策流程图放在这里YesNo_个位数节点或同机同席YesNo_过了网关就是底层业务YesNo_重在当下排障与近期容量 启动监控架构选型节点规模庞大吗(机器数量 10台)属于深水区微服务吗(跨进程调用层级 3层 AND同一应用部署多个副本)有极高的合规底线吗(需集中存档审计 3 年以上) 果断申请预算上重型舰队Prometheus ES 集中式 APM✅ 极简降维打击上铁桶阵SkyWalking-Local RRD 在线管控一、绝对统治区传统的纯单体 Java 应用这是我们这套极简监控体系最毫无争议的“主阵地”。画像经典的 Spring Bootjava -jar应用可能还带着一些定时任务直接连着数据库和 Redis调用各种其它SAAS服务与上下游进行业务串联。痛点客户要求不高预算有限往往缺乏专职运维。为什么是极简为了保护这样一个占用几百兆内存的应用去额外申请 3 台 16G 内存的机器部署 SkyWalking OAP 和 ElasticSearch 集群这在商业逻辑上简直是荒谬的。直接挂上Glowroot和Actuator单兵作战投入产出比ROI直接拉满。二、降维打击区“伪微服务”、私有化部署与“研发兼职运维”这是现实中最滑稽但也最真实的痛点场景。过去几年微服务风气盛行导致很多根本没必要拆分的系统被硬生生拆成了十几个微服务进程。更要命的是它所处的交付环境画像 1同机同席与微小集群所谓的微服务其实全塞在同一台物理机上运行或者哪怕分开了整体也就是 3~5 台机器组成的微小集群。画像 2ToB 客户现场孤岛应用不是集中部署在公司自己掌控的云端而是作为私有化交付分散部署在全国各地、网络相互隔离的客户机房里画像 3链路极浅的“假模块”这类系统还有一个极具讽刺意味的显著特点——调用链路极浅。往往是过了一个 Gateway网关就直接打到了最终的胖业务系统。根本不存在互联网大厂那种七八层、网状交叉的深水区 RPC 调用。这也是完美解释了“为什么我们不需要重型链路追踪组件的拓扑图功能”。在大厂比如阿里、美团一个请求可能要穿透 7、8 层不同的微服务网关 - 聚合层 - 业务层 - 基础服务层 - 数据字典层…没有图形化的链路瀑布流人脑根本理不清。但对于这种“过了网关就是底层”的浅链路伪微服务拓扑关系简单到三岁小孩都能画出来。为了这么浅的链路去部署一套庞大的 OAP 服务端来画拓扑图纯属自我折磨痛点活人微服务死于搞运维团队里压根没有专职运维研发写完代码还得兼职修单子。面对几十个网络隔离的客户现场如果你要上重型的 SkyWalking ElasticSearch 集中监控难道你要在每个客户那儿都额外部署一套吃内存的监控集群客户连买业务服务器的预算都抠搜会给你批机器装监控这在商业实施上纯属痴人说梦为什么极简策略在这里是绝对的降维打击面对这种“伪微服务 现场私有化部署 研发兼运维”的绝境我们的破局核心只有六个字“监控随制品交付”。我们果断放弃搭建 OAP 服务端和 ES 的幻想转而采用纯本地化的探针级追踪方案生态王牌SkyWalking-Local拯救伪微服务诚如专栏前文 《极简模式下JVM监控与链路追踪》 所述对于依然需要极其强悍的 Trace 链路能力的场景这是我们的首选它最大的杀手锏在于即便砍掉了后端的 OAP它依然完美保留了原生 SkyWalking 探针的全部功力。背靠其庞大的开源生态无论你是 Redis、MQ 还是各种生僻中间件Agent 织入统统开箱即用。在资源极度受限的客户现场依然能白嫖到最顶级的全链路追踪与 JVM 监控。单兵神器补充Glowroot 共享二进制如果你更偏爱极简的一体化 UI也可以使用 单体Glowroot 方案。在单台客户物理机上放置一份公共的glowroot.jar通过-Dglowroot.base.dir让各个微服务共享探针但独立配置DRY原则。配合 HTTP Header 注入 TraceID 实现人工跨服务串联。出了问题直接看对应端口的极简 UI。免外网穿透的就地排障当现场客户报障时研发不需要苦哈哈地去搞内网穿透或者 VPN 连服务器敲命令。不管是利用 SkyWalking-Local 打印在业务日志里的 MDC TraceID还是使用独立工具你只需要告诉现场的技术支持或客户“麻烦打开浏览器的http://现场IP:端口/log-viewer把高亮的那行红字截图给我”。把所有的监控、日志视图、诊断脚本、链路追踪 Agent 全部内嵌在项目自身的部署包里。不论交付到多么恶劣的现场环境只要业务系统能跑起来你的“铁桶防御阵”就已经就地展开。用最土的办法解决最绝望的交付排障这才是架构师的生存智慧 客户现场物理机 (单机或微小集群) 本地隔离存储️ 共享监控二进制包 (DRY原则)⚙️ 所谓的伪微服务向下游透传 TraceID向下游透传 TraceID加载挂载加载挂载独立 Dir 落盘独立 Dir 落盘暴露独立端口 UI暴露独立端口 UI网关服务进程Header 注入 TraceID业务线 A 进程业务线 B 进程SkyWalking-Local 探针 / Glowroot业务 A 独立微型库/RRD业务 B 独立微型库/RRD‍ 前线实施 / 兼职研发毒舌一下到底什么是“伪微服务”戳破那些掩耳盗铃的诡辩很早之前我就写过一篇吐槽文章 —— 微服务了个寂寞 。但既然这里再次提到了“伪微服务”我们有必要在这里给它下一个极其残酷却精准的定义。真正的微服务是为了解决“团队规模庞大、业务边界极其复杂、需要独立伸缩”而诞生的。而现实中 80% 的中小项目其所谓的微服务只是一个“分布式的单体应用Distributed Monolith”。“伪微服务”的典型特征如下强耦合的同机部署几十个服务因为甲方没预算最后全被塞在了一两台 16G 内存的物理机上。你只是把原来在 JVM 堆内的对象方法调用变成了极其消耗 CPU 和网络带宽的 Localhost HTTP/RPC 调用。“一荣俱荣一损俱损”的启动依赖服务之间没有服务降级重启时必须严格按照 A - B - C 的顺序启动挂了一个非核心服务整个链路全盘崩溃。面对这些质疑很多“面向简历编程”的架构师往往会抛出各种极其滑稽的诡辩诡辩 1“虽然我们没做分库分表但我们把业务模块拆成了十几个独立的服务这也叫微服务解耦”无情驳斥共用同一个底层关系型数据库的微服务纯属“流氓架构”你以为你拆分了系统实际上你只是发明了“全宇宙最昂贵、延迟最高的 SQL JOIN 方式”。原本在单体 JVM 里零点几毫秒就能在内存里或者通过一条 SQL 完成的关联查询被你硬生生拆成了跨网络的 RPC 调用。更致命的是底层数据表结构的强耦合丝毫没有解除A 服务改个表字段B 服务当场宕机且整个系统的并发上限依然被那个可怜的单点 MySQL 死死卡住。你不仅没享受到微服务“独立扩容”的红利反而凭空多出了网络开销、分布式事务失败和海量连接池耗尽的噩梦。这不叫微服务这叫“带网络延迟的分布式大单体”诡辩 2“我们不是共享一个数据库为了拆分我们连本地的 SQLite/H2 都用上了你看每个服务都有自己的库”无情驳斥微服务提倡“Database per service每个服务独立数据库”是为了数据领域自治和解除底层耦合。而你把核心业务全放在一个大 MySQL 里为了硬凑“多数据源”强行让几个边缘服务去用 SQLite 这种单机文件型数据库。这不仅没有实现微服务的解耦反而破坏了云原生架构最基本的“无状态Stateless”原则一旦你的应用需要多节点横向扩容或者所在的容器飘移了你写在本地 SQLite 文件里的数据瞬间就成了死局。这种操作不仅没有微服务的命反而得了微服务的病诡辩 3“我们的代码拆分到了不同的 Git 仓库这就叫微服务解耦”无情驳斥代码拆分不等于架构拆分。如果你一个 5 个人的团队要去维护 20 个拆碎的微服务仓库每次发版都要人肉切几十个分支、打包几十个镜像。这不是在拥抱微服务这是在给自己徒增几十倍的交付和运维成本。结论只要你的系统本质上是“高度数据耦合”、“同机物理部署”且“链路极浅”它就是一头披着微服务外衣的单体巨兽。面对这种怪胎不要有任何心理负担果断抛弃庞大的 OAP 监控集群直接掏出本专栏的极简单体监控武器库如单进程 Glowroot 共享、SkyWalking-Local用对付单体应用的招数去降维打击它这才是能让你活下来并准点下班的唯一真理三、灵活游击区核心微服务大盘下的“边缘单体服务”在大中型企业中你往往会面对一种“混合生态”画像公司有一个极其核心的交易/订单微服务集群但也存在着大量由不同部门研发的“边缘服务”如部门内部的运营后台、爬虫工具、独立的文件解析服务、跨部门的辅助支撑系统。痛点边缘单体服务往往是分阶段构建的交由不同的小团队自主负责。彼此之间并不进行强制的技术栈统一。如果强行要求这几十个边缘散碎系统全都接入公司核心的重型 APM 集群不仅沟通改造成本极高还会产生海量的“垃圾数据”冲垮核心监控集群。极简策略的巧妙应用核心链路用标准微服务可观测性SkyWalking OAP/Prometheus统一纳管而边缘/辅助服务强烈建议放权让它们使用本专栏这套极简体系边缘团队自主负责、自给自足。出了 Bug他们自己看log-viewer自己开Script Console救火完全不需要去麻烦中央基础架构团队。这极大地保护了核心团队的专注力也赋予了边缘团队极高的排障敏捷度。 企业整体技术生态 核心交易微服务集群 (几十上百节点)海量数据集中上报海量数据集中上报海量数据集中上报️ 边缘单体与辅助服务群 (各自独立自治)孤岛 A内部运营爬虫(搭载极简铁桶阵)孤岛 B跨部门文件解析(搭载极简铁桶阵)孤岛 C外包遗留系统(搭载极简铁桶阵)核心网关订单微服务支付微服务集中式 OAP 服务端庞大的 ElasticSearch 集群核心 SRE 团队维护重型基建边缘敏捷团队依靠极简工具免 SSH 自助排障四、越界红线什么时候必须老老实实上“重型监控”虽然我们一路在吹爆“极简监控”但如果你遇到了以下场景请果断收起这套工具箱老老实实去向老板申请预算搭建诸如Prometheus Grafana ElasticSearch 集中式 APM的重型舰队节点规模爆炸机器数量 10台及以上极简监控的本质是“分散自治”。如果有 50 个节点遇到一个偶发问题你不可能去分别打开 50 个log-viewer网页看日志。此时你必须需要一个集中的 ES 来汇总日志需要一个集中的 Grafana 来绘制横跨 50 个节点的宏观大盘。真正的深水区微服务调用链路 3层当一个请求进来需要在 A - B - C - D 四个独立子系统间穿梭且大量运用了异构语言Go/Python/Java和消息队列异步解耦时。单体视角的微操将彻底失效你必须依赖 SkyWalking 或 OpenTelemetry 的集中式 OAP 服务端来为你自动画出全局拓扑图和跨进程的瀑布流。极高强度的合规与数据留存要求如果行业如金融、医疗要求所有的系统运行日志和性能指标必须集中归档并至少保留 3 年以上以备审计那么依赖本地文件和内存滑窗的极简监控显然是无法满足合规底线的。五、结语看菜吃饭量体裁衣架构的本质不是追新而是对当下的资源、团队能力和业务场景做最精准的匹配。如果你正在维护着一套庞大的微服务集群重型可观测性体系是你绕不开的基建但如果你手里攥着的是单体应用、一台机器上的伪微服务、或者是边缘孤岛系统请千万不要被大厂的开源宣发洗脑去搞什么过度设计。果断用上本专栏里的这套极简兵器库吧用最少的代码最零碎的运维成本打造出让上下游胆寒的防御铁桶做自己的救世主开开心心准点下班六、相关【极简监控·番外随笔】一个老兵的反思观察行业十年我为什么非要死磕“单体极简监控”【专栏导读】拒绝过度设计零运维成本打造单体Java应用的“铁桶级”极简监控体系微服务了个寂寞