假設(shè)有這樣一個需求，需要你寫一個爬蟲，爬取微博中關(guān)于某個話題的討論，然后分析情感，最后用一個網(wǎng)頁來展示分析結(jié)果。那么你一開始的數(shù)據(jù)流程可能是這樣的：

后來，老板發(fā)現(xiàn)只有微博一個源不夠，于是又給你加了100000個源?，F(xiàn)在你的系統(tǒng)是這樣的：

為了防止太多的線做交叉，我做了一些處理。

一開始你調(diào)用 NLP 分析接口的時候，傳入的參數(shù)只有爬取內(nèi)容的正文，但有一天，NLP 研究員希望做一個情感衰減分析。于是你要修改每一個爬蟲，讓每一個爬蟲在調(diào)用 NLP 分析接口的時候，都帶上時間參數(shù)。這花了你幾天的時間。

你一想，這不行啊，豈不是每次增加修改字段，都要改每一個爬蟲?為了避免動到爬蟲，于是你對系統(tǒng)架構(gòu)做了一些修改：

現(xiàn)在，爬蟲這邊總是會把它能爬到的全部數(shù)據(jù)都寫進 Kafka 里面。你的 ETL 程序只挑選需要的字段傳給 NLP 接口進行分析，分析完成以后，寫入數(shù)據(jù)庫中。程序的處理線條變得清晰了。

你以為這樣就完了?還早呢。

有一天，你發(fā)現(xiàn)網(wǎng)頁上的數(shù)據(jù)很久沒有更新了。說明數(shù)據(jù)在某個地方停了?，F(xiàn)在，你首先去 Kafka 檢查爬蟲的數(shù)據(jù)，發(fā)現(xiàn)爬蟲數(shù)據(jù)是正常入庫的。那么，說明問題出現(xiàn)在下圖這一塊：

那么，請問是 ETL 在處理數(shù)據(jù)的時候出現(xiàn)問題導(dǎo)致數(shù)據(jù)丟失了，還是 NLP 接口出了問題，導(dǎo)致你傳給他的數(shù)據(jù)沒有返回?還是數(shù)據(jù)庫不堪重負(fù)，寫入數(shù)據(jù)庫的時候出錯了?

你現(xiàn)在根本不知道哪里出了問題。于是互相甩鍋。

為了避免這個問題，你再一次修改了系統(tǒng)架構(gòu)：

現(xiàn)在通過檢查 Kafka 的數(shù)據(jù)，我可以知道 ETL 程序是否正常輸出內(nèi)容。也可以知道 NLP 分析程序是否正常返回數(shù)據(jù)。我還可以對比兩邊的數(shù)據(jù)變化率進行監(jiān)控。甚至還可以通過監(jiān)控 Kafka，發(fā)現(xiàn)負(fù)面內(nèi)容太多時，及時報警。

當(dāng)然，這還沒有完，如果還需要發(fā)現(xiàn)新的鏈接，并自動抓取，那么又需要增加新的節(jié)點。又或者有一些內(nèi)容需要用瀏覽器渲染，又要增加新的節(jié)點……

大家可以看到，數(shù)據(jù)會反復(fù)進出 Kafka，那么它的效率顯然會比直接用爬蟲串聯(lián)萬物的寫法慢。但我認(rèn)為這樣的效率損失是值得的。因為通過把系統(tǒng)拆解成不同的小塊，我們可以對系統(tǒng)運行的每一個階段進行監(jiān)控，從而能夠更好地了解系統(tǒng)的運行狀態(tài)。并且，每一個小塊也能夠更方便地進行維護，無論是修 bug 還是增加新功能，都能減小對其他部分的影響，并且可以提高修復(fù)的速度。