「樂高式鬆耦合」架構實戰

做者：王康

白山聯合創始人兼產品副總裁。
王康先生主要負責產品的完善與升級、產品開發流程把控及進度協調、產品設計改進及按期優化、產品全生命週期管理等工做。他帶領團隊實現白山首款產品CDN-X的多項創新，下降CDN使用門檻，極大拓展了CDN客戶資源，提高了白山品牌價值，促進總體CDN市場的擴大與發展。
王康先生曾就任於網宿科技，任該公司產品及售前高級總監，負責技術團隊的運營工做；擁有10年CDN行業經驗，專一於提升產品輸出的高質量和高可靠性。
王康先生擁有三項發明專利。

如今不少公司都在作鬆耦合，由於隨着業務發展、需求增長，緊耦合系統的問題會慢慢凸顯，並日益加重。
以雲分發行業爲例，其屬性在逐漸發生變化。過去，極少人產生內容，絕大多數人消費內容，雲分發主要如下行流量爲主，而隨着全民直播的興起，雲分發變成了雲交互；物聯網的發展使物與物的數據交流成爲主要方式，例如智能家居天天會產生上千條數據，但其中只有幾條會被消費；VR爆發，用戶產生的數據逐漸會從圖片、視頻轉變爲VR內容；基於此咱們能夠預料到上行流量將逐步增長，並逐漸超過下行流量，成爲基礎網絡架構的巨大挑戰。
用戶需求與網絡基礎環境的快速變化，使得咱們須要愈來愈快的實現需求，然而緊耦合系統卻爲研發帶來諸多困難，使功能實現愈來愈耗費精力與時間，因此在白山創立之初就決定作「樂高式鬆耦合」架構，來構建整個產品體系，像搭積木通常靈活自如。

1、 傳統難點
（1）需求堆積，收斂週期長
不少創業公司在成立之初採用野蠻生長的模式，原則是越快越好。緊耦合架構能夠很好的知足這些要求，他們能夠快速的創建CMDB與資源管理平臺，並配置自動化、portal、監控等功能。但隨着功能增多與需求開發的增長，這個系統逐漸變爲人心渙散。當有新需求發生時，他們須要爲其作不少硬編碼動做，收斂週期愈來愈長。
（2）「老中醫」資源的浪費
在緊耦合系統中，看似一個沒有什麼關係的小改動，極有可能會引發一個重大bug；爲防止錯誤發生，只能將系統設計的愈來愈複雜。例如爲防止客戶端掛掉，研發一般會爲其添加一個守護進程；當守護進程不穩定時，新入職的研發經常使用的解決方案是再添加一個守護進程，這就致使了系統愈來愈臃腫。
這時候，公司每每就須要經驗豐富、瞭解系統總體狀況的「老中醫」才能對平臺進行改造。而做爲核心資產的「老中醫」在忙於救火、進行技術攻堅，很難抽出時間來進行系統重構。

2、 「樂高式鬆耦合」架構落地
快速實現需求與需求實現愈來愈慢的矛盾如何解決？最終白山的產品架構聚焦在解耦上，方便平臺快速迭代，減小系統間依賴程度，打通無關聯項目，爲運營互動提供高效支持，確保服務質量。
（1） 第一層鬆耦合架構
以白山雲分發CDN-X系統爲例，其根本核心是運營。爲使運營支撐系統經過解耦讓公司的研發、運營靈活運轉，須要進行第一層抽象。將運營支撐系統抽象爲5個組件，包括：客戶管理類、帳單信息類、資源管理、運營監控和配置管理。並對這5個組件進行畫像，肯定邊界、輸入輸出，按照運營場景描述用戶場景。
幾個組件之間經過消息總線交互指令，經過標準的reset接口交互數據；同時將5個組件投入到實際開發中，按照不一樣類型作實例化。

（第一層鬆耦合架構）

（2）第二層鬆耦合架構
作完第一層解耦以後，咱們發現第二層還能夠繼續作抽象。以配置管理系統爲例，又可抽象出4部分。

1. 生成配置：主要負責配置的生成以及配置到git倉庫；

2. 分發控制：管理灰度發佈過程；

3. 執行分發：分發收到的指令，並經過一些工具（如：salt、ansible、http get）彙報給上面的組件；

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

（第二層鬆耦合架構）

運營支撐系統中的各個組件均可以一直抽象下去，抽象概念貫穿整個設計平臺的始末。
核心組件設計時再通過進一步抽象成工廠模式或單例模式，造成針對不一樣特性服務及場景，只需編寫極小的落地代碼便可得到整個運營支撐服務的可插拔架構。

（3）建設原則

1. 組件即服務
   研發中人人都是架構師，收到研發需求後不是研究輸入輸出與邊界，而是瞭解業務。根據狀況輸出需求文檔，並與業務方進行確認，按照需求設計架構。每個組件，再也不是功能，而是服務，有本身的服務對象；研發人員從最初的對代碼質量、輸入輸出負責，發展爲對服務質量負責。

