歡迎回到我們的系列断医。在第一部分中，我們談到了微服務(wù)和容器的最近興起廷雅。我們介紹了這種類(lèi)型的體系結(jié)構(gòu)引起的日志記錄問(wèn)題以及可能的解決方案 - 聚合。既然之前我們已經(jīng)介紹了這些京髓，現(xiàn)在讓我們來(lái)看看服務(wù)架構(gòu)中的一些不同的聚合模式航缀。

源端聚合模式

第一個(gè)問(wèn)題是，我們是否應(yīng)該匯總 數(shù)據(jù)的 來(lái)源 - 在服務(wù)方面堰怨。答案顯然是不唯一的芥玉。

沒(méi)有 源聚合的聚合服務(wù)框架的最大好處 是簡(jiǎn)單。但是备图，簡(jiǎn)單的代價(jià)是：

• 修正了聚合器（端點(diǎn)）地址灿巧。 如果您更改聚合器的地址赶袄，則必須重新配置每個(gè)收集器。
• 許多網(wǎng)絡(luò)連接抠藕。 還記得我們說(shuō)我們需要小心不要超載我們的網(wǎng)絡(luò)饿肺？這就是網(wǎng)絡(luò)過(guò)載發(fā)生的原因。在源端聚合我們的數(shù)據(jù)要比在目的端聚合更有效的網(wǎng)絡(luò)效率 - 導(dǎo)致網(wǎng)絡(luò)支持的套接字和數(shù)據(jù)流更少盾似。
• 聚合器中的高負(fù)載敬辣。 源端聚合不僅會(huì)導(dǎo)致網(wǎng)絡(luò)流量過(guò)大，而且會(huì)導(dǎo)致聚合器中的CPU過(guò)載零院，造成數(shù)據(jù)丟失溉跃。

現(xiàn)在我們來(lái)看看源端聚合的另一面。

在源頭上聚合有一個(gè)缺點(diǎn)：這是一個(gè)更多的資源密集型告抄。它需要每個(gè)主機(jī)上有一個(gè)額外的容器撰茎。但是這個(gè)額外的資源帶來(lái)了幾個(gè)好處

• 更少的連接。 較少的連接意味著較少的網(wǎng)絡(luò)流量打洼。
• 較低的聚合器負(fù)載乾吻。 由于此資源成本分散在整個(gè)數(shù)據(jù)基礎(chǔ)架構(gòu)中，因此您將不會(huì)有任何單個(gè)聚合器超載的機(jī)會(huì)拟蜻，從而減少數(shù)據(jù)丟失的機(jī)會(huì)绎签。
• 容器中的配置較少。 由于每個(gè)收集器的聚合器地址是“本地主機(jī)”酝锅，所以配置被大大簡(jiǎn)化诡必。目標(biāo)地址只需要在一個(gè)節(jié)點(diǎn)（本地聚合容器）中指定。
• 高度靈活的配置搔扁。 這種簡(jiǎn)化的配置使您的數(shù)據(jù)基礎(chǔ)架構(gòu)高度“模塊化”爸舒。您可以將服務(wù)交換到您的內(nèi)心。

目標(biāo)端聚合模式

無(wú)論我們是否在源端聚合稿蹲，我們也可以選擇在目的端分別有聚合器扭勉。我們是否應(yīng)該這樣做，又是一個(gè)折中的問(wèn)題苛聘。避免目標(biāo)聚合限制節(jié)點(diǎn)的數(shù)量涂炎，從而導(dǎo)致更簡(jiǎn)單的配置。

僅來(lái)源聚合

但是设哗，就像在資源方面一樣唱捣，避免在目標(biāo)方面的聚合帶來(lái)了成本：

• 目標(biāo)端的更改會(huì)影響源端。 這是我們?cè)谠炊藳](méi)有聚合器時(shí)所看到的配置問(wèn)題网梢。如果目標(biāo)地址更改震缭，則必須重新配置源上的所有聚合器。
• 更糟的表現(xiàn)战虏。 目標(biāo)端沒(méi)有聚合器會(huì)導(dǎo)致許多并發(fā)連接和寫(xiě)入請(qǐng)求到我們的存儲(chǔ)系統(tǒng)拣宰。取決于您使用哪一個(gè)党涕，幾乎總是會(huì)對(duì)性能產(chǎn)生重大影響。事實(shí)上巡社，這是系統(tǒng)中最經(jīng)常發(fā)生的部分遣鼓，即使是最強(qiáng)健的基礎(chǔ)設(shè)施也是如此。

