摘要：由于容器是無法改變和一次性的，所以存儲在容器中的日志會隨著容器的失效而刪除。收集節(jié)點存在于容器中，同時將結(jié)構(gòu)化好的日志數(shù)據(jù)實時或者小批量的傳輸?shù)胶喜⒐?jié)點。

容器服務(wù)和微服務(wù)已經(jīng)越來越多的被現(xiàn)代科技公司所采用。當你需要提供支持跨平臺和多應(yīng)用的服務(wù)時，采用微服務(wù)的服務(wù)架構(gòu)是非常重要的。.像Docker一樣的容器服務(wù)，因為可以提供高效的統(tǒng)一資源管理和讓服務(wù)保持更好的獨立性，并且有比虛擬機（Virtual Machines）更好的便攜性（portability），所以更適合微服務(wù)的開發(fā)。

但是引入微服務(wù)和容器服務(wù)的同時也帶來了各種問題。下圖我們來看一下微服務(wù)架構(gòu)和現(xiàn)在并不怎么流行的前輩，“統(tǒng)一型架構(gòu)”（monolithic architecture）

。

統(tǒng)一型架構(gòu)雖然沒有足夠的靈活性和可擴展性，但是，它是一個整體（unity）。為了了解它的重要性，我們來從業(yè)務(wù)需求的角度了解一下我們需要收集（collect）和整合（aggeregate）多少種不同的日志。你可能想知道你的用戶最常訪問的網(wǎng)頁有哪些，或者哪個按鈕和廣告最容易被點擊。你也可能想對比從移動應(yīng)用端獲取的銷售數(shù)據(jù)，或者作為一個游戲開發(fā)者，你想了解用戶玩兒游戲時候的數(shù)據(jù)。你也可能需要收集用戶手機上的操作日志。假設(shè)你的團隊在做流式分析或者事件影響力分析，這時就需要對比計算結(jié)果和歷史數(shù)據(jù)。IoT數(shù)據(jù)，SaaS數(shù)據(jù)，公共開放數(shù)據(jù)……等等等等。

統(tǒng)一型架構(gòu)產(chǎn)生的數(shù)據(jù)，理論上來說，是很容易被跟蹤和收集的。由于系統(tǒng)在定義的時候就是中心化的，它所產(chǎn)生的日志可以通過定義相同的格式規(guī)則來定義。相反，微服務(wù)卻不是這樣。日志又不同的服務(wù)產(chǎn)生，它們都有著各自的格式，或者有些根本沒有格式！由于這些原因，收集并“消化”這些來自于不同服務(wù)的日志，并轉(zhuǎn)換成一個可讀的格式，是一個非常復雜并且難以解決的數(shù)據(jù)工程問題。

容器時代，我們必須重新考慮如何記日志

“如何記日志？“ ，這是我們開始討論容器服務(wù)必須先講的。 “容器化（Containerization）”，是一項可以使基于微服務(wù)架構(gòu)開發(fā)的服務(wù)更高效的利器。容器會使用比虛擬機（VM）更少的資源，更不用說實體機了。容器可以是使我們的服務(wù)更接近我們的客戶，提高操作速度。并且由于容器之間相互獨立，各服務(wù)之間的依賴問題也減少了（并沒有完全消除）。

但是，這些使容器服務(wù)更適合微服務(wù)架構(gòu)的有點卻在記日志和數(shù)據(jù)整合的過程中帶來了更多的麻煩。通常來說，日志都會有標記IP地址，來表明它來自于哪臺服務(wù)器。這種情況在容器服務(wù)中并不存在，容器服務(wù)切斷了服務(wù)器和用戶之間的固定映射關(guān)系。另外一個問題是日志的存儲問題。由于容器是無法改變（immutable）和一次性（disposable）的，所以存儲在容器中的日志會隨著容器的失效而刪除。你可以選擇把日志都存在主機端而不是在容器里，但是你可能會同時啟動多個容器和服務(wù)。如果服務(wù)器存儲空間滿了怎么辦？那么我們該如何獲取這些日志？用控制臺直接看？太棒了，又得安裝一個新組件（翻白眼）。或者我們通過rsync、ssh或者tail來查看日志。那么我們要確定我們這些常用的工具是在容器里都安裝過的……