2. 事件組件化
   在最初設計過程當中，咱們發現，不少運營中的動做稱不上是平臺上的動做，而是由事件組成。若是這些事件經過自動化來完成，就須要投入大量的精力。以節點上架自動化爲例：包括自動化掃描端口、監控、安裝、配置下發管理，甚至能夠將自動化加入當前系統平臺爲用戶提供服務。組件自動後，若是包裝成事件，將浪費沒必要要的人力成本。若是將事件組件化，運維管理人員則能夠在平臺上方便的拖拽、引用、規範組件，經過拖拽、配置工做實現總體自動化。

3. 數據聚合管理系統
   數據每每是運營中的判斷標誌，經過數據與數據間的關係來組建成組件。因爲數據源之間的API不一樣，會致使花費過長的時間來對接API。咱們將機房質量、監控負載、慢速比、卡頓率等數據進行整理，部分進行二次轉化，經過統一的接口調用，作成一個數據聚合管理系統。

實例分享－節點自動上線

（運維完成過程）

這個過程當中運維人員完成了不少組件，如：配置管理、內部測試以及外部測試、入覆蓋地區等；隨後引入多種數據源進行追蹤。事件模版完成後只需運維人員選擇需上架的節點及其覆蓋方案與地區，其他過程均有系統自動化完成。
此模版還能夠根據須要不斷修改，例如：丟包率組件等能夠隨時加入，不會影響業務的進行。
不少公司也在作一樣的事件管理系統，不一樣的是其管理的是動做；而咱們發現每每動做完成後還須要進行人工跟蹤。鑑於此咱們將事件作成一個完整的生命週期，同時引入數據源來跟蹤異常服務狀態碼。
這個事件的完成過程當中運維人員所需的操做已經從寫腳本、人肉分析，簡化爲在模版上拖拽、引用組件，根據經驗設置閥值，甚至使用其餘的事件模版來完成事件。

3、 鬆耦合須要堅持的細節
（1）保持簡單
隨着時間的推移與功能的不斷增長，系統必然會出現複雜性，而這種複雜性不少是由咱們自身操做致使的，如上文提到的「守護進程」的例子，當使用複雜方案解決問題時每每會致使系統的臃腫。若是保證系統具有容錯能力，組件運營不正常時系統能夠自動修復，這個問題就會簡化。
以消息管理機制爲例，強消息管理機制要求確認消息確實能夠被每臺設備收到並執行。咱們對此進行了改善，使消息病毒式傳播，每臺設備能夠向周圍5-6臺設備發出消息，即使中間有一次失敗，還會有其餘設備再次向這臺設備傳輸。這樣的容錯能力保證了系統能夠簡單地自動實現強研發、強跟蹤等功能。
（2）在平臺的基礎上構建應用程序
例如在大數據平臺上構建應用，研發人員在開發組件時無需考慮數據庫的設計以及瓶頸優化問題，只須要對接數據聚合平臺，大幅提升研發效率。
（3）不斷迭代
以Facebook爲例，目前每秒能夠處理12億張圖片；而其初版系統只能容許用戶上傳圖片，並將其保存在數據庫中，該系統只存續3個月；隨着活躍用戶的增長， 其後端壓力不斷增長，因而將存儲改成二進制存儲方式；Facebook的每一次迭代都不是爲了某一特定目標，而是爲了解決業務上的痛苦。
因此最開始作開發時，咱們只須要考慮需求與業務，設計足夠簡單的方案，再進行不斷迭代以知足新增需求。

4、 帶來的變化（1） 快捷引入新特性咱們使用P2P消息管理機制結合收斂算法，將文件刪除由5分鐘改進至0.7秒，咱們對系統沒有進行大範圍改變，只是替換了其中的消息機制，利用當前基礎的通信機制和基礎數據，過去所作的優化與UI仍能夠繼續使用。引用這些新特性時保持輕量級，對其餘組件幾乎沒有影響。（2） 開發效率高例如遊戲交互過程當中的數字包交互，業內公認很難作到。目前咱們正在進行嘗試，咱們引入開源的TCP代理軟件，並規劃新的應用服務類型，軟件按指定好的打包方式放在指定位置，就能夠實現軟件的自動發佈，同時調用其餘組件接口對新業務進行監控，編寫配置生成邏輯實現業務配置自動化。只須要編寫很是輕量級的落地代碼，整個組件落地以後就能夠服務運營。（3）運維自動化提升在問題定位時，若是人工跟蹤通常是「是與否選擇」的串行計算，而在事件管理系統中，則進行並行計算，即：調用監控系統，判斷節點是否正常；調用第三方數據進行及時測試，判斷節點當前服務是否正常；調用客戶App數據驗證服務質量；使用ELK系統分析日誌，精準、快速的定位問題，分析時間由10分鐘大幅度縮減爲3分鐘。