Buoyant是一家雲服務公司，宣布了Linkerd(發音為“linker-DEE”)的一周年紀念日，這是一個基於微服務的原生雲應用程序的開源“服務網格”項目。誠如公告所述：
在20世紀90年代，TCP/IP協議之類網絡通信的轉變，使得全行業從主機轉移到客戶機/服務器結構，Linkerd作為下一代雲應用的基礎網絡層，受到越來越多的采用，使得企業能夠在不犧牲可靠性的情況下將其計算架構從單片應用轉移到了微服務。
Linkerd通過自動化負載均衡、服務發現和運行時恢復能力為微服務提供可靠性。
Linkerd於2016年2月發布0.1.0版本，由前Twitter工程師William Morgan，現任Buoyant首席執行官和 Oliver Gould（Buoyant現任首席技術官）創建。Linkerd建立在 Finagle之上 ，是“一個與協議無關的、用於JVM的異步RPC系統，這使它可以簡單地在Java、Scala或者任何JVM托管語言中構建強大的客戶端和服務器”，部署在Twitter的生產環境中。
下圖演示了Linkerd如何被部署成應用程序實例的服務網格：
Buoyant最近發布了Linkerd的0.9.0版本。此為新版本特點：
- 改進管理儀表板
- 改進對 Prometheus指標的支持
- 簡化路由器名稱
InfoQ獨家專訪Bouyant的創始人兼首席執行官William Morgan，並談及了這個里程碑。
InfoQ： Linkerd是什么，為什么微服務和雲本地應用程序在通信層需要新的“服務網格”？
Morgan： Linkerd是一個“服務網格”，它是專用於處理時間敏感的服務到服務的通信基礎設施層。與傳統網格物料相反，服務網格進行請求級別操作。所以我們不談論數據包或者是字節，我們考慮的是請求導致響應的結果。服務Foo將與服務Bar交流，並且等待它做出響應，當它做到時，Foo將會處理結果，然后將自己的結果中繼給它的調用者。如果Bar不及時回應，那么Foo也不得不做出一些反饋。
當然這種請求-響應模式自從網絡編程開始便一直存在，但正在改變的是，對於微服務，使用原生雲應用程序，每次對應用程序進行調用，這種通信將在應用程序內發生了幾十或者幾百次。因此，如果有成千上百個的服務，而且每個服務運行數百個實例，並且每秒有數百個請求，那么你最終會遇到一個非常復雜的請求流通過應用程序。而且這個實例可能正在死亡，或者正變得越來越超負荷，又或者被重新安排了所有的時間….總之它變得十分復雜。
服務網格的目標是解耦這個模型的操作復雜性，將其移動到應用程序之外，使應用程序保持純凈。因此程序代碼只需要說：“嘿，我是服務Foo，我需要發送請求到服務Bar。”而操作的東西，比如重試、超時、截止日期、負載均衡和服務發現，他們不僅極其難以找到合適的，但關鍵是找到了合適的之后，應用程序也不會停留太長時間，當然，如果他們不正確，應單獨處理。它們是在單獨的一層，在那里，他們可以獨立於應用程序運行進行管理。
Linkerd以它目前的形式，是一個用戶空間代理，因為這是人們最容易使用的。這就像注入了類固醇的HAProxy。但是根本上服務網格概念遠遠超過了代理模型。