這個問題是沒辦法繞開的。在容器化微服務(wù)的世界里，我們必須重新思考如何記日志。

日志必須要以下特征:

在源頭就完成標記（labeled）和解析（parsed）

以最快的速度推到目標存儲落地

讓我們來看看智能數(shù)據(jù)架構(gòu)是如何工作的。

像我們之前提到的，來自于不同地方的日志可能都有著不同的日志結(jié)構(gòu)和格式。對于數(shù)據(jù)分析來講，處理原始日志就是一場噩夢。收集節(jié)點（Collector Nodes）通過將原始日志轉(zhuǎn)換為結(jié)構(gòu)化數(shù)據(jù)來解決這個問題。例如：JSON中的KV數(shù)據(jù)，信息包（MessagePack）或者其他標準的數(shù)據(jù)格式。

收集節(jié)點存在于容器中，同時將結(jié)構(gòu)化好的日志數(shù)據(jù)實時（或者小批量）的傳輸?shù)?strong>合并節(jié)點（Aggregator Nodes）。合并節(jié)點的工作是將小量的數(shù)據(jù)合并成一個容易被處理的數(shù)據(jù)流到存儲層（Store），在存儲層的數(shù)據(jù)是被持久化存儲的。

如上所述的是一種數(shù)據(jù)架構(gòu)，不是所有人都清楚他們的數(shù)據(jù)也需要一個架構(gòu)，但是在容器微服務(wù)的角度，我們必須這樣做。

如果想要你的數(shù)據(jù)架構(gòu)有更好的彈性擴展能力（scalable and resilient），下面幾點是必須要考慮的：

網(wǎng)絡(luò)情況。當我們有這么大量的數(shù)據(jù)在網(wǎng)絡(luò)中進行交換的時候，我們需要一個虛擬的“網(wǎng)絡(luò)交警”來保證我們的網(wǎng)絡(luò)不會超載，不會丟失數(shù)據(jù)。

CPU負載。在源頭解析數(shù)據(jù)和在合并節(jié)點格式化數(shù)據(jù)是一項CPU密集型工作。再次強調(diào)，我們需要一個穩(wěn)定的系統(tǒng)來管理這些資源，來保證我們的CPU不會超載。

冗余性。彈性擴展意味著冗余儲備。我們需要保證我們的合并節(jié)點是冗余的（多余實際需求的），從而能保證我們遇到節(jié)點失敗時可以快速切換避免數(shù)據(jù)丟失。

控制延遲。我們沒辦法避免系統(tǒng)可能產(chǎn)生的延遲。如果我們沒法逃避這個問題，我們必須嘗試把潛在的延遲放在可控的范圍。

現(xiàn)在我們了解了我們應(yīng)該做什么了，那我們來看看不一樣合并方式對于服務(wù)架構(gòu)的影響。

首先我們要問的問題時，我們?nèi)绾螕?jù)定是在服務(wù)端做數(shù)據(jù)合并還是在數(shù)據(jù)源做數(shù)據(jù)合并？答案是，視情況而定（譯者注：廢話）。

服務(wù)端數(shù)據(jù)合并框架帶來的好處是簡潔，但同時也付出了很大的代價。

數(shù)據(jù)合并位置固定。如果你改變了你合并節(jié)點的位置，你必須重新調(diào)整所有的獨立收集節(jié)點的配置。

無法控制的網(wǎng)絡(luò)連接數(shù)量。還記得我們提到要謹慎控制網(wǎng)絡(luò)流量不要超載么？這種架構(gòu)就會導致網(wǎng)絡(luò)超載。我們在數(shù)據(jù)源側(cè)做合并是網(wǎng)絡(luò)效率更優(yōu)的選擇，因為減少了大量的網(wǎng)絡(luò)通訊和數(shù)據(jù)傳輸。

合并節(jié)點高負載。不僅僅網(wǎng)絡(luò)會超載，這種架構(gòu)也會導致合并節(jié)點CPU超負荷，導致宕機造成數(shù)據(jù)丟失。

現(xiàn)在我們來看看另一種方案。

源頭聚合的方式有一個缺陷：就是會導致資源緊張。它需要在每個主機上都存在一個額外的容器，但是這個額外的資源也有很多好處：