源和目標(biāo)聚合

最佳配置是在源和 目標(biāo)端都進(jìn)行聚合 重贺。** 再一次地骑祟，折中的是，我們最終得到更多的節(jié)點(diǎn)和稍微更復(fù)雜的配置气笙。但好處很明顯：

• 目標(biāo)端更改不會(huì)影響源端次企。 這導(dǎo)致整體維護(hù)少得多。
• 更好的性能潜圃。 通過(guò)在Source方面使用單獨(dú)的聚合器缸棵，我們可以對(duì)聚合器進(jìn)行微調(diào)，并且在Store上的寫(xiě)請(qǐng)求更少谭期，從而使我們能夠使用標(biāo)準(zhǔn)數(shù)據(jù)庫(kù)堵第，而且性能和縮放問(wèn)題更少。

冗余

源端匯聚的另一個(gè)主要優(yōu)勢(shì)是 容錯(cuò)性隧出。 在現(xiàn)實(shí)世界中踏志，服務(wù)器有時(shí)候會(huì)停下來(lái)。處理在一個(gè)大型的微服務(wù)系統(tǒng)中產(chǎn)生的服務(wù)日志的不斷胀瞪，重負(fù)載使得服務(wù)器崩潰的可能性更大针余。當(dāng)發(fā)生這種情況時(shí)，停機(jī)期間發(fā)生的事件可能會(huì)永遠(yuǎn)丟失凄诞。如果系統(tǒng)停留時(shí)間足夠長(zhǎng)圆雁，甚至源端緩沖區(qū)（如果您正在使用帶有源端緩沖區(qū)的日志平臺(tái) - 一分鐘內(nèi)會(huì)更多）將會(huì)溢出并導(dǎo)致永久數(shù)據(jù)丟失。

目標(biāo)端聚合通過(guò)增加冗余來(lái)提高容錯(cuò)能力 帆谍。通過(guò)在容器和數(shù)據(jù)庫(kù)之間提供最后一層伪朽，可以將相同的數(shù)據(jù)副本發(fā)送到多個(gè)聚合器，而不會(huì)使用并發(fā)連接壓倒數(shù)據(jù)庫(kù)汛蝙。

縮放模式

負(fù)載平衡 是另一個(gè)重要的數(shù)據(jù)基礎(chǔ)架構(gòu)考慮 處理負(fù)載平衡有上千種方法烈涮，但是我們關(guān)心的重要因素是放大之間的權(quán)衡 ，即使用單個(gè)HTTP / TCP負(fù)載均衡器來(lái)處理比例大小的隊(duì)列和大量工作人員患雇，或者 向外擴(kuò)展跃脊，在負(fù)載平衡許多客戶(hù)端匯聚節(jié)點(diǎn)分布，以循環(huán)的方式苛吱，和規(guī)模管理通過(guò)簡(jiǎn)單地添加更多的聚合。

哪種類(lèi)型的負(fù)載均衡最好器瘪？再次翠储，這取決于绘雁。您使用的方法應(yīng)該取決于系統(tǒng)的大小，以及是否使用目標(biāo)端聚合援所。

至少在概念上庐舟，放大比放大略顯簡(jiǎn)單。正因?yàn)槿绱俗∈茫梢赃m合初創(chuàng)公司挪略。但是，在最壞的時(shí)候滔岳，企業(yè)傾向于粉碎的規(guī)模有限杠娱。當(dāng)你的服務(wù)每天增加到50億個(gè)事件，并且每次需要做垃圾收集時(shí)突然開(kāi)始崩潰谱煤，你不覺(jué)得討厭 嗎摊求？

擴(kuò)展比較復(fù)雜，但是（理論上）提供了無(wú)限的容量刘离。您始終可以 添加更多聚合節(jié)點(diǎn)室叉。

因此，我們介紹了微服務(wù)和容器可以創(chuàng)建的日志記錄問(wèn)題硫惕，以及聚合模式如何幫助解決這些問(wèn)題茧痕。留意系列的最后一集，我們將在這里詳細(xì)介紹Fluentd以及它在緩解這個(gè)過(guò)程中扮演的角色恼除。

翻譯人：Shedray大數(shù)據(jù)專(zhuān)欄凿渊，該成員來(lái)自云+社區(qū)翻譯社

原文鏈接：https://dzone.com/articles/distributed-logging-in-the-container-era-part-2-1

原文作者：Glenn Davis