摘要：二樂高式松耦合架構(gòu)落地快速實現(xiàn)需求與需求實現(xiàn)越來越慢的矛盾如何解決最終白山的產(chǎn)品架構(gòu)聚焦在解耦上，方便平臺快速迭代，減少系統(tǒng)間依賴程度，打通無關(guān)聯(lián)項目，為運營互動提供高效支持，確保服務(wù)質(zhì)量。

作者：王康

白山聯(lián)合創(chuàng)始人兼產(chǎn)品副總裁。
王康先生主要負(fù)責(zé)產(chǎn)品的完善與升級、產(chǎn)品開發(fā)流程把控及進(jìn)度協(xié)調(diào)、產(chǎn)品設(shè)計改進(jìn)及定期優(yōu)化、產(chǎn)品全生命周期管理等工作。他帶領(lǐng)團(tuán)隊實現(xiàn)白山首款產(chǎn)品CDN-X的多項創(chuàng)新，降低CDN使用門檻，極大拓展了CDN客戶資源，提升了白山品牌價值，促進(jìn)整體CDN市場的擴(kuò)大與發(fā)展。
王康先生曾就職于網(wǎng)宿科技，任該公司產(chǎn)品及售前高級總監(jiān)，負(fù)責(zé)技術(shù)團(tuán)隊的運營工作；擁有10年CDN行業(yè)經(jīng)驗，專注于提高產(chǎn)品輸出的高質(zhì)量和高可靠性。
王康先生擁有三項發(fā)明專利。

現(xiàn)在很多公司都在做松耦合，因為隨著業(yè)務(wù)發(fā)展、需求增加，緊耦合系統(tǒng)的問題會慢慢凸顯，并日益加劇。
以云分發(fā)行業(yè)為例，其屬性在逐漸發(fā)生變化。過去，極少人產(chǎn)生內(nèi)容，絕大多數(shù)人消費內(nèi)容，云分發(fā)主要以下行流量為主，而隨著全民直播的興起，云分發(fā)變成了云交互；物聯(lián)網(wǎng)的發(fā)展使物與物的數(shù)據(jù)交流成為主要方式，例如智能家居每天會產(chǎn)生上千條數(shù)據(jù)，但其中只有幾條會被消費；VR爆發(fā)，用戶產(chǎn)生的數(shù)據(jù)逐漸會從圖片、視頻轉(zhuǎn)變?yōu)閂R內(nèi)容；基于此我們可以預(yù)料到上行流量將逐步增加，并逐漸超過下行流量，成為基礎(chǔ)網(wǎng)絡(luò)架構(gòu)的巨大挑戰(zhàn)。
用戶需求與網(wǎng)絡(luò)基礎(chǔ)環(huán)境的快速變化，使得我們需要越來越快的實現(xiàn)需求，然而緊耦合系統(tǒng)卻為研發(fā)帶來諸多困難，使功能實現(xiàn)越來越耗費精力與時間，所以在白山創(chuàng)立之初就決定做“樂高式松耦合”架構(gòu)，來構(gòu)建整個產(chǎn)品體系，像搭積木一般靈活自如。

一、 傳統(tǒng)難點
（1）需求堆積，收斂周期長
很多創(chuàng)業(yè)公司在成立之初采用野蠻生長的模式，原則是越快越好。緊耦合架構(gòu)可以很好的滿足這些要求，他們可以快速的建立CMDB與資源管理平臺，并配置自動化、portal、監(jiān)控等功能。但隨著功能增多與需求開發(fā)的增加，這個系統(tǒng)逐漸變?yōu)橐槐P散沙。當(dāng)有新需求發(fā)生時，他們需要為其做很多硬編碼動作，收斂周期越來越長。
（2）“老中醫(yī)”資源的浪費
在緊耦合系統(tǒng)中，看似一個沒有什么關(guān)系的小改動，極有可能會引起一個重大bug；為防止錯誤發(fā)生，只能將系統(tǒng)設(shè)計的越來越復(fù)雜。例如為防止客戶端掛掉，研發(fā)通常會為其添加一個守護(hù)進(jìn)程；當(dāng)守護(hù)進(jìn)程不穩(wěn)定時，新入職的研發(fā)常用的解決方案是再添加一個守護(hù)進(jìn)程，這就導(dǎo)致了系統(tǒng)越來越臃腫。
這時候，公司往往就需要經(jīng)驗豐富、了解系統(tǒng)整體情況的“老中醫(yī)”才能對平臺進(jìn)行改造。而作為核心資產(chǎn)的“老中醫(yī)”在忙于救火、進(jìn)行技術(shù)攻堅，很難抽出時間來進(jìn)行系統(tǒng)重構(gòu)。