更少的鏈接數(shù)。意味著更少的網(wǎng)絡(luò)傳輸。

更低的合并節(jié)點負載。由于資源消耗被發(fā)散到了你的整個的數(shù)據(jù)架構(gòu)上，你遇到多帶帶合并節(jié)點超載的幾率大大減少，也會帶來更多的數(shù)據(jù)穩(wěn)定性。

更少的配置項。由于每個合并節(jié)點的地址對于每個采集節(jié)點來說都是“l(fā)ocalhost”，配置起來就變得非常簡單。目標地址只需要在本地合并容器聲明一次就夠了。

高度靈活配置項。簡化的配置項讓你的數(shù)據(jù)架構(gòu)高度“模塊化”。你可以隨意改變你架構(gòu)中的核心內(nèi)容。

我們來換種思路，不僅僅選擇在源頭側(cè)做數(shù)據(jù)合并，還可以選擇在目標側(cè)做同樣的事情。為什么要這么做呢？就是在實際業(yè)務(wù)中的一種權(quán)衡之舉。

就像在源頭端做合并一樣，會有以下幾點問題：

目標端做的改變會同時影響到源頭段。這里同樣會遇到我們之前的問題，當我們在源頭段沒有合并節(jié)點的時候，配置項就會變的非常復雜。如果目標端IP地址變化，所有的配置都需要重新生成。

更差的性能。在目標側(cè)沒有合并節(jié)點會導致我們的存儲系統(tǒng)有很多鏈接并發(fā)的問題。

最優(yōu)化的配置方式是同時在源頭側(cè)和目標側(cè)都存在合并節(jié)點。再次重申，我們的妥協(xié)會導致需要復雜的配置來控制多個節(jié)點，但是有點也是顯而易見的：

目標側(cè)和源頭側(cè)分離，沒有互相影響。

更好的性能。當把源頭側(cè)的合并節(jié)點分離，我們可以更好的調(diào)試合并節(jié)點并且減少對于存儲層的請求量，使我們在使用標準的數(shù)據(jù)庫的時候避免遇到性能和擴展的問題。

源頭側(cè)聚合帶來的最大一點的好處就是容錯性。在真實業(yè)務(wù)場景中，服務(wù)器會時不時的宕機。導致宕機的原因就是，大量持續(xù)的處理由微服務(wù)架構(gòu)構(gòu)成的大型系統(tǒng)的日志。當遇到這種情況的時候，在宕機時產(chǎn)生的數(shù)據(jù)會被永久的丟失。如果你的服務(wù)很久沒有恢復，即使你在源頭端留有緩存（大部分日志平臺都會在源頭側(cè)留有至少一分鐘的緩存），這些緩存也會溢出并造成永久的數(shù)據(jù)丟失。

目標側(cè)合并由于增加了冗余性從而提高了容錯性。因為在容器和數(shù)據(jù)庫之間增加了一層，多次拷貝的數(shù)據(jù)可以發(fā)送給多個合并節(jié)點，從而減少了并發(fā)鏈接導致數(shù)據(jù)庫過載的可能性。

負載均衡是數(shù)據(jù)架構(gòu)需要認真考慮的一個重要特性。處理負載均衡的方法有很多種，但是我們在這里需要關(guān)注的是如何判斷我們是該向上擴展（scaling up），比如，使用單一的HTTP/TCP的負載均衡器的時候，它通過控制大量的worker和一個超長隊列來做負載均衡。還是該橫向擴展（scaling out）當處理多個客戶端合并節(jié)點做負載均衡的時候，只能簡單的增加節(jié)點來控制規(guī)模。

那種負載平衡的方式更好？再次強調(diào)，要視情況而定。需要根據(jù)你的系統(tǒng)規(guī)模來確定該使用哪種方法。至少從概念上來說，向上擴展比橫向擴展要簡單的多。因為如此，很多創(chuàng)業(yè)公司都會這樣做。但是向上擴展的在業(yè)務(wù)量急劇上升的時期，會更加頻繁的在GC階段出問題?（your service scales to 5 billion events per day and suddenly starts crashing every time it has to do garbage collection?）。

橫向擴展更加復雜，但是理論上講提供了無限的存儲空間，你可以一直增加合并節(jié)點。