Envoy如何將連接映射到線程

今天就跟大家聊聊有關Envoy如何將連接映射到線程，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

我得到的關于Envoy的最常見技術問題之一是要求對其使用的線程模型進行低級描述。 小編將介紹Envoy如何將連接映射到線程，以及內部使用的線程本地存儲（TLS）系統的描述，以使代碼極其平行且性能高。

Threading overview

Envoy使用三種不同類型的線程，如圖1所示。

Main：此線程擁有服務器啟動和關閉，所有xDS API處理（包括DNS，運行狀況檢查和常規集群管理），運行時，統計刷新，管理和一般進程管理（信號，熱啟動等）。 在此線程上發生的所有事情都是異步的并且是“非阻塞的”。通常，主線程協調所有不需要大量CPU來完成的關鍵過程功能。 這允許將大多數管理代碼編寫為單線程編寫。

Worker：默認情況下，Envoy為系統中的每個硬件線程生成一個工作線程。 （這可以通過--concurrency 選項控制）。 每個工作線程運行一個“非阻塞”事件循環，負責監聽每個偵聽器（當前沒有偵聽器分片），接受新連接，為連接實例化過濾器堆棧，以及處理所有IO的生命周期。 連接。 同樣，這允許將大多數連接處理代碼寫成好像是單線程的。

文件刷新器：Envoy寫入的每個文件（主要是訪問日志）當前都有一個獨立的阻塞刷新線程。 這是因為即使使用O_NONBLOCK寫入文件系統緩存文件有時也會阻塞（嘆息）。 當工作線程需要寫入文件時，數據實際上被移入內存緩沖區，最終通過文件刷新線程刷新。 這是代碼的一個區域，技術上所有工作人員都可以阻止同一個鎖嘗試填充內存緩沖區。 還有一些其他的將在下面進一步討論。

連接處理

如上所述，所有工作線程都會在沒有任何分片的情況下監聽所有偵聽器。 因此，內核用于智能地將接受的套接字分派給工作線程。 現代內核一般都很擅長這個; 他們使用諸如IO優先級提升之類的功能來嘗試填充線程的工作，然后開始使用同時監聽同一套接字的其他線程，以及不使用單個自旋鎖來處理每個接受。

一旦工人接受了連接，它就永遠不會離開那個工人。 所有進一步的連接處理都在工作線程內完全處理，包括任何轉發行為。 這有一些重要的含義：

Envoy中的所有連接池都是每個工作線程。 因此，盡管HTTP / 2連接池一次只與每個上游主機建立一個連接，但如果有四個工作站，則每個上游主機在穩定狀態下將有四個HTTP / 2連接。

Envoy以這種方式工作的原因是因為通過將所有代碼保存在單個工作線程中，幾乎所有代碼都可以在沒有鎖的情況下編寫，就像它是單線程一樣。 這種設計使得大多數代碼更易于編寫，并且可以非常好地擴展到幾乎無限數量的工作人員。

然而，一個主要的問題是，從內存和連接池效率的角度來看，調整 -- 并發選項實際上非常重要。 擁有比所需更多的工作人員將浪費內存，創建更多空閑連接，并導致更低的連接池命中率。 在Lyft，我們的邊車Envoys以非常低的并發性運行，因此性能大致與他們旁邊的服務相匹配。 我們只以最大并發性運行我們的邊緣Envoys。

什么是非阻塞

到目前為止，在討論主線程和工作線程如何操作時，已經多次使用術語“非阻塞”。 所有代碼都是在假設沒有任何阻塞的情況下編寫的。 然而，這并不完全正確（完全是真的嗎？）。 特使確實采用了一些過程寬鎖：

如前所述，如果正在寫入訪問日志，則所有工作程序在填充內存訪問日志緩沖區之前都會獲取相同的鎖。 鎖定保持時間應該非常低，但是這種鎖可以在高并發性和高吞吐量下競爭。

Envoy采用了一個非常復雜的系統來處理線程本地的統計數據。 這將是一個單獨的帖子的主題。 但是，我將簡要提一下，作為線程本地統計處理的一部分，有時需要獲取對中央“stat store”的鎖定。這種鎖定不應該高度爭用。

主線程需要定期與所有工作線程協調。 這是通過從主線程“發布”到工作線程（有時從工作線程返回到主線程）來完成的。 發布需要鎖定，以便將發布的消息放入隊列中以便以后發送。 這些鎖永遠不應該高度爭用，但它們仍然可以在技術上阻止。

當Envoy將自己記錄到標準錯誤時，它會獲取進程范圍的鎖定。 一般來說，Envoy本地記錄被認為是表現糟糕的，所以沒有多少考慮改善這一點。

還有一些其他隨機鎖，但它們都不在性能關鍵路徑中，永遠不應該爭用。

線程本地存儲

由于Envoy將主線程職責與工作線程職責分開，因此需要在主線程上完成復雜處理，然后以高度并發的方式使每個工作線程可用。 下面介紹了Envoy的高級線程本地存儲（TLS）系統。 

