微服務與宏觀問題現代的科技公司強調微服務架構，容器，也隨著越來越重要。在需要為多種平臺和應用提供服務的世界裡，微服務是必不可少的。容器，比如Docker，相比於它的近親，虛擬機器， 擁有更高的資源利用率，更好的隔離性和更棒的可移植性，這使其成為了微服務的理想選擇。但是微服務和容器也有他自己的問題，相比於它已經過時的前代單體架構對現代微服務架構來進行思考。單體架構也許不具備可擴充套件性和靈活性，但它有統一性的優勢。要理解為什麼統一性非常重要，想象你也許需要根據你的業務需求，收集和聚合不同型別的日誌資料。你也許想知道站點的哪個頁面是訪問最頻繁的，哪個按鈕或者廣告是使用者頻繁點選的。你也許想把這些資料與從手機應用渠道來的銷售資料，或者遊戲資料做比對，如果你是一個遊戲製作者的話。你也許想收集使用者手機的操作日誌，或者感測器的資料。如果你的內部團隊正在做漏洞分析或者事件影響分析，你也許需要對比這些計算結果和歷史資料。物聯網資料，SaaS 服務資料，公共資料等等各種各樣的資料型別。理論上，由單體架構產生的資料很容易追蹤。按定義說，系統是中心化的，它生成的日誌都可以使用相同的模式格式化。微服務，就我們所知道，不是這樣的。不同服務的日誌有自己的模式，或者根本就沒有模式可言！因此，簡單地從不同的服務收集日誌，再將它們轉成可讀的格式，是一個難以解決的資料基礎架構問題。在容器化的世界裡，我們必須從不同的角度想日誌記錄。這是接下來我們要聊容器之前的所有問題。容器化，如我們所說，對以微服務為基礎的服務是非常有用的，因為它很高效。容器使用的資源比虛擬機器少得多 – 遠比實體伺服器少。它們可以非常接近客戶，提高執行速度。並且由於它們相互隔離，依賴的問題會可以減少（如果不能完全消除）。但這些使容器有利於微服務的優勢，也導致了更多日誌和資料聚合問題。傳統上，日誌用它們的來源伺服器的 IP 地址標記。這不適用於容器，容器阻隔了固定的伺服器和角色之間的對映。另一個問題是日誌檔案的儲存。容器是不可變的，用後即可丟棄的，所以存在容器裡的日誌會隨著容器例項結束而消失。你可以把它們儲存在主機伺服器上，但是你可能在同一個主機伺服器上執行多個容器和服務。如果伺服器的儲存空間不足時又會發生什麼呢？我們如何獲取這些日誌呢？用服務發現軟體，比如 Consul？太棒了，有需要安裝一個元件（翻白眼）。或者也許我們應該用 rsync，或 ssh 和 tail。現在我們需要把這些喜歡的工具安裝在我們的所有容器裡。突破日誌困境：智慧的資料基礎架構沒有辦法繞過上面的問題。在一個容器化微服務的世界中，我們必須以不同的方式思考如何記錄日誌。日誌應該是：在來源處標記和解析，並儘可能快地推送到目的地讓我們來看看這是如何工作的。如我們前面說的，來自不同來源的日誌可能是結構化或者非結構化的格式。處理原始日誌簡直是資料分析的噩夢。收集器節點透過將原始日誌轉換為結構化資料（例如，JSON中的鍵值對，訊息包或者其他標準格式）來解決這個問題。在容器裡執行的收集器節點代理，將結構化的資料實時的（或者微批次的）轉發到聚合器節點。聚合器節點的工作是將多個小的日誌流組合成一個數據流，更容易處理和收集到 Store 節點，在那裡他們將被持久化以備日後使用。我剛剛介紹的就是一種資料基礎架構。並不是每個人都接受他們的資料需要基礎架構的想法，但是在容器化微服務的世界裡，沒有其他辦法。為了使我們的資料基礎架構具有可擴充套件性和可恢復性，有一些問題需要提前考慮。1、網路流量：資料在所有的這些節點之間來回轉發，我們需要一個“流量警察”，以確保網路不會過載或丟失資料。2、CPU 負載：在來源端解析資料和在聚合器上對其格式化是非常消耗計算資源的。同樣，我們也需要一個系統來管理這些資源，防止我們的 CPU 超載。3、冗餘：彈性需要冗餘。我們需要使聚合器冗餘，以防止單點故障時造成資料丟失。4、控制延遲：沒有辦法避免系統中的延遲。我們不能完全擺脫延遲，但我們需要控制它，這樣我們才知道什麼時候，系統中發生了什麼。現在我們看完了這些需求，讓我們接著看看服務架構中一些不同的聚合模式。
來源端聚合模式
1、固定的聚合器（服務端）地址。如果想更改聚合器的地址，你不得不重新配置每一個收集器。2、過多的網路連線。記得我們說的，小心不要超載我們的網路嗎？網路超載就是這樣發生的。在來源端聚合資料遠比直接在目標端聚合資料，網路效率高得多 — 需要支撐的 socket 連線和資料流更少。3、聚合器高負載。來源端聚合不僅導致網路流量高，也會使聚合器的 CPU 過載，導致資料丟失。現在讓我們看下在來源端聚合資料的利弊。
1、更少的網路連線數。更少的網路連線也意味著更少的網路流量。2、較低的聚合負載。因為資源的消耗分攤在整個資料基礎架構上，因此某個聚合器過載的機率會大大減少，從而資料丟失機率更小。3、容器的配置更簡單。因為對於每個收集器，聚合器的地址都是 “localhost”（本地），設定可以大大簡化。目標端地址只需要在一個節點中（本地的聚合器容器）指定。4、高度靈活的配置。這種簡化配置使你的資料基礎架構高度模組化。你可以隨時為你的主要業務增刪伺服器。目標端聚合模式
目標端的修改會影響來源端。這和我們不在來源端設定聚合器的情況下遇到的配置問題類似。如果目標端地址更新了，所有的來源端的聚合器都要被重新配置。更差的效能。在不在目標端設定聚合器會導致很多併發連線和寫請求傳送到我們的儲存系統。視你選擇的儲存系統而定，這幾乎總是會導致重大的效能問題。實際上，這是系統最頻繁的大規模出現問題的部分，甚至可以讓最健壯的系統宕掉。來源端和目標端聚合
最佳的配置是同時在來源端和目標端設定聚合器，同樣，我們要權衡利弊，這樣會導致有更多的節點，比之前的配置稍複雜。但是好處是顯而易見的：- 目標端的改變不會影響來源端，總體維護成本更低。- 更好的效能。有了來源端的獨立的聚合器，我們可以調整聚合器，減少對 Store 的寫請求，這讓我們可以選擇效能和擴充套件問題更少的標準資料庫。
冗餘
在來源端聚合的另一個好處是容錯性。在現實世界中，伺服器是可能宕掉的。在處理由大量微服務連續不斷生成的日誌時，過重的負載更可能讓伺服器崩潰。當這種情況發生時，在宕機期間產生的事件會永久丟失，如果你的系統宕機時間過長，即使有來源端緩衝（如果你用的日誌平臺有來源端緩衝 — 超過一分鐘）也會溢位，導致永久性的資料丟失。
目標端聚合透過增加冗餘提高了容錯能力。透過在容器和資料庫之間多加一層，相同的資料副本會被髮送給多個聚合器，而不是用併發連線過載你的資料庫。
擴充套件模式
負載均衡是資料基礎架構另一個需要考慮的問題。有一千種方法來實現負載均衡，但是我們重點是要擴充套件模式之間做權衡，比如用一個 HTTP/TCP 負載均衡伺服器來處理巨大的佇列和大批的工作節點，或者水平擴充套件，負載透過迴圈方式均衡地分配到多個客戶端聚合器節點，透過簡單地增加聚合器來管理擴充套件。
哪種型別的負載均衡是最好的，同樣，取決於現實情況。使用哪種方式取決於你係統的規模和它是否採用目標端聚合。
至少在概念上垂直擴充套件比水平擴充套件簡單。因此，它很適合創業專案。但是垂直擴充套件有侷限性，有可能在最壞的時機出故障。難道當你的服務擴充套件到每天處理 50 億事件，然後突然開始在每次垃圾回收的崩潰，你不惱火嗎？
水平擴充套件更復雜，但可以提供（理論上講）無限的容量。你可以隨時新增更多的聚合器節點。
鎖與鑰匙：Docker + Fluentd
對微服務統一的日誌層的需求促使 Sadayuki Furuhashi，Treasure Data 首席機構師，開發並開源了 Fluentd 框架。Fluentd 是一個日誌採集系統，守護程序，類似 syslogd，它監聽來自服務的訊息，並以各種方式路由它們。但與 syslogd 不同，Fluentd 是為了統一微服務的日誌源從頭構建的，因此可以有效地用於生產環境和分析工具。相同的高效能程式碼可以在收集器或聚合器模式下使用，只要簡單的調整配置，使其非常容易在整個系統上進行部署。
因為 Docker Machine 原生支援 Fluentd，可以不必在每個容器中執行任何“代理”，就可以收集所有容器日誌。只需要使用 “-log-driver=fluentd” 選項啟動 Docker 容器，並確保主機或者指定的“日誌”容器執行 Fluentd。這種方法可以確保大部分容器執行“精簡”，因為不需要在來源容器中安裝日誌代理。
說到易於配置，很難有比只需要在你的應用裡配置幾行 Fluentd 日誌庫的程式碼，就可以在每個容器中啟用直接把日誌轉發到 Fluentd 例項更易用的了。因為這幾乎毫不費力，對於剛剛起步的創業公司來說是巨大利好，這類公司通常只有少數幾個服務，資料量也比較小，可以通過幾個併發連線存在標準的 MySQL 資料庫中。
但是冒著徒勞無收益的風險，這樣的系統可擴充套件的能力是有限的。如果你的創業公司一飛沖天呢？取決於你的業務多大程度上是資料驅動的，你也許想提前做些準備（或者考慮把問題託管給資料架構技術公司）來避免到時措手不及。
另一種可能的配置是在來源端使用 Fluentd 聚合，並用有400種多社群貢獻外掛之一，將聚合好的日誌傳送至一個 NoSQL 資料庫儲存。我們看看 Elasticsearch 這個例子，因為它非常流行。這種配置（用 Kibana 做資料視覺化），被稱作 EFK 技術棧，可以執行在 Kubernetes 上。這相當直觀，通常對於中等資料規模來說也很管用。
使用 Elasticsearch 需要注意：它是一個很棒的搜尋平臺，但不是資料基礎架構中心組建的最優選擇。當你需要負載大量的重要資料時，尤其如此。在生產級擴充套件方面，Elasticserach 已經被證明有關鍵的採集問題，包括腦裂問題，會導致資料丟失。在 EFK 配置裡，由於 Fluentd 是在來源端聚合而不是目標端，如果儲存部件丟失資料，則無法繼續進行任何公眾。
對於生產級擴充套件分析，你可以考慮一個更容錯的平臺，比如 Hadoop 或者 Cassandra ，這兩個平臺都針對大量寫操作負載進行了最佳化。
如果你需要處理大量的複雜資料，最好的辦法是同時在來源端和目標端設定聚合節點，利用 Fluentd 的多種設定模式。使用 Docker 附帶的 Fluentd 日誌驅動程式，你的應用程式可以將其日誌寫到 STDOUT 輸出流。Docker 會自動把它們轉發到本地的 Fluentd 例項上，然後按順序聚合並透過 TCP 連線把它們再轉發到目標端的 Fluentd 聚合器上。
這就是 Fluentd 強大的功能和靈活性的體現。在這種構架中，Fluentd 預設啟用具有自動故障轉移功能的迴圈負載平衡。這很適合水平擴充套件的架構，因為每個新節點都根據下游例項的流量複雜平衡。另外，內建的緩衝儲存外掛能使其在傳輸過程中的每個階段提自動防止資料丟失。它甚至包括自動的損壞檢測（啟動上傳重試，直到完成全部資料傳送）以及資料去重 API。
哪種配置更適合你？
然而，隨著各種規模的組織變得越來越資料驅動，花時間思考你的長期目標是值得的。你是否需要確保當每天開始處理數十億次事件時，資料管道不會阻塞？你是否希望未來無論新增的任何資料來源時，系統具有最大的可擴充套件性？那樣你應該考慮同時在來源端和目標端做聚合。未來資料量爆發時，你（和同事）將感謝你的深謀遠慮。
如果你需要最大未來可擴充套件性，但現在沒有足夠的資源來實現，或者想要未來最大限度地減少維護用時，你可以考慮 Treasure Data 的 Fluentd 企業支援版。企業版提供 24*7 的安全，監控和維護服務以及框架研發團隊的支援。
如果您想要即插即用資料技術棧來外包整個分析系統的管理，請考慮 Treasure Data 全面管理的收集，儲存和處理系統。