Buoyant是一家雲服務公司，宣佈了Linkerd(發音為“linker-DEE”)的一週年紀念日，這是一個基於微服務的原生雲應用程式的開源“服務網格”專案。誠如公告所述：

在20世紀90年代，TCP/IP協議之類網路通訊的轉變，使得全行業從主機轉移到客戶機/伺服器結構，Linkerd作為下一代雲應用的基礎網路層，受到越來越多的採用，使得企業能夠在不犧牲可靠性的情況下將其計算架構從單片應用轉移到了微服務。

Linkerd通過自動化負載均衡、服務發現和執行時恢復能力為微服務提供可靠性。

Linkerd於2016年2月釋出0.1.0版本，由前Twitter工程師William Morgan，現任Buoyant執行長和 

下圖演示了Linkerd如何被部署成應用程式例項的服務網格：

Buoyant最近釋出了Linkerd的0.9.0版本。此為新版本特點：

• 改進管理儀表板
• 簡化路由器名稱

InfoQ獨家專訪Bouyant的創始人兼執行長William Morgan，並談及了這個里程碑。

InfoQ： Linkerd是什麼，為什麼微服務和雲本地應用程式在通訊層需要新的“服務網格”？

Morgan： Linkerd是一個“服務網格”，它是專用於處理時間敏感的服務到服務的通訊基礎設施層。與傳統網格物料相反，服務網格進行請求級別操作。所以我們不談論資料包或者是位元組，我們考慮的是請求導致響應的結果。服務Foo將與服務Bar交流，並且等待它做出響應，當它做到時，Foo將會處理結果，然後將自己的結果中繼給它的呼叫者。如果Bar不及時迴應，那麼Foo也不得不做出一些反饋。

當然這種請求-響應模式自從網路程式設計開始便一直存在，但正在改變的是，對於微服務，使用原生雲應用程式，每次對應用程式進行呼叫，這種通訊將在應用程式內發生了幾十或者幾百次。因此，如果有成千上百個的服務，而且每個服務執行數百個例項，並且每秒有數百個請求，那麼你最終會遇到一個非常複雜的請求流通過應用程式。而且這個例項可能正在死亡，或者正變得越來越超負荷，又或者被重新安排了所有的時間….總之它變得十分複雜。

服務網格的目標是解耦這個模型的操作複雜性，將其移動到應用程式之外，使應用程式保持純淨。因此程式程式碼只需要說：“嘿，我是服務Foo，我需要傳送請求到服務Bar。”而操作的東西，比如重試、超時、截止日期、負載均衡和服務發現，他們不僅極其難以找到合適的，但關鍵是找到了合適的之後，應用程式也不會停留太長時間，當然，如果他們不正確，應單獨處理。它們是在單獨的一層，在那裡，他們可以獨立於應用程式執行進行管理。

Linkerd以它目前的形式，是一個使用者空間代理，因為這是人們最容易使用的。這就像注入了類固醇的HAProxy。但是根本上服務網格概念遠遠超過了代理模型。