白山「樂高式松耦合」架構實戰

2021-08-19 12:52:11 字數 3300 閱讀 9379

現在很多公司都在做松耦合,因為隨著業務發展、需求增加,緊耦合系統的問題會慢慢凸顯,並日益加劇。

使用者需求與網路基礎環境的快速變化,使得我們需要越來越快的實現需求,然而緊耦合系統卻為研發帶來諸多困難,使功能實現越來越耗費精力與時間,所以在白山創立之初就決定做「樂高式松耦合」架構,來構建整個產品體系,像搭積木一般靈活自如。

很多創業公司在成立之初採用野蠻生長的模式,原則是越快越好。緊耦合架構可以很好的滿足這些要求,他們可以快速的建立cmdb與資源管理平台,並配置自動化、portal、監控等功能。但隨著功能增多與需求開發的增加,這個系統逐漸變為一盤散沙。當有新需求發生時,他們需要為其做很多硬編碼動作,收斂週期越來越長。

在緊耦合系統中,看似乙個沒有什麼關係的小改動,極有可能會引起乙個重大bug;為防止錯誤發生,只能將系統設計的越來越複雜。例如為防止客戶端掛掉,研發通常會為其新增乙個守護程序;當守護程序不穩定時,新入職的研發常用的解決方案是再新增乙個守護程序,這就導致了系統越來越臃腫。

這時候,公司往往就需要經驗豐富、了解系統整體情況的「老中醫」才能對平台進行改造。而作為核心資產的「老中醫」在忙於救火、進行技術攻堅,很難抽出時間來進行系統重構。

快速實現需求與需求實現越來越慢的矛盾如何解決?最終白山的產品架構聚焦在解耦上,方便平台快速迭代,減少系統間依賴程度,打通無關聯專案,為運營互動提供高效支援,確保服務質量。

以白山雲分發cdn-x系統為例,其根本核心是運營。為使運營支撐系統通過解耦讓公司的研發、運營靈活運轉,需要進行第一層抽象。將運營支撐系統抽象為5個元件,包括:客戶管理類、賬單資訊類、資源管理、運營監控和配置管理。並對這5個元件進行畫像,確定邊界、輸入輸出,按照運營場景描述使用者場景。

幾個元件之間通過訊息匯流排互動指令,通過標準的reset接**互資料;同時將5個元件投入到實際開發中,按照不同型別做例項化。

圖1:第一層松耦合架構

做完第一層解耦之後,我們發現第二層還可以繼續做抽象。以配置管理系統為例,又可抽象出4部分。

i.生成配置:主要負責配置的生成以及配置到git倉庫;

ii.分發控制:管理灰度發布過程;

iii.執行分發:分發收到的指令,並通過一些工具(如:salt、ansible、http get)匯報給上面的元件;

iv.執行測試:呼叫已經寫好的測試用例倉庫測試這一次配置分發過程的最後效果。

圖2:第二層松耦合架構

運營支撐系統中的各個元件都可以一直抽象下去,抽象概念貫穿整個設計平台的始末。

核心元件設計時再經過進一步抽象成工廠模式或單例模式,形成針對不同特性服務及場景,只需編寫極小的落地**即可獲得整個運營支撐服務的可插拔架構。

(1)元件即服務

研發中人人都是架構師,收到研發需求後不是研究輸入輸出與邊界,而是了解業務。根據情況輸出需求文件,並與業務方進行確認,按照需求設計架構。每乙個元件,不再是功能,而是服務,有自己的服務物件;研發人員從最初的對**質量、輸入輸出負責,發展為對服務質量負責。

(2)事件元件化

在最初設計過程中,我們發現,很多運營中的動作稱不上是平台上的動作,而是由事件組成。如果這些事件通過自動化來完成,就需要投入大量的精力。

以節點上架自動化為例:包括自動化掃瞄埠、監控、安裝、配置下發管理,甚至可以將自動化加入當前系統平台為使用者提供服務。元件自動後,如果包裝成事件,將浪費不必要的人力成本。

