亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

可觀察性是一把覆蓋多個(gè)移動(dòng)部件的寬傘。服務(wù)網(wǎng)格覆蓋了很多領(lǐng)域，無(wú)需我們編寫(xiě)一行代碼。

服務(wù)網(wǎng)格和可觀察性是微服務(wù)社區(qū)中的熱門(mén)話題。在本趨勢(shì)報(bào)告中，我們將詳細(xì)探討服務(wù)網(wǎng)格以及良好的可觀察性堆棧如何幫助我們克服使用微服務(wù)時(shí)面臨的一些最緊迫的挑戰(zhàn)。

常見(jiàn)的微服務(wù)挑戰(zhàn)

采用微服務(wù)很難。調(diào)試并確保它們繼續(xù)運(yùn)行更加困難。微服務(wù)以第 2 天操作的形式引入了大量開(kāi)銷。讓我們深入探討使使用微服務(wù)變得困難的幾個(gè)方面。

在分布式系統(tǒng)中調(diào)試錯(cuò)誤是一場(chǎng)噩夢(mèng)

微服務(wù)的分布式特性使得調(diào)試錯(cuò)誤變得困難。在單體應(yīng)用中，只需查看日志和堆棧跟蹤就足以確定錯(cuò)誤的根本原因。當(dāng)涉及到微服務(wù)時(shí)，事情就不是那么簡(jiǎn)單了。在出現(xiàn)錯(cuò)誤的情況下，挖掘微服務(wù)的日志可能無(wú)法直接指出確切的問(wèn)題。相反，它可以簡(jiǎn)單地提及從依賴微服務(wù)收到的請(qǐng)求和/或響應(yīng)中存在的錯(cuò)誤。

換句話說(shuō)，我們必須跟蹤整個(gè)網(wǎng)絡(luò)跟蹤以確定哪個(gè)微服務(wù)是問(wèn)題的根本原因。這是一個(gè)非常耗時(shí)的過(guò)程。

識(shí)別系統(tǒng)中的瓶頸并不容易

在單體應(yīng)用中，識(shí)別性能瓶頸就像分析我們的應(yīng)用程序一樣容易。分析通常足以確定代碼庫(kù)中哪些方法最耗時(shí)。這有助于您將優(yōu)化工作集中在一小段代碼上。不幸的是，找出導(dǎo)致整個(gè)系統(tǒng)變慢的微服務(wù)是一項(xiàng)挑戰(zhàn)。

單獨(dú)測(cè)試時(shí)，每個(gè)微服務(wù)似乎都表現(xiàn)出色。但在現(xiàn)實(shí)世界的場(chǎng)景中，每項(xiàng)服務(wù)的負(fù)載可能會(huì)有很大差異。可能存在一些其他微服務(wù)所依賴的核心微服務(wù)。在孤立的測(cè)試環(huán)境中復(fù)制此類場(chǎng)景非常困難。

維護(hù)微服務(wù)依賴樹(shù)很困難

微服務(wù)的全部意義在于我們可以發(fā)布新軟件的敏捷性。話雖如此，重要的是要注意發(fā)布微服務(wù)時(shí)可能會(huì)產(chǎn)生多種下游影響。某些經(jīng)常破壞功能的事件是：

1. 在上游依賴之前釋放依賴的微服務(wù)
2. 刪除遺留系統(tǒng)仍然依賴的已棄用 API
3. 發(fā)布破壞 API 兼容性的微服務(wù)

當(dāng)微服務(wù)之間沒(méi)有明確的依賴樹(shù)時(shí)，這些事件變得難以避免。依賴樹(shù)可以更輕松地通知適當(dāng)?shù)膱F(tuán)隊(duì)并更好地計(jì)劃發(fā)布。

可觀察性：微服務(wù)問(wèn)題的解決方案

我上面提到的所有問(wèn)題都可以通過(guò)可觀察性來(lái)解決。根據(jù) Jay Livens 的說(shuō)法，可觀察性是一種根據(jù)系統(tǒng)生成的指標(biāo)和日志捕獲系統(tǒng)當(dāng)前狀態(tài)的做法。它是一個(gè)系統(tǒng)，可以幫助我們監(jiān)控應(yīng)用程序的健康狀況，生成故障警報(bào)，并在問(wèn)題發(fā)生時(shí)捕獲足夠的信息來(lái)調(diào)試問(wèn)題。

圖 1：具有開(kāi)源示例的可觀察性堆棧組件

任何可觀察性堆棧都將具有以下組件：

1. 指標(biāo)/日志的來(lái)源——我們用來(lái)生成數(shù)據(jù)的代理或庫(kù)
2. Metric/log shipper——將數(shù)據(jù)傳輸?shù)酱鎯?chǔ)引擎的代理；通常嵌入在度量源中
3. 收集器/存儲(chǔ)- 負(fù)責(zé)存儲(chǔ)生成的數(shù)據(jù)的有狀態(tài)服務(wù)
4. 儀表板——精美的圖表，使我們易于解釋和消化數(shù)據(jù)
5. 警報(bào)管理器——負(fù)責(zé)觸發(fā)通知的服務(wù)

