大家要如何以规模化方式运维微服务应用程序？实践当中会出现哪些问题，我们又该如何加以解决？在大规模与非预测性工作负载场景当中，我们需要满足哪些条件才能运行一款大型微服务应用程序，而又能够确保不必受到功能发布或者产品变更的影响？
在围绕微服务展开的探讨当中，我们发现几乎很少有人能够切实回答上述问题。以Docker、Mesos、Kubernetes以及gRPC为代表的各类新型技术成果的快速崛起使得我们能够轻松建立小型新架构。然而，高流量生产性用例又该如何实现？根据我们的推算，目前能够以规模化方式运行微服务，从而解决实际问题的企业数量仍然相当有限。
Twitter就是其中的典型代表。而且尽管其也经历过公共服务中断，但Twitter负责运维的是世界上规模最大的微服务应用之一，其中包含上百种服务、数以万计的节点以及每项服务中的数百万RPS。令人震惊的是，事实证明这样的工作绝非易事。虽然不是不可能，但需要企业投入多年并充分运用自身聪明才智，从而令一切在实践层面运作良好。
当Oliver和我前几年离开Twitter公司时，我们的目标是运用自己多年积累下的专业知识，将其转化成可供全世界各组织机构使用的可行性资源。令人振奋的是，这些知识中已经有相当一部分以开源项目的面貌了，也就是Finagle项目——这是一套用于支撑Twitter微服务架构的高通量RPC库。
Finagle属于Twitter的内部核心库，负责管理不同服务间之通信流程。事实上，Twitter公司的每一项在线服务都立足于Finagle构建而成，而且其支持着每秒发生的成百上千万条RPC调用。除了Twitter之外，Finagle还为多家企业的基础设施提供帮助，具体包括Pinterest、SoundCloud、Strava、StumbleUpon以及其它众多公司。
今天，我们很高兴地宣布我们将Finagle推向大众的愿景已经迈出了重要的一步。linkerd已经迎来其0.1.0版本，而我们亦以Apache License v2为基础对其进行了开源。
linkerd是我们面向微服务的开源RPC代理。它直接立足于Finagle构建而成，设计目标在于帮助用户简化微服务架构下的运维。这些多年积累下来的宝贵经验能够让我们轻松实现自包含、最低依赖性并确保将对现有应用程序的调整幅度控制在最低水平。
如果大家正在着手构建一套微服务方案，那么肯定需要发挥Finagle的各项优势——包括智能化、自适应负载均衡、服务发现抽象化以及内部业务流量路由等等。大家可以利用linkerd将这些功能添加进入，而无需对应用程序代码做出任何变更。另外，linkerd还提供一套漂亮的仪表板！
linkerd目前尚未彻底完工，不过遵循“早发布、频发布”的原则，我们认为现在已经应该将其早期版本交付给大家。
因此，如果大家对此抱有兴趣，那么不妨首先访问linkerd.io网站获取说明文档及进行下载。另外，如果大家乐于为其做出贡献，也可以直接前往linkerd GitHub repo提交您的成果。我们强烈支持开源精神——而我们也乐于以此为核心建立起一整套社区。
我们未来还有着漫长的发展道路，并已经准备好了一份接下来需要被添加进linkerd的令人兴奋的功能清单。欢迎大家加入我们这个开源大家庭。
——William、Oliver以及整个Buoyant团队
如果大家对这个名称感到好奇，我们将linkerd理解为微服务的‘动态链接器’，即dynamic linker。正如操作系统中的动态链接器需要获取库名称与函数以对该函数进行调用一样，linkerd也需要获取服务名称与RPC端点，从而对该RPC加以执行——而且整个过程安全且可靠。
参考资料：
http://j.news.163.com/docs/28/2016022009/BG8MBR7J9001BR7K.html
http://www.tuicool.com/articles/RRFFJrq