【51CTO.com快譯】微服務(wù)架構(gòu)是一種全新的應(yīng)用結(jié)構(gòu)，它能夠幫助您通過松耦合的系統(tǒng)，開發(fā)、測試、部署和發(fā)布彼此相互獨(dú)立的各種服務(wù)。因此微服務(wù)背后的理念是：將大型系統(tǒng)分解成多個(gè)獨(dú)立的小部分。

通常情況下，每個(gè)服務(wù)都能通過HTTP的端點(diǎn)與其他服務(wù)交互。它們在隱藏技術(shù)棧細(xì)節(jié)的同時(shí)，會(huì)暴露自己的契約(contract)給其對(duì)應(yīng)的消費(fèi)者(consumer)角色。例如：服務(wù)A可以在調(diào)用服務(wù)B的同時(shí)，也去調(diào)用服務(wù)C，而只要整個(gè)請求鏈?zhǔn)峭暾?，那么服?wù)A就能夠?qū)Πl(fā)起請求的客戶端做出響應(yīng)。

微服務(wù)架構(gòu)能夠給我們的系統(tǒng)帶來很多方面的好處，其主要能力包括：使用不同的技術(shù)棧、獨(dú)立地進(jìn)行部署、一次只解決一個(gè)小問題等。但是，由于它在通信和管理上的復(fù)雜性，一般使用微服務(wù)的成本會(huì)比較高。而且在一個(gè)或多個(gè)服務(wù)出現(xiàn)問題時(shí)，微服務(wù)會(huì)變得更加復(fù)雜。如果沒有掌握良好的、且有意義的日志的話，你都無法回答諸如：哪個(gè)服務(wù)、為什么、和在什么情況下失敗了等問題。

老實(shí)說，我本人最憎恨那些由于糟糕的日志策略，所導(dǎo)致的一些“未知”的系統(tǒng)錯(cuò)誤。下面我們和您分享一些，自己在與微服務(wù)打交道時(shí)總結(jié)出的七種優(yōu)秀實(shí)踐。

1.用唯一性ID來關(guān)聯(lián)各個(gè)請求

請回想一下我們上面提到的服務(wù)A、B、C之間的請求調(diào)用鏈。在實(shí)踐中，我們應(yīng)當(dāng)給每一個(gè)調(diào)用分配一個(gè)唯一性的ID，以便標(biāo)識(shí)出每一個(gè)請求。

設(shè)想您正在記錄每個(gè)服務(wù)的訪問與錯(cuò)誤日​​志。如果您發(fā)現(xiàn)在服務(wù)B上有錯(cuò)誤，那么您就能知道該錯(cuò)誤是來自于服務(wù)A、還是服務(wù)C。

如果錯(cuò)誤信息足夠詳細(xì)的話，您也許不必去重現(xiàn)錯(cuò)誤。但是多數(shù)情況并非如此，您必須通過正確的方式，將各個(gè)服務(wù)(如服務(wù)B)中的所有請求進(jìn)行錯(cuò)誤重現(xiàn)。因此，如果您發(fā)現(xiàn)了某個(gè)與之相關(guān)聯(lián)的請求，那么您只需要在日志中尋找出它所對(duì)應(yīng)的ID便可。

隨后，您可以順藤摸瓜地從系統(tǒng)中將那些主要請求的某個(gè)部分，從服務(wù)的全量日志中截取出來。接著，您就可以知道是哪項(xiàng)服務(wù)的主請求花費(fèi)了最多的時(shí)間。其可能性包括：可能是某項(xiàng)服務(wù)使用到了緩存、或是某項(xiàng)服務(wù)不止一次調(diào)用了其他服務(wù)、以及其他有趣的細(xì)節(jié)。

2.在響應(yīng)中包含唯一性ID

微服務(wù)的用戶可能會(huì)不止一次地碰到同一個(gè)錯(cuò)誤。面對(duì)這樣的情況，您應(yīng)該乘機(jī)對(duì)客戶端可能接收到的響應(yīng)進(jìn)行編碼，以便它能夠?qū)⒁粋€(gè)唯一性的ID，連同與該錯(cuò)誤相關(guān)的任何其他有用的信息都傳遞出來。當(dāng)然，這個(gè)唯一性的ID完全可以和我們在上面所提到的相關(guān)請求保持一致。

因此，在響應(yīng)的有效載荷中包含與請求相關(guān)的唯一性ID，將有助于您和您的客戶更迅速地發(fā)現(xiàn)各類問題。同時(shí)，您也可以獲悉請求日期、時(shí)間和其他細(xì)節(jié)上的參數(shù)，以便您能夠更好地理解自己所碰到的問題。另外，您還可以將請求的ID，添加到諸如“請聯(lián)系服務(wù)管理員，并報(bào)告該問題。”之類的常見補(bǔ)充性錯(cuò)誤信息之中，以便深入了解到底是什么原因引起該錯(cuò)誤，進(jìn)而防止它在未來再次發(fā)生。