對(duì)我們來(lái)說(shuō)幸運(yùn)的是，有一些強(qiáng)大的開(kāi)源工具可以幫助簡(jiǎn)化設(shè)置可觀察性堆棧的過(guò)程。

介紹服務(wù)網(wǎng)格

可觀察性的一個(gè)主要方面是捕獲網(wǎng)絡(luò)遙測(cè)，擁有良好的網(wǎng)絡(luò)洞察力可以幫助我們解決我們最初談到的許多問(wèn)題。通常，生成此遙測(cè)數(shù)據(jù)的任務(wù)由開(kāi)發(fā)人員來(lái)實(shí)現(xiàn)。這是一個(gè)極其繁瑣且容易出錯(cuò)的過(guò)程，并不會(huì)真正以遙測(cè)結(jié)束。開(kāi)發(fā)人員還負(fù)責(zé)實(shí)施安全功能并使通信能夠抵御故障。

理想情況下，我們希望我們的開(kāi)發(fā)人員編寫(xiě)應(yīng)用程序代碼，而不是別的。微服務(wù)網(wǎng)絡(luò)的復(fù)雜性需要下推到底層平臺(tái)。實(shí)現(xiàn)這種解耦的更好方法是使用服務(wù)網(wǎng)格，如Istio、Linkerd或Consul Connect。

服務(wù)網(wǎng)格是一種用于控制和監(jiān)控微服務(wù)網(wǎng)絡(luò)和通信的架構(gòu)模式。

讓我們以 Istio 為例來(lái)了解服務(wù)網(wǎng)格是如何工作的。

圖 2：典型的服務(wù)網(wǎng)格架構(gòu)

來(lái)源：圖片改編自 Istio 文檔

服務(wù)網(wǎng)格有兩個(gè)主要組件：數(shù)據(jù)平面和控制平面。數(shù)據(jù)平面負(fù)責(zé)管理我們的微服務(wù)將產(chǎn)生的所有網(wǎng)絡(luò)流量。為了實(shí)現(xiàn)這一點(diǎn)，服務(wù)網(wǎng)格會(huì)在我們的每個(gè)微服務(wù)旁邊注入一個(gè) sidecar 代理。這個(gè) sidecar，通常是 Envoy，負(fù)責(zé)透明地?cái)r截流過(guò)服務(wù)的所有流量。另一方面，控制平面僅負(fù)責(zé)配置代理。沒(méi)有應(yīng)用程序流量到達(dá)控制平面。

如圖 2 所示，服務(wù)網(wǎng)格架構(gòu)可幫助您抽象出我們之前談到的所有復(fù)雜性。最好的部分是我們可以開(kāi)始使用服務(wù)網(wǎng)格，而無(wú)需編寫(xiě)任何代碼。服務(wù)網(wǎng)格幫助我們管理基于微服務(wù)的架構(gòu)的多個(gè)方面。一些顯著的優(yōu)勢(shì)包括：

1. 全面了解流量如何流動(dòng)
2. 控制網(wǎng)絡(luò)流量
3. 保護(hù)微服務(wù)通信

在圖 3 中，應(yīng)用 A 正在向應(yīng)用 B 發(fā)出請(qǐng)求。由于位于每個(gè)應(yīng)用旁邊的 Envoy 代理正在攔截請(qǐng)求，因此它們對(duì)流經(jīng)這兩個(gè)微服務(wù)的流量具有完全的可見(jiàn)性。代理可以檢查此流量以收集信息，例如發(fā)出的請(qǐng)求數(shù)和每個(gè)請(qǐng)求的響應(yīng)狀態(tài)代碼。

換句話說(shuō)，服務(wù)網(wǎng)格可以幫助我們回答以下問(wèn)題：

1. 哪個(gè)服務(wù)正在與哪個(gè)對(duì)話？
2. 每個(gè)微服務(wù)觀察到的請(qǐng)求吞吐量是多少？
3. 每個(gè) API 的錯(cuò)誤率是多少？

圖 3：服務(wù)網(wǎng)格可以幫助收集指標(biāo)

控制網(wǎng)絡(luò)

服務(wù)網(wǎng)格不僅僅是一個(gè)沉默的旁觀者。它可以積極參與塑造所有網(wǎng)絡(luò)流量。用作 sidecar 的 Envoy 代理是 HTTP 感知的，并且由于所有請(qǐng)求都流經(jīng)這些代理，因此可以將它們配置為實(shí)現(xiàn)幾個(gè)有用的功能，例如：

1. 自動(dòng)退出——在遇到網(wǎng)絡(luò)錯(cuò)誤時(shí)重放請(qǐng)求的能力
2. 斷路——將已停止響應(yīng)的上游微服務(wù)的不健康副本列入黑名單
3. 請(qǐng)求重寫(xiě)——在滿足某些條件時(shí)設(shè)置標(biāo)頭或修改請(qǐng)求 URL 的能力

