日志功能是任何一個系統或組件必不可或缺的組成部分，我們每次規劃建設一套系統或一個服務的時候，都少不了需要考慮日志的問題。容器云平臺也是一樣，不但要考慮容器云平臺自身的日志，還要考慮部署于平臺的業務應用、業務服務以及云上中間件的日志。再推廣一點，以微服務的思想來構建容器云平臺，日志作為獨立的組件微服務，不僅容器云平臺可以訪問使用日志中心服務，其他平臺、其他組件同樣也可以訪問日志中心服務。這樣日志中心服務就可以成為基礎的組件服務，服務于整個公司的系統、應用、服務等，而不僅僅是服務于某個特定的系統、應用、服務。真正做到一次建設，永久使用。

基于上面的考慮，我們提出容器云平臺日志中心需求。

一、日志中心需求概述

1.組件服務化需求

我們以前也討論過以微服務思想構建容器云平臺，很重要的一點就是實現服務共享，一次建設，多次使用。日志功能是最基礎的功能需求之一，為避免重復建設，重復投資，造成浪費，把公用的日志能力單獨提取出來作為一個微服務組件，以實現服務共享、降低成本、節省時間，最大化收益的目的。

2.日志數據集中分析處理需求

技術的發展使日志數據也越來越顯示出其價值。以前在無法處理分析大量日志的情況下，很多日志數據散落于各處，也由于豎井式的應用系統架構方式，日志數據歸集繁瑣，關聯困難，日志數據很難保存，大多都過一段時間就會被刪除。隨著大數據分析技術的成熟，使我們能從大量的日志信息中挖掘獲取到高價值信息、趨勢，提供預測、決策支持。目前已經沒有了技術限制，因此日志數據的歸集也更便于數據的統計、查詢、分析、存儲等，更好的挖掘數據的價值。

在去中心化大行其道的今天，我們為什么強調集中化和中心化？其實并不矛盾。去中心化并不是沒有中心，更多的是去單中心化，實現多中心化。在設計時需要自成一體，同時又是某一個中心的一員。宇宙——銀河系——太陽系——地球——生物——細胞——原子……，免備案空間 香港服務器，他們都依附于一個中心，都是一個中心，同時并行的中心又有很多個。這樣是一個生態系統。我們在做軟件設計、軟件架構的時候，同樣可以參考這樣的思想，避免只見樹木不見森林。

3.簡化開發，專注于業務實現

簡化業務系統、業務應用、業務服務研發，直接調用日志服務，不再關注日志格式、存儲、運維等問題，專注于業務邏輯研發。

4.日志格式標準化，采集規范化，存儲統一化

不同的系統不同的應用格式不統一，首先把日志作為組件服務提出出來，在設計實施時只需要按照日志中心的標準格式來打印輸出日志，也實現了日志采集的規范化，日志數據存儲的統一化，這樣對于日志的統計、分析等也易于處理。

5.可擴展性需求

要實現服務共享，可能就無法確切的預測到底需要多少資源，這就需要考慮可擴展性。隨著業務的需要自動或手動擴展。容器云平臺的擴展，更多是考慮橫向的擴展，比如增加節點數，增加實例數，以支持更高的負載請求壓力。最理想的方案是擴展無限制，但目前不太現實，所以單個節點或者單個實例的能力還是要滿足相應的要求。容器技術理論很好，但落地時也會面臨著這樣那樣的技術細節問題。所以不能盲目樂觀，可擴展性是一個容器云平臺需要認真面對的問題。

6.松耦合需求

松耦合需求也是一項很重要的內容。組件或服務易擴展，組件或服務之間耦合性不能太強。組件與組件之間，組件內部等都需要考慮松耦合的架構。組件服務彼此獨立又相互關聯，就象人與人之間的社會關系。不管容器云平臺還是日志中心內部的架構，都應該是一種松耦合的架構。組件可以獨立存在，也可以被替換。

7.開放性，標準化需求

在遵循相應的開放性標準或規范的情況下，松耦合的組件很容器被替換。如果是私有標準，就可能會增加很多工作量。所以在做設計的時候需要考慮開放性的需求。

8.實時準實時處理需求

日志的采集和處理到查詢展示通常情況下是有一個可以忍受的延遲時間。比如，1秒或2秒，如果超過5秒，體驗明顯就會不好。所以日志中心設計也需要考慮日志的實時或準實時處理。可能不同的日志需要考慮分級，所采用的技術和方法會有不同。比如交易類就可能需要實時的日志記錄、采集、展示。管理類可以接受準實時的日志延遲。

9.支持不同的日志格式、日志類型需求