二、 “樂高式松耦合”架構(gòu)落地
快速實現(xiàn)需求與需求實現(xiàn)越來越慢的矛盾如何解決？最終白山的產(chǎn)品架構(gòu)聚焦在解耦上，方便平臺快速迭代，減少系統(tǒng)間依賴程度，打通無關(guān)聯(lián)項目，為運營互動提供高效支持，確保服務(wù)質(zhì)量。
（1） 第一層松耦合架構(gòu)
以白山云分發(fā)CDN-X系統(tǒng)為例，其根本核心是運營。為使運營支撐系統(tǒng)通過解耦讓公司的研發(fā)、運營靈活運轉(zhuǎn)，需要進(jìn)行第一層抽象。將運營支撐系統(tǒng)抽象為5個組件，包括：客戶管理類、賬單信息類、資源管理、運營監(jiān)控和配置管理。并對這5個組件進(jìn)行畫像，確定邊界、輸入輸出，按照運營場景描述用戶場景。
幾個組件之間通過消息總線交互指令，通過標(biāo)準(zhǔn)的reset接口交互數(shù)據(jù)；同時將5個組件投入到實際開發(fā)中，按照不同類型做實例化。

（第一層松耦合架構(gòu)）

（2）第二層松耦合架構(gòu)
做完第一層解耦之后，我們發(fā)現(xiàn)第二層還可以繼續(xù)做抽象。以配置管理系統(tǒng)為例，又可抽象出4部分。

生成配置：主要負(fù)責(zé)配置的生成以及配置到git倉庫；

分發(fā)控制：管理灰度發(fā)布過程；

執(zhí)行分發(fā)：分發(fā)收到的指令，并通過一些工具（如：salt、ansible、http get）匯報給上面的組件；

執(zhí)行測試：調(diào)用已經(jīng)寫好的測試用例倉庫測試這一次配置分發(fā)過程的最后效果。

（第二層松耦合架構(gòu)）

運營支撐系統(tǒng)中的各個組件都可以一直抽象下去，抽象概念貫穿整個設(shè)計平臺的始末。
核心組件設(shè)計時再經(jīng)過進(jìn)一步抽象成工廠模式或單例模式，形成針對不同特性服務(wù)及場景，只需編寫極小的落地代碼即可獲得整個運營支撐服務(wù)的可插拔架構(gòu)。

（3）建設(shè)原則

組件即服務(wù)
研發(fā)中人人都是架構(gòu)師，收到研發(fā)需求后不是研究輸入輸出與邊界，而是了解業(yè)務(wù)。根據(jù)情況輸出需求文檔，并與業(yè)務(wù)方進(jìn)行確認(rèn)，按照需求設(shè)計架構(gòu)。每一個組件，不再是功能，而是服務(wù)，有自己的服務(wù)對象；研發(fā)人員從最初的對代碼質(zhì)量、輸入輸出負(fù)責(zé)，發(fā)展為對服務(wù)質(zhì)量負(fù)責(zé)。

事件組件化
在最初設(shè)計過程中，我們發(fā)現(xiàn)，很多運營中的動作稱不上是平臺上的動作，而是由事件組成。如果這些事件通過自動化來完成，就需要投入大量的精力。以節(jié)點上架自動化為例：包括自動化掃描端口、監(jiān)控、安裝、配置下發(fā)管理，甚至可以將自動化加入當(dāng)前系統(tǒng)平臺為用戶提供服務(wù)。組件自動后，如果包裝成事件，將浪費不必要的人力成本。如果將事件組件化，運維管理人員則可以在平臺上方便的拖拽、引用、規(guī)范組件，通過拖拽、配置工作實現(xiàn)整體自動化。

數(shù)據(jù)聚合管理系統(tǒng)
數(shù)據(jù)往往是運營中的判斷標(biāo)志，通過數(shù)據(jù)與數(shù)據(jù)間的關(guān)系來組建成組件。由于數(shù)據(jù)源之間的API不同，會導(dǎo)致花費過長的時間來對接API。我們將機(jī)房質(zhì)量、監(jiān)控負(fù)載、慢速比、卡頓率等數(shù)據(jù)進(jìn)行整理，部分進(jìn)行二次轉(zhuǎn)化，通過統(tǒng)一的接口調(diào)用，做成一個數(shù)據(jù)聚合管理系統(tǒng)。

實例分享－節(jié)點自動上線

（運維完成過程）

