作者 | Eran Stiller
譯者 | 明知山
策劃 | Tina
LinkedIn 開源「Iris 消息處理器」，該服務被用於增強其現有 Iris 事件升級管理系統（Escalation Management System）的性能和可靠性。iris-message-processor 的處理速度有了顯著提升，相比之前的處理器，在平均負載下速度快 4.6 倍，在高負載下速度快 86.6 倍。
「iris-message-processor」是之前的 iris-sender 的分布式替代方案，支持更高的並發處理和直接將消息發送給目標供應商。它可以進行水平伸縮，並且不使用資料庫作為消息隊列，因而減少了對資料庫的依賴。
iris-message-processor 可以處理大量的事件，經測試，它可以在不到 10 秒的時間內處理 6000 個事件，與之前的系統需要 30 分鐘相比，進步巨大。即使在同時減少 50% 節點的情況下，新處理器也保持了高效的處理速度，可以在不到 30 秒的時間內完成集群再均衡，並在不到 3 秒的時間內處理升級事件，即使是在高於平均負載的情況下。
為了提升性能，LinkedIn 將 Iris 升級事件拆分為桶，動態分配給 Iris 消息處理器集群中的不同節點，改進了並發處理和直接發送消息的能力。Iris 進行了重新設計，以應對未來「10 倍」流量增長，避免在未來因需求增加時才匆忙進行改造。
_ 新 Iris 系統的架構（來源）_
新服務是用 Go 開發的。它不使用資料庫作為消息隊列，從而減輕了現有資料庫系統的壓力。新系統可以使用最終一致性資料庫來存儲結果消息進行審計跟蹤，從而增強了可伸縮性。
LinkedIn 已經使用 iris-message-processor 大約一年時間都沒有發生中斷，並始終保持每毫秒處理 1000 條消息的 SLO。作為 iris-sender 的替代方案，iris-message-processor 不僅保留了現有的 Iris API，同時還提供了實質性的性能改進。
LinekedIn 的工程師採用了各種措施來確保上線期間的穩定性，包括保持向後兼容性和進行增量式驗證和測試。
LinekedIn 已將 Iris -message-processor 開源，代碼可在 Iris 和 Oncall 代碼庫中找到。這個工具可以在 LinkedIn 的環境之外運行，可以完全取代其他現成的事件管理系統。
InfoQ 採訪了 LinkedIn 高級軟體工程師 Diego Cepeda，聊了聊關於 iris-message-processor 的話題，包括它的實現和開源。
InfoQ：引入 iris-message-processor 後，資源使用（CPU、內存、網絡帶寬）發生了什麼變化，這對運營成本有怎樣的影響？
Diego Cepeda：實際上，資源利用率的變化可以忽略不計。LinkedIn 的關鍵監控基礎設施具有非常高的容錯冗餘水平，因為我們認為可靠的監控是可靠運營的基礎。
我們的 Iris 實例分布在不同的數據中心，每個數據中心都有足夠的容量來處理整個站點的警報需求。不過，因為 Iris 足夠高效，我們在每個數據中心只使用了 3 個實例，每個實例只配備了 8 個核心和 32GB 內存，這些足夠了。
每個數據中心有 3 個 MySQL 主機為 Iris 和 iris-message-processor 提供支持。值得注意的是，即使對於 LinkedIn 這樣的規模，這樣的配置也有點過剩，因為每個 iris-message-processor 實例平均使用不到 5% 的 CPU 和不到 1% 的內存。
InfoQ：你是否可以提供一些投資回報率 (ROI) 指標來證明 iris-message-processor 與其他現成解決方案在成本效益方面的差異？
Cepeda：我們沒有與其他商業系統進行過比較或分析。不過，有大約 6000 名 Iris 內部用戶積極待命，我們可以據此推測，使用現成的解決方案將是一筆相當大的投入。
我們確實有時間維度的比較，例如持續維護 Iris 所需的工作量，我們估計大部分時間都花在幫助我們的開發人員熟悉系統和回答問題上。
此外，我們沒有專門為 Iris 投入人員資源，它只是監控基礎設施團隊負責處理的許多個服務中的一個。
Iris 已經為我們的整體投入帶來了回報。對於選擇使用 Iris 的組織來說，ROI 可能會更大，因為它們只會產生硬體和維護成本，並且可以從 Iris 的開源中受益。
InfoQ：你選擇 Go 作為 iris-message-processor 的開發語言，這個決定背後的原因是什麼？這個選擇對系統的性能和可伸縮性有怎樣的影響？
Cepeda：我們選擇 Go 是因為它能夠快速開發 Bug 少、高度可伸縮的並發應用程式。Go 的輕量級協程非常適合用來完成這項任務，因為管理並發任務變得很容易，避免了傳統線程的複雜性。使用通道在程序之間進行通信增強了安全性和同步能力。
此外，Go 的標準庫提供了並發、網絡、分布式系統和測試用的包，減少了對第三方庫的依賴，簡化了開發。這些特性使得我們能夠編寫 Bug 更少的代碼，支持高效的伸縮，並快速交付健壯的並發應用程式，如 iris-message-processor。
在過去的幾年，我們一直在用 Go 語言逐步重寫我們的大部分關鍵監控服務，並在開發速度、性能和可操作性方面獲得顯著的好處。一個典型的例子就是 iris-message-processor，它在高負載下的性能比之前的版本要好幾個數量級。
InfoQ：你提到 iris-message-processor 已經在 LinkedIn 運行了大約一年時間都沒有出現過中斷，並且始終保持很好的 SLO。你能分享系統在高壓環境下測試的例子嗎？它的表現如何？
Cepeda：值得慶幸的是，LinkedIn 的系統都是相對可靠的，所以我們很少對系統進行真正的壓力測試。當然，對於龐大而複雜的系統，出現故障總是不可避免的。我們曾經遇到過一個 DNS 問題導致我們的一個生產數據中心中的大部分服務（包括 iris-message-processor）無法訪問時。
這是我們所見過的最接近高壓的場景，數百個服務同時出現數千個警報，Iris 集群有三分之一的節點無法啟動。
值得慶幸的是，我們在設計 iris-message-processor 時就考慮到了這種場景。
正如我們所計劃的那樣，集群可以丟棄不可達的節點，進行再均衡，並在不到 60 秒的時間內處理升級事件。以前的系統可能需要幾十分鐘才能完全解決這個問題，這會導致處理信息不及時，浪費了工程師發現問題和解決問題的寶貴時間。
InfoQ：隨著 iris-message-processor 的開源，你希望社區可以帶來怎樣的特新和改進？你計劃如何管理開源項目，確保它們與目標和質量標準對齊？
Cepeda：iris-message-processor 的核心思想是可伸縮性和靈活性。我們意識到這個世界上不存在兩個完全相同的環境，在設計和實現中我們注意到了這一點。例如，我們目前使用 Twilio 發送語音和短消息，但其他組織可能使用不同的供應商。
我們沒有對他們進行強制鎖定，而是為消息供應商提供了一個可插拔的接口，任何想要集成到其他系統的組織都可以非常快速地編寫出一個新的插件，並在對代碼庫進行最少變更的情況下啟動並運行。
這種模式也體現在我們對存儲系統的選擇上。iris-message-processor 使用 MySQL 作為數據存儲，當然也可以很容易地使用其他數據存儲。所有與 MySQL 相關的代碼都進行了抽象，這樣就可以為不同的數據存儲編寫新的集成實現，而不需要修改代碼的其他部分。這種設計使得擁有不同技術棧的組織更容易採用新系統。
對於已經開源的 Iris 和 Oncall 來說，項目的管理無疑是一個挑戰。在這方面，我們採用基於測試驅動的開發和測試。為了確保與質量標準對齊，我們希望新的貢獻代碼是可測試的，除此之外，代碼在被接受之前會在本地開發環境進行驗證。
我們期待外部貢獻者幫助我們把它變成一個更好、更容易使用的平台。
查看英文原文：
https://www.infoq.com/news/2023/09/linkedin-iris-message-processor/
耗時一年用戶從 0 增長至 1400 萬，背後僅三名工程師，這家社交巨頭背後的技術棧是如何搭建的？
行業老兵聊 To B 產品技術：To B 難，難不過做好軟體
網易回應員工因 BUG 被 HR 威脅後輕生；阿里新 CEO：要讓 85、90 後成為主力管理者；華為 Mate60 正面「剛贏」蘋果？| Q 資訊
GitHub 變 Twitter？強「喂」新推薦算法引公憤，開發者從「編程烏托邦」被驅趕到了信息繭房