讓生產(chǎn)環(huán)境微服務(wù)更流暢的方式有哪些

這篇文章主要介紹“讓生產(chǎn)環(huán)境微服務(wù)更流暢的方式有哪些”，在日常操作中，相信很多人在讓生產(chǎn)環(huán)境微服務(wù)更流暢的方式有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”讓生產(chǎn)環(huán)境微服務(wù)更流暢的方式有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

微服務(wù)的另一面

關(guān)注點(diǎn)分離并不是什么新概念，分布式計(jì)算也不是。優(yōu)勢很明顯，但是它們的代價通常是時間和金錢上更高的運(yùn)維成本。將這兩者混合在一起，就會遇到所有類型的問題。將其上生產(chǎn)環(huán)境，問題會變成四倍。調(diào)試修復(fù)，但是等一下——

調(diào)試并不能讓問題消失。

就像Bryan Cantrill在其QCon演講里所指出的，“調(diào)試已經(jīng)退化成了口頭傳說，期望問題能夠神話般消失。”事實(shí)上，調(diào)試更像一門科學(xué)，要理解系統(tǒng)是如何工作的，而不是我們認(rèn)為它是如何工作的。

調(diào)試不僅僅是微不足道的邊緣任務(wù)，而是個根本性問題。Sir Maurice Wilkes，創(chuàng)造出首批程序之一的調(diào)試者，那時候就已經(jīng)認(rèn)識到調(diào)試會成為開發(fā)人員需要承擔(dān)的主要職責(zé)。

“在開始編程的1949年，我們驚訝地發(fā)現(xiàn)讓程序像我們認(rèn)為地那樣工作并不容易。必須找到調(diào)試方法。我還能記得那一刻，我意識到從今之后我生命的很大一部分會花在尋找自己編寫的程序的錯誤上?！?/p>

我們曾經(jīng)認(rèn)為這是為了解決問題。但是實(shí)際挑戰(zhàn)是要理解系統(tǒng)到底是如何工作的。

問題#1：如果監(jiān)控單體應(yīng)用還不夠困難

無論你是逐步將單體應(yīng)用分解成微服務(wù)，還是從頭構(gòu)建一個新系統(tǒng)，現(xiàn)在你都有更多的服務(wù)需要監(jiān)控。每個都很有可能：

• 使用不同的技術(shù)/語言

• 在不同機(jī)器/容器里

• 有自己的版本

要點(diǎn)是智慧地監(jiān)控，系統(tǒng)是高度碎片化的，迫切需要中央化監(jiān)控和日志，才能夠理解到底發(fā)生了什么事情。

比如，在最近持續(xù)討論播客描述的一個場景里是需要回滾的差版本。這是單體應(yīng)用最直接的方式。但是——現(xiàn)在我們有微服務(wù)了。因此需要確定哪個服務(wù)需要回滾，這樣的回滾對其他服務(wù)會有什么影響，或者可能只是需要添加一些功能，但是也可能就直接將問題推到另一個服務(wù)里。

要點(diǎn)#1：如果你認(rèn)為監(jiān)控單體架構(gòu)很難，那么微服務(wù)會更難10倍，并且需要預(yù)先計(jì)劃更多的投資。

問題#2：日志分布在服務(wù)間

日志 日志 日志。服務(wù)器每天都會產(chǎn)生數(shù)GB的非結(jié)構(gòu)化文本。IT界和二氧化碳排放等價的東西，是溢出的硬盤和瘋狂的Splunk賬單/ELK存儲費(fèi)用。另外，如果想學(xué)習(xí)Splunk或者ELK，可以看看我們最新的電子書：《Splunk vs ELK：日志管理工具決策指導(dǎo)》。

在單體架構(gòu)下，日志很可能已經(jīng)分散在不同的地方，單體思維里就得使用日志記錄在不同地方的幾層設(shè)計(jì)。在微服務(wù)里 - 日志更加分散?，F(xiàn)在當(dāng)研究一些用戶事務(wù)相關(guān)的場景時，不得不從所有可能使用到的服務(wù)那里將所有的不同日志收集到一起，才能理解什么地方出錯了。

在Takipi里，我們的團(tuán)隊(duì)通過使用Takipi解決這樣的問題。對于來自生產(chǎn)JVM里的所有日志錯誤或者報警，我們在日志里注入了可以指引事件分析的鏈接。包括每一幀完整的stack trace和變量狀態(tài)，即使它們分布在一定數(shù)量的服務(wù)/機(jī)器上。

