一、需求描述

在上一篇《利用Vector和鴻鵠搭建微服務(wù)應(yīng)用的可觀測(cè)性平臺(tái)》中，闡述了微服務(wù)的基本概念、優(yōu)點(diǎn)及如何利用鴻鵠來處理分布式應(yīng)用的日志。本文將進(jìn)一步討論微服務(wù)架構(gòu)面臨的問題、服務(wù)網(wǎng)格及鴻鵠處理Istio Gateway的獨(dú)特優(yōu)勢(shì)。

1.1 微服務(wù)架構(gòu)面臨的挑戰(zhàn)

1.1.1 云基礎(chǔ)設(shè)施并不總是可靠

無論是公有云還是私有云，都由成千上萬的硬件和軟件構(gòu)成。理論上，或多或少存在不可用的組件。而我們的微服務(wù)一般會(huì)部署在云上，工程師在構(gòu)建微服務(wù)時(shí)，一般都會(huì)假設(shè)基礎(chǔ)設(shè)施是非永久的且部分基礎(chǔ)設(shè)施甚至是不可用狀態(tài)。所以在架構(gòu)中，必須前瞻性地考慮云基礎(chǔ)設(shè)施的非永久性特征。

1.1.2 必須確保服務(wù)之間通信的彈性

因?yàn)樵苹A(chǔ)設(shè)施的不可靠性，在設(shè)計(jì)微服務(wù)系統(tǒng)的時(shí)候，需要考慮服務(wù)本身的彈性，確保部分基礎(chǔ)設(shè)施不可用的情況下，還能持續(xù)對(duì)外提供服務(wù)。業(yè)界目前一般有如下的解決方案：

• 客戶端負(fù)載均衡: 提供多個(gè)服務(wù)端點(diǎn)，由客戶端決定如何調(diào)用

• 服務(wù)發(fā)現(xiàn)機(jī)制：定期的更新健康的服務(wù)端點(diǎn)

• 短路：對(duì)于非正常的服務(wù)，實(shí)施一定時(shí)間的隔離

• 限制措施：對(duì)連接數(shù)、線程數(shù)、會(huì)話數(shù)等進(jìn)行限制

• 超時(shí)：對(duì)API請(qǐng)求的時(shí)長(zhǎng)，設(shè)置超時(shí)機(jī)制

• 重試及重試控制：失敗重試及限制最大重試次數(shù)或一定時(shí)間范圍內(nèi)的重試次數(shù)

• 請(qǐng)求有效期限：如果請(qǐng)求返還超時(shí)，則丟棄，不做進(jìn)一步處理

1.1.3 實(shí)時(shí)了解系統(tǒng)狀態(tài)

我們需要實(shí)時(shí)的知道服務(wù)之間的調(diào)用關(guān)系、某個(gè)典型服務(wù)當(dāng)前的負(fù)載、失敗是否在預(yù)期之內(nèi)、如果服務(wù)掛了系統(tǒng)如何表現(xiàn)等?？偟膩碚f，運(yùn)營(yíng)一個(gè)微服務(wù)平臺(tái)，除了微服務(wù)本身，利用指標(biāo)類數(shù)據(jù)、日志、追蹤來把握整個(gè)系統(tǒng)的全局是必不可少的一環(huán)。

1.2 傳統(tǒng)的解決方案：應(yīng)用程序庫(kù)

早期的時(shí)候，為了解決如上的問題，業(yè)界一般采用應(yīng)用程序庫(kù)（如下），以方便開發(fā)人員快速地開發(fā)和實(shí)現(xiàn)非功能性的需求，但帶來的壞處是應(yīng)用程序必須和某個(gè)語言綁定。

• Hystrix：用于短路及限流

• Ribbon：用于客戶端負(fù)載均衡

• Eureka：服務(wù)注冊(cè)和發(fā)現(xiàn)

• Zuul：動(dòng)態(tài)服務(wù)代理

1.3 現(xiàn)代的解決方案：服務(wù)網(wǎng)格

服務(wù)網(wǎng)格是一種透明的、獨(dú)立于程序之外的、用于處理網(wǎng)絡(luò)通信的分布式基礎(chǔ)設(shè)施，它由數(shù)據(jù)平面和控制平面所組成，如下圖所示：

微服務(wù)架構(gòu)集成服務(wù)網(wǎng)格后，對(duì)日志收集和監(jiān)控也帶來了進(jìn)一步要求；分析上述拓?fù)鋱D，我們需要收集對(duì)應(yīng)的Istio Proxy日志及進(jìn)一步做關(guān)聯(lián)分析，經(jīng)過了解，這也是鴻鵠平臺(tái)所擅長(zhǎng)的。