如已經描述的那樣，主線程基本上處理Envoy過程中的所有管理/控制平面功能。 （控制平面在這里有點過載但是當在特使過程中考慮并與工人做的轉發進行比較時，似乎是合適的）。 主線程進程執行某些工作是一種常見模式，然后需要使用該工作的結果更新每個工作線程，并且工作線程不需要在每次訪問時獲取鎖定。

Envoy的TLS系統的工作原理如下：

在主線程上運行的代碼可以分配進程范圍的TLS槽。 雖然是抽象的，但實際上，這是一個允許O（1）訪問的向量索引。

主線程可以將任意數據設置到其槽中。 完成此操作后，數據將作為正常事件循環事件發布到每個工作程序中。

工作線程可以從其TLS槽讀取，并將檢索那里可用的任何線程本地數據。

雖然非常簡單，但這是一個非常強大的范例，與RCU鎖定概念非常相似。 （實質上，工作線程在工作時從不會看到TLS插槽中的數據發生任何變化。更改只發生在工作事件之間的靜止期間）。 特使以兩種不同的方式使用它：

通過在沒有任何鎖定的情況下訪問每個工作人員存儲不同的數據

通過將共享指針存儲到每個worker的只讀全局數據。 因此，每個工作者都具有對在工作時不能遞減的數據的引用計數。 只有當所有工作人員都已停頓并加載新的共享數據時，舊數據才會被銷毀。 這與RCU相同。

集群線程更新

我將描述TLS如何用于集群管理。 群集管理包括xDS API處理和/或DNS以及運行狀況檢查。

圖3顯示了涉及以下組件和步驟的總體流程：

集群管理器是Envoy內部的組件，用于管理所有已知的上游集群，CDS API，SDS / EDS API，DNS和活動（帶外）運行狀況檢查。 它負責創建每個上游集群的最終一致視圖，其中包括已發現的主機以及運行狀況。

運行狀況檢查程序執行活動運行狀況檢查，并將運行狀況更改報告回集群管理器。

執行CDS / SDS / EDS / DNS以確定群集成員資格。 狀態更改將報告回集群管理器。

每個工作線程都在不斷運行事件循環。

當集群管理器確定集群的狀態已更改時，它會創建集群狀態的新只讀快照，并將其發布到每個工作線程。

在下一個靜止期間，工作線程將更新分配的TLS插槽中的快照。

在需要確定要負載均衡的主機的IO事件期間，負載均衡器將在TLS插槽中查詢主機信息。 沒有獲得鎖定來執行此操作。 （另請注意，TLS還可以在更新時觸發事件，以便負載平衡器和其他組件可以重新計算高速緩存，數據結構等。這超出了本文的范圍，但在代碼中的各個位置使用）。

通過使用先前描述的過程，Envoy能夠處理每個請求而不需要任何鎖定（除了之前描述的那些）。 除了TLS代碼本身的復雜性之外，大多數代碼都不需要理解線程如何工作，并且可以編寫為單線程。 這使得大多數代碼更容易編寫，并產生出色的性能。

其他使用TLS的子系統

TLS和RCU在Envoy中廣泛使用。 其他一些例子包括：

運行時（功能標志）覆蓋查找：在主線程上計算當前功能標志覆蓋映射。 然后使用RCU語義為每個工作程序提供只讀快照。

路由表交換：對于RDS提供的路由表，路由表在主線程上實例化。 然后使用RCU語義為每個工作程序提供只讀快照。 這使得路由表交換有效地原子化。

HTTP日期標頭緩存：事實證明，在每個請求上計算HTTP日期標頭（當每個核心執行~25K + RPS時）非常昂貴。 Envoy大約每半秒計算一次日期標題，并通過TLS和RCU將其提供給每個工作人員。

還有其他情況，但前面的例子應該提供TLS所用事物的良好品味。

已知的性能陷阱

雖然Envoy整體表現相當不錯，但是當它以非常高的并發性和吞吐量使用時，有一些已知領域需要注意：

正如本文中已經描述的那樣，當前所有工作者在寫入訪問日志的內存緩沖區時都會獲得鎖定。 在高并發性和高吞吐量的情況下，當寫入最終文件時，將需要以按順序交付為代價對每個工作人員批量訪問日志進行批處理。 或者，訪問日志可以成為每個工作線程。

盡管統計信息已經過非常優化，但在非常高的并發性和吞吐量下，個別統計信息可能存在原子爭用。 對此的解決方案是每個工人計數器，定期沖洗到中央計數器。 這將在后續文章中討論。

如果Envoy部署在幾乎沒有需要大量資源來處理的連接的場景中，現有架構將無法正常運行。 這是因為無法保證連接在工作人員之間均勻分布。 這可以通過實現工作者連接平衡來解決，其中工作人員能夠將連接轉發給另一個工作人員進行處理。

Envoy的線程模型旨在支持編程的簡單性和大規模并行性，但如果調整不當可能會浪費內存和連接使用。 該模型允許它在非常高的工人數量和吞吐量下表現良好。

正如我在Twitter上簡要提到的那樣，該設計也適合在DPDK之類的完整用戶模式網絡堆棧上運行，這可能導致商用服務器在執行完整的L7處理時每秒處理數百萬個請求。 看看未來幾年建成什么將是非常有趣的。

看完上述內容，你們對Envoy如何將連接映射到線程有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。