3.發(fā)送日志到集中的位置

在此，讓我們假設(shè)您已經(jīng)對(duì)各種有用的日志信息進(jìn)行了分類。下一步，我們就需要將各類日志發(fā)送到一個(gè)集中化的位置。

試想一下：如果您每次都需要登錄到各個(gè)相互單獨(dú)的服務(wù)器上，以來讀取不同的日志信息，那么您將不得不花費(fèi)更多的時(shí)間去試圖關(guān)聯(lián)這些問題。這遠(yuǎn)不如您登錄到某一個(gè)位置，并一站式地訪問到所有的日志，以定位問題。

此外，您的系統(tǒng)通常會(huì)隨著時(shí)間的推移，而變得日趨復(fù)雜，而各項(xiàng)微服務(wù)的數(shù)量也會(huì)節(jié)節(jié)攀升。同時(shí)，您的各種服務(wù)可能會(huì)分處不同的服務(wù)器或提供商，這都會(huì)讓形勢變得更為復(fù)雜。

因此，集中式存放日志正在成為業(yè)界的常規(guī)方法，特別是當(dāng)您的服務(wù)工作在云端、容器、或其他混合環(huán)境之中，而某些服務(wù)器可能會(huì)在無任何通知的情況下下線的時(shí)候。例如，在出現(xiàn)異常錯(cuò)誤，或是內(nèi)存的消耗水平已經(jīng)達(dá)到100%時(shí)，某些容器就會(huì)被終止運(yùn)行。

您可以在服務(wù)器中斷之前，通過設(shè)置代理，每五分鐘推/拉一次日志，來解決此類問題。您也可以在服務(wù)器上配置一個(gè)cronjob(定時(shí)任務(wù))、sidecar container、或是一個(gè)與其他進(jìn)程共享的文件位置，來集中化各種日志。為了避免日志被篡改，您還可以自行構(gòu)建一套解決方案，具體請參見鏈接：https://blog.scalyr.com/2017/11/log-management-need/。

可見，將所有服務(wù)的日志都集中到一處，會(huì)有助于您更容易、且有效地定位各種關(guān)聯(lián)問題。

4.結(jié)構(gòu)化您的日志數(shù)據(jù)

在具體實(shí)踐中，我們很難為所有的日志數(shù)據(jù)預(yù)先定義好格式。有些日志可能需要比其他日志更多的字段，相反這些字段可能會(huì)對(duì)那些不需要的日志來說不但多余、而且浪費(fèi)字節(jié)數(shù)。

微服務(wù)架構(gòu)是通過使用不同的技術(shù)堆棧，來解決此類問題的。不過，這會(huì)影響每個(gè)服務(wù)的日志格式。例如：某一個(gè)服務(wù)可能是用逗號(hào)來分隔不同的字段，而其他日志則使用的是管道或命名空間。

上述方法顯然比較復(fù)雜。因此，我們可以通過將自己的日志數(shù)據(jù)構(gòu)建成一套標(biāo)準(zhǔn)的格式，如：JavaScript Object Notation(JSON)，來簡化解析日志的過程。JSON允許您擁有多層次的數(shù)據(jù)。在必要的時(shí)候，您可以在單個(gè)日志的事件中獲取更多的語義信息。

同時(shí)，此法也使得對(duì)于特定日志格式的解析更加直接。通過對(duì)數(shù)據(jù)采取結(jié)構(gòu)化，就算您的日志里有各種不同的字段，其格式也會(huì)變得更加標(biāo)準(zhǔn)。籍此，您也可以在集中化的位置上創(chuàng)建各種搜索，例如：檢索包含有500條及以上，“HTTP_CODE”字段的日志信息?？梢哉f，使用結(jié)構(gòu)化的日志方式既能讓您的微服務(wù)日志實(shí)現(xiàn)標(biāo)準(zhǔn)化，又不失靈活性。

5.為每個(gè)請求添加上下文

通常情況下，如果系統(tǒng)能夠提供足夠的信息，那么我們就能夠更好地了解針對(duì)某個(gè)問題的上下文請求，更快地發(fā)現(xiàn)該問題的根本原因。不過，給各種日志添加上下文，也會(huì)在代碼層面上產(chǎn)生一些重復(fù)性的工作，因?yàn)樵谀枰脑S多日志事件中，已經(jīng)包含了諸如日期和時(shí)間等通用數(shù)據(jù)信息。因此在我們的代碼中，應(yīng)當(dāng)只記錄那些重要的消息、并涉及到一些特定的領(lǐng)域，以使得日志看起來簡單明了。