要點(diǎn)#2：微服務(wù)是指將東西分解成單個組件。這么做的副作用是，運(yùn)維和監(jiān)控也隨之分解到每個服務(wù)里，并且失去了作為整體的系統(tǒng)的力量。這里的挑戰(zhàn)是使用合適的工具重新將這些中央化。

問題#3：一個服務(wù)導(dǎo)致的問題，會造成其他地方的問題

如果跟蹤某個特定服務(wù)的故障事務(wù)，你無法保證正在查看的服務(wù)就是出問題的地方。假定服務(wù)間有一些消息傳遞機(jī)制，比如RabbitMQ、ActiveMQ或者可能使用的是Akka。
 

即使服務(wù)行為正常，沒有找到什么問題，也可能會發(fā)生如下場景：

• 它接收到的輸入是錯的，那么你需要理解是什么導(dǎo)致前一個服務(wù)的異常行為

• 其結(jié)果的接收方返回了一些異常響應(yīng)，那么你需要理解下一個服務(wù)是如何工作的

• 如果這些依賴條件比1:1更加復(fù)雜會如何？或者多個服務(wù)受益于該問題呢？

無論問題是什么，微服務(wù)下的第一步都是要知道從哪里開始尋找答案。數(shù)據(jù)完全分散，很有可能完全不在日志和儀表盤里。
 

要點(diǎn)#3：單體應(yīng)用里，你通常能夠知道檢查的方向是正確的，微服務(wù)讓理解問題的來源在哪里，以及應(yīng)該到哪里得到數(shù)據(jù)變得更加困難。

問題#4：找到問題的根本原因

好的，讓我們繼續(xù)調(diào)查。現(xiàn)在的出發(fā)點(diǎn)是我們已經(jīng)找到了有問題的服務(wù)，拿到了需要的數(shù)據(jù)，從日志里找到了stack trace和一些變量值。如果使用的是APM（就像New Relic、AppDynamics或者Dynatrace，我們也有文章介紹，在這里和這里），你可能還得到其他一些數(shù)據(jù)，有關(guān)一些方法的高速處理時間/對問題的嚴(yán)重性做了一些基本的評估。

但是——實(shí)際問題是什么呢？真正的根本原因？要找到實(shí)際出錯的代碼。

大多數(shù)情況下，從日志里首先得到的變量數(shù)據(jù)并不是真正需要的數(shù)據(jù)。它們通常指到下一個線索，要求你發(fā)現(xiàn)更多的真相，并且添加更多的日志聲明。部署變更，期望問題能夠重現(xiàn)，或者不重現(xiàn)，因?yàn)椤袝r候僅僅添加一條日志聲明似乎就能解決問題。

要點(diǎn)#4：當(dāng)某個微服務(wù)的根本原因影響多個服務(wù)時，有可用的中央化根本原因檢測工具至關(guān)重要。如果你使用Java/其他JVM語言，一定要來看看我們Takipi是怎么做的。

Takipi的錯誤分析儀表盤——每一幀的變量值放在實(shí)際代碼之上

問題#5：版本管理和服務(wù)間的循環(huán)依賴

持續(xù)討論博客里提到的另一個問題是從典型單體架構(gòu)的單層模型到微服務(wù)的圖模型。
 

這里可能發(fā)生的兩個問題和依賴有關(guān)。

1. 如果在服務(wù)間存在循環(huán)依賴，當(dāng)某個事務(wù)可能死鎖在循環(huán)里時，就會出現(xiàn)溢出錯誤。

2. 如果兩個服務(wù)共享某個依賴，并且你以會影響它們的方式更新了其他服務(wù)的API，那么就需要一次更新所有這三個服務(wù)。這會帶來這樣的問題，你應(yīng)該先更新哪個？怎么才能讓這樣的更新平穩(wěn)過渡？

更多的服務(wù)意味著每個服務(wù)都有不同的發(fā)布周期，大大增加了這里的復(fù)雜度。當(dāng)問題在一個版本消失，在新版本又出現(xiàn)時，重現(xiàn)問題就會很復(fù)雜。
 

要點(diǎn)#5：在微服務(wù)架構(gòu)里，你更容易遇到依賴相關(guān)的問題。

到此，關(guān)于“讓生產(chǎn)環(huán)境微服務(wù)更流暢的方式有哪些”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！