最近幾年好像大家都開(kāi)始對(duì)微服務(wù)著迷，與此同時(shí)單體架構(gòu)也在慢慢淡出人們的視線。

當(dāng)然，熱門的趨勢(shì)總是來(lái)來(lái)去去，而且它們所受到的關(guān)注往往被媒體夸大了，實(shí)際情況并不總是如此。不過(guò)，對(duì)于微服務(wù)來(lái)說(shuō)，人們似乎已經(jīng)達(dá)成共識(shí)，認(rèn)為這個(gè)趨勢(shì)會(huì)一直存在下去。這是有道理的。從概念的角度來(lái)說(shuō)，微服務(wù)擴(kuò)展了工程師們幾十年來(lái)采用的相同原則。

一旦你開(kāi)始使用微服務(wù)架構(gòu)，也許你需要本文中提到的5個(gè)規(guī)則，幫助你成功運(yùn)行它們。

微服務(wù)的另一面

關(guān)注點(diǎn)分離(SoC)是一項(xiàng)設(shè)計(jì)原則，規(guī)定軟件的構(gòu)建應(yīng)根據(jù) "關(guān)注點(diǎn) "或總體功能來(lái)確定不同的部分，30多年來(lái)一直被用來(lái)決定如何構(gòu)建技術(shù)。在單體應(yīng)用中，它體現(xiàn)在典型的3層架構(gòu)中的表現(xiàn)層、業(yè)務(wù)層和數(shù)據(jù)層的分離。

微服務(wù)采用了這個(gè)概念，并將其顛覆。它們將同一個(gè)應(yīng)用程序以這樣的方式分離出來(lái)，應(yīng)用程序的單一代碼庫(kù)可以被分解并單獨(dú)部署。這樣做的好處是巨大的，但也是有代價(jià)的，通常體現(xiàn)在時(shí)間和金錢兩方面的運(yùn)維成本較高。除了將現(xiàn)有的應(yīng)用程序過(guò)渡到容器所帶來(lái)的巨大的前期投資之外，維護(hù)該應(yīng)用程序也帶來(lái)了新的挑戰(zhàn)。

挑戰(zhàn)1：似乎很難監(jiān)控整體

雖然單體應(yīng)用程序也有其自身的挑戰(zhàn)，但在單體中回滾一個(gè)“壞”版本的過(guò)程是相當(dāng)簡(jiǎn)單的。在容器化應(yīng)用中，事情就變得復(fù)雜許多。無(wú)論你是將單體應(yīng)用逐步分解為微服務(wù)，還是從頭開(kāi)始構(gòu)建一個(gè)新系統(tǒng)，你現(xiàn)在都有更多的服務(wù)需要監(jiān)控。其中每一個(gè)都可能會(huì)：

• 使用不同的技術(shù)和/或語(yǔ)言。
• 運(yùn)行在不同的機(jī)器和/或容器上
• 使用K8s或類似的技術(shù)進(jìn)行容器化和編排

隨之而來(lái)的是，系統(tǒng)變得高度分散，更需要集中監(jiān)控。遺憾的是，這也意味著需要監(jiān)控的東西也多了起來(lái)。以前只有一個(gè)單體進(jìn)程，而現(xiàn)在可能有幾十個(gè)容器化進(jìn)程運(yùn)行在不同的區(qū)域，有時(shí)甚至是不同的云。這意味著不再有一套單一的運(yùn)維指標(biāo)來(lái)統(tǒng)治它們，IT/運(yùn)維團(tuán)隊(duì)可以用它來(lái)評(píng)估應(yīng)用程序的一般正常運(yùn)行時(shí)間。取而代之的是，團(tuán)隊(duì)現(xiàn)在必須處理數(shù)以百計(jì)(甚至數(shù)以千計(jì))的指標(biāo)、事件和告警類型，他們需要從中分離出有效信號(hào)和無(wú)效噪音。

解決方案

DevOps監(jiān)控需要從扁平化的數(shù)據(jù)模型轉(zhuǎn)向分層模型，在這種模型中，可以隨時(shí)觀察到一系列高級(jí)系統(tǒng)和業(yè)務(wù)KPI。只要有一點(diǎn)偏差，團(tuán)隊(duì)就必須能夠進(jìn)入指標(biāo)層次結(jié)構(gòu)，查看干擾來(lái)自于哪個(gè)微服務(wù)，并從那里了解實(shí)際發(fā)生故障的容器。這很可能需要從數(shù)據(jù)存儲(chǔ)和可視化的角度重新調(diào)整DevOps工具鏈。開(kāi)源的時(shí)序DB工具，諸如Prometheus和Grafana 7.0等使得這個(gè)目標(biāo)非常容易實(shí)現(xiàn)。

