多年來，我們一直很高興地看到我們的使用者建立了令人驚奇的東西。例如，Discord使用Tokio將尾部延遲降低了5倍。Fly.io發現，有了Tokio，他們可以毫不費力地滿足他們的效能要求，並專注於為客戶提供功能。對於Zcash基金會來說，基於Tokio的構建使他們能夠設計抗誤用的API。對於AWS來說，他們的Lambda團隊使用Tokio實現了更加可靠和靈活的服務。

四年多前，我們首次公佈了Tokio。從那時起，它有了很大的發展。最顯著的變化發生在一年前，在Rust中加入了async和 await。今天，Tokio更容易使用，功能更強大。這種進化也引起了一些摩擦。它需要庫來跟蹤這些變化，當不小心依賴多個版本的 Tokio 時，可能會導致混亂的錯誤資訊。

Tokio 1.0 版本結束了這種混亂。作為版本的一部分，我們承諾為生態系統提供一個穩定的基礎。我們目前沒有 Tokio 2.0 的計劃，我們承諾至少在 3 年內不釋出 Tokio 2.0。我們計劃維護 Tokio 1.0 分支至少 5 年。Tokio 將保持 6 個月的滾動 MSRV（最小支援的 rust 版本）政策。當增加MSRV時，新的Rust版本必須至少在6個月前釋出。

這種穩定性並不意味著 Tokio 會停滯不前。我們還有很多工作要做。

我們預計在未來一年內會重點關注幾個領域。Stream、io_uring、追蹤整合和Tokio堆疊。

流

今天，tokio-stream crate提供了基於Stream trait的非同步迭代工具。將Stream trait從期貨核心轉移到Rust標準庫的RFC正在等待批准。

一旦標準庫提供了 Stream trait，Tokio 的 Stream 工具將被轉移到 Tokio crate 中。

io_uring 是一個新的 Linux 介面，為所有型別的 I/O（包括磁碟）提供非同步操作，同時減少所需的系統呼叫次數。目前，在 Linux 上，Tokio 使用 epoll(7)介面，但眾所周知，它不能用於磁碟訪問。為了解決這個問題，Tokio 提供了非同步檔案系統 API，將同步操作排程到執行緒池。雖然這樣做是可行的，但並不是最佳的。

透過利用io_uring，Tokio將能夠提供真正的非同步檔案系統操作。此外，io_uring 的早期基準非常有前途，我們希望這些效能的提升能夠延續到 Tokio 上。

圍繞運營Tokio應用定義一流的故事將是2021年的重點。這個故事的一個重要部分將是圍繞跟蹤和指標的工具。追蹤箱已經提供了許多所需的基礎設施。它為結構化診斷實現了一個面層和資料模型，允許庫和應用程式發出可被以各種方式消耗的機器可讀資料。

在未來的一年裡，我們將在跟蹤和Tokio堆疊的其他部分之間建立更深入的整合。這種整合將有助於提供Tokio內部所需的可見性，以回答問題。比如你如何調整Tokio執行時以減少尾巴延遲，知道當前正在執行的任務，或者哪些鎖是最有爭議的。

此外，我們將繼續改進和發展追蹤生態系統的其他部分。這包括新版本的核心跟蹤和跟蹤核心的裝箱，在Tokio堆疊的庫中新增更豐富的工具，並提供與其他診斷和可觀察性工具的整合，如tracing-opentelemetry。

Tokio為標準基元（如套接字和定時器）提供了執行時和非同步API，但網路應用通常會使用更高級別的協議，如HTTP和gRPC。Tokio協議棧包括HTTP的Hyper和gRPC的Tonic，以滿足這些需求。今天，我們釋出了支援 Tokio 1.0 的 Hyper 0.14。Tonic將很快更新。

隨著Tokio 1.0的釋出，我們也將專注於Tower，這是一套可重複使用的元件，用於構建可靠的客戶端和伺服器。

如果沒有我們眾多的貢獻者，特別是Alice Ryhl，她對專案的貢獻是非常寶貴的，Tokio是不可能的。感謝Tokio堆疊庫的領導者。Sean McArthur (Hyper), Lucio Franco (Tonic), Eliza Weisman (Tracing), 和Thomas De Zeeuw (Mio). 另外，如果沒有Aaron Turon和Alex Crichton的早期參與，Tokio是不可能實現的。

最後，還要感謝那些在經濟上支援 Tokio 的公司。Mozilla、Dropbox、Buoyant和AWS。