這個過程中運維人員完成了很多組件，如：配置管理、內(nèi)部測試以及外部測試、入覆蓋地區(qū)等；隨后引入多種數(shù)據(jù)源進(jìn)行追蹤。事件模版完成后只需運維人員選擇需上架的節(jié)點及其覆蓋方案與地區(qū)，其余過程均有系統(tǒng)自動化完成。
此模版還可以根據(jù)需要不斷修改，例如：丟包率組件等可以隨時加入，不會影響業(yè)務(wù)的進(jìn)行。
很多公司也在做同樣的事件管理系統(tǒng)，不同的是其管理的是動作；而我們發(fā)現(xiàn)往往動作完成后還需要進(jìn)行人工跟蹤。鑒于此我們將事件做成一個完整的生命周期，同時引入數(shù)據(jù)源來跟蹤異常服務(wù)狀態(tài)碼。
這個事件的完成過程中運維人員所需的操作已經(jīng)從寫腳本、人肉分析，簡化為在模版上拖拽、引用組件，根據(jù)經(jīng)驗設(shè)置閥值，甚至使用其他的事件模版來完成事件。

三、 松耦合需要堅持的細(xì)節(jié)
（1）保持簡單
隨著時間的推移與功能的不斷增加，系統(tǒng)必然會出現(xiàn)復(fù)雜性，而這種復(fù)雜性很多是由我們自身操作導(dǎo)致的，如上文提到的“守護(hù)進(jìn)程”的例子，當(dāng)使用復(fù)雜方案解決問題時往往會導(dǎo)致系統(tǒng)的臃腫。如果保證系統(tǒng)具備容錯能力，組件運營不正常時系統(tǒng)可以自動修復(fù)，這個問題就會簡化。
以消息管理機(jī)制為例，強(qiáng)消息管理機(jī)制要求確認(rèn)消息確實可以被每臺設(shè)備收到并執(zhí)行。我們對此進(jìn)行了改善，使消息病毒式傳播，每臺設(shè)備可以向周圍5-6臺設(shè)備發(fā)出消息，即便中間有一次失敗，還會有其他設(shè)備再次向這臺設(shè)備傳輸。這樣的容錯能力保證了系統(tǒng)可以簡單地自動實現(xiàn)強(qiáng)研發(fā)、強(qiáng)跟蹤等功能。
（2）在平臺的基礎(chǔ)上構(gòu)建應(yīng)用程序
例如在大數(shù)據(jù)平臺上構(gòu)建應(yīng)用，研發(fā)人員在開發(fā)組件時無需考慮數(shù)據(jù)庫的設(shè)計以及瓶頸優(yōu)化問題，只需要對接數(shù)據(jù)聚合平臺，大幅提高研發(fā)效率。
（3）不斷迭代
以Facebook為例，目前每秒可以處理12億張圖片；而其第一版系統(tǒng)只能允許用戶上傳圖片，并將其保存在數(shù)據(jù)庫中，該系統(tǒng)只存續(xù)3個月；隨著活躍用戶的增加， 其后端壓力不斷增加，于是將存儲改為二進(jìn)制存儲方式；Facebook的每一次迭代都不是為了某一特定目標(biāo)，而是為了解決業(yè)務(wù)上的痛苦。
所以最開始做開發(fā)時，我們只需要考慮需求與業(yè)務(wù)，設(shè)計足夠簡單的方案，再進(jìn)行不斷迭代以滿足新增需求。

四、 帶來的變化
（1） 快捷引入新特性
我們使用P2P消息管理機(jī)制結(jié)合收斂算法，將文件刪除由5分鐘改進(jìn)至0.7秒，我們對系統(tǒng)沒有進(jìn)行大范圍改變，只是替換了其中的消息機(jī)制，利用當(dāng)前基礎(chǔ)的通訊機(jī)制和基礎(chǔ)數(shù)據(jù)，過去所做的優(yōu)化與UI仍可以繼續(xù)使用。引用這些新特性時保持輕量級，對其他組件幾乎沒有影響。
（2） 開發(fā)效率高
例如游戲交互過程中的數(shù)字包交互，業(yè)內(nèi)公認(rèn)很難做到。目前我們正在進(jìn)行嘗試，我們引入開源的TCP代理軟件，并規(guī)劃新的應(yīng)用服務(wù)類型，軟件按指定好的打包方式放在指定位置，就可以實現(xiàn)軟件的自動發(fā)布，同時調(diào)用其他組件接口對新業(yè)務(wù)進(jìn)行監(jiān)控，編寫配置生成邏輯實現(xiàn)業(yè)務(wù)配置自動化。只需要編寫非常輕量級的落地代碼，整個組件落地之后就可以服務(wù)運營。
（3）運維自動化提高
在問題定位時，如果人工跟蹤一般是“是與否選擇”的串行計算，而在事件管理系統(tǒng)中，則進(jìn)行并行計算，即：調(diào)用監(jiān)控系統(tǒng)，判斷節(jié)點是否正常；調(diào)用第三方數(shù)據(jù)進(jìn)行及時測試，判斷節(jié)點當(dāng)前服務(wù)是否正常；調(diào)用客戶App數(shù)據(jù)驗證服務(wù)質(zhì)量；使用ELK系統(tǒng)分析日志，精準(zhǔn)、快速的定位問題，分析時間由10分鐘大幅度縮減為3分鐘。