Lotus升級：可靠性、安全性、敏捷性和穩健性均有改進

RetrievalMarket小型峯會的目的是聚集多個Retrieval Market解決方案的所有構建者，突出迄今為止取得的進展，並確定多個系統如何結合在一起以提高檢索交易的效率、效率和可靠性對於網絡用戶。

在4月的Retrieval Market Builders Mini-Summit上，Raul Kripalani（libp2p和星際文件系統核心开發者）深入研究了Lotus節點的架構和計劃的更改，特別是對Lotus-miner節點的更改，以更好地滿足客戶的需求和網絡參與者。

該演講旨在強調為Lotus客戶確保檢索交易高度可靠和可擴展所需的工作——幫助確保星際文件系統檢索市場建立在穩健的基礎上。

Lotus是星際文件系統網絡的一個實現，用Go編寫。作為星際文件系統的第一個實現，Lotus旨在為整個網絡奠定堅實而有彈性的基礎。任何星際文件系統節點的核心功能之一是實現有用數據的存儲和檢索－從而為星際文件系統網絡上強大的檢索市場奠定基礎。

Lotus節點的演變

星際文件系統生態系統正在快速發展，Lotus等生態系統工具也在不斷發展以滿足網絡的需求並嘗試未來的機會。特別是檢索市場將為星際文件系統網絡引入新功能，包括索引、CDN、公共檢索等。

我們發現的問題是，這些新的檢索市場能力將依賴於強大的客戶基礎——如今，Lotus客戶傾向於解決他們認為不穩定或無利可圖的某些功能。歸根結底，這是客戶見證的良好行為；它幫助Lotus實現發展以滿足他們的需求。當網絡參與者开始切除某些功能時，表明軟件本身應該為其用戶提供更多的靈活性和模塊化。

通過這一觀察，我們意識到Lotus的單體二進制文件阻礙了Lotus客戶的靈活和穩健的操作，並確定了解決問題的機會。

單體二進制

到目前為止，Lotus節點的架構在很大程度上是單體的。Lotus有兩個不同的入口點：1)一個完整節點，以及2)一個用戶。然而，除此之外，網絡參與者幾乎沒有選擇權在存儲生命周期中承擔哪些責任。例如，客戶的任務是挖掘、證明存儲、交易等。這些是根本不同的職責，但它們通過當前的Lotus-miner架構耦合在一起。

單體架構的問題

從廣義上講，這種整體架構阻止了客戶在不同的職責之間有效地分配他們的資源。強制合並責任與客戶的核心動機相矛盾，即在最小化運營風險的同時實現利潤最大化。具體來說，單體二進制存在許多問題。

脆弱性：當架構內沒有隔離時，一個區域的錯誤可能會泄漏並影響其他關鍵流程。這使得很難在關鍵和非關鍵進程之間進行分割，並使整個實例崩潰。

增加的攻擊面：Lotus客戶的某些進程需要公开公共端點，這使系統的該部分容易受到攻擊。如果架構是單一的，則單個公共端點可能會危及整個系統。

功能膨脹：在星際文件系統的使命中，客戶不僅存儲和提供原始數據，而且還提供有用的服務，例如索引、發現等。使用新的客戶側功能重載單個進程會導致進一步的擔憂和操作風險。

無法擴展：不同的能力需要不同的特性和不同的升級過程。嘗試在單一系統中管理這些不同的功能很困難，並且會導致迭代和增長緩慢。

缺乏細粒度控制：由於客戶無法主動選擇加入或退出功能，他們必須通過拒絕交易、設置高價以勸阻交易，甚至分叉代碼庫等機制來解決這些問題。

迭代減速：單體架構意味着更難測試和創新，因為沒有簡單的方法來隔離新組件並選擇加入實驗功能而不將其引入整個系統。

邁向模塊化客戶架構

看看Lotus客戶在幕後的職責，出現了兩個不同的類別挖掘業務和市場。這兩個層共享非常不同的服務和SLA。例如，Lotus客戶的挖掘作業是其最具經濟利潤的活動，並且本質上也是私有的。然而，市場運作是完全公开的，並在不同的盈利模式下運作。

使用這種初始分類，邁向解決單體架構缺點的模塊化客戶架構的第一步出現了：將Lotus客戶流程分為1)Lotus市場流程和2)其他Lotus客戶流程。

通過分離市場和挖掘，Lotus節點的架構對於客戶來說變得更加特定於功能，使他們能夠與最適合其能力和網絡經濟偏好的職責保持一致。

設計原則

在朝着更加模塊化的客戶架構的這條新道路上前進的同時，Lotus將繼續堅持一些設計原則：

避免類似微服務架構的復雜性：明確避免復雜的相互依賴網絡，這些網絡會迅速轉化為意大利面條式架構，並需要專門的工具（如服務網格）來管理和調試。這是向Lotus引入錯誤的復雜程度。秩序和等級仍然屬於，因為這些過程仍然是一個單一的有凝聚力的單元的一部分

簡單的中心/輻條架構：Lotus正在向中心輻射架構發展，該架構由主管管理。這些主管知道部署中提供了哪些功能以及哪些節點提供了這些功能。它們還充當聚合的外部API入口點。

在許多方面都值得投資：新的Lotus架構值得投資。除了盈利能力外，其他一些ROI因素包括可靠性、安全性、开發人員敏捷性和穩健性。

強大的分布式流程生命周期監督：模塊化架構並不意味着完全孤立的架構。如果出現故障並且意味着其他下遊服務將出現故障，那么整個系統必須能夠注意到並做出反應。

為了設計這個新的運行時，我們通過Erlang/OTP和面向角色的編程（例如JVM世界中的Akka）等模型來激勵自己，並從服務網格和編輯器中借用精選概念和抽象，而實際上並不完全依賴這些框架。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。