看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!
服务网格框架 Linkerd 背后的公司 Buoyant 发布用于 Kubernetes 的新型服务网格“ Conduit ”。Conduit 的数据面板使用 Rust 开发,而控制面板则使用 Go 语言开发。Conduit 并不是 Linkerd 2.0,它主要面向 Kubernetes,适用的场景不同。Buoyant 说,他们会继续开发、维护和为 Linkerd 提供商业支持。
在过去一年,人们对服务网格的兴趣程度出现了戏剧性的增长,Linkerd 和 Envoy 走向开源,Lyft、谷歌和 IBM 联合发布了 Istio。开发大会也开始热烈讨论服务网格,包括最近举行的 CNCF CloudNativeCon。很多互联网巨头和独角兽公司使用了服务网格技术,比如 Lyft 的 Envoy、Twitter 的 Finagle、谷歌的 Stubby 和 Global Software Load Balancer( GSLB )。Buoyant 说,Linkerd 是“世界上部署率最多的服务网格”,Salesforce、Paypal、Expedia、AOL 和 Monzo 都在使用它。
Linkerd 是 Buoyant 团队在使用 Twitter 的 Finagle RPC 框架时开发出来的。Buoyant 在“ Conduit 简介”这篇博文中提到,从过去 18 个月与使用了 Linkerd 的企业的合作中了解到,Linkerd 的 JVM 资源占用率太高。
Linkerd 的构建块 Finagle、Netty、Scala 和 JVM 让它能够支撑非常高的工作负载,只要给它提供足够的 CPU 和内存。不过,在资源有限的环境中就发挥不了太大作用。在将 Linkerd 作为“边车”代理与应用程序运行在一起时,就会出现问题,而通常 Kubernetes 都使用了这种部署模式。
Conduit 是 Buoyant 的“下一代”服务网格,其代理数据面板使用 Rust 开发,“简洁而强大”的控制面板则使用 Go 语言开发。Buoyant 说,性能是 Conduit 首要的考虑因素之一,单个 Conduit 代理的延迟是亚毫秒级的,而且实际使用的物理内存不到 10M。另外,它还默认实现了网络通信的 TLS,并使用了 Rust 的内存安全保证机制。
有些工程师在 Twitter 上发问,这对 Linkerd 的未来意味着什么,Buoyant Conduit 官方博客的回应称“影响很有限”:
我们会继续开发、维护和提供 Linkerd 的商业支持,我们承若 Linkerd 的用户将继续保持目前这种愉快的使用体验。
博文还说,Conduit 不是 Linkerd 2.0,它面向的是 Kubernetes 这样的特定环境,并没有解决与其他平台的集成问题,如 AWS、ECS 或 Mesos。
更多关于 Conduit 的信息可以在项目官网和 GitHub 仓库上找到。Conduit 的 GitHub README 文件清楚地写明,项目还处于实验阶段,只支持 HTTP/2(可与 gRPC 兼容)。
查看英文原文: Buoyant Releases New Kubernetes Service Mesh “Conduit” Written in Rust and Golang
评论