圖 4： 服務(wù)網(wǎng)格可以塑造網(wǎng)絡(luò)流量

它并沒(méi)有在這里結(jié)束。代理還可以根據(jù)一定的權(quán)重分割流量。例如，我們可以將代理配置為將 95% 的傳入流量發(fā)送到服務(wù)的穩(wěn)定版本，而其余的可以重定向到金絲雀版本。這可以通過(guò)支持金絲雀部署等高級(jí)實(shí)踐來(lái)幫助我們簡(jiǎn)化發(fā)布管理流程。

保護(hù)微服務(wù)通信

使用服務(wù)網(wǎng)格的另一個(gè)巨大優(yōu)勢(shì)是安全性。我們的 sidecar 代理可以配置為使用雙向 TLS。這可確保所有網(wǎng)絡(luò)流量在傳輸過(guò)程中自動(dòng)加密。管理和輪換 mTLS 所需證書(shū)的任務(wù)由服務(wù)網(wǎng)格控制平面完全自動(dòng)化。

服務(wù)網(wǎng)格還可以通過(guò)選擇性地允許哪個(gè)服務(wù)與哪個(gè)服務(wù)進(jìn)行通信來(lái)協(xié)助訪問(wèn)控制。所有這些都可以幫助我們徹底消除諸如中間人攻擊等一整套安全漏洞。

圖 5：服務(wù)網(wǎng)格可以保護(hù)網(wǎng)絡(luò)流量

服務(wù)網(wǎng)格如何幫助提高可觀察性？

我們剛剛看到了服務(wù)網(wǎng)格如何捕獲遙測(cè)數(shù)據(jù)。讓我們更深入地了解這些數(shù)據(jù)可以支持什么樣的用例。

分布式跟蹤

我們已經(jīng)討論了調(diào)試微服務(wù)有多么困難。解決這個(gè)可調(diào)試性問(wèn)題的一種方法是通過(guò)分布式跟蹤——捕獲請(qǐng)求生命周期的過(guò)程。僅一張圖表就可以更容易找出問(wèn)題的根本原因。

大多數(shù)服務(wù)網(wǎng)格會(huì)自動(dòng)收集網(wǎng)絡(luò)跟蹤并將其發(fā)送到 Jaeger 等工具。您需要做的就是在應(yīng)用程序代碼中轉(zhuǎn)發(fā)一些 HTTP 標(biāo)頭。而已！

流量指標(biāo)

服務(wù)網(wǎng)格可以幫助我們收集必須監(jiān)控的四個(gè)黃金信號(hào)中的三個(gè)，以確定服務(wù)的健康狀況：

1. 請(qǐng)求吞吐量——每個(gè)微服務(wù)正在服務(wù)的請(qǐng)求數(shù)
2. 響應(yīng)錯(cuò)誤率——失敗請(qǐng)求的百分比
3. 響應(yīng)延遲——微服務(wù)響應(yīng)所需的時(shí)間；這是一個(gè)直方圖，您可以從中提取n 個(gè)百分位數(shù)的延遲

服務(wù)網(wǎng)格收集的指標(biāo)還有很多，但這些是迄今為止最重要的指標(biāo)。這些指標(biāo)可用于支持幾個(gè)有趣的用例。其中一些包括：

1. 根據(jù)請(qǐng)求吞吐量等高級(jí)參數(shù)啟用擴(kuò)展
2. 啟用高級(jí)流量控制功能，例如速率限制和斷路
3. 執(zhí)行自動(dòng)化 Canary 部署和 A/B 測(cè)試

服務(wù)網(wǎng)格可以幫助我們自動(dòng)構(gòu)建網(wǎng)絡(luò)拓?fù)洌梢酝ㄟ^(guò)將跟蹤數(shù)據(jù)與流量指標(biāo)相結(jié)合來(lái)構(gòu)建。如果你問(wèn)我，這是一個(gè)真正的救星。網(wǎng)絡(luò)拓?fù)淇梢詭椭覀円荒苛巳坏乜梢暬麄€(gè)微服務(wù)依賴樹(shù)。此外，它還可以突出我們集群的網(wǎng)絡(luò)健康狀況。這對(duì)于識(shí)別我們的應(yīng)用程序中的瓶頸非常有用。

結(jié)論

可觀察性是一把覆蓋多個(gè)移動(dòng)部件的寬傘。對(duì)我們來(lái)說(shuō)幸運(yùn)的是，像服務(wù)網(wǎng)格這樣的工具覆蓋了很多領(lǐng)域，而不需要我們編寫(xiě)一行代碼。簡(jiǎn)而言之，服務(wù)網(wǎng)格通過(guò)以下方式幫助我們：

1. 生成分布式跟蹤數(shù)據(jù)以簡(jiǎn)化調(diào)試
2. 充當(dāng)關(guān)鍵指標(biāo)的來(lái)源，例如微服務(wù)監(jiān)控的黃金信號(hào)
3. 生成網(wǎng)絡(luò)拓?fù)?/li>