二、解決方案

2.1 系統(tǒng)架構(gòu)

相比于上一篇《利用Vector和鴻鵠搭建微服務(wù)應(yīng)用的可觀測(cè)性平臺(tái)》， 此方案引入了Istio服務(wù)網(wǎng)格的概念，除了采集應(yīng)用程序本身的日志之外，需要采集Istio Ingress Gateway和Istio Proxy的日志，以得到對(duì)全局服務(wù)網(wǎng)格的洞察性。

2.2 數(shù)據(jù)接入

鴻鵠具備多種數(shù)據(jù)接入功能，內(nèi)置的Vector和Kafka數(shù)據(jù)接入功能，大大方便了企業(yè)收集數(shù)據(jù)，導(dǎo)入鴻鵠分析平臺(tái)進(jìn)一步挖掘數(shù)據(jù)價(jià)值的便利性?；谝陨系牟杉到y(tǒng)，具體操作步驟如下：

2.2.1 啟用鴻鵠數(shù)據(jù)收集接口

2.2.1.1 進(jìn)入：鴻鵠 -> 數(shù)據(jù)導(dǎo)入 -> 從外部數(shù)據(jù)源導(dǎo)入

2.2.1.2 配置Vector接口，選擇數(shù)據(jù)集范圍

2.2.1.3 選擇數(shù)據(jù)集和數(shù)據(jù)源類型，生成和下載Vector配置模版，以備后續(xù)配置Vector使用

2.2.2 配置及安裝Vector

按照Vector的設(shè)計(jì)（如上圖），Data Pipeline分為三個(gè)階段：確定數(shù)據(jù)源、對(duì)數(shù)據(jù)做轉(zhuǎn)換和數(shù)據(jù)匯集。以下是實(shí)際運(yùn)行的配置文件（考慮到信息安全性，對(duì)部分做了脫敏處理）。

這個(gè)配置主要包含了確定采集的數(shù)據(jù)源、數(shù)據(jù)如何被加工轉(zhuǎn)換（多行處理、如何進(jìn)一步解析和抽取數(shù)據(jù)、豐富數(shù)據(jù)以滿足鴻鵠的需求）和數(shù)據(jù)最終匯集到鴻鵠，相信大家不難理解。

有了Vector的配置文件，就可以安裝Vector了。本文的方案需要采集運(yùn)行在Kubernetes上的微服務(wù)的日志，Vector將會(huì)用Helm命令來安裝，具體命令如下：

如果需要詳細(xì)了解Vector Helm chart，可參考 Vector Helm Chart（https://github.com/vectordotdev/helm-charts/tree/develop/charts/vector）

2.3 數(shù)據(jù)加工

2.3.1 創(chuàng)建數(shù)據(jù)源

鴻鵠系統(tǒng)提供了常用的數(shù)據(jù)源類型，比如json、csv、nginx、syslog等，以方便用戶開箱即用地接入數(shù)據(jù)。本文提到的Istio Ingress Gateway網(wǎng)關(guān)本身是基于Envoy實(shí)現(xiàn)的，為了更好的說明后續(xù)步驟，讓我們首先來介紹下Istio Gateway日志的格式。

根據(jù)文檔 Envoy Access Log（https://istio.io/latest/docs/tasks/observability/logs/access-log/），默認(rèn)格式如下：

根據(jù)如上的信息，Envoy的日志包含了豐富的信息，為了后續(xù)方便分析和處理，需要單獨(dú)創(chuàng)建數(shù)據(jù)源，如下圖。

2.3.2 字段加工

字段加工是鴻鵠的核心功能，也就是在讀時(shí)模式下，對(duì)字段進(jìn)行進(jìn)一步抽取和豐富，以滿足各種業(yè)務(wù)部門對(duì)同一數(shù)據(jù)以不同視角分析的需要。那接下去以Envoy Access Log為例，看看鴻鵠是怎么做的。

2.3.2.1 打開高級(jí)搜索窗口

從搜索窗口可以看到，此數(shù)據(jù)包含266279條數(shù)據(jù)，因?yàn)闆]有對(duì)數(shù)據(jù)進(jìn)行讀時(shí)抽取，共用0.9s時(shí)間。

2.3.2.2 點(diǎn)擊 “抽取新字段”，進(jìn)入字段抽取向?qū)ы撁?/strong>