TL博士：我們內部網路配置管理系統 QControl 的客戶端-伺服器架構的描述。 它基於兩層傳輸協議，可處理 gzip 打包的訊息，無需在端點之間解壓縮。 分散式路由器和端點接收設定更新，並且協定本身允許安裝本地化中間中繼。 該系統的建構原理 （“最近穩定”，如下所述）並使用 JMESpath 查詢語言和 Jinja 模板引擎來呈現設定檔。
Qrator Labs 經營一個全球分散式攻擊緩解網路。 我們的網路依照選播原則運行，子網路透過 BGP 進行通告。 作為物理上位於地球多個區域的 BGP 選播網絡，我們可以處理和過濾更靠近互聯網核心（一級運營商）的非法流量。
另一方面，成為一個地理上分散的網路並不容易。 網路存在點之間的通訊對於安全服務提供者擁有所有網路節點的一致配置並及時更新它們至關重要。 因此，為了向消費者提供盡可能高水準的核心服務，我們需要找到一種跨大陸可靠地同步配置資料的方法。
太初有道。 它很快就成為需要更新的通訊協定。
QControl 存在的基石，同時也是花費大量時間和資源來建立此類協議的主要原因，是需要獲得單一權威配置來源並最終同步我們的存在點用它。 儲存本身只是 QControl 開發過程中的幾個要求之一。 此外，我們還需要與存在點 (POP) 上的現有和計劃服務、資料驗證的智慧（且可自訂）方法以及存取控制進行整合。 除此之外，我們也希望使用指令來控制這樣的系統，而不是修改檔案。 在 QControl 出現之前，資料幾乎是手動傳送到存在點的。 如果其中一個存在點不可用並且我們稍後忘記更新它，則配置最終會不同步，我們將不得不浪費時間將其恢復並運行。
於是，我們提出瞭如下方案：
配置伺服器負責資料驗證和儲存；路由器有多個端點，用於接收設定更新並將其從客戶端和支援團隊廣播到伺服器，以及從伺服器廣播到存在點。
世界各地的網路連線品質仍然存在很大差異 - 為了說明這一點，讓我們來看看從捷克共和國布拉格到新加坡和香港的簡單地鐵。
從布拉格到新加坡的地鐵
香港也一樣
高延遲意味著較低的速度。 另外，還有丟包的情況。 通道寬度並不能彌補這個問題，在建構去中心化系統時必須始終考慮到這一點。
存在點的完整配置包含大量數據，必須透過不可靠的連線傳送給許多收件者。 幸運的是，雖然配置不斷變化，但變化的增量很小。
最近穩定的設計
可以說，基於增量更新原理建構分散式網路是一個相當明顯的解決方案。 但差異存在著許多問題。 我們需要保存參考點之間的所有差異，並且還能夠重新發送它們，以防有人丟失部分資料。 每個目的地必須按照嚴格指定的順序應用它們。 通常，在多個目的地的情況下，這樣的操作可能需要很長時間。 接收器還必須能夠請求遺失的部分，當然，中央部分必須正確回應此類請求，僅發送遺失的資料。
結果，我們得出了一個相當有趣的解決方案 - 我們只有一個參考層，固定的，我們稱其為穩定的，並且只有一個差異 - 最近的。 每個最近的數據都基於最後產生的穩定數據，足以重建配置數據。 一旦新的最近的到達目的地，舊的就不再需要了。
剩下的就是不時發送新的穩定配置，例如因為最近的配置變得太大。 這裡同樣重要的是，我們以廣播/多播模式發送所有這些更新，而不用擔心單一接收者及其拼湊資料片段的能力。 一旦我們確定每個人都有正確的馬厩，我們只會發送最近的新馬厩。 是否值得澄清這是否有效？ 作品。 穩定版本快取在配置伺服器和收件者上，最新版本根據需要建立。
二級傳輸架構
為什麼我們要在兩個層面上建造我們的交通？ 答案非常簡單 - 我們希望將路由與高級邏輯分離，從 OSI 模型及其傳輸層和應用程式層中汲取靈感。 我們使用 Thrift 來充當傳輸協定的角色，並使用 msgpack 序列化格式來充當控制訊息的高級格式。 這就是為什麼路由器（執行多播/廣播/中繼）不會查看 msgpack 內部，不會解包或打包內容，而僅轉發資料。
Thrift（來自英語 - “thrift”，發音為 [θrift]）是一種介面描述語言，用於為不同的程式語言定義和創建服務。 它是遠端過程呼叫（RPC）的框架。 將軟體管道與程式碼產生引擎結合，以開發在語言之間或多或少高效且輕鬆工作的服務。
我們選擇Thrift框架是因為RPC並且支援多種語言。 像往常一樣，簡單的部分是客戶端和伺服器。 然而，路由器卻是一個棘手的難題，部分原因是我們在開發過程中缺乏現成的解決方案。
還有其他選擇，例如 protobuf / gRPC，但是，當我們開始專案時，gRPC 還很新，我們不敢接受。
當然，我們可以（事實上應該）建造自己的自行車。 根據我們的需求建立一個協定會更容易，因為與在 Thrift 上建立路由器相比，客戶端-伺服器架構的實作相對簡單。 無論如何，人們對自行編寫的協議和流行庫的實現存在一種傳統的偏見（有充分的理由）；此外，在討論過程中總是會出現這樣的問題：「我們如何將其移植到其他語言？” 於是我們立刻就丟掉了自行車的想法。
Msgpack 與 JSON 類似，但更快、更小。 它是一種二進位資料序列化格式，允許在多種語言之間交換資料。
在第一級，我們使用 Thrift 提供路由器轉發訊息所需的最少資訊。 第二層是打包好的 msgpack 結構。
我們選擇 msgpack 是因為它比 JSON 更快、更緊湊。 但更重要的是，它支援自訂資料類型，使我們能夠使用很酷的功能，例如傳遞原始二進位檔案或指示缺少資料的特殊對象，這對於我們的「最近穩定」方案很重要。
JMES路徑
JMESPath 是一種 JSON 查詢語言。
這正是我們從 JMESPath 官方文件中得到的描述，但事實上，它的作用遠不止於此。 JMESPath 可讓您搜尋和過濾任意樹結構中的子樹，並即時對資料套用變更。 它還允許您添加特殊的過濾器和資料轉換程式。 當然，儘管它需要大腦的努力才能理解。
神社
對於某些消費者，我們需要將配置轉換為文件 - 因此我們使用模板引擎，而 Jinja 是顯而易見的選擇。 在它的幫助下，我們根據模板和在目的地接收的資料產生設定檔。
要產生設定文件，我們需要一個 JMESPath 請求、FS 中檔案位置的範本以及配置本身的範本。 在這個階段澄清文件權限也是一個好主意。 所有這些都成功地合併在一個檔案中 - 在設定範本開始之前，我們放置了一個 YAML 格式的標頭來描述其餘部分。
例如：
---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}
為了為新服務製作配置文件，我們只需添加新的模板文件。 無需更改存在點上的原始碼或軟體。
自 QControl 上線以來發生了哪些變化？ 第一件也是最重要的事情是將配置更新一致且可靠地傳送到網路中的所有節點。 第二個是獲得一個強大的工具，用於由我們的支援團隊以及服務的消費者檢查配置並對其進行更改。
我們能夠使用最近穩定的更新方案來完成所有這一切，以簡化配置伺服器和配置接收者之間的通訊。 使用兩層協定支援內容無關的資料路由方式。 成功地將基於 Jinja 的配置產生引擎整合到分散式過濾網路中。 該系統支援我們的分散式和異質外設的多種配置方法。
感謝您在撰寫資料時提供的協助。 , , .
郵政。
來源： www.habr.com