如果將事件元件化,運維管理人員則可以在平台上方便的拖拽、引用、規範元件,通過拖拽、配置工作實現整體自動化。

(3)資料聚合管理系統

資料往往是運營中的判斷標誌,通過資料與資料間的關係來組建成元件。由於資料來源之間的api不同,會導致花費過長的時間來對接api。我們將機房質量、監控負載、慢速比、卡頓率等資料進行整理,部分進行二次轉化,通過統一的介面呼叫,做成乙個資料聚合管理系統。

例項分享-節點自動上線

圖3:運維完成過程

這個過程中運維人員完成了很多元件,如:配置管理、內部測試以及外部測試、入覆蓋地區等;隨後引入多種資料來源進行追蹤。事件模版完成後只需運維人員選擇需上架的節點及其覆蓋方案與地區,其餘過程均有系統自動化完成。

此模版還可以根據需要不斷修改,例如:丟包率元件等可以隨時加入,不會影響業務的進行。

很多公司也在做同樣的事件管理系統,不同的是其管理的是動作;而我們發現往往動作完成後還需要進行人工跟蹤。鑑於此我們將事件做成乙個完整的生命週期,同時引入資料來源來跟蹤異常服務狀態碼。

這個事件的完成過程中運維人員所需的操作已經從寫指令碼、人肉分析,簡化為在模版上拖拽、引用元件,根據經驗設定閥值,甚至使用其他的事件模版來完成事件。

隨著時間的推移與功能的不斷增加,系統必然會出現複雜性,而這種複雜性很多是由我們自身操作導致的,如上文提到的「守護程序」的例子,當使用複雜方案解決問題時往往會導致系統的臃腫。如果保證系統具備容錯能力,元件運營不正常時系統可以自動修復,這個問題就會簡化。

以訊息管理機制為例,強訊息管理機制要求確認訊息確實可以被每台裝置收到並執行。我們對此進行了改善,使訊息病毒式傳播,每台裝置可以向周圍5-6臺裝置發出訊息,即便中間有一次失敗,還會有其他裝置再次向這台裝置傳輸。這樣的容錯能力保證了系統可以簡單地自動實現強研發、強跟蹤等功能。

例如在大資料平台上構建應用,研發人員在開發元件時無需考慮資料庫的設計以及瓶頸優化問題,只需要對接資料聚合平台,大幅提高研發效率。

以facebook為例,目前每秒可以處理12億張;而其第一版系統只能允許使用者上傳,並將其儲存在資料庫中,該系統只存續3個月;隨著活躍使用者的增加, 其後端壓力不斷增加,於是將儲存改為二進位制儲存方式;facebook的每一次迭代都不是為了某一特定目標,而是為了解決業務上的痛苦。

所以最開始做開發時,我們只需要考慮需求與業務,設計足夠簡單的方案,再進行不斷迭代以滿足新增需求。

我們使用p2p訊息管理機制結合收斂演算法,將檔案刪除由5分鐘改進至0.7秒,我們對系統沒有進行大範圍改變,只是替換了其中的訊息機制,利用當前基礎的通訊機制和基礎資料,過去所做的優化與ui仍可以繼續使用。引用這些新特性時保持輕量級,對其他元件幾乎沒有影響。

例如遊戲互動過程中的數字包互動,業內公認很難做到。目前我們正在進行嘗試,我們引入開源的tcp**軟體,並規劃新的應用服務型別,軟體按指定好的打包方式放在指定位置,就可以實現軟體的自動發布,同時呼叫其他元件介面對新業務進行監控,編寫配置生成邏輯實現業務配置自動化。只需要編寫非常輕量級的落地**,整個元件落地之後就可以服務運營。

白山「樂高式松耦合」架構實戰

白山聯合創始人兼產品副總裁 王康先生主要負責產品的完善與公升級 產品開發流程把控及進度協調 產品設計改進及定期優化 產品全生命週期管理等工作。他帶領團隊實現白山首款產品cdn x的多項創新,降低cdn使用門檻,極大拓展了cdn客戶資源,提公升了白山品牌價值,促進整體cdn市場的擴大與發展。王康先生曾...