您可能會(huì)想到各種五花八門的數(shù)據(jù)需要被記錄，但是讓我們通過如下的列表，來告訴您哪些才是真正需要記錄的具體特定領(lǐng)域吧。

• 日期和時(shí)間。當(dāng)然，如果能夠保證讀取日志的人都在同一時(shí)區(qū)的話，您大可不必一律采用UTC(世界標(biāo)準(zhǔn)時(shí)間)的格式。
• 堆棧錯(cuò)誤。您可以將異常對(duì)象作為參數(shù)傳遞給自己的日志庫。
• 服務(wù)的名稱或代碼，這樣您就可以根據(jù)微服務(wù)來區(qū)分不同的日志。
• 發(fā)生錯(cuò)誤的函數(shù)、類或文件名，這樣您就省去了跟蹤問題出處的時(shí)間。
• 與外部服務(wù)交互的各種名稱，例如：您可以獲悉是哪個(gè)進(jìn)程在調(diào)用數(shù)據(jù)庫時(shí)出現(xiàn)了問題。
• 服務(wù)器和客戶端請求的IP地址。這些信息將有助于發(fā)現(xiàn)那些不健康的服務(wù)器、或識(shí)別出DDoS類攻擊。
• 應(yīng)用程序的用戶代理，以便您能判斷是哪些瀏覽器或用戶碰到了問題。
• 通過HTTP代碼來獲取錯(cuò)誤的更多語義。這些代碼將有助于創(chuàng)建各類警報(bào)。

可見，為每個(gè)請求添加上下文，能夠節(jié)省您對(duì)系統(tǒng)進(jìn)行排障的時(shí)間。

6.將日志存儲(chǔ)到本地

將日志存儲(chǔ)到本地，似乎聽起來和我們前面說的“發(fā)送日志到集中的位置”有些矛盾，其實(shí)則不然。最初我是將各種日志，直接通過HTTP請求的方式發(fā)送到別處的。但是我屢次發(fā)現(xiàn)這些流量傳輸占用掉了我大量的出站帶寬，以至于影響到了其他更為重要的微服務(wù)調(diào)用。

因此，我們需要對(duì)日志的外發(fā)和本地存儲(chǔ)有所取舍。最終，我之所以選擇了本地存儲(chǔ)，是因?yàn)檫@樣有助于從應(yīng)用程序中分離日志、并減少上下文的切換。針對(duì)數(shù)據(jù)庫，您可以采取將應(yīng)用程序與其日志區(qū)分不同存儲(chǔ)卷的方式。

例如：亞馬遜的AWS就一個(gè)選項(xiàng)，用戶可以使用一種稱為Elastic File System(EFS)的服務(wù)，去掛載某個(gè)卷。其功能類似于網(wǎng)絡(luò)附屬存儲(chǔ)(network-attached storage，NAS)。那么，您可以按需輾轉(zhuǎn)到另一臺(tái)服務(wù)器上，掛載相同容量的卷，然后將各種日志轉(zhuǎn)發(fā)到那個(gè)集中的位置上。

簡單說來，我們可以使用Docker容器，來實(shí)現(xiàn)將所有應(yīng)用程序的日志都發(fā)送到相同的位置。然后匯總、過濾和轉(zhuǎn)發(fā)這些日志的存儲(chǔ)庫，到其他進(jìn)程或服務(wù)那里。

7.記錄重要且有意義的數(shù)據(jù)，有備無患

如果您是剛開始接觸微服務(wù)的日志問題，那么上述最佳實(shí)踐可能會(huì)對(duì)你比較“無感”。但是，只要您足夠細(xì)心，在持續(xù)使用了微服務(wù)一段時(shí)間之后，您就可以通過對(duì)現(xiàn)有日志信息和方式的評(píng)估，逐漸摸索出哪些才是您可以用來發(fā)現(xiàn)和解決奇怪問題的有用信息。

同時(shí)，在記錄和積累了足夠多的日志數(shù)據(jù)之后，您還可以伺機(jī)采用自動(dòng)化的警報(bào)方式，以節(jié)約您通過讀取大量日志來定位問題的時(shí)間。當(dāng)然，自動(dòng)化警報(bào)也能夠幫助您以一種積極主動(dòng)方式，限制各種錯(cuò)誤向所有用戶處蔓延。

總之，集中化日志信息，是微服務(wù)錯(cuò)誤分析的必備手段。而為日志添加足夠多的上下文信息，則能夠更好地分辨出那些是有用的日志，那些是無用的信息。

原文標(biāo)題：Microservices Logging Best Practices，作者：Christian Melendez & David McAllister

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】