LinkedIn如何重新設計其已有17年曆史的整體訊息傳遞平臺 - thenewstack

banq發表於2020-06-16

LinkedIn訊息平臺現在儲存了價值17年的訊息（使用17年的不同產品功能建立），並且傳送的訊息數量一直保持不變往上走。
最初，這些訊息看起來很像電子郵件。現在，他們看起來更像是聊天，帶有主題，群組對話，表情符號，沒有主題行。支援該訊息傳遞系統的程式碼已經過更新，變得越來越複雜，但是多年來，支援所有不同的LinkedIn訊息傳遞體驗的通用基礎結構並未發生太大變化。
原始基礎架構是一個單一的Oracle資料庫，在一個資料中心中執行，有兩個表為兩項服務提供動力：一個用於儲存訊息，其中包括用於多個LinkedIn產品的訊息的所有業務邏輯，以及一個負責不同方法的訊息。可以傳遞郵件-推送通知，不同的電子郵件格式以及跟蹤它們的接收情況。
隨著時間的推移，LinkedIn新增了新的資料中心，並使用其自己的NoSQL JSON資料庫Espresso切換到具有分片架構的分散式資料儲存。向外擴充套件帶來了自己的複雜性。使用個人資料路由服務在各個分片之間劃分不同的訊息郵箱，以跟蹤其訊息收件箱位於哪個分片上，並進行雙向複製，以在出現可用性問題時將每個分片的副本放入不同的資料中心。
當任何LinkedIn產品團隊想要向訊息傳遞中新增功能（有時為其編寫程式碼或與他們合作進行開發）時，基礎結構團隊都會參與其中，並負責維護生產中的所有新程式碼。所有這些業務用例都存在於一個單獨的程式碼庫中，由訊息團隊負責長期維護。
隨著公司的發展，隨著我們在17年內增加了更多的業務範圍，用例變得越來越複雜，用例也越來越多，大約有六十種不同的自定義業務邏輯。這對於我們的工程師來說確實很難。沒有人能完全理解平臺中發生的每個業務用例。
開發人員對最簡單的更改過於謹慎，因為越來越多的團隊時間都花在了保持執行上。維護成本消耗了大部分工程時間。

解決辦法
在在基礎結構和產品團隊之間重新分配服務所有權。分解訊息內容，讓可以共享的內容共享，然後將不需要共享的內容隔離到一個服務中，然後圍繞責任歸屬設計我們的系統，然後提供這些服務的資料成為後面資料庫的責任。
訊息傳遞的基本單元不再是整個收件箱，而是會話，這使得傳遞快速的搜尋和檢索時間變得更加容易，因為會話和訊息可以分解並分佈在整個資料庫中。會話與訊息分開儲存，並帶有對訊息的引用，以避免非常活躍的資料庫記錄出現“熱key”問題，這些問題可能會使系統變慢。
現在，無法直接從訊息列表中獲取某個訊息，只能獲取會話列表，只有訪問了其中一個會話，才可以訪問其中的訊息。
產品團隊仍與基礎架構團隊一起工作，但是所有自定義業務邏輯已從訊息儲存中移出並封裝到外掛中以實現其功能，並且不同的服務所有者可以在需要幫助時與他們一起工作。

更詳細點選標題見原文



 

相關文章