挑戰(zhàn)2：跨服務(wù)日志記錄

在談?wù)摫O(jiān)控應(yīng)用程序時(shí)，首先要提出的事情之一是：日志、日志、日志。服務(wù)器每天都會(huì)產(chǎn)生的IT日志相當(dāng)于碳的排放量，最終導(dǎo)致溢出的硬盤驅(qū)動(dòng)器以及瘋狂攝取、存儲(chǔ)和工具成本。即使采用單體架構(gòu)，你的日志也可能已經(jīng)使你的工程師有些頭疼。

使用微服務(wù)，日志變得更加分散。一個(gè)簡(jiǎn)單的用戶業(yè)務(wù)現(xiàn)在可以通過(guò)許多服務(wù)進(jìn)行，所有這些服務(wù)都有自己的日志記錄框架。要解決問(wèn)題，你必須從業(yè)務(wù)可能通過(guò)的所有服務(wù)中提取所有不同的日志，以了解問(wèn)題所在。

解決方案

這里的主要挑戰(zhàn)是了解單個(gè)業(yè)務(wù)如何在不同服務(wù)之間“流動(dòng)”。為了實(shí)現(xiàn)這一點(diǎn)，需要對(duì)傳統(tǒng)的單體程序在順序業(yè)務(wù)執(zhí)行期間通常如何記錄所有事件的方式進(jìn)行大量修改。盡管已經(jīng)出現(xiàn)了許多框架來(lái)幫助開(kāi)發(fā)人員進(jìn)行處理(我們特別喜歡Jaeger的方法)，但對(duì)于希望將單體重構(gòu)為微服務(wù)的企業(yè)而言，轉(zhuǎn)向異步、跟蹤驅(qū)動(dòng)的日志記錄仍需要付出艱巨的努力。

挑戰(zhàn)3：部署一項(xiàng)服務(wù)會(huì)破壞另一項(xiàng)服務(wù)

單片機(jī)世界中的一個(gè)關(guān)鍵假設(shè)是，所有代碼都是在同一時(shí)間部署的，這意味著應(yīng)用程序處于最脆弱狀態(tài)的時(shí)間范圍是一個(gè)已知的、相對(duì)較短的時(shí)間段(即部署后的前24-48小時(shí))。在微服務(wù)的世界里，這個(gè)假設(shè)不再成立：由于微服務(wù)本質(zhì)上是相互交織的，其中一個(gè)服務(wù)細(xì)微的變更可能會(huì)導(dǎo)致行為或性能問(wèn)題，而這些問(wèn)題會(huì)在另一個(gè)服務(wù)中體現(xiàn)出來(lái)。因此所面臨的挑戰(zhàn)是，當(dāng)前出現(xiàn)故障的微服務(wù)使得另一個(gè)開(kāi)發(fā)團(tuán)隊(duì)并沒(méi)有預(yù)料到他們的代碼會(huì)出現(xiàn)中斷。這既會(huì)導(dǎo)致整個(gè)應(yīng)用意外的不穩(wěn)定性，也會(huì)導(dǎo)致一些組織內(nèi)部的摩擦。雖然微服務(wù)架構(gòu)可能讓部署代碼的過(guò)程變得更容易，但實(shí)際上卻讓部署后驗(yàn)證代碼行為的過(guò)程變得更難。

解決方案

企業(yè)必須創(chuàng)建共享的發(fā)布日歷，并且每當(dāng)部署相關(guān)的微服務(wù)時(shí)，都要分配資源用于密切測(cè)試和監(jiān)控整個(gè)應(yīng)用的行為。在沒(méi)有跨團(tuán)隊(duì)協(xié)調(diào)的情況下部署新版本的微服務(wù)，就像牛油果加吐司一樣，是解決這一挑戰(zhàn)的成功秘訣。

挑戰(zhàn)4：難以找到問(wèn)題的根本原因

在這一點(diǎn)上，你已經(jīng)鎖定了有問(wèn)題的服務(wù)，提取了所有需要提取的數(shù)據(jù)，包括堆棧跟蹤和日志中的一些變量值。你可能還有一些APM解決方案，比如New Relic、AppDynamics或Dynatrace。從那里，你會(huì)得到一些額外的數(shù)據(jù)，關(guān)于一些相關(guān)方法的異常高處理時(shí)間。但是......問(wèn)題的根本原因呢?

