Conduit 登场
今天我们要介绍 Conduit，面向 Kubernetes 的新的开源 Service Mesh。
Conduit 横空出世，目标是成为最快、最轻、最简单并且最安全的 Service Mesh。他使用 Rust 构建了快速、安全的数据平面，用 Go 开发了简单强大的控制平面，总体设计围绕着性能、安全性和可用性进行。更重要的是，Conduit 将会完全吸收过去 18 个月中，我们在 Linkerd 的生产级 Service Mesh 中积累沉淀的真实经验。
为什么要做一个 Conduit？Linkerd 是世界上最多生产级部署的 Service Mesh。这一产品创造了 "Service Mesh" 这一词汇，在软件基础设施中成功的开辟了新的领域，为遍及全球的企业客户（例如 Salesforce、Paypal、Expedia、AOL 以及 Monzo）承载了数以万亿计的请求。这一段时间里，我们和客户以及用户们甘苦与共——我们一起开会，设计交叉路线图，凌晨三点起床救火。开源的基础设施和现实世界的对撞中，我们学到了弥足珍贵的经验和教训。
这中间有个突出的问题就是，Linkerd 的部署模型太重了。虽然 Linkerd 的各个组件，例如 Finagle、Netty、Scala 以及 JVM，都是被广泛采用千锤百炼的，有了这些组件的帮助，在有足够 CPU 和内存支持的情况下，Linkerd 能够达到非常高的负载能力；然而设计过程中鲜有考虑在有限的资源情况下，基于 sidecar 模式的 Kubernetes 部署方式。所以今年年初，我们自问：有了 18 个月的生产级 Service Mesh 的经验，如果要做出一个功能完备又可以在低资源环境下运行的 Service Mesh，我们会怎么做？
答案就是 Conduit。和 Linkerd 类似，Conduit 是让微服务安全可靠的下一代 Service Mesh。他能透明的管理服务之间的通信，自动提供可测性、可靠性、安全性和弹性的支持。还是跟 Linkerd 相仿，他的数据平面是在应用代码之外运行的轻量级代理，控制平面是一个高可用的控制器。然而和 Linkerd 不同的是，Conduit 的设计更加倾向于 Kubernetes 中的低资源部署。
Conduit 为什么伟大（hhhhh）：
- 轻量高速：Conduit 代理只需要不到 10 MB 实际内存（RSS），p99 延迟在分毫秒以内。
- 安全：Rust 的内存使用相当安全，同时还缺省使用了 TLS，Conduit 的安全性与生俱来。
- 最小化：Conduit 的特性集被设计为尽量的最小化和可编排，便于使用 gRPC 插件进行定制。
- 易用性：内置有聚合的服务指标，强大的客户端工具（想想看，微服务界的 tcpdump），Conduit 为运维人员提供了新的强大的工具来对付生产环境的微服务。
过去半年中我们一直在努力的构建 Conduit。我们聘请了 Phil、Carl、Sean 以及 Brain 这样的高手；向 Tokio 和 Tower 这样的核心技术投资，让 Conduit 又快又安全。最重要的是，我们决心用 Conduit 解决在 Linkerd 社区遇到的实际问题。
Linkerd 怎么办？
简单说说，Linkerd 是世界上最广泛在生产环境进行使用的 Service Mesh，他会长期存在，我们会持续的进行开发、管理并提供商业支持；我们会保证我们的 Linkerd 用户的幸福感。
Conduit 不是 Linkerd 2.0。Conduit 面向的是非常特定的环境 —— Kubernetes，而不准备像 Linkerd 一样做出众多的集成支持。我们的大量用户在使用 ECS、Consul、Mesos、ZooKeeper、Nomad、Rancher 或者混合的多环境系统，Linkerd 是目前的最好选择，我们会持续投入进行改善。
现在开始！
我们刚刚发布了 Conduit 0.1。来跳坑吧！目前这是个 Alpha 版本，所以理直气壮的仅提供 HTTP/2 的支持（是的，HTTP/1.1 都不支持）。我们希望我们的早期用户能够尽早接触 Conduit，并从中获得反馈。
接下来的几个月中，我们会积极工作，推进 Conduit 的生产化进程，预计来年初面世的 0.2 中，会加入 HTTP/1.1 和 TCP 的支持（路线图）。这一产品的进展和目标会非常公开。最后，我们还会提供 Conduit 的商业支持，如果有兴趣的话可以联系我们。
想要了解更多？可以订阅我们的发布通知邮件列表，加入 Linkerd 的 Slack 频道，或者 Follow @runconduit。
Conduit 是基于 Apache 2.0 协议的开源软件。