作者：王康
王康 白山聯合創始人兼產品副總裁
(王康主要負責產品的完善與升級、產品開發流程把控及進度協調、產品設計改進及定期優化、產品全生命週期管理等工作。他帶領團隊實現白山首款產品CDN-X的多項創新，降低CDN使用門檻，極大拓展了CDN客戶資源，提升了白山品牌價值，促進整體CDN市場的擴大與發展。
王康曾就職於網宿科技，任該公司產品及售前高級總監，負責技術團隊的運營工作；擁有10年CDN行業經驗，專注於提高產品輸出的高質量和高可靠性。
王康擁有三項發明專利。)
現在很多公司都在做松耦合，因爲隨着業務發展、需求增加，緊耦合系統的問題會慢慢凸顯，並日益加劇。
以雲分發行業爲例，其屬性在逐漸發生變化。過去，極少人產生內容，絕大多數人消費內容，雲分發主要以下行流量爲主，而隨着全民直播的興起，雲分發變成了雲交互；物聯網的發展使物與物的數據交流成爲主要方式，例如智能家居每天會產生上千條數據，但其中只有幾條會被消費；VR爆發，用戶產生的數據逐漸會從圖片、視頻轉變爲VR內容；基於此我們可以預料到上行流量將逐步增加，並逐漸超過下行流量，成爲基礎網絡架構的巨大挑戰。
用戶需求與網絡基礎環境的快速變化，使得我們需要越來越快的實現需求，然而緊耦合系統卻爲研發帶來諸多困難，使功能實現越來越耗費精力與時間，所以在白山創立之初就決定做“樂高式松耦合”架構，來構建整個產品體系，像搭積木一般靈活自如。
傳統難點
1.需求堆積，收斂週期長
很多創業公司在成立之初採用野蠻生長的模式，原則是越快越好。緊耦合架構可以很好的滿足這些要求，他們可以快速的建立CMDB與資源管理平臺，並配置自動化、portal、監控等功能。但隨着功能增多與需求開發的增加，這個系統逐漸變爲一盤散沙。當有新需求發生時，他們需要爲其做很多硬編碼動作，收斂週期越來越長。
2.”老中醫”資源的浪費
在緊耦合系統中，看似一個沒有什麼關係的小改動，極有可能會引起一個重大bug；爲防止錯誤發生，只能將系統設計的越來越複雜。例如爲防止客戶端掛掉，研發通常會爲其添加一個守護進程；當守護進程不穩定時，新入職的研發常用的解決方案是再添加一個守護進程，這就導致了系統越來越臃腫。
這時候，公司往往就需要經驗豐富、瞭解系統整體情況的“老中醫”才能對平臺進行改造。而作爲核心資產的“老中醫”在忙於救火、進行技術攻堅，很難抽出時間來進行系統重構。
“樂高式松耦合”架構落地
快速實現需求與需求實現越來越慢的矛盾如何解決？最終白山的產品架構聚焦在解耦上，方便平臺快速迭代，減少系統間依賴程度，打通無關聯項目，爲運營互動提供高效支持，確保服務質量。
1.第一層松耦合架構
以白山雲分發CDN-X系統爲例，其根本核心是運營。爲使運營支撐系統通過解耦讓公司的研發、運營靈活運轉，需要進行第一層抽象。將運營支撐系統抽象爲5個組件，包括：客戶管理類、賬單信息類、資源管理、運營監控和配置管理。並對這5個組件進行畫像，確定邊界、輸入輸出，按照運營場景描述用戶場景。
幾個組件之間通過消息總線交互指令，通過標準的reset接口交互數據；同時將5個組件投入到實際開發中，按照不同類型做實例化。
第一層松耦合架構
2.第二層松耦合架構
做完第一層解耦之後，我們發現第二層還可以繼續做抽象。以配置管理系統爲例，又可抽象出4部分。
i. 生成配置：主要負責配置的生成以及配置到git倉庫；
ii. 分發控制：管理灰度發佈過程；
iii. 執行分發：分發收到的指令，並通過一些工具（如：salt、ansible、http get）彙報給上面的組件
iv. 執行測試：調用已經寫好的測試用例倉庫測試這一次配置分發過程的最後效果。
第二層松耦合架構
運營支撐系統中的各個組件都可以一直抽象下去，抽象概念貫穿整個設計平臺的始末。
核心組件設計時再經過進一步抽象成工廠模式或單例模式，形成針對不同特性服務及場景，只需編寫極小的落地代碼即可獲得整個運營支撐服務的可插拔架構。
3.建設原則
i. 組件即服務
研發中人人都是架構師，收到研發需求後不是研究輸入輸出與邊界，而是瞭解業務。根據情況輸出需求文檔，並與業務方進行確認，按照需求設計架構。每一個組件，不再是功能，而是服務，有自己的服務對象；研發人員從最初的對代碼質量、輸入輸出負責，發展爲對服務質量負責。
ii. 時間組件化
在最初設計過程中，我們發現，很多運營中的動作稱不上是平臺上的動作，而是由事件組成。如果這些事件通過自動化來完成，就需要投入大量的精力。
以節點上架自動化爲例：包括自動化掃描端口、監控、安裝、配置下發管理，甚至可以將自動化加入當前系統平臺爲用戶提供服務。組件自動後，如果包裝成事件，將浪費不必要的人力成本。
如果將事件組件化，運維管理人員則可以在平臺上方便的拖拽、引用、規範組件，通過拖拽、配置工作實現整體自動化。
iii. 數據聚合管理系統
數據往往是運營中的判斷標誌，通過數據與數據間的關係來組建成組件。由於數據源之間的API不同，會導致花費過長的時間來對接API。我們將機房質量、監控負載、慢速比、卡頓率等數據進行整理，部分進行二次轉化，通過統一的接口調用，做成一個數據聚合管理系統。
實例分享－節點自動上線
運維完成過程
這個過程中運維人員完成了很多組件，如：配置管理、內部測試以及外部測試、入覆蓋地區等；隨後引入多種數據源進行追蹤。事件模版完成後只需運維人員選擇需上架的節點及其覆蓋方案與地區，其餘過程均有系統自動化完成。
此模版還可以根據需要不斷修改，例如：丟包率組件等可以隨時加入，不會影響業務的進行。
很多公司也在做同樣的事件管理系統，不同的是其管理的是動作；而我們發現往往動作完成後還需要進行人工跟蹤。鑑於此我們將事件做成一個完整的生命週期，同時引入數據源來跟蹤異常服務狀態碼。
這個事件的完成過程中運維人員所需的操作已經從寫腳本、人肉分析，簡化爲在模版上拖拽、引用組件，根據經驗設置閥值，甚至使用其他的事件模版來完成事件。
松耦合需要堅持的細節
1.保持簡單
隨着時間的推移與功能的不斷增加，系統必然會出現複雜性，而這種複雜性很多是由我們自身操作導致的，如上文提到的“守護進程”的例子，當使用複雜方案解決問題時往往會導致系統的臃腫。如果保證系統具備容錯能力，組件運營不正常時系統可以自動修復，這個問題就會簡化。
以消息管理機制爲例，強消息管理機制要求確認消息確實可以被每臺設備收到並執行。我們對此進行了改善，使消息病毒式傳播，每臺設備可以向周圍5-6臺設備發出消息，即便中間有一次失敗，還會有其他設備再次向這臺設備傳輸。這樣的容錯能力保證了系統可以簡單地自動實現強研發、強跟蹤等功能。
2.在平臺的基礎上構建應用程序
例如在大數據平臺上構建應用，研發人員在開發組件時無需考慮數據庫的設計以及瓶頸優化問題，只需要對接數據聚合平臺，大幅提高研發效率。
3.不斷迭代
以Facebook爲例，目前每秒可以處理12億張圖片；而其第一版系統只能允許用戶上傳圖片，並將其保存在數據庫中，該系統只存續3個月；隨着活躍用戶的增加，其後端壓力不斷增加，於是將存儲改爲二進制存儲方式；Facebook的每一次迭代都不是爲了某一特定目標，而是爲了解決業務上的痛苦。
所以最開始做開發時，我們只需要考慮需求與業務，設計足夠簡單的方案，再進行不斷迭代以滿足新增需求。
像搭積木一樣靈活自由
帶來的變化
1.快捷引入新特性
我們使用P2P消息管理機制結合收斂算法，將文件刪除由5分鐘改進至0.7秒，我們對系統沒有進行大範圍改變，只是替換了其中的消息機制，利用當前基礎的通訊機制和基礎數據，過去所做的優化與UI仍可以繼續使用。引用這些新特性時保持輕量級，對其他組件幾乎沒有影響。
2.開發效率高
例如遊戲交互過程中的數字包交互，業內公認很難做到。目前我們正在進行嘗試，我們引入開源的TCP代理軟件，並規劃新的應用服務類型，軟件按指定好的打包方式放在指定位置，就可以實現軟件的自動發佈，同時調用其他組件接口對新業務進行監控，編寫配置生成邏輯實現業務配置自動化。只需要編寫非常輕量級的落地代碼，整個組件落地之後就可以服務運營。
3.運維自動化提高
在問題定位時，如果人工跟蹤一般是“是與否選擇”的串行計算，而在事件管理系統中，則進行並行計算，即：調用監控系統，判斷節點是否正常；調用第三方數據進行及時測試，判斷節點當前服務是否正常；調用客戶App數據驗證服務質量；使用ELK系統分析日誌，精準、快速的定位問題，分析時間由10分鐘大幅度縮減爲3分鐘。
白山雲科技
國內首家雲鏈服務提供商
微信ID：baishancloud