Linkerd因JVM性能劣势败给Envoy揭示数据平面选型的性能优先原则

服务网格数据平面产品的兴衰史，是一个性能压过先发优势的典型案例。 Linkerd（2016年1月发布）是服务网格的鼻祖，Linkerd-proxy是业界第一款 正式的边车代理，2017年1月就进入CNCF孵化——但它用Scala开发、需要JVM 支持，在启动时间、预热、内存消耗这几个边车代理场景下最要命的指标上， 全面落后于晚它半年发布的挑战者Envoy（C++开发，2016年9月开源），很快 就被Istio+Envoy的组合击败，结束了短暂的统治期。Envoy由Lyft开发，因Lyft 与Google、IBM达成合作而成为Istio的默认数据平面；更关键的是Envoy采用 公开的xDS协议接受控制，不是任何一家的私有物，这让它被大量其他管理 平面（不只是Istio）选用，进一步巩固了市场占有率第一的位置。Linkerd 背后的Buoyant公司随后用Rust重写了第二代产品（先叫Conduit，进CNCF后 和原Linkerd合并改名Linkerd 2），性能和资源消耗已经追上Envoy，但它的 定位变成了Linkerd 2专属数据平面，成败很大程度上系于Linkerd 2这个 控制平面产品本身的发展。这段历史印证了一个朴素但常被忽视的教训：边车 代理这类基础设施级组件，”第一个做出来”的先发优势远不如”启动快、预热 快、内存省”这类硬性能指标重要——用户不会因为怀旧而容忍明显的资源劣势。