你(希望)從日志中得到的前幾位變量數(shù)據(jù)很可能不會(huì)是那些移動(dòng)針的數(shù)據(jù)。它們通常更像是面包屑，指向下一條線索的方向，而不是更進(jìn)一步的原因。在這一點(diǎn)上，我們需要盡我們所能，發(fā)掘出更多應(yīng)用程序下的 "魔力"。傳統(tǒng)上，這需要發(fā)出關(guān)于每個(gè)失敗事務(wù)狀態(tài)的詳細(xì)信息(即到底為什么失敗)。這里的挑戰(zhàn)是，需要開(kāi)發(fā)人員具有巨大的預(yù)見(jiàn)性，以知道他們需要哪些信息來(lái)提前排除問(wèn)題。

解決方案

當(dāng)微服務(wù)中的錯(cuò)誤根源橫跨多個(gè)服務(wù)時(shí)，制定一個(gè)集中的問(wèn)題根源檢測(cè)方法至關(guān)重要。團(tuán)隊(duì)必須考慮需要哪些信息顆粒來(lái)診斷未來(lái)的問(wèn)題，以及它們應(yīng)該在什么層級(jí)上發(fā)出日志，以考慮到性能和安全因素——這是一座高高的山，而且是一座永無(wú)止境的山。

挑戰(zhàn)5：版本管理

我們認(rèn)為值得強(qiáng)調(diào)的問(wèn)題是，從典型的單體架構(gòu)中的層模型過(guò)渡到微服務(wù)的圖模型。由于超過(guò)80%的應(yīng)用程序代碼通常是第三方代碼，因此在公司的不同微服務(wù)之間管理第三方代碼的共享方式成為避免陷入前所未有的“依賴地獄”的關(guān)鍵因素。

考慮這樣一種情況：一些團(tuán)隊(duì)在使用第三方組件或共享實(shí)例程序的X.Y版本(幾乎所有公司都有)，而其他團(tuán)隊(duì)則使用X.Z版本。這就增加了由于不同版本之間缺乏兼容性而產(chǎn)生的關(guān)鍵軟件問(wèn)題的風(fēng)險(xiǎn)，或者說(shuō)，不同版本之間行為的輕微變化，可能會(huì)導(dǎo)致需要排查最特異和痛苦的軟件bug。

而在這一切之前，我們還要提醒自己，任何一個(gè)微服務(wù)使用第三方代碼的舊版本、更脆弱的版本，都會(huì)產(chǎn)生安全問(wèn)題——這是黑客的天堂。允許不同的團(tuán)隊(duì)在孤島般的repo中管理他們的依賴性，在單體世界中可能是可行的，但在微服務(wù)架構(gòu)中，這是絕對(duì)不可以的。

解決方案

公司必須在重新設(shè)計(jì)他們的構(gòu)建流程方面進(jìn)行投資，以便為第三方和共享實(shí)用程序代碼利用集中式artifact倉(cāng)庫(kù)(Artifactory將是其中之一)。團(tuán)隊(duì)?wèi)?yīng)該只允許將自己的代碼存儲(chǔ)在單獨(dú)的倉(cāng)庫(kù)中。

最后的思考

與科技行業(yè)的大多數(shù)進(jìn)步一樣，微服務(wù)采用了一個(gè)熟悉的概念，并將其顛覆。它們重新思考了大規(guī)模應(yīng)用的設(shè)計(jì)、構(gòu)建和維護(hù)方式。它們帶來(lái)了許多好處，但也帶來(lái)了新的挑戰(zhàn)。當(dāng)我們把這五個(gè)主要挑戰(zhàn)放在一起看時(shí)，我們可以看到它們都源于同一個(gè)理念。因此，每當(dāng)采用像微服務(wù)這樣的新技術(shù)時(shí)，底線是既需要重新思考，也需要重新調(diào)整代碼的構(gòu)建、部署和觀察方式。微服務(wù)所帶來(lái)的優(yōu)勢(shì)是難以拒絕的——但風(fēng)險(xiǎn)也是巨大的。

當(dāng)前題目：5個(gè)規(guī)則，確保你的微服務(wù)優(yōu)化運(yùn)行
本文地址：http://jinyejixie.com/news/103962.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、App設(shè)計(jì)、虛擬主機(jī)、網(wǎng)站設(shè)計(jì)公司、ChatGPT、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)