服务网格视角：技术讨论应回归客观本位

　　工位上的键盘声吵得我头疼——隔壁测试又在狂敲“F12”查日志，手机还亮了一下，是运维群在吐槽今天第三回熔断。我原以为服务网格这玩意儿早该消停了，结果去年一月的线上事故又把“技术选型该不该带立场”这事儿翻出来吵。当时是订单系统突然QPS掉了一半，前端小张直接冲过来拍我显示器：“你们网格的流量治理是不是又抽风了？”

　　其实那会儿我刚接手网格控制面，正被Sidecar的日志量折磨得想砸键盘。排查的时候发现，是某个服务的熔断阈值被硬编码成了“50%错误率”，可这服务平时错误率就挺高——运维老李之前还吐槽过：“这破服务自己都不稳，熔断规则写死等于自杀。”但当时没人敢动这参数，毕竟“网格的规则就得统一管”这话是架构组拍板的，谁改谁背锅。

文章配图，仅供参考

　　咖啡凉了，我灌了一口继续说。后来查日志发现，熔断那会儿网格的Sidecar确实报了“规则触发”，但服务的实际负载根本没到瓶颈——因为那服务的代码里有段隐藏逻辑：错误率超过40%时会主动降级，返回缓存数据。也就是说，网格的熔断和服务的自保机制撞车了，两边都在“保护”系统，结果一起把系统搞崩了。运维老李当时说了句大实话：“这就像两个人同时拉刹车，车没停住，先把自己甩出去了。”

　　其实最气的是事后复盘会。架构组坚持说“网格的规则没问题，是服务没对接好”，可服务组反驳“你们规则写死了，我们没法灵活调整”。两边吵了半小时，最后主管拍板：“下次网格规则加白名单，重要服务可以自己配。”我听着就想笑——这不就是承认“统一管控”站不住脚吗？但没人敢直接说“网格的方案有缺陷”，毕竟去年刚花了三个月把所有服务都迁到网格上，现在说“选型错了”，等于打自己的脸。

　　说白了，这事儿的核心根本不是网格好不好，而是“技术讨论能不能别带立场”。我见过太多次：有人为了证明自己选的方案对，硬把问题往对手方案上引。就像上次招聘，面试官问候选人“服务网格和API网关怎么选”，候选人说“网格更先进”，面试官当场拍板——可后来才发现，他们团队连微服务都没拆明白，用网格纯属跟风。这种“为了选型而选型”的讨论，最后肯定翻车。

　　窗外天黑了，测试还在敲键盘。我翻了翻今天的工单，发现又有三个服务在申请“退出网格管控”——理由都是“网格规则限制了我们的优化空间”。我忽然想起上个月和旧同事吃饭，他在另一家公司做架构，说他们团队早就不用网格了，“改用服务自带的治理能力，配合少量通用组件，灵活多了”。我当时还反驳“网格的统一管控是优势”，现在想想，可能真是自己陷在“网格必须好”的立场里了。

　　其实优胜劣汰的道理谁都懂，可一到技术选型就容易变味。就像去年那事故，如果大家能客观说“网格的规则需要适配服务特性”，而不是“网格的规则必须统一”，可能根本不会出问题。但现在呢？网格组还在加白名单，服务组还在申请特例，两边都在“妥协”，可问题的根源——规则是否该统一——反而没人敢碰了。

　　我摸了摸凉透的咖啡杯，决定明天找运维老李聊聊。他之前提过“网格的规则应该做成可配置的插件”，当时我觉得麻烦，现在想想，可能这才是解法。但话说回来，如果真改成插件化，网格的“统一管控”优势还在吗？我也不知道——可能这就是技术讨论的麻烦之处：你永远没法在立场和客观之间找到完美的平衡点，只能边